Problembehandlung bei fehlenden SYSVOL- und Netlogon-Freigaben

  • Artikel

Dieser Artikel enthält die Schritte zum Beheben von Problemen mit fehlenden SYSVOL - und Netlogon -Freigaben in Windows Server 2012 R2.

Gilt für: Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Ursprüngliche KB-Nummer: 2958414

Symptome

SYSVOL - und Netlogon -Freigaben werden nicht auf einem Domänencontroller freigegeben. Die folgenden Symptome oder Zustände können auch auftreten:

  • Der sysvol Ordner ist leer.
  • Der betroffene Domänencontroller wurde kürzlich heraufgestuft.
  • Die Umgebung enthält Domänencontroller, auf denen Frühere Versionen von Windows als Windows Server 2012 R2 ausgeführt werden.
  • Die DFS-Replikation wird verwendet, um den SYSVOL replizierten Freigabeordner zu replizieren.
  • Ein Upstream DFS-Replikationsdienst des Domänencontrollers befindet sich in einem Fehlerzustand.

Ursache

Domänencontroller ohne SYSVOL freigegeben können eingehende Daten nicht replizieren, da sich Upstream Domänencontroller (Quelle) in einem Fehlerzustand befinden. Häufig (aber nicht beschränkt auf) haben die Upstream-Server die Replikation aufgrund eines modifiziert Herunterfahrens (Ereignis-ID 2213) beendet.

Lösung

Dieser Abschnitt enthält empfohlene Methoden zur Problembehandlung und Behebung fehlender SYSVOL Und-Freigaben Netlogon auf Domänencontrollern, die mithilfe des DFS-Replikationsdiensts repliziert werden.

Der Prozess initialisiert die DFS-Replikation erneut, wenn SYSVOL nicht auf Domänencontrollern freigegeben wird, wie eine autoritative oder nicht autoritative Synchronisierung für DFSR-repliziertes SYSVOL (z. B. "D4/D2" für FRS) erzwungen wird. Dies ist in den meisten Fällen nicht erforderlich und kann zu Datenverlusten führen, wenn sie falsch ausgeführt wird. Darüber hinaus wird verhindert, dass die Ursache des Problems ermittelt und zukünftige Vorkommen des Problems abgewendet werden.

Nachfolgend sind allgemeine Schritte zum Untersuchen der fehlenden Freigaben aufgeführt. Ermitteln Sie, ob das Problem durch ein einmaliges Auftreten verursacht wird oder ob die Upstream Domänencontroller die Replikation mithilfe der DFS-Replikation nicht unterstützen können.

Das Löschen der DFS-Replikationsdatenbank aus dem Volume sollte nicht erforderlich sein, und es wird davon abgeraten. Dies bewirkt, dass die DFS-Replikation alle lokalen Daten auf dem Server als nicht autoritativ betrachtet. Indem die DFS-Replikation die Datenbank ordnungsgemäß wiederherstellen lässt (wie im Ereignis 2213 angegeben), gewinnt der letzte Writer weiterhin alle in Konflikt stehenden Datenversionen SYSVOL .

Schritt 1: Auswerten des Status der DFS-Replikation auf allen Domänencontrollern

