Votre contrôleur de domaine est resté isolé au‑delà de la Tombstone Lifetime ? Ce guide opérationnel vous aide à choisir la bonne approche, éviter les lingering objects et remettre le service en sécurité, avec procédures pas à pas, scripts et check‑lists.
Vue d’ensemble du problème
Lorsqu’un contrôleur de domaine (DC) ne réplique plus pendant une durée supérieure à la Tombstone Lifetime (par défaut 180 jours à partir de Windows Server 2003 SP1 ; 60 jours sur les versions antérieures ou si la valeur n’a jamais été modifiée), Active Directory bloque la réplication entrante et sortante. L’objectif est d’empêcher la réintroduction d’objets obsolètes appelés lingering objects. Le DC en dépassement est marqué comme périmé et doit être remis en conformité avant toute reprise de service.
Signes et messages typiques
- Événements Annuaire : 2042 (« trop longtemps sans répliquer »), 2095 (protection contre la réintroduction d’objets), 1988 (détection d’objets persistants).
- Erreurs
repadmin
: code 8614 (« la durée depuis la dernière réplication a dépassé la tombstone lifetime »), refus de réplication entrante/sortante. - Alertes de l’Observateur d’événements sur la cohérence USN et sur des partitions non synchronisées.
Avant de commencer
- Isoler le DC en dépassement (désactiver ses cartes réseau ou le mettre hors ligne) pour éviter toute réplication accidentelle avant nettoyage.
- Confirmer l’état du ou des DC sains :
dcdiag /v repadmin /replsummary repadmin /showrepl *
- Vérifier la valeur de la Tombstone Lifetime (et, si la Corbeille AD est activée, la durée des objets supprimés) :
dsquery * "CN=Directory Service,CN=Windows NT,CN=Services, CN=Configuration,DC=exemple,DC=com" -attr tombstoneLifetime # PowerShell (si module AD installé) Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=exemple,DC=com" ` -Properties tombstoneLifetime,msDS-DeletedObjectLifetime | Format-List tombstoneLifetime,msDS-DeletedObjectLifetime
- Strict Replication Consistency : s’assurer qu’elle est activée sur les DC sains (c’est le cas par défaut depuis 2003 SP1). Contrôle rapide :
reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v StrictReplicationConsistency
- Ne jamais restaurer un instantané ancien d’une VM DC : risque d’USN rollback. Préférez toujours une restauration système autoritaire/non autoritaire à partir d’une sauvegarde valide < Tombstone Lifetime.
Choisir l’approche la plus sûre
La voie la plus simple et la plus sûre consiste à reconstruire le DC à partir d’un DC sain existant. Les procédures de purge ne s’envisagent que si la reconstruction est impossible (site isolé, contraintes fortes, configurations spécifiques).
Approche | Quand l’utiliser | Étapes principales | Avantages / Inconvénients |
---|---|---|---|
Démonter puis reconstruire le DC (recommandé) | Au moins un autre DC sain existe dans le domaine | 1) Transférer/saisir les rôles FSMO si nécessaire. 2) Démotion forcée ( dcpromo /forceremoval ou cmdlets PowerShell).3) Nettoyage des métadonnées (NTDSUTIL ou outils graphiques). 4) Rejoindre le domaine et promouvoir à neuf. | + Zéro propagation d’objets obsolètes. – Demande une reconstruction. |
Purger les objets persistants puis réactiver la réplication | Vous devez absolument conserver ce DC (site distant, contraintes, bande passante, configuration locale) | 1) Lister et supprimer les lingering objects depuis un DC sain (repadmin /removelingeringobjects ).2) Réactiver prudemment la réplication ( repadmin /options ). | + Pas de réinstallation. – Procédure délicate ; risque si des objets corrompus subsistent. |
Forcer la réplication sans nettoyage (non recommandé) | Cas d’extrême urgence, aucune sauvegarde exploitable, impossibilité de reconstruire | Réactiver la réplication sans purge (repadmin /options ), forcer une synchro. | + Rapidité. – Risque majeur d’incohérences irréversibles. |
Démontage puis reconstruction du contrôleur de domaine
Transférer/saisir les rôles FSMO (si détenus par le DC isolé)
Depuis un DC sain :
netdom query fsmo
# PowerShell : identifier les rôles
Get-ADDomain | Format-List PDCEmulator,RIDMaster,InfrastructureMaster
Get-ADForest | Format-List SchemaMaster,DomainNamingMaster
# Transférer (si le DC isolé est encore joignable)
Move-ADDirectoryServerOperationMasterRole -Identity "NomDCSain" `
-OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster -Confirm:$false
# Saisir (si le DC isolé est définitivement indisponible)
ntdsutil "roles" "connections" "connect to server NomDCSain" q ` "seize schema master" "seize naming master" "seize rid master"`
"seize pdc" "seize infrastructure master" q q
Démotion forcée du DC dépassé
Sur le serveur concerné :
- Windows Server 2012 et ultérieur :
Uninstall-ADDSDomainController -ForceRemoval ` -LocalAdministratorPassword (Read-Host -AsSecureString "Mot de passe admin local") ` -DemoteOperationMasterRole:$true -Force
- Versions antérieures :
dcpromo /forceremoval
Le serveur redevient membre autonome. Ne le rebranchez pas encore au réseau de production tant que le nettoyage n’est pas terminé.
Nettoyage des métadonnées et de DNS
- NTDSUTIL depuis un DC sain :
ntdsutil "metadata cleanup" "connections" "connect to server NomDCSain" q ` "select operation target" "list domains" "select domain <index>" ` "list sites" "select site <index>" "list servers in site" ` "select server <index>" q "remove selected server" q q
- Sites et Services AD : supprimer l’objet NTDS Settings résiduel du serveur retiré.
- Utilisateurs et Ordinateurs AD : supprimer/renommer l’objet ordinateur si nécessaire.
- DNS : purger les enregistrements SRV/host obsolètes du DC (zones
_msdcs
,DomainDnsZones
,ForestDnsZones
).
Rejoindre et promouvoir le serveur reconstruit
- Réinstaller l’OS si nécessaire, corriger l’horloge (NTP), configurer l’IP et les DNS pointant vers des DC sains.
- Joindre le domaine, puis installer AD DS :
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools Install-ADDSDomainController -Credential (Get-Credential) ` -DomainName "exemple.com" -SiteName "Site-Exemple"` -InstallDns:$true -NoGlobalCatalog:$false ` -DatabasePath "C:\Windows\NTDS" -LogPath "C:\Windows\NTDS" -SysvolPath "C:\Windows\SYSVOL"
- Validation post‑promotion :
dcdiag /v repadmin /replsummary repadmin /showrepl *
Purger les lingering objects puis réactiver la réplication
À réserver aux cas où le DC doit impérativement être conservé (site sans accès rapide, services locaux, configurations matérielles spécifiques). La logique : bloquer la réplication du DC périmé, purger tous les objets divergents en se basant sur un DC de référence sain, puis relancer la réplication.
Préparation
- Sur le DC isolé, s’assurer que la réplication est désactivée :
repadmin /options NomDCIsolé +DISABLE_INBOUND_REPL +DISABLE_OUTBOUND_REPL
- Identifier un DC de référence parfaitement sain (NomDCRef) et collecter son DSA GUID :
repadmin /showrepl NomDCRef # Le GUID du "NTDS Settings" du DC de référence sera utilisé ci‑dessous
- Recenser les naming contexts à traiter (exécuter la purge pour chacun) :
DC=exemple,DC=com
(domaine)CN=Configuration,DC=exemple,DC=com
CN=Schema,CN=Configuration,DC=exemple,DC=com
DC=DomainDnsZones,DC=exemple,DC=com
(si présent)DC=ForestDnsZones,DC=exemple,DC=com
(si présent)
Exécuter l’audit puis la purge
Audit (conseillé) : d’abord en mode conseil pour mesurer l’ampleur.
repadmin /removelingeringobjects NomDCIsolé <GUID_Ref> "DC=exemple,DC=com" /advisory_mode
repadmin /removelingeringobjects NomDCIsolé <GUID_Ref> "CN=Configuration,DC=exemple,DC=com" /advisory_mode
repadmin /removelingeringobjects NomDCIsolé <GUID_Ref> "CN=Schema,CN=Configuration,DC=exemple,DC=com" /advisory_mode
repadmin /removelingeringobjects NomDCIsolé <GUID_Ref> "DC=DomainDnsZones,DC=exemple,DC=com" /advisory_mode
repadmin /removelingeringobjects NomDCIsolé <GUID_Ref> "DC=ForestDnsZones,DC=exemple,DC=com" /advisory_mode
Purge effective : relancer les commandes ci‑dessus sans /advisory_mode
.
Réactiver et resynchroniser la réplication
repadmin /options NomDCIsolé -DISABLE_INBOUND_REPL -DISABLE_OUTBOUND_REPL
repadmin /syncall NomDCIsolé /AdeP
repadmin /replsummary
Surveiller l’Observateur d’événements (Directory Service, File Replication Service ou DFS Replication pour SYSVOL selon la version). Toute nouvelle apparition de 1988 doit déclencher une nouvelle purge ciblée.
Forcer la réplication sans nettoyage
Non recommandé. À n’utiliser qu’en connaissance de cause et en dernier recours. Le risque d’introduire des divergences persistantes est élevé.
repadmin /options NomDCIsolé -DISABLE_INBOUND_REPL -DISABLE_OUTBOUND_REPL
repadmin /syncall NomDCIsolé /AdeP
Si cette voie a été empruntée, planifier ensuite une reconstruction contrôlée pour revenir à un état propre.
Vérifications et validation finale
Contrôle | Commande / Attendu | Résultat attendu |
---|---|---|
État global | dcdiag /v | Aucune erreur critique (Fail = 0) sur les tests principaux. |
Réplication | repadmin /replsummary | Erreurs = 0 ; files d’attente faibles ; latence acceptable. |
Topologie | repadmin /showrepl NomDC | Toutes les partitions listées avec dernier succès récent. |
SYSVOL | FRS/DFSR : événements OK, partage SYSVOL présent | Le DC publie NETLOGON et SYSVOL . |
DNS | Enregistrements SRV corrects, résolution des DC | SRV en place dans _msdcs , résolution des noms DC <> adresses IP. |
Scripts utiles
Lister les partitions AD et le DSA GUID d’un DC
# PowerShell
(Get-ADRootDSE).namingContexts
Get-ADObject -LDAPFilter "(objectClass=nTDSDSA)" -SearchBase `
"CN=Configuration,$((Get-ADRootDSE).configurationNamingContext)" `
-Properties objectGUID,distinguishedName |
Select-Object distinguishedName,@{n="DSA_GUID";e={$_.ObjectGUID}}
Vérifier la santé de la réplication sur tout le site
# PowerShell (RSAT AD PowerShell requis)
$servers = (Get-ADDomainController -Filter *).HostName
foreach ($s in $servers) {
Write-Host "=== $s ==="
& repadmin.exe /showrepl $s
}
Aide‑mémoire pour la purge des lingering objects
# À exécuter depuis un DC sain :
$refGuid = "<GUID_Ref>"
$contexts = @(
"DC=exemple,DC=com",
"CN=Configuration,DC=exemple,DC=com",
"CN=Schema,CN=Configuration,DC=exemple,DC=com",
"DC=DomainDnsZones,DC=exemple,DC=com",
"DC=ForestDnsZones,DC=exemple,DC=com"
)
$isolated = "NomDCIsolé"
foreach ($nc in $contexts) {
& repadmin.exe /removelingeringobjects $isolated $refGuid $nc /advisory_mode
}
Erreurs fréquentes et parades
Symptôme | Cause probable | Correctif recommandé |
---|---|---|
8614 lors d’une réplication | Durée de non‑réplication > Tombstone Lifetime | Reconstruction du DC ou purge des lingering objects puis réactivation graduelle. |
Événement 1988 | Objets persistants détectés | Exécuter repadmin /removelingeringobjects sur chaque partition. |
SYSVOL non partagé | FRS/DFSR bloqué après restauration ou purge | Vérifier FRS/DFSR, autoriser la réplication, resynchroniser, corriger les états JRNL/Backlog. |
Enregistrements DNS incohérents | Anciennes IP/SRV conservées | Nettoyage manuel des enregistrements, relancer l’inscription DNS (ipconfig /registerdns ). |
Échec de promotion | Rôles FSMO non disponibles / latence DNS | Contrôler FSMO et DNS, réessayer après résolution des dépendances. |
Checklist express
Avant la remise en service
- Au moins un DC sain validé (
dcdiag
,repadmin
). - Horodatage/NTP corrects sur tous les serveurs.
- Strict Replication Consistency activée.
- Plan clair : reconstruction (recommandée) ou purge (cas particulier).
- Accès administrateur, RSAT, sauvegarde système récente si restauration envisagée.
Après la remise en service
- Réplication OK sur toutes les partitions (
/replsummary
= 0 erreurs). - Publication
SYSVOL
etNETLOGON
confirmée. - SRV DNS corrects, KCC a recalculé la topologie.
- Surveillance en place (journaux, alertes) ; sauvegarde système planifiée < Tombstone Lifetime.
Bonnes pratiques de prévention
- Surveiller la réplication (alertes proactives sur échecs, latences, événements 2042/2095/1988).
- Deux DC minimum par domaine/site pour éviter le point de défaillance unique.
- Sauvegardes système régulières et testées, plus récentes que la Tombstone Lifetime.
- Entretien DNS : nettoyage des enregistrements obsolètes (vieillissement/élimination).
- Procédures de site distant : scripts de purge prêts, documentation locale, accès d’urgence.
- Virtualisation : proscrire les retours à un ancien instantané sur un DC.
FAQ
Faut‑il modifier la Tombstone Lifetime ?
Rares sont les cas où ajuster la valeur est judicieux. Une valeur trop longue retarde le nettoyage des objets supprimés ; trop courte, elle réduit la fenêtre de restauration non autoritaire. Mieux vaut fiabiliser la réplication et les sauvegardes.
La Corbeille AD change‑t‑elle quelque chose ?
Quand elle est activée, l’attribut msDS-DeletedObjectLifetime
régit la durée durant laquelle un objet supprimé est récupérable. Le seuil de blocage de réplication en dépassement reste gouverné par tombstoneLifetime
; contrôlez les deux.
Et pour un RODC ?
La logique reste la même : privilégier la reconstruction. Si purge, traitez aussi la réplication des mots de passe et vérifiez les stratégies locales spécifiques au RODC.
Conclusion
Face à un DC ayant dépassé la Tombstone Lifetime, la stratégie gagnante est la reconstruction complète dès qu’un autre DC sain est disponible : c’est la voie la plus sûre et la plus rapide pour revenir à un état cohérent. La purge des lingering objects est réservée aux environnements contraints et doit être exécutée avec méthode, en contrôlant chaque partition et en validant la réplication avant la remise en production.