Windows Server 2022: Domaincontroller reparieren (2)

Lesezeit
3 Minuten
Bis jetzt gelesen

Windows Server 2022: Domaincontroller reparieren (2)

13.01.2025 - 07:02
Veröffentlicht in:

Das Active Directory ist in den meisten Firmen eine kritische Infrastrukturkomponente. Glücklicherweise ist der Verzeichnisdienst ziemlich resistent. Er schützt sich gegen viele Fehler und potenzielle Störfälle von selbst und der Ausfall einzelner Server führt nicht zum Ausfall des ganzen Verbunds. Doch manchmal müssen Sie als Administrator Hand anlegen und einzelne Domänencontroller oder das ganze AD reparieren. Im zweiten Teil beschreiben wir, mit welchen Checks Sie die SYSVOL-Replikation sicherstellen.

Neben der AD-Replikation für die Verzeichnisdaten ist die SYSVOL-Replikation für die Nutzdaten von Gruppenrichtlinien (GPOs) entscheidend. Ohne GPOs sind Clients nicht in der Lage, Einstellungen zu übernehmen. Und ohne SYSVOL ist der Domänencontroller nicht komplett.

SYSVOL-Replikation sicherstellen
Die generelle Prüfung, ob SYSVOL verfügbar ist, haben wir im vorherigen Abschnitt schon durchgeführt. Ob die Replikation von SYSVOL überhaupt klappt und ob es ein Backlog gibt, finden Sie über die DFS-Managementkonsole heraus. DFS ist in neueren AD-Umgebungen der Replikationsmotor für SYSVOL. In älteren Infrastrukturen ist das noch der File Replication Service (FRS), dessen Entwicklung Microsoft schon vor vielen Jahren eingestellt hat. Sie sollten Ihre SYSVOL-Replikation auf DFS-R umstellen, um die schnellere und fehlerresistentere Replikation nutzen zu können.

Sie prüfen auf zwei Arten, wie SYSVOL repliziert wird. Da DFS-R erst mit Domänen mit Domänenfunktionslevel 2008 oder neuer zum Einsatz kommen kann, scheiden alte oder Mischdomänen mit Windows Server 2003 aus. Für neuere Domänen zeigt das folgende Kommando den Status an:

dfsrmig /getglobalstate

Ist der Status in einem anderen Zustand als "Eliminated", wird weiterhin FRS eingesetzt. Die zweite Prüfungsmöglichkeit bietet die DFS-Managementkonsole. Auf einem DC müssen Sie die Konsole zunächst als weiteres Feature unter den Management-Tools als Teil der Dateiverwaltungsrolle nachinstallieren: "Remote Server Administration Tools (RSAT) / Role Administration / File Services Tools / DFS Management Tools". In der geöffneten DFS-Konsole sollte dann "Domain System Volume" unter dem "Replication"-Knoten erscheinen. Sind dort auch die DCs gelistet, ist DFS-R im Einsatz. Für Umgebungen mit FRS empfiehlt Microsoft den Umstieg auf DFS-R mithilfe des Migrationstools "dfsrmig".

Das Überprüfen von DFS-R für SYSVOL führen Sie durch einen Klick auf "Domain System Volume" und dann in der rechten Fensterseite auf "Create Diagnostic Report" durch. Dabei werden die Dateistände der einzelnen Domänencontroller verglichen und kontrolliert, wie lange die Replikation von Änderungen zwischen den DCs dauert. Dabei kann die Konsole zwei Tests durchführen: eine Prüfung der Gesundheit von DFS-R und einen Propagierungstest. Dauert die Replikation der SYSVOL-Daten zu lange oder funktioniert nicht richtig, lohnt sich der "Propagation Test".

Einige Zeit später, wenn die Replikation hoffentlich abgeschlossen ist, generieren Sie den Report, ebenfalls über den Wizard mit "Propagation Report". Die gesammelten Daten und Erkenntnisse landen in einem HTML-Bericht. Gehen wir davon aus, dass auch nach Stunden der Propagierungstest keine erfolgreiche Replikation ausgibt. Eine Analyse des "Health Reports" zeigt, dass sich beide Domänencontroller für DFS-R im "initial Replication state" befinden – obwohl beide bereits ein SYSVOL-Verzeichnis besitzen und Endbenutzer darauf zugreifen können.

Das könnte eventuell mit dem Verschwinden des dritten Domänencontrollers, der aufgrund eines Fehlers ausgefallen ist, zu tun haben. Es ist schlecht, wenn beide DCs SYSVOL nicht mehr replizieren, potenziell aber Änderungen entgegengenommen haben könnten. Ein kurzer Check verrät, dass DC-1 der PDC-Emulator ist und somit per Standardeinstellung von der GPMC für Gruppenrichtlinien genutzt wird. An dieser Stelle müssten wir als Gegenprobe die Daten auf den jeweiligen SYSVOL untersuchen und checken, ob DC-1 tatsächlich über die aktuellsten Daten verfügt.

