Comment résoudre les problèmes liés aux partages SYSVOL et Netlogon manquants

  • Article

Cet article décrit les étapes à suivre pour résoudre les problèmes liés aux partages et Netlogon manquants SYSVOL dans Windows Server 2012 R2.

S’applique à : Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Numéro de la base de connaissances d’origine : 2958414

Symptômes

SYSVOL les partages et Netlogon ne sont pas partagés sur un contrôleur de domaine. Les symptômes ou conditions suivants peuvent également se produire :

  • Le sysvol dossier est vide.
  • Le contrôleur de domaine affecté a récemment été promu.
  • L’environnement contient des contrôleurs de domaine exécutant des versions de Windows antérieures à Windows Server 2012 R2.
  • La réplication DFS est utilisée pour répliquer le SYSVOL dossier share répliqué.
  • Un amont service de réplication DFS du contrôleur de domaine est dans un état d’erreur.

Cause

Les contrôleurs de domaine sans SYSVOL partagé ne peuvent pas être répliqués entrants, car amont contrôleurs de domaine (source) sont dans un état d’erreur. Souvent (mais sans s’y limiter), les serveurs amont ont arrêté la réplication en raison d’un arrêt sale (ID d’événement 2213).

Résolution

Cette section contient les méthodes recommandées pour résoudre les problèmes et les partages manquants SYSVOLNetlogon sur les contrôleurs de domaine qui sont répliqués à l’aide du service de réplication DFS.

Le processus réinitialise la réplication DFS si SYSVOL n’est pas partagée sur les contrôleurs de domaine selon Comment forcer une synchronisation faisant autorité ou non faisant autorité pour SYSVOL répliqué DFSR (comme « D4/D2 » pour FRS) . Cette opération n’est pas nécessaire dans la plupart des cas et peut entraîner une perte de données si elle est effectuée de manière incorrecte. En outre, il empêche de déterminer la cause du problème et d’éviter les occurrences futures du problème.

Voici des étapes générales pour examiner les partages manquants. Déterminez si le problème est dû à une occurrence unique ou si le ou les contrôleurs de domaine amont ne peuvent pas prendre en charge la réplication à l’aide de la réplication DFS.

La suppression de la base de données de réplication DFS du volume ne doit pas être nécessaire et est déconseillée. La réplication DFS considère toutes les données locales sur le serveur comme non authentifiées. En laissant la réplication DFS récupérer la base de données correctement (comme indiqué dans l’événement 2213), le dernier enregistreur gagne toujours toutes les versions de SYSVOL données en conflit.

Étape 1 : Évaluer l’état de la réplication DFS sur tous les contrôleurs de domaine

Évaluez le nombre de contrôleurs de domaine qui ne partagent SYSVOLpas, qui ont récemment enregistré un événement d’erreur et le nombre de contrôleurs de domaine dans un état d’erreur. Procédez comme suit.

  • Rechercher le SYSVOL partage

    Vous pouvez case activée manuellement si est partagé ou vous SYSVOL pouvez inspecter chaque contrôleur de domaine à l’aide de la commande net view :

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo

  • Vérifier l’état de la réplication DFS

    Pour case activée l’état de la réplication DFS sur les contrôleurs de domaine, vous pouvez interroger WMI. Vous pouvez interroger tous les contrôleurs de domaine du domaine pour le dossier share répliqué à l’aide SYSVOL de WMI comme suit :

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

    Les state valeurs peuvent être :
    0 = Non initialisé
    1 = Initialisé
    2 = Synchronisation initiale
    3 = Récupération automatique
    4 = Normal
    5 = Erreur

    Remarque

    Selon la condition d’un contrôleur de domaine, il peut ne pas pouvoir signaler une valeur d’état et indiquer qu’aucun instance disponible.

  • Vérifier les erreurs ou avertissements récents dans les journaux des événements

    Si des contrôleurs de domaine ne signalent pas le SYSVOL dossier share répliqué comme étant dans un état 4 (normal), case activée le journal des événements de ces contrôleurs de domaine pour évaluer leur état. Examinez chaque contrôleur de domaine pour rechercher les erreurs ou avertissements récents dans le journal des événements de réplication DFS, comme l’ID d’événement d’avertissement 2213 qui indique que la réplication DFS est actuellement suspendue.

  • Vérifier la configuration de l’actualisation du contenu

    Déterminez si la réplication DFS a déclenché la protection de l’actualisation du contenu sur les contrôleurs de domaine affectés. L’actualisation du contenu est activée sur les contrôleurs de domaine Windows Server 2012 (et versions ultérieures) par défaut. Toutefois, il peut également être activé manuellement sur les serveurs Windows Server 2008 R2.

    Pour évaluer si l’actualisation du contenu est activée, le MaxOfflineTimeInDays paramètre est défini sur 60. Si l’actualisation du contenu est désactivée, MaxOfflineTimeInDays est défini sur 0. Pour case activée MaxOfflineTimeInDays, exécutez la commande suivante :

    wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    Pour interroger tous les contrôleurs de domaine dans le domaine, exécutez la commande suivante :

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    Pour chaque contrôleur de domaine activé pour l’actualisation du contenu, évaluez si la réplication DFS a enregistré un ID d’événement 4012 qui indique que la réplication du dossier s’est arrêtée, car la réplication a échoué plus longtemps que le MaxOfflineTimeInDays paramètre .