Bewerten Sie, wie viele Domänencontroller nicht freigegeben SYSVOLwerden, kürzlich ein Fehlerereignis protokolliert haben und wie viele Domänencontroller sich in einem Fehlerzustand befinden. Führen Sie die folgenden Schritte aus.

  • Überprüfen auf die SYSVOL Freigabe

    Sie können manuell überprüfen, ob SYSVOL freigegeben ist, oder Sie können jeden Domänencontroller überprüfen, indem Sie den Befehl net view verwenden:

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

  • Überprüfen des DFS-Replikationsstatus

    Um den Zustand der DFS-Replikation auf Domänencontrollern zu überprüfen, können Sie WMI abfragen. Sie können alle Domänencontroller in der Domäne für den SYSVOL replizierten Freigabeordner abfragen, indem Sie WMI wie folgt verwenden:

    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

    Die state Werte können wie folgt sein:
    0 = Nicht initialisiert
    1 = Initialisiert
    2 = Erste Synchronisierung
    3 = Automatische Wiederherstellung
    4 = Normal
    5 = Fehler

    Hinweis

    Abhängig von der Bedingung eines Domänencontrollers kann es vorkommen, dass ein Zustandswert nicht gemeldet wird und keine instance verfügbar sind.

  • Überprüfen der Ereignisprotokolle auf aktuelle Fehler oder Warnungen

    Wenn Domänencontroller den SYSVOL replizierten Freigabeordner nicht als status 4 (normal) melden, überprüfen Sie das Ereignisprotokoll dieser Domänencontroller, um deren Zustand zu bewerten. Überprüfen Sie jeden Domänencontroller auf aktuelle Fehler oder Warnungen im Ereignisprotokoll der DFS-Replikation, z. B. die Warnungsereignis-ID 2213, die angibt, dass die DFS-Replikation derzeit angehalten ist.

  • Überprüfen der Inhaltsaktuitätskonfiguration

    Ermitteln Sie, ob die DFS-Replikation den Inhaltsaktuitätsschutz auf den betroffenen Domänencontrollern ausgelöst hat. Content Freshness ist standardmäßig auf Windows Server 2012 Domänencontrollern (und höheren Versionen) aktiviert. Es kann jedoch auch manuell auf Windows Server 2008 R2-Servern aktiviert werden.

    Um auszuwerten, ob die Aktualität des Inhalts aktiviert ist, wird die MaxOfflineTimeInDays Einstellung auf 60 festgelegt. Wenn die Aktualität des Inhalts deaktiviert ist, MaxOfflineTimeInDays wird auf 0 festgelegt. Führen Sie den folgenden Befehl aus, um zu überprüfen MaxOfflineTimeInDays:

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

    Führen Sie den folgenden Befehl aus, um alle Domänencontroller in der Domäne abzufragen:

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

    Bewerten Sie für jeden Domänencontroller, der für die Aktualität von Inhalten aktiviert ist, ob die DFS-Replikation eine Ereignis-ID 4012 protokolliert hat, die angibt, dass die Replikation des Ordners beendet wurde, weil die Replikation länger als der MaxOfflineTimeInDays Parameter fehlgeschlagen ist.

Schritt 2: Vorbereiten der Domänencontroller, die sich in einem Fehlerzustand befinden

  • Installieren geeigneter Updates

    Installieren Sie für alle Domänencontroller, auf denen Windows Server 2008 R2 ausgeführt wird, zuerst DFS-Replikationsupdates, um Datenverluste zu verhindern und bekannte Probleme zu beheben. Es empfiehlt sich, die neueste Version der DFS-Replikation zu verwenden. Informationen zur neuesten Version der DFS-Replikation finden Sie unter Liste der derzeit verfügbaren Hotfixes für DFS-Technologien (Distributed File System ).

  • Sichern von SYSVOL Daten

    Führen Sie eine Sicherung der SYSVOL Daten (sofern vorhanden) auf jedem Domänencontroller durch. Sicherungen können eine Dateikopie des SYSVOL Inhalts an einem sicheren Speicherort oder eine Sicherung sein, die Sicherungssoftware verwendet.

    Je nach Situation können Richtliniendateien in "PreExisting" oder " Conflict and Deleted" verschoben werden. PreExisting und Konflikt und Gelöschte Inhalte werden gelöscht, wenn die erste Synchronisierung mehrmals auf einem Server durchgeführt wird. Sichern Sie Daten an diesen Speicherorten, um Datenverluste zu vermeiden.

Schritt 3: Wiederherstellen der DFS-Replikation auf den Domänencontrollern im Fehlerzustand