Die Lösung dieses Fehlers besteht in einem Restore von DFS-R. In diesem Fall wird DC-1 als "authoritative" markiert, DC-2 als "non-authoritative", damit er alle Delta-Änderungen repliziert. Der "authoritative"-Marker sorgt dafür, dass nach einem Stopp und Neustart der DFSR-Dienste aller Domänencontroller der eine für gut befundene Domänencontroller als Quelle für die Neureplikation herangezogen wird.

Stoppen Sie zunächst den DFS-Replikationsdienst auf DC-1, den Sie danach als "authorativ" markieren. Mit dem MMC-Snapin "ADSIEdit.msc" verbinden Sie sich über "Action" und "Connect to" mit DC1. In "Select a well known Naming Context:" wählen Sie den "Default Naming Context”, der die bekannten AD-Daten wie Benutzer, Computer und Gruppen beinhaltet. Browsen Sie über das Domänenobjekt in die "Domain Controllers"- OU und dann zum DC-Objekt von DC1. Klicken Sie anschließend auf dessen Subobjekt "DFSR-LocalSettings", "Domain System Volume" und das Zielobjekt "SYSVOL Subscription". Ein Doppelklick öffnet den Attributeditor, in dem Sie die beiden folgenden Attribute so anpassen: "msDFSR-Enabled" wird zu "False" und "msDFSR-Options" wird mit dem Wert "1" bedacht.

Für DC-2, der die Änderungen erhalten soll und "non-authoritative" restauriert wird, führen Sie die gleichen Schritte aus, ändern jedoch nur das msDFSR-Enabled-Attribut zu "False" – das "msDFSRoptions"-Attribut lassen Sie unverändert.

Anschließend warten Sie die AD-Replikation ab. Ist sie fertig, starten Sie den DFSR-Dienst auf DC-1 neu. Ist der Dienst wieder verfügbar, sollten die geänderten Attributdaten für den authoritativen Restore geladen worden sein. Dann können Sie für das SYSVOL-Objekt für DC-1 das "msDFSR-options"-Objekt zurück auf "TRUE" setzen. Alle Domaincontroller sollten, nach kurzer Replikationszeit, wieder mitbekommen haben, dass DC-1 DFS-R repliziert und authoritativ Daten bereithält. Um sicherzugehen, dass der DFSR-Dienst auf DC-1 die Änderungen aus dem AD übernommen hat, stoßen Sie mit dfsrdiag PollAD das Neuladen der DFSR-Daten an.

Anschließend starten Sie den DFSR-Dienst auf DC-2 – und allen anderen relevanten Domänencontrollern. Hat auch das geklappt, schalten Sie den DSFR-Dienst für SYSVOL auf DC-2 wieder scharf, indem Sie msDFSR-Enabled zurück auf "True" setzen. Nach einiger Zeit – oder durch manuelle Aktualisierung via dfsrdiag PollAD nach der AD-Replikation – wird der Restore durchgeführt.

ln/dr/Frank Tess

Im dritten und letzten Teil der Workshopserie gehen wir unter anderem darauf ein, wie Sie gängige Fehler wie eine falsche Uhrzeit vermeiden. Im ersten Teil haben wir uns nach einer Einführung in das Thema die Diagnosemöglichkeiten mit DCDiag angeschaut und erklärt, wie Sie DCs direkt nach der Installation überprüfen.

Ähnliche Beiträge

Windows Server 2022: Domaincontroller reparieren (1)

Das Active Directory ist in den meisten Firmen eine kritische Infrastrukturkomponente. Glücklicherweise ist der Verzeichnisdienst ziemlich resistent. Doch manchmal müssen Sie als Administrator Hand anlegen und einzelne Domänencontroller oder das ganze AD reparieren. Im ersten Teil schauen wir uns nach einer Einführung in das Thema die Diagnosemöglichkeiten mit DCDiag an und erklären, wie Sie DCs direkt nach der Installation überprüfen.

Windows Server 2025 - Bereit für das neueste Upgrade? Neues E-Book von Thomas-Krenn

Windows Server 2025 ist neu auf dem Markt und bringt zahlreiche Verbesserungen und Innovationen für die IT-Infrastruktur von Unternehmen mit sich. Um Sie optimal auf die Nutzung der neuen Technologien vorzubereiten, hat die Thomas-Krenn.AG ein umfassendes E-Book entwickelt.

Warum Passwörter wie "Snowboard!2042#" nicht so sicher sind, wie man denkt

Warum starke Passwortrichtlinien für den Schutz eines Unternehmens vor Cyberangriffen wichtig sind, ist klar. Dennoch gibt es ein paar Faktoren, die oftmals unbeachtet bleiben. In diesem Artikel wollen wir die wichtigsten Faktoren einer Kennwortrichtlinie einmal genauer beleuchten.