Active Directory : tombstone lifetime dépassé entre deux DC — guide de survie, nettoyage et restauration

Deux contrôleurs de domaine Active Directory ont cessé de répliquer au‑delà de la tombstone lifetime. Voici un guide opérationnel pour conserver le bon DC, nettoyer l’autre et rétablir rapidement une réplication saine — sans perdre le domaine.

Sommaire

Vue d’ensemble : que se passe‑t‑il lorsque deux DC « tombstonent » ?

Dans un domaine avec seulement deux contrôleurs de domaine (DC), une interruption de réplication plus longue que la durée de vie du tombstone (tombstone lifetime) a deux effets majeurs :

Chacun des DC considère l’autre comme trop obsolète et refuse ses objets (« lingering objects », objets persistants).
Les contrôles d’intégrité AD bloquent la réplication entrante depuis le partenaire « vieux », entraînant des erreurs 2042/1988 dans l’Observateur d’événements et des échecs repadmin.

Bonne nouvelle : le domaine n’est pas « perdu ». Si au moins un DC est fiable, vous pouvez sauver l’environnement en choisissant un DC de référence, nettoyant les métadonnées de l’autre puis en recréant un DC sain.

Rappels rapides (pour décider vite)

Tombstone lifetime : durée pendant laquelle les suppressions sont conservées comme « tombstones » pour éviter la résurrection d’objets supprimés. Par défaut, 180 jours dans les forêts créées sur des versions modernes (les forêts plus anciennes peuvent être restées à 60 jours).
Lingering objects : objets devenus « orphelins » car un DC n’a pas reçu à temps la suppression. Un DC strict ne les acceptera pas.
Strict Replication Consistency (SRC) : mécanisme qui empêche l’introduction d’objets obsolètes lors d’une reprise de réplication. Il doit être activé.
Deux DC seulement : pas de tiers « arbitre », donc une rupture prolongée conduit quasi mécaniquement à la situation « deux versions de la vérité ».

Réponse courte & stratégie

Oui, vous pouvez choisir un DC à garder, éliminer logiquement l’autre (metadata cleanup), puis promouvoir un nouveau DC depuis le survivant pour restaurer la redondance. Évitez de forcer une réplication entre deux DC tombstonés : vous risqueriez d’introduire des objets persistants.

Playbook en 7 étapes (résumé)

Étape	Action	Objectif / Détails
Sélection du DC de référence	Choisir le DC dont les données sont les plus fiables (dernier à servir les utilisateurs, cohérence DNS/SYSVOL, détenteur actuel ou destiné des rôles FSMO).	Point de départ sain.
Vérification & sécurisation	Démarrage sans erreurs AD/DNS, journaux propres, activer Strict Replication Consistency.	Éviter l’introduction d’objets obsolètes.
Saisie éventuelle des rôles FSMO	Si les rôles sont détenus par le DC à retirer : `ntdsutil` ou PowerShell pour les seize.	Garantir l’unicité des rôles.
Metadata cleanup	Supprimer proprement le DC défaillant (objets NTDS Settings, compte d’ordinateur, enregistrements DNS SRV).	Retirer toute trace du DC tombstoné.
Tests de santé	`dcdiag`, `repadmin`, diagnostics DNS, état de SYSVOL.	Confirmer l’état « vert ».
Reprise de production	Servir les clients avec le DC unique.	Continuité de service.
Restauration de la redondance	Promouvoir un nouveau DC (ou réinstaller l’ancien) et le joindre au domaine.	Retrouver tolérance de panne.

Procédure détaillée pas à pas

1. Choisir le DC de référence (celui que l’on garde)

Critères concrets :

Les utilisateurs se sont authentifiés récemment dessus ? Les partages et GPO y sont cohérents ?
Le journal Directory Service ne présente pas d’erreurs critiques récurrentes (USN rollback, base NTDS corrompue) ?
DNS : zones AD‑intégrées présentes et résolues, dcdiag /test:DNS OK.
SYSVOL : le partage SYSVOL est présent, les scripts de démarrage et GPO sont visibles.

Astuce décisionnelle

Symptôme	Garder ce DC ?	Pourquoi
Événements 2042/1988, mais DNS/SYSVOL cohérents, clients OK	Oui	Les erreurs proviennent de la coupure longue, pas d’une corruption locale.
Événements de type USN rollback, base NTDS douteuse	Non	Risque d’incohérences profondes, préférez l’autre DC si possible.
DNS manquant ou incohérent	À évaluer	DNS est critique : une correction est envisageable si le reste est sain.

