Fehler bei Active Directory Domain Controller Herunterstufung (ForestDnsZones – fSMORoleOwner Attribut)

Das Problem

Bei der Herunterstufung von einem Active Directory Domain Controller kam es zu der Meldung, dass der Vorgang nicht erfolgreich abgeschlossen werden kann und der Domain Controller nicht abgebaut werden kann.

Der Vorgang konnte nicht durchgeführt werden. Fehler:
Active Directory konnte die verbleibenden Daten in der Verzeichnispartition DC=DomainDnsZones,DC=domain,DC=local nicht zum Domänencontroller \server.domain.local übertragen.
“Dem Verzeichnisdienst fehlen verbindliche Konfigurationsinforationen. Er kann daher den Besitz der Betriebsmodi für wechselnde Einzelmaster nicht bestimmen.”

Im Eventlog tauchten diverse Meldungen auf, unter anderem Warnung 2091 (Verzeichnisdienst):

Der Besitzer der folgenden FSMO-Rolle wurde auf einen Server festgelegt, der entweder gelöscht wurde oder nicht vorhanden ist.
Vorgänge, die eine Kontaktaufnahme mit dem FSMO-Betriebsmaster erfordern, sind nicht erfolgreich, solange dieser Zustand nicht behoben wird.
FSMO-Rolle: CN=Infrastructure,DC=ForestDnsZones,DC=Domäne,DC=Domäne,DC=de
DN des FSMO-Servers: CN=NTDS Settings\0ADEL:9d5aaea7-45f7-4d98-9e29-27ce6bf86836,CN=DC02\0ADEL:eddc064a-458f-4b98-aca8-169e38e36a47,CN=Servers,CN=Standardname-des-ersten-Standorts,CN=Sites,CN=Configuration,DC=domäne,DC=domäne,DC=de
Benutzeraktion:
Ermitteln Sie, welcher Server über die fragliche Rolle verfügen sollte.
Die Konfigurationsansicht ist eventuell nicht mehr aktuell. Stellen Sie sicher, dass die Konfigurationspartition von dem Server vor kurzem repliziert wurde, falls dieser vor kurzem heraufgestuft wurde. Stellen Sie sicher, dass die Partition (die die aktuelle Besitzerrolle enthält) von dem Server vor kurzem repliziert wurde, falls dieser vor kurzem herabgestuft und dessen Rolle übertragen wurde.
Ermitteln Sie, ob die Rolle richtig auf dem FSMO-Rollenhalterserver festgelegt wurde. Führen Sie NTDSUTIL.EXE aus, um die Rolle zu übertragen bzw. zu übernehmen, wenn sie nicht festgelegt wurde. Dieser Vorgang sollte entsprechend den Schritten, die in den KB-Artikeln 255504 und 324801 auf http://support.microsoft.com aufgelistet sind, durchgeführt werden.
Verifizieren Sie, dass die Replikation der FSMO-Partition zwischen dem FSMO-Rollenhalterserver und diesem Server erfolgreich durchgeführt wird.
Die folgenden Vorgänge werden eventuell beeinträchtigt:
Schema: Sie können das Schema für diese Gesamtstruktur nicht mehr modifizieren.
Domänenbenennung: Sie können keine Domänen zu dieser Gesamtstruktur hinzufügen bzw. daraus entfernen.
PDC: Sie können keine weiteren Vorgänge, wie z.B. die Aktualisierung von Gruppenrichtlinien oder das Zurücksetzen von Kennwörtern für nicht in den Active Directory-Domänendiensten vorhandene Konten, auf dem primären Domänencontroller durchführen.
RID: Sie können keine neuen Sicherheits-IDs für neue Benutzer- oder Computerkonten bzw. für Sicherheitsgruppen zuweisen.
Infrastruktur: Domänenübergreifende Namensverweise, wie z.B. universelle Gruppenmitgliedschaften, werden nicht richtig aktualisiert, wenn das Zielobjekt entfernt oder umbenannt wird.

Die Ursache

Die Ursache für dieses Problem war, dass in der Active Directory ein veralteter Wert bzw. falscher Wert eingetragen war. Den Wert selbst kann man per ADSIEDIT einsehen und auch ändern. Der alte Wert war in meinem Fall ein Server, der in früheren Zeiten mal DC war, nun aber nicht mehr existent ist.

Die Lösung

Den korrekten Namen herausfinden

Als erstes brauchen wir die Information, auf welchem Server sich aktuell die FSMO-Rollen befinden. Dies geht am einfachsten mit der Windows PowerShell:

Wir wechseln nun auf genau diesen Server und rufen dort (über Ausführen oder über eine cmd/PowerShell) ADSIEDIT.MSC auf. Nun stellen wir eine neue Verbindung her

und verbinden uns mit dem Verbindungspunkt Konfiguration. Als Computer im unteren Bereich stellen wir den lokalen Server ein, auf dem wir uns gerade befinden und der auch Halter der FSMO-Rolle ist.

Wir navigieren nun zu

  • Konfiguration
  • CN=Configuration,DC=Domäne,DC=local
  • CN=Sites
  • CN=Standardname-des-ersten-Standorts
  • CN=Servers
  • CN=Servername

Standardname-des-ersten-Standorts muss hier ersetzt werden durch den Namen der Site, Servername ist das System, welches die FSMO-Rolle hält.

In den Eigenschaften von CN=NTDS Settings müssen wir uns nun den Wert distinguishedName anschauen und für später in einen Editor kopieren.

Die ForestDnsZones überprüfen und ggf. bearbeiten

Nun schließen wir die Eigenschaften und bauen eine zweite Verbindung im ADSI-Editor auf. Dazu wählen wir die Option Verbindung herstellen… im Kontextmenü des ADSI-Editors.

In den Verbindungseinstellungen müssen die folgenden Einstellungen gesetzt werden:

  • Name: Standardmäßiger Namenskontext
  • Verbindungspunkt: Definierten Namen
    • DC=ForestDnsZones,DC=Domäne,DC=local
  • Computer: Domäne oder Server auswählen
    • Servername.domäne.local

Kann die Verbindung erfolgreich hergestellt werden, taucht ein zweiter Punkt im ADSIEDIT auf (Standardmäßiger Namenskontext). Hier wechseln wir auf den ersten Unterordner DC=ForestDnsZones,DC=Domäne,DC=local und wechseln in die Eigenschaften von CN=Infrastructure.

Hier müssen wir das Attribut fSMORoleOwner beachten. In diesem Attribut muss der DN-Name von unserem aktuellen FSMO-Server stehen (der Wert, den wir vorhin in den Editor kopiert haben). Ist dies nicht der Fall, und hier ist eine lange, kryptische ID zu sehen, muss diese durch den Namen in unserem Editor ersetzt werden.

Die DomainDnsZones überprüfen und ggf. bearbeiten

Nun wiederholen wir die Verbindung erneut, dieses Mal wird aber eine Verbindung zur DomainDnsZones aufgebaut. Die Eigenschaften der Verbindung sehen wie folgt aus:

Nach dem erfolgreichen Aufbau der Verbindung schauen wir uns auch hier den CN=Infrastructure Wert an.

Auch hier müssen wir das fSMORoleOwner Attribut überprüfen und ggf. mit dem Wert aus unserem Editor überschreiben, wenn der aktuelle Eintrag nicht mit dem korrekten Wert übereinstimmt.

Jan

Jan Kappen arbeitet sein 2005 in der IT. Er hat seine Ausbildung 2008 abgeschlossen und war bis 2018 als IT-Consultant im Bereich Hyper-V, Failover Clustering und Software Defined Storage unterwegs. Seit 2015 wurde er jährlich von Microsoft als Most Valuable Professional (MVP) im Bereich "Cloud & Datacenter Management" ausgezeichnet für seine Kenntnisse und die Weitergabe seines Wissens. Jan ist häufig auf Konferenzen als Sprecher zu finden, weiterhin bloggt er viel. Seit September 2018 ist Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.