Problème d'incohérence des stratégies de groupe (Group Policy) entre les contrôleurs de domaine

Question

Problème d'incohérence des stratégies de groupe (Group Policy) entre les contrôleurs de domaine

Jacob Kirin 0

Je souhaite synchroniser les configurations sur l'ensemble des stations de travail Windows de l'entreprise, mais chaque fois que ces machines se connectent à un contrôleur de domaine (Domain Controller) différent, je constate un comportement incohérent des stratégies de groupe, ce qui m'empêche de gérer le système correctement. Veuillez m'indiquer comment résoudre ce problème.

Comment puis-je vérifier l'état de la réplication SYSVOL et identifier la version faisant autorité (authoritative version) de la stratégie ?

0 commentaires

1 réponse

Votre réponse

Answer 1

Bonjour Jacob Kirin,

Pour identifier la version faisant autorité de vos stratégies, vous devez consulter l'émulateur de contrôleur de domaine principal (PDC Emulator), car ce serveur agit comme la cible par défaut pour toutes les modifications de stratégie de groupe. Vous pouvez déterminer quel serveur détient ce rôle en exécutant netdom query fsmo dans une invite de commandes avec privilèges élevés. Une fois que vous avez identifié l'émulateur PDC, connectez-vous à celui-ci, accédez à C:\Windows\SYSVOL\sysvol\votredomaine\Policies, et ouvrez le dossier correspondant au GUID de votre stratégie. Inspectez le fichier GPT.ini dans ce dossier. Le numéro de version contenu dans ce fichier texte représente l'état réel et faisant autorité de la stratégie, que vous pouvez utiliser pour auditer les fichiers GPT.ini sur vos autres contrôleurs de domaine afin de prouver qu'ils distribuent des données obsolètes.

Pour vérifier l'état exact de votre réplication SYSVOL, lancez une session PowerShell avec privilèges élevés et exécutez l'applet de commande Get-DfsrState pour afficher immédiatement l'état de santé des connexions et les fichiers en attente (backlogs) entre vos partenaires de réplication. Vous pouvez également exécuter la commande dfsrdiag backlog pour quantifier exactement combien de fichiers ne parviennent pas à être transférés. De plus, inspectez le journal des événements de réplication DFS pour détecter des erreurs critiques telles que l'Event ID 4012 ou 5014, qui signalent une corruption de la base de données ou une topologie interrompue. Si la base de données est irrécupérable, vous devez effectuer une synchronisation DFSR faisant autorité à l'aide d'ADSI Edit, une procédure administrative qui désigne l'émulateur PDC comme source principale et force tous les autres contrôleurs de domaine à effacer leurs répertoires SYSVOL locaux et à les reconstruire à partir de zéro.

J'espère que cette réponse vous a apporté des informations utiles. Si c'est le cas, veuillez cliquer sur « accepter la réponse » (accept answer). Si vous avez des questions, n'hésitez pas à laisser un commentaire.

VPHAN