Wählen Sie basierend auf der Anzahl der Domänencontroller in der Domäne die geeignete Methode aus, um den DFS-Replikationsdienst wiederherzustellen.

Für Umgebungen mit zwei Domänencontrollern

Ermitteln Sie, ob ein modifiziert Herunterfahren (Ereignis-ID 2213) auf einem der Domänencontroller erkannt wurde. Möglicherweise wartet der zweite Domänencontroller auf den Abschluss der Initialisierung von SYSVOL. Der Grund dafür ist, dass nach der Heraufstufung ein 4614-Ereignis protokolliert wird, das angibt, dass die DFS-Replikation auf die erste Replikation wartet. Darüber hinaus wird kein 4604-Ereignis protokolliert, das signalisiert, dass die DFS-Replikation initialisiert SYSVOLhat.

  • Wenn die Aktualität von Inhalten auf beiden Domänencontrollern aktiviert ist

    Wenn der zweite Domänencontroller auf die Erstsynchronisierung wartet (Ereignis 4614 ohne das Antiereignis 4604 protokolliert), befolgen Sie die Schritte unter Erzwingen einer autoritativen und nicht autoritativen Synchronisierung für DFSR-repliziertes SYSVOL (z. B. "D4/D2" für FRS), um den ersten Domänencontroller als autoritativ festzulegen. Sie müssen den zweiten Domänencontroller nicht als nicht autoritativ konfigurieren, da er bereits auf die erste Synchronisierung wartet.

    Wenn der zweite Domänencontroller fehlerfrei und SYSVOL freigegeben ist, führen Sie die folgenden Schritte aus:

    1. Sichern Sie den gesamten SYSVOL Inhalt des ersten Domänencontrollers.

    2. Bewerten Sie, ob die Daten des zweiten Domänencontrollers SYSVOL auf dem neuesten Stand sind. Andernfalls sollten Sie aktualisierte SYSVOL Dateien vom ersten Domänencontroller auf den zweiten Domänencontroller kopieren. Andernfalls werden alle auf dem ersten Domänencontroller vorhandenen Daten, die auf dem zweiten nicht vorhanden sind, in die Ordner PreExisting und Conflict and Deleted verschoben .

    3. Legen Sie den ersten Domänencontroller als nicht autoritativ fest, indem Sie die Mitgliedschaft gemäß How to force an autoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (z. B. "D4/D2" für FRS) deaktivieren. Vergewissern Sie sich, dass eine Ereignis-ID 4114 protokolliert wird, um anzugeben, dass die Mitgliedschaft deaktiviert ist.

    4. Aktivieren Sie die Mitgliedschaft des ersten Domänencontrollers, und warten Sie auf die Ereignisse 4614 und 4604, die den Abschluss der ersten Synchronisierung melden. Stellen Sie bei Bedarf alle aktualisierten Dateien aus PreExisting am ursprünglichen Speicherort wieder her.

  • Wenn die Aktualität von Inhalten auf beiden Domänencontrollern nicht aktiviert oder ausgelöst wird

    Wenn sich der erste Domänencontroller in der Ereignis-ID 2213 befindet und der zweite Domänencontroller die Initialisierung nach dem Heraufstufen noch nie abgeschlossen hat und die Inhaltsneuheit nicht ausgelöst wurde. Führen Sie die folgenden Schritte aus:

    1. Führen Sie die ResumeReplication WMI-Methode auf dem ersten Domänencontroller aus, wie im Ereignis 2213 angegeben.

    2. Nach der Fortsetzung der Replikation wird die Ereignis-ID 4602 protokolliert, die angibt, dass die DFS-Replikation den SYSVOL replizierten Ordner initialisiert und als primäres Mitglied angegeben hat.

    3. Führen Sie den dfsrdiag pollad Befehl auf dem zweiten Domänencontroller aus, um die erste Synchronisierung (Ereignis-ID 4614) auszulösen. Sobald die erste Synchronisierung abgeschlossen ist, wird die Ereignis-ID 4604 protokolliert, und die Signalisierung SYSVOL wurde abgeschlossen.

    Wenn sich der erste Domänencontroller im Zustand 2213 befindet und der zweite Domänencontroller fehlerfrei ist (SYSVOL ist freigegeben), führen Sie die ResumeReplication WMI-Methode auf dem ersten Domänencontroller aus. Die Ereignis-ID 2214 wird nach Abschluss modifiziert Wiederherstellung protokolliert.

