Objectif
Identifier la cause réelle d’une réplication Active Directory dégradée en séparant topologie, DNS, réseau/RPC, temps/Kerberos et erreurs de réplication avant toute tentative de réparation intrusive.
Prérequis
- Accès administrateur sur au moins un contrôleur de domaine
- Liste des DC, sites, versions Windows Server et changements récents réseau/DNS.
- Heure approximative du premier échec et code exact retourné par repadmin ou les événements Directory Service.
- Sauvegarde système/AD adaptée avant toute réparation destructive.
Procédure pas à pas
Mesurer l’étendue du problème
Commencez par un résumé forêt pour savoir si le défaut touche un seul partenaire, un site ou plusieurs DC. Notez le delta depuis le dernier succès et les codes d’erreur au lieu de vous limiter à “replication failed”.
repadmin /replsummaryrepadmin /showrepl * /csv > C:Tempshowrepl.csv- Vous identifiez les DC sources/destinations, le nombre d’échecs et le dernier succès.
Examiner les partenaires du DC affecté
Sur le DC en anomalie, listez chaque partition et son partenaire entrant. Relevez le code Win32/AD exact : 5, 1722, 1256, 8452, 8464, 8589, etc. Le code oriente la suite du diagnostic.
repadmin /showreplrepadmin /showrepl /verbose- Un code d’erreur précis et un partenaire sont identifiés pour chaque partition en défaut.
Valider DNS avant tout
AD DS dépend fortement du DNS pour localiser les partenaires via les enregistrements SRV et GUID. Vérifiez la configuration DNS du DC, la résolution de son propre nom et du partenaire, puis testez le diagnostic DNS de dcdiag.
ipconfig /allResolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.contoso.localdcdiag /test:dns /v- Les DC utilisent les DNS AD attendus et les enregistrements SRV/GUID se résolvent correctement.
Contrôler réseau, RPC et temps
Une erreur de réplication peut venir du réseau, de RPC ou de Kerberos. Vérifiez la connectivité vers le partenaire et l’état du temps. Un écart important de temps peut empêcher l’authentification Kerberos même si le ping fonctionne.
Test-NetConnection DC02.contoso.local -Port 135w32tm /query /statusw32tm /query /source- Le port RPC endpoint mapper est joignable et la source de temps est cohérente.
Exécuter les tests AD ciblés
Utilisez dcdiag pour les réplications et les services clés. Ne vous arrêtez pas à un test global : les détails indiquent souvent le naming context ou le service qui échoue.
dcdiag /test:replications /vdcdiag /test:services /vdcdiag /test:advertising /v- Les tests en échec correspondent aux symptômes observés dans repadmin.
Vérifier la topologie de sites
Confirmez que les DC sont dans les bons sites, que les subnets correspondent au réseau réel et que les site links relient réellement les emplacements. Une topologie AD sans équivalent WAN/VPN peut produire des partenaires impossibles à joindre.
Get-ADReplicationSite -Filter * | Select-Object NameGet-ADReplicationSubnet -Filter * | Select-Object Name,SiteGet-ADReplicationSiteLink -Filter * | Select-Object Name,Cost,ReplicationFrequencyInMinutes,SitesIncluded- Les sites et liens correspondent à la connectivité réelle.
Corriger une cause à la fois puis retester
Appliquez la correction directement liée au code identifié : DNS, firewall/RPC, compte machine, temps, site link, service arrêté. Après correction, relancez d’abord showrepl/replsummary. Une synchronisation manuelle ne doit servir qu’à valider une topologie redevenue saine.
repadmin /kccrepadmin /syncall /AdeP- Le nombre d’échecs diminue et un nouveau succès de réplication est enregistré.
Note : N’utilisez /syncall qu’après avoir rétabli les dépendances. Dans un incident complexe, une réplication forcée non comprise peut compliquer le diagnostic.
Surveiller la convergence
Une fois les erreurs corrigées, surveillez plusieurs cycles et comparez les dernières heures de succès. Vérifiez également SYSVOL/GPO et les événements Directory Service afin de confirmer qu’il ne reste pas une seconde cause.
repadmin /replsummaryGet-WinEvent -LogName "Directory Service" -MaxEvents 100 | Where-Object LevelDisplayName -in "Error","Warning" | Select-Object TimeCreated,Id,Message- Tous les DC attendus répliquent et aucune erreur récurrente n’apparaît.
Validation
La procédure est validée lorsque :
- repadmin /replsummary ne montre plus d’échec persistant sur les DC en service.
- repadmin /showrepl indique un dernier succès récent pour les partitions concernées.
- dcdiag /test:replications et les tests DNS/Services sont cohérents avec un environnement sain.
- Les journaux Directory Service ne montrent plus la même erreur après plusieurs cycles de réplication.
Retour arrière
- Si une modification réseau/DNS a aggravé la situation, restaurer la configuration documentée avant l’intervention.
- Annuler une modification de site/site link si elle a créé un partenaire impossible à joindre.
- Si le DC reste irrécupérable, planifier une démotion/reconstruction propre selon la procédure dédiée plutôt que supprimer des objets au hasard.
Dépannage / erreurs fréquentes
- Erreur 1722/RPC : examiner réseau, firewall, résolution DNS et services RPC.
- Erreur 5/Access denied : contrôler authentification du compte machine, canal sécurisé, temps et sécurité AD.
- Erreur 8452 : vérifier que la source est réellement partenaire pour le naming context demandé.
- Erreur liée au tombstone lifetime : ne réactivez pas simplement la réplication ; suivez la procédure Microsoft spécifique au code et évaluez la reconstruction du DC.