Étape 2 : Préparer les contrôleurs de domaine qui sont dans un état d’erreur

  • Installer les mises à jour appropriées

    Pour tous les contrôleurs de domaine exécutant Windows Server 2008 R2, commencez par installer les mises à jour de réplication DFS pour éviter la perte de données et résoudre les problèmes connus. Il est recommandé d’utiliser la dernière version de la réplication DFS. Consultez La liste des correctifs logiciels actuellement disponibles pour les technologies de système de fichiers distribués (DFS) pour connaître la dernière version de la réplication DFS.

  • Sauvegarder des SYSVOL données

    Effectuez une sauvegarde des SYSVOL données (le cas échéant) sur chaque contrôleur de domaine. Les sauvegardes peuvent être une copie de fichier du SYSVOL contenu vers un emplacement sûr ou, il peut s’agir d’une sauvegarde qui utilise un logiciel de sauvegarde.

    Selon la situation, les fichiers de stratégie peuvent être déplacés vers Préexistant ou En conflit, puis supprimés. Les contenus préexistants et enconflit et supprimés sont vidés si la synchronisation initiale est effectuée plusieurs fois sur un serveur. Sauvegardez les données dans ces emplacements pour éviter toute perte de données.

Étape 3 : Récupérer la réplication DFS sur les contrôleurs de domaine dans l’état d’erreur

En fonction du nombre de contrôleurs de domaine dans le domaine, sélectionnez la méthode appropriée pour récupérer le service de réplication DFS.

Pour les environnements qui ont deux contrôleurs de domaine