Für Umgebungen mit drei oder mehr Domänencontrollern

Ermitteln Sie, ob ein modifiziert Herunterfahren erkannt wurde und ob die DFS-Replikation auf allen Domänencontrollern angehalten wird (Ereignis-ID 2213). Möglicherweise wartet ein Domänencontroller auf den Abschluss der Initialisierung von nach der Heraufstufung SYSVOL . Es protokolliert ein 4614-Ereignis, das angibt, dass die DFS-Replikation auf die erste Replikation wartet. Außerdem wird kein 4604-Ereignis protokolliert, das signalisiert, dass die DFS-Replikation initialisiert SYSVOLhat.

  • Wenn die Aktualität von Inhalten aktiviert ist und drei oder mehr Domänencontroller in der Domäne vorhanden sind.

    Content Freshness Protection protokolliert die Ereignis-ID 4012, die angibt, dass die Replikation beendet wurde, weil die Replikation im Ordner länger als der MaxOfflineTimeInDays Parameter fehlgeschlagen ist. Um die DFS-Replikation auf den betroffenen Domänencontrollern erneut zu initialisieren, befolgen Sie die Anweisungen unter Erzwingen einer autoritativen und nicht autoritativen Synchronisierung für DFSR-repliziertes SYSVOL (z. B. "D4/D2" für FRS).

    Wenn alle Domänencontroller das Ereignis 4012 protokolliert haben und ihr Zustand 5 ist, befolgen Sie die Anweisungen unter Erzwingen einer autoritativen und nicht autoritativen Synchronisierung für DFSR-repliziertes SYSVOL (z. B. "D4/D2" für FRS), um vollständig zu initialisieren SYSVOL. Es ist die einzige Situation, einen DFS-Replikationsserver als autoritativ festzulegen. Stellen Sie sicher, dass der als autoritativ konfigurierte Domänencontroller über die aktuellste Kopie aller SYSVOL Inhalte verfügt.

    Oder wenn ein oder mehrere Domänencontroller die Replikation aufgrund der Aktualität des Inhalts blockieren, müssen sie jeweils nicht autoritativ wiederhergestellt werden. Gehen Sie folgendermaßen vor:

    1. Sichern Sie den gesamten SYSVOL Inhalt der Domänencontroller. In der Regel werden Richtlinienbearbeitungen auf dem PDC-Emulator vorgenommen, aber dies ist nicht garantiert. Alle Daten, die auf den wiederhergestellten Domänencontrollern vorhanden sind, die nicht mit den Partnern übereinstimmen, werden in den Ordner PreExisting , Conflict and Deleted oder beides verschoben.

    2. Legen Sie die Domänencontroller als nicht autoritativ fest, indem Sie die Mitgliedschaft deaktivieren, wie unter Erzwingen einer autoritativen und nicht autoritativen Synchronisierung für DFSR-repliziert SYSVOL (z. B. "D4/D2" für FRS) beschrieben. Sie müssen die Replikationstopologie kennen, und Sie müssen von einem fehlerfreien Domänencontroller aus auffächern, indem Sie direkte Partner davon auswählen, dann weitere downstream-Domänencontroller wiederherstellen usw. Die Ereignis-ID 4144 wird protokolliert, um zu bestätigen, dass die Mitgliedschaft deaktiviert ist. Stellen Sie sicher, dass das Ereignis auf allen Domänencontrollern protokolliert wird, für die die Wiederherstellung erforderlich ist. Es kann erforderlich sein, die Active Directory-Replikation zu erzwingen und dann den dfsrdiag pollad Befehl auf jedem Domänencontroller auszuführen, um die deaktivierte Mitgliedschaft schnell zu erkennen.

    3. Aktivieren Sie die Mitgliedschaft, und warten Sie, bis die Ereignisse 4614 und 4604 den Abschluss der ersten Synchronisierung melden. Stellen Sie alle erforderlichen Dateien nach Bedarf aus der Sicherung oder aus PreExisting und Conflict und Deleted wieder her.

  • Wenn die Inhaltsneuigkeit nicht aktiviert oder ausgelöst wird und drei oder mehr Domänencontroller in der Domäne vorhanden sind

    Wenn der Inhaltsneuheitsschutz nicht ausgelöst wird, führen Sie die ResumeReplication WMI-Methode auf den betroffenen Domänencontrollern aus. Sie müssen die Replikationstopologie kennen, und Sie müssen von einem fehlerfreien Domänencontroller aus auffächern, indem Sie direkte Partner davon auswählen, dann weitere downstream-Domänencontroller wiederherstellen usw. Nachdem die Replikation fortgesetzt wurde, protokolliert die DFS-Replikation die Ereignisse 2212, 2218 und dann 2214 (was angibt, dass die DFS-Replikation den SYSVOL replizierten Ordner initialisiert hat).