2. Sécuriser le DC conservé

Vérifiez les services : NTDS, Netlogon, DNS, DFSR (ou FRS si très ancien).
Forcer Strict Replication Consistency : repadmin /regkey <NomDuDC> +strict (ou registre : HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency = 1)
Contrôler l’horloge du PDC Emulator (service temps) : w32tm /query /status w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update net stop w32time && net start w32time

3. Gérer les rôles FSMO si nécessaire

Si le DC que vous retirez détient encore des rôles FSMO et qu’il est irrécupérable, saisissez (seize) les rôles sur le DC conservé.

Rôle FSMO	Vérifier	Basculer (PowerShell)
Schema Master	`Get-ADForest \| Select SchemaMaster`	`Move-ADDirectoryServerOperationMasterRole -Identity <DC> SchemaMaster -Force`
Domain Naming Master	`Get-ADForest \| Select DomainNamingMaster`	`Move-ADDirectoryServerOperationMasterRole -Identity <DC> DomainNamingMaster -Force`
PDC Emulator	`Get-ADDomain \| Select PDCEmulator`	`Move-ADDirectoryServerOperationMasterRole -Identity <DC> PDCEmulator -Force`
RID Master	`Get-ADDomain \| Select RIDMaster`	`Move-ADDirectoryServerOperationMasterRole -Identity <DC> RIDMaster -Force`
Infrastructure Master	`Get-ADDomain \| Select InfrastructureMaster`	`Move-ADDirectoryServerOperationMasterRole -Identity <DC> InfrastructureMaster -Force`

Alternative (console) : ntdsutil roles seize <rôle>.

4. Nettoyer les métadonnées du DC à retirer

Ne jamais se contenter de dcpromo /forceremoval sur l’ancien DC : il faut nettoyer la forêt pour éviter des « fantômes ». Depuis le DC survivant :

Metadata cleanup (au choix) : ntdsutil "metadata cleanup" "connections" "connect to server <DCConserve>" quit "select operation target" "list domains" "select domain <ID>" "list sites" "select site <ID>" "list servers in site" "select server <IDDuDCAretirer>" quit "remove selected server" quit quit …ou en PowerShell (attention aux GUIDs) : # Suppression de l'objet NTDS Settings du DC retiré $ntds = Get-ADObject -LDAPFilter "(objectClass=nTDSDSA)" -SearchBase "CN=Servers,..." -Properties objectGUID | ? {$_.Name -like "NTDS Settings"} Remove-ADObject -Identity $ntds -Confirm:$false -Recursive
DNS : purger les enregistrements SRV pour que les clients n’appellent plus l’ancien DC. # Exemple PowerShell avec DNSServer Get-DnsServerResourceRecord -ZoneName "_msdcs.<domaine>" | ` ? {$_.RecordData.HostNameAlias -like "*<AncienDC>*"} | ` Remove-DnsServerResourceRecord -ZoneName "_msdcs.<domaine>" -Force Get-DnsServerResourceRecord -ZoneName "" | ` ? {$_.HostName -eq "<AncienDC>"} |` Remove-DnsServerResourceRecord -ZoneName "" -Force Vérifiez aussi les enregistrements A/AAAA, _ldap._tcp, _kerberos._tcp, _gc._tcp.
Sites et services AD : supprimez l’objet Server résiduel dans le bon site, ainsi que les Connection Objects associés.

5. Assainir objets persistants (si nécessaire)

Si vous suspectez des lingering objects (événements 1988, erreurs de réplication ciblées), vous pouvez exécuter :

# Audit des lingering objects (mode conseil)
repadmin /removelingeringobjects <DCSain> <GuidSource> "<NC DN>" /advisory_mode

# Suppression effective (à exécuter uniquement si validé)

repadmin /removelingeringobjects   ""

NC DN correspond par exemple à DC=contoso,DC=com ou CN=Configuration,DC=contoso,DC=com.

6. Vérifier l’état de santé (avant retour en production)

dcdiag /v
repadmin /replsummary
repadmin /showrepl *
dcdiag /test:DNS /e /v

Contrôlez également :

SYSVOL : le partage SYSVOL est accessible. En DFSR, l’événement 4012 doit disparaître après correction et « non‑authoritative restore » si nécessaire.
RID : dcdiag /test:RidManager /v doit être OK.
Journaux : pas d’erreur critique récurrente.

7. Promouvoir un nouveau DC (restauration de la redondance)

Préparez un serveur Windows Server à jour, joignez‑le au domaine, installez le rôle Active Directory Domain Services et promouvez‑le en DC. Exemple :

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSDomainController -DomainName "contoso.com" -InstallDns -NoRebootOnCompletion:$false

Après promotion :

Contrôlez dcdiag/repadmin entre les deux DC.
Vérifiez la réplication DFSR de SYSVOL (ou FRS si héritage : envisagez sa migration vers DFSR).
Redistribuez/validez les rôles FSMO si souhaité.

Gestion de SYSVOL : DFSR vs FRS

DFSR (recommandé) et FRS (ancien) ne se traitent pas de la même façon en cas de reprise :

Technologie	Symptômes fréquents	Action type
DFSR	Événement 4012/2213, réplication suspendue	Non‑authoritative restore du dossier SYSVOL sur le nouveau DC, redémarrage de DFSR, `dfsrdiag pollad`.
FRS	BurFlags requis	Utiliser les valeurs `D2`/`D4` (non/autoritative) après sauvegarde. Planifier la migration vers DFSR.

Contrôles & commandes utiles (prêt‑à‑copier)

Inspecter la tombstone lifetime

# PowerShell (Module ActiveDirectory)
$ds = (Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com" -Properties tombstoneLifetime)
$ds.tombstoneLifetime  # Null = valeur par défaut (selon version/époque de création)

État de la réplication

repadmin /replsummary
repadmin /showrepl *
repadmin /showvector /latency * "DC=contoso,DC=com"
repadmin /showutdvec <DCSain> "DC=contoso,DC=com"

Activer SRC sur tous les DC actuels

repadmin /regkey * +strict

Tests DNS intégrés

dcdiag /test:DNS /e /v

Cas limites & options avancées

Incohérences lourdes (comptes, GPO, OU divergentes) : examinez les journaux de changement, exportez les objets des deux côtés (LDIF/PowerShell), comparez, et statuez avant de choisir le DC à garder. Si l’historique du « mauvais » DC est préférable, partez de lui et nettoyez l’autre.
Aucun DC n’est sain : il reste la restauration à partir d’une sauvegarde du système‑État la plus récente (idéalement du DC PDC Emulator), avec, si nécessaire, une restauration autoritaire d’unités d’organisation/groupes/GPO ciblés. Si aucune sauvegarde n’est exploitable, la ré‑création de la forêt peut être la seule voie.
RODC présents : assurez‑vous qu’ils ne restent pas référencés par le DC supprimé. Purgez leurs métadonnées si l’un d’eux a disparu.
Environnements multi‑domaines : effectuez les nettoyages métadonnées depuis le domaine racine de la forêt en premier, puis dans les domaines enfants.
USN rollback / snapshots hyperviseur : ne restaurez jamais un DC depuis un snapshot VM sans procédure AD dédiée. Préférez le système‑État.

Check‑list « Go/No‑Go »

Contrôle	OK	Si KO
`dcdiag /v` sans erreur critique	✓	Examiner journaux AD DS/DNS, corriger avant de continuer
`repadmin /replsummary` vert entre DCs restants	✓	Revoir SRC, lingering objects, liens sites
Zones DNS AD‑intégrées « Healthy »	✓	Réparer enregistrements SRV/host, nettoyer l’ancien DC
Partage `SYSVOL` disponible	✓	Réparer DFSR/FRS avant promotion d’un nouveau DC
Rôles FSMO sur des DC vivants	✓	Seize sur le DC sain

Mesures préventives (pour ne plus revivre ça)

Surveillance de réplication : automatiser repadmin /replsummary quotidien, alertes sur événements 2042/1988/1311.
Sauvegardes Système‑État de chaque DC, testées et documentées (procédure de restauration).
Deux DC par site physique au minimum (si possible), plus un site d’appoint.
Ne pas rallonger la tombstone lifetime pour masquer des problèmes de réseau : corrigez la cause (lien WAN, firewall, MTU, etc.).
AD Recycle Bin activée pour faciliter la récupération d’objets supprimés.
MCO/DRP : écrivez (et testez) le scénario de seize FSMO et de metadata cleanup.
Migration FRS → DFSR si ce n’est déjà fait, afin de fiabiliser SYSVOL.

FAQ express

Peut‑on « réparer » en rebranchant les deux DC et en attendant ?

Non. Une réplication reprise après dépassement de la tombstone lifetime risque d’introduire des lingering objects. Il faut d’abord choisir un DC de référence, activer SRC, puis nettoyer le reste.

Que faire si des comptes récents existaient des deux côtés ?

Exportez et comparez (CSV/LDIF). Décidez quel côté est la « source de vérité » pour chaque ensemble (utilisateurs, groupes, GPO). Au besoin, procédez à des restaurations autoritaires ciblées.

Faut‑il réinstaller le DC retiré, ou en créer un nouveau ?

Créez de préférence un nouveau serveur (identité machine propre). Vous pouvez réutiliser l’ancien hôte une fois réinstallé, mais ne le remettez pas en service sans nettoyage complet de ses anciennes références.

Changer la tombstone lifetime aide‑t‑il ?

Non pour corriger un incident en cours. C’est un paramètre structurel ; le modifier pour « gagner du temps » reporte le problème et augmente les risques de divergence.

Exemple de plan d’exécution (terrain)

T0 : isolez le DC jugé non fiable (câble réseau / firewall).
T0+15 min : SRC sur le DC survivant, contrôles dcdiag, repadmin, SYSVOL, DNS.
T0+30 min : Seize des rôles FSMO si nécessaire.
T0+45 min : Metadata cleanup du DC retiré, purge DNS SRV.
T0+60 min : Health‑check global, retour en production côté clients.
T0+2 h : promotion d’un nouveau DC, validation dcdiag/repadmin.
T0+J1 : audit lingering objects en advisory, correction si nécessaire, sauvegarde Système‑État des deux DC.

Erreurs courantes à éviter

Réattacher le mauvais DC au réseau « pour voir » : c’est la meilleure manière d’introduire des objets persistants.
Négliger le DNS : même si AD est propre, des vieux SRV peuvent attirer les clients vers un DC supprimé.
Ignorer SYSVOL : AD peut être vert, mais sans GPO/scripts synchronisés vous aurez des symptômes côté postes.
Seize sans évaluer : vérifiez toujours que le DC cible est stable, surtout pour PDC Emulator et RID Master.
Restaurer depuis snapshot VM : cela provoque des USN rollback. Utilisez les sauvegardes Système‑État.

Modèles de commandes (copier/coller) pour l’incident

Basculer tous les rôles FSMO sur le DC survivant

Move-ADDirectoryServerOperationMasterRole -Identity "<DCSain>" `
  SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster `
  -Force

Nettoyage DNS des enregistrements SRV d’un DC supprimé

$dc = "<AncienDC>"
$zones = @("_msdcs.<domaine>","<domaine>")
foreach ($z in $zones) {
  Get-DnsServerResourceRecord -ZoneName $z |
    Where-Object {$_.RecordData.ToString() -match $dc -or $_.HostName -match $dc} |
    Remove-DnsServerResourceRecord -ZoneName $z -Force
}

Vérification rapide santé AD/DNS

dcdiag /c /v
repadmin /replsummary
dcdiag /test:DNS /e /v

Conclusion

Deux DC qui « tombstonent » n’annoncent pas la fin du domaine. En appliquant une méthode stricte — choix d’un DC de référence, activation de la Strict Replication Consistency, metadata cleanup rigoureux, contrôles de santé puis promotion d’un nouveau DC — vous restaurez un Active Directory propre et redondant sans ressusciter d’objets obsolètes. La clé réside dans la discipline d’exécution (ne jamais reconnecter un DC douteux) et dans la prévention (surveillance, sauvegardes, DNS et SYSVOL maîtrisés).

Référence rapide : symptômes → actions

Symptôme	Cause probable	Action immédiate
Événement 2042 : réplication stoppée (tombstone dépassé)	Interruption de réplication > tombstone lifetime	Choisir le DC sain, activer SRC, isoler l’autre DC
Événement 1988 : lingering objects	Objets obsolètes sur un DC	`repadmin /removelingeringobjects` (audit puis suppression)
Clients ciblent un DC supprimé	SRV/host DNS obsolètes	Purge DNS, `dcdiag /test:DNS`
GPO non appliquées	SYSVOL non synchronisé (DFSR/FRS)	Réparer DFSR/FRS, vérifier `SYSVOL` sur chaque DC

Annexe : procédure reproductible (pas de surprise)

Isoler le DC à retirer (déconnexion réseau)
Sur le DC conservé :
- Activer Strict Replication Consistency
- Vérifier dcdiag/repadmin/DNS/SYSVOL
- Seize FSMO si nécessaire
Effectuer le metadata cleanup du DC retiré (AD + DNS + Sites et services)
Valider la santé (dcdiag, repadmin, journal AD DS/DNS)
Remettre en service pour les clients
Promouvoir un nouveau DC depuis le survivant
Stabiliser : vérifier la réplication AD, DFSR SYSVOL, DNS
Sauvegarder le système‑État des deux DC