Déterminez si un arrêt sale a été détecté (ID d’événement 2213) sur l’un des contrôleurs de domaine. Vous pouvez constater que le deuxième contrôleur de domaine attend la fin de l’initialisation de SYSVOL. La raison en est qu’après la promotion, il journalise un événement 4614 qui indique que la réplication DFS est en attente d’effectuer la réplication initiale. En outre, il ne journalise pas un événement 4604 signalant que la réplication DFS a initialisé SYSVOL.

  • Si l’actualisation du contenu est activée sur les deux contrôleurs de domaine

    Si le deuxième contrôleur de domaine attend d’effectuer la synchronisation initiale (événement 4614 journalisé sans l’anti-événement 4604), suivez comment forcer une synchronisation faisant autorité et non faisant autorité pour SYSVOL répliqué DFSR (comme « D4/D2 » pour FRS) pour définir le premier contrôleur de domaine comme faisant autorité. Vous n’avez pas besoin de configurer le deuxième contrôleur de domaine comme non authentifié, car il est déjà en attente d’effectuer la synchronisation initiale.

    Ou, si le deuxième contrôleur de domaine est sain et SYSVOL partagé, procédez comme suit :

    1. Sauvegardez tout SYSVOL le contenu du premier contrôleur de domaine.

    2. Évaluer si les données du deuxième contrôleur de SYSVOL domaine sont à jour. Si ce n’est pas le cas, vous pouvez copier les fichiers mis à jour SYSVOL vers le deuxième contrôleur de domaine à partir du premier contrôleur de domaine. Dans le cas contraire, toutes les données existantes présentes sur le premier contrôleur de domaine qui ne sont pas présentes sur le second sont entrées dans les dossiers PréExisting andConflict et Deleted .

    3. Définissez le premier contrôleur de domaine comme non autorisé en désactivant l’appartenance selon Comment forcer une synchronisation faisant autorité et non autorité pour SYSVOL répliqué DFSR (comme « D4/D2 » pour FRS). Vérifiez qu’un ID d’événement 4114 est enregistré pour indiquer que l’appartenance est désactivée.

    4. Activez l’appartenance du premier contrôleur de domaine et attendez les événements 4614 et 4604 qui signalent la fin de la synchronisation initiale. Si nécessaire, restaurez tous les fichiers mis à jour de PréExisting à l’emplacement d’origine.

  • Si l’actualisation du contenu n’est pas activée ou déclenchée sur les deux contrôleurs de domaine

    Si le premier contrôleur de domaine est dans l’état 2213 de l’ID d’événement et que le deuxième contrôleur de domaine n’a jamais terminé l’initialisation après sa promotion et que l’actualisation du contenu n’a pas été déclenchée. Procédez comme suit :

    1. Exécutez la ResumeReplication méthode WMI sur le premier contrôleur de domaine comme indiqué dans l’événement 2213.

    2. Une fois la réplication reprise, elle journalise un ID d’événement 4602 qui indique que la réplication DFS a initialisé le SYSVOL dossier répliqué et l’a spécifié comme membre principal.

    3. Exécutez la commande sur le deuxième contrôleur de domaine pour le déclencher pour terminer la dfsrdiag pollad synchronisation initiale (ID d’événement 4614). Dès que la synchronisation initiale est terminée, l’ID d’événement 4604 est journalisé, la signalisation SYSVOL a terminé l’initialisation.

    Ou, si le premier contrôleur de domaine est à l’état 2213 et que le deuxième contrôleur de domaine est sain (SYSVOL est partagé), exécutez la ResumeReplication méthode WMI sur le premier contrôleur de domaine. Il journalisera l’ID d’événement 2214 à la fin de sale récupération d’arrêt.

Pour les environnements qui ont au moins trois contrôleurs de domaine