Verhindern des zukünftigen Auftretens des Problems

Überprüfen Sie, ob die Anwendungs- und Systemereignisprotokolle häufig ESENT-Datenbankwiederherstellungsvorgänge, Datenträgerleistungsprobleme oder beides melden. Die Ereignisprotokolle fallen in der Regel mit unerwarteten Herunterfahren des Systems zusammen, wobei die DFS-Replikation nicht ordnungsgemäß beendet wird, oder Datenträgersubsystemfehler. Erwägen Sie, die Systemtreiber zu aktualisieren, geeignete Updates für das Datenträgersubsystem zu installieren oder sich an den Hardwarehersteller des Systems zu wenden, um dies weiter zu untersuchen. Sie können sich auch an den Microsoft-Kundendienst wenden, um die Integrität des Systems und das DFS-Replikationsverhalten zu bewerten.

Der Dienststeuerungs-Manager (Service Control Manager, SCM) verwendet das Standardtimeout von 20 Sekunden zum Beenden eines Diensts. In einigen komplexen DFS-Replikationsimplementierungen ist dieser Timeoutwert möglicherweise zu kurz, und die DFS-Replikation wird beendet, bevor die entsprechende Datenbank geschlossen wird. Beim Neustart des Diensts erkennt die DFS-Replikation diese Bedingung und führt dann die Datenbankwiederherstellung durch. WaitToKillServiceTimeout kann verwendet werden, um der DFS-Replikation mehr Zeit für das Committen von Änderungen an der Datenbank während des Herunterfahrens zu gewähren. Weitere Informationen findest du im Artikel Sie erhalten die DFSR-Ereignis-ID 2212, nachdem Sie den DFSR-Dienst neu gestartet haben.

Nachdem Sie die DFS-Replikation von SYSVOLwiederhergestellt haben, muss die DFS-Replikationsintegrität in der Umgebung sorgfältig überwacht werden, um dieses Szenario zu verhindern. Es wird eine regelmäßige Überprüfung der DFS-Replikationsereignisprotokolle, das Sammeln von Integritätsberichten der DFS-Replikation und das Sammeln des Replikationsstatus (mithilfe der WMI-Abfrage im Abschnitt Überprüfen des DFS-Replikationsstatus unter Schritt 1 – Auswerten des Zustands der DFS-Replikation auf allen Domänencontrollern) empfohlen.