Problème de synchronisation entre deux contrôleurs de domaine
Résolu
vanderson
-
vanderson -
vanderson -
A voir également:
- Le système ne parvient pas à contacter un contrôleur de domaine
- Restauration systeme windows 10 - Guide
- Cette action ne peut pas être réalisée car le fichier est ouvert dans system - Guide
- Comment refaire le système d'un ordinateur - Guide
- Contacter facebook compte bloqué - Guide
- Contacter vendeur cdiscount - Forum Consommation & Internet
4 réponses
Bonjour,
je serais toi je tenterai de supprimer le rôle de contrôleur de domaine sur le premier puis de le réinstaller pour qu'il reparte sur une bonne base et qu'il se resynchronise correctement avec le deuxième.
je serais toi je tenterai de supprimer le rôle de contrôleur de domaine sur le premier puis de le réinstaller pour qu'il reparte sur une bonne base et qu'il se resynchronise correctement avec le deuxième.
Je pensais à cette solution. Mais je ne l'ai pas encore testé. Je me demande s'il n'y aura pas de répercussion irréversible par la suite.
Par exemple, actuellement j'ai un serveur Kaspersky Sécurity Center qui ne reconnait pas l'ordinateur nouvellement ajouté afin d'y installer l'agent. Il faut pour cela faire la manipulation manuellement. L'ordinateur est vu sur le premier contrôleur ( qui a été "snapshoté") mais pas sur le deuxième contrôleur.
Par exemple, actuellement j'ai un serveur Kaspersky Sécurity Center qui ne reconnait pas l'ordinateur nouvellement ajouté afin d'y installer l'agent. Il faut pour cela faire la manipulation manuellement. L'ordinateur est vu sur le premier contrôleur ( qui a été "snapshoté") mais pas sur le deuxième contrôleur.
Hello,
Les snapshots ne doivent pas être utilisés avec Active Directory. C'est simplement à proscrire et bannir définitivement. Il ne fallait surtout pas faire ça.
Ce n'est d'ailleurs pas une méthode de sauvegarde ou de restauration supportée par Microsoft (ni fonctionnelle d'ailleurs).
Quand tu claques un snapshot de cette manière, tu fous la grouille sur ce qu'on appelle les "USN" et les "Invocation ID" , ça permet au serveur de savoir ce qu'il faut répliquer avec un autre DC.
Ce qui explique pourquoi il ne réplique plus, ça revient à cloner un DC. Si tu fais ça sur une grosse infra, dis toi que c'est très très chaud.
Première chose à faire : coupe ce DC cloné de suite et ne la rallume pas.(et enleve lui la carte réseau dans VMWare) -> il faudra à terme la supprimer de toute façon.
Si tu laisses le DC, les 2 machines vont diverger et ton annuaire ne sera pas sain.
-
La seule solution propre : faut nettoyer ce DC cloné.
! Fais attention aux rôles FSMO, connecte toi sur le second DC et regarde qui détient les rôles :
Si les rôles sont détenus par le serveur qui marche, alors tout va bien.
Si les rôles sont détenus par le DC Cloné, alors il faut forcer le transfert sur le DC propre. (on appelle cela un "Seize")
1. Tu déglingues le DC cloné du snapshot :
- Tu fais un
- Tu reconstruis une machine from scratch et tu en fais un nouveau DC mais avec un nom différent.
2. tu check les réplications :
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Les snapshots ne doivent pas être utilisés avec Active Directory. C'est simplement à proscrire et bannir définitivement. Il ne fallait surtout pas faire ça.
Ce n'est d'ailleurs pas une méthode de sauvegarde ou de restauration supportée par Microsoft (ni fonctionnelle d'ailleurs).
Quand tu claques un snapshot de cette manière, tu fous la grouille sur ce qu'on appelle les "USN" et les "Invocation ID" , ça permet au serveur de savoir ce qu'il faut répliquer avec un autre DC.
Ce qui explique pourquoi il ne réplique plus, ça revient à cloner un DC. Si tu fais ça sur une grosse infra, dis toi que c'est très très chaud.
Première chose à faire : coupe ce DC cloné de suite et ne la rallume pas.(et enleve lui la carte réseau dans VMWare) -> il faudra à terme la supprimer de toute façon.
Si tu laisses le DC, les 2 machines vont diverger et ton annuaire ne sera pas sain.
-
La seule solution propre : faut nettoyer ce DC cloné.
! Fais attention aux rôles FSMO, connecte toi sur le second DC et regarde qui détient les rôles :
netdom query fsmo
Si les rôles sont détenus par le serveur qui marche, alors tout va bien.
Si les rôles sont détenus par le DC Cloné, alors il faut forcer le transfert sur le DC propre. (on appelle cela un "Seize")
1. Tu déglingues le DC cloné du snapshot :
- Tu fais un
METADATA Cleanupavec
NTDSUTILpour supprimer toutes traces du DC cloné.
- Tu reconstruis une machine from scratch et tu en fais un nouveau DC mais avec un nom différent.
2. tu check les réplications :
repadmin /replsum
repadmin /showrepl
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Bonjour @kelux,
Je vais tenter ton approche et je te ferais un retour.
Malheureusement, Le rôle FSMO est sur le DC cloné.
Je vous fais un retour dès que possible.
Cdt.
Je vais tenter ton approche et je te ferais un retour.
Malheureusement, Le rôle FSMO est sur le DC cloné.
Je vous fais un retour dès que possible.
Cdt.
Malheureusement, Le rôle FSMO est sur le DC cloné.
Il faut absolument seize les rôles FSMO avant de faire le metadata cleanup.
Via powershell : Move-ADDirectoryServerOperationMasterRole et le paramètre -force
Il faut absolument seize les rôles FSMO avant de faire le metadata cleanup.
Via powershell : Move-ADDirectoryServerOperationMasterRole et le paramètre -force
Hello,
Pour monter le nouveau contrôleur, change de nom; évite de reprendre l'ancien.
Pour l'adresse IP, tu peux reprendre l'ancienne , pour ça ce n'est pas un souci.
Il y aura probablement du nettoyage à faire sur la configuration des zones DNS (records NS notamment) intégrées à AD.
Idem, vérifier les records dans la zone _msdcs : ceux du DC nettoyé ne doivent plus y être.
Pour monter le nouveau contrôleur, change de nom; évite de reprendre l'ancien.
Pour l'adresse IP, tu peux reprendre l'ancienne , pour ça ce n'est pas un souci.
Il y aura probablement du nettoyage à faire sur la configuration des zones DNS (records NS notamment) intégrées à AD.
Idem, vérifier les records dans la zone _msdcs : ceux du DC nettoyé ne doivent plus y être.