Déterminez si un arrêt sale a été détecté et si la réplication DFS est suspendue sur les contrôleurs de domaine (ID d’événement 2213). Vous pouvez constater qu’un contrôleur de domaine attend la fin de l’initialisation de après SYSVOL la promotion. Il journalise un événement 4614 qui indique que la réplication DFS est en attente d’effectuer la réplication initiale. Il ne journalise pas non plus un événement 4604 signalant que la réplication DFS a initialisé SYSVOL.

  • Si l’actualisation du contenu est activée et qu’il existe au moins trois contrôleurs de domaine dans le domaine.

    La protection de l’actualisation du contenu journalisera un ID d’événement 4012 qui indique que la réplication s’est arrêtée, car la réplication sur le dossier a échoué pendant plus longtemps que le MaxOfflineTimeInDays paramètre . Pour réinitialiser la réplication DFS sur le ou les contrôleurs de domaine affectés, suivez les instructions de la rubrique Guide pratique pour forcer une synchronisation faisant autorité et non faisant autorité pour SYSVOL répliqué DFSR (comme « D4/D2 » pour FRS).

    Si tous les contrôleurs de domaine ont enregistré l’événement 4012 et que leur état est 5, suivez les instructions fournies dans Comment forcer une synchronisation faisant autorité et non faisant autorité pour SYSVOL répliqué DFSR (comme « D4/D2 » pour FRS) pour initialiser SYSVOLcomplètement . C’est la seule situation pour définir un serveur de réplication DFS comme faisant autorité. Assurez-vous que le contrôleur de domaine configuré comme faisant autorité dispose de la copie la plus à jour de tout SYSVOL le contenu.

    Ou, si un ou plusieurs contrôleurs de domaine bloquent la réplication en raison de l’actualisation du contenu, ils doivent tous être récupérés sans autorité. Procédez comme suit :

    1. Sauvegardez tout SYSVOL le contenu du ou des contrôleurs de domaine. En règle générale, les modifications de stratégie sont effectuées sur l’émulateur PDC, mais cela n’est pas garanti. Toutes les données présentes sur le ou les contrôleurs de domaine récupérés qui ne correspondent pas aux partenaires sont entrées dans le dossier Préexisting ou Conflict et Deleted , ou les deux.

    2. Définissez le ou les contrôleurs de domaine comme non autorisés en désactivant l’appartenance, comme décrit dans Guide pratique pour forcer une synchronisation faisant autorité et non faisant autorité pour la réplication SYSVOL DFSR (comme « D4/D2 » pour FRS). Vous devez connaître la topologie de réplication, et vous devez sortir d’un contrôleur de domaine sain en sélectionnant des partenaires directs de celui-ci, puis en récupérant d’autres contrôleurs de domaine en aval, etc. L’ID d’événement 4144 sera journalisé pour confirmer que l’appartenance est désactivée. Assurez-vous que tous les contrôleurs de domaine nécessitant une récupération journaliser l’événement. Il peut être nécessaire de forcer la réplication Active Directory, puis d’exécuter la dfsrdiag pollad commande sur chaque contrôleur de domaine pour détecter rapidement l’appartenance désactivée.

    3. Activez l’appartenance et attendez que les événements 4614 et 4604 signalent la fin de la synchronisation initiale. Restaurez tous les fichiers requis à partir d’une sauvegarde ou d’un conflit préexistants et en conflit et supprimés si nécessaire.

  • Si l’actualisation du contenu n’est pas activée ou déclenchée et qu’il existe au moins trois contrôleurs de domaine dans le domaine

    Si la protection de l’actualisation du contenu n’est pas déclenchée, exécutez la ResumeReplication méthode WMI sur les contrôleurs de domaine affectés. Vous devez connaître la topologie de réplication, et vous devez sortir d’un contrôleur de domaine sain en sélectionnant des partenaires directs de celui-ci, puis en récupérant d’autres contrôleurs de domaine en aval, etc. Une fois la réplication reprise, la réplication DFS journalise les événements 2212, 2218, puis 2214 (indiquant que la réplication DFS a initialisé le SYSVOL dossier répliqué).

Prévention des occurrences futures du problème

Vérifiez si les journaux des événements application et système signalent fréquemment des opérations de récupération de base de données ESENT, des problèmes de performances de disque, ou les deux. Les journaux des événements coïncident généralement avec des arrêts inattendus du système, la réplication DFS ne s’arrêtant pas correctement ou les défaillances du sous-système de disque. Envisagez de mettre à jour les pilotes du système, d’installer les mises à jour appropriées sur le sous-système de disque ou de contacter le fabricant du matériel du système pour examiner plus en détail. Vous pouvez également contacter les services de support technique Microsoft pour vous aider à évaluer l’intégrité du système et le comportement de réplication DFS.

Le Gestionnaire de contrôle de service (SCM) utilise le délai d’attente par défaut de 20 secondes pour arrêter un service. Dans certaines implémentations de réplication DFS complexes, cette valeur de délai d’attente peut être trop courte et la réplication DFS s’arrête avant la fermeture de la base de données appropriée. Au redémarrage du service, la réplication DFS détecte cette condition, puis effectue la récupération de la base de données. WaitToKillServiceTimeout peut être utilisé pour accorder à la réplication DFS plus de temps pour valider les modifications apportées à la base de données pendant l’arrêt. Pour plus d’informations, consultez l’article Vous recevez l’ID d’événement DFSR 2212 après avoir redémarré le service DFSR.

Une fois que vous avez restauré la réplication DFS de , l’intégrité de SYSVOLla réplication DFS doit être soigneusement surveillée dans l’environnement pour éviter ce scénario. Il est recommandé d’examiner régulièrement les journaux des événements de réplication DFS, la collecte des rapports d’intégrité de la réplication DFS et la collecte de l’état de réplication (à l’aide de la requête WMI de la section Vérifier l’état de la réplication DFS sous Étape 1 - Évaluer l’état de la réplication DFS sur tous les contrôleurs de domaine).