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:DNSOK. - SYSVOL : le partage
SYSVOLest 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(ouFRSsi 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 "" -ForceVérifiez aussi les enregistrementsA/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 /vContrôlez également :
- SYSVOL : le partage
SYSVOLest accessible. En DFSR, l’événement 4012 doit disparaître après correction et « non‑authoritative restore » si nécessaire. - RID :
dcdiag /test:RidManager /vdoit ê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:$falseAprès promotion :
- Contrôlez
dcdiag/repadminentre 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 * +strictTests DNS intégrés
dcdiag /test:DNS /e /vCas 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 /replsummaryquotidien, 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 `
-ForceNettoyage 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 /vConclusion
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