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.

10 Kommentare:

  1. Hallo Herr Kappen,
    vielen Dank für diese Anleitung! Die hat uns bei einem größeren Kundenprojekt den Ar… gerettet 🙂
    Wir mussten einen älteren Win Srv 2008r2 der schon ewig von einem 2012r2 gesyncht wurde und als Primary ersetzt wurde, allerdings konnten wir ihn genau wegen der von ihnen hier beschriebenen Fehlermeldung nicht demoten. Die Anleitung war zwar tricky und man muss genau lesen, aber danach klappte es wunderbar! Gut, ich hätte den alten zwar “herausreissen” können, aber so eine Fehlermeldung hinterlässt immer ein unangenehmes Gefühl welches spätestens beim nächsten DC-Wechsel in diesem System wieder aufkommen lassen würde…
    Vielen dank für ihre Mühe!!!
    Gruß aus Tirol

  2. Hallo Herr Kappen,
    habe das gleiche Problem kann aber Ihrer Beschreibung bei:
    “Standardname-des-ersten-Standorts muss hier ersetzt werden durch den Namen der Site, Servername ist das System, welches die FSMO-Rolle hält”
    leider nicht folgen. Könnten Sie das bitte im Detail erklären.
    Das wäre super
    Gruß aus dem Allgäu

    • Hallo,
      wenn Sie auf einem Domänen-Controller das Programm “Active Directory-Standorte und -Dienste” aufrufen, bekommen Sie die Namen der Sites (Standorte) aufgeführt. Wenn man dies nach der Installation einer AD nicht ändert, ist der Name des ersten Standortes immer “Standardname-des-ersten-Standorts”. Häufig wird der Name geändert, so das man hier z.B. “Zentrale”, den Namen der Stadt oder eine andere Beschreibung findet, die den Standort beschreibt. Diesen Namen müssen Sie nutzen.
      Gruß, Jan

  3. Danke Herr Kappen,
    stand auf dem Schlauch, da überall der englische Name:
    Default-First-Site-Name stand.
    Hat alles wunderbar geklappt
    Grüße aus dem verschneiten Allgäu
    Bernd

  4. Hallo Herr Kappen,

    ich bin Ihnen gerade zu tiefstem Dank verpflichtet!
    Endlich hat das Herabstufen funktioniert. Ich war am verzweifeln!

    Vielen lieben Dank für das verständliche Teilen Ihres Wissens!

    Grüße aus der Lüneburger Heide

  5. Hallo,

    danke für den Beitrag. jetzt sind die alten DCs aus der Domäne raus. Seit ca. 10 Jahren sind die beiden Einträge falsch. Wieso hat alles trotzdem alles funktioniert?

    Vielen Dank für den Beitrag…..

    • Hallo Michael,
      ich vermute der Wert ist im laufenden Betrieb kaum in Nutzung oder ist für viele Dinge nicht relevant, die dann “einfach so” funktionieren. Bei einer Anpassung am AD wie der Entfernung von alten Systemen kommt er dann zum Tragen, ist falsch und blockiert eine Herunterstufung. Aber jetzt scheint es bei dir ja auch funktioniert zu haben 🙂
      LG, Jan

  6. Hat mir heute super aus der patsche geholfen DANKE !!!

  7. Hallo Herr Kappen!
    Top Anleitung, Danke. Ich möchte 2 alte DC demoten, habe 2 neue installiert.
    Muss ich: Die ForestDnsZones überprüfen und ggf. bearbeiten
    für jeden einzelnen Server machen?

    LG Roman

Schreibe einen Kommentar

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