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:
Get-ADDomain domain.local | ft InfrastructureMaster
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.
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
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
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
Hallo,
danke für die Rückmeldung 🙂
Schönen Gruß zurück aus dem Sauerland
Jan
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
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
Hat mir heute super aus der patsche geholfen DANKE !!!
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
Vielen Dank für diese Anleitung!
Hallo Herr Kappen,
danke für diese Anleitung. Hat mir beim Herabstufen unsers DC 2008 R2 sehr geholfen.
VG Matthias
Viiiiiiieeeeelen DANK,
endlich kann ich mich vom SBS2003 –> SBS2011 verabschieden 🙂
Oliver R.
einfach Spitze!
Ohne diese ADSI Anleitung hätte ich einen /forceremoval und manuelle Metadatenbereinung machen müssen.
Jetzt ist das Ganze sauber gelaufen und ich kann den 2008R2 endgueltig abschalten.
DNS und NTDS settings sollten trotz allem geprueft und ggf. bereinigt werden.
Vielen Dank!
Geniale Lösung, viel Ärger gespart, Problem effizient und professionell behoben. Den Kontakt hab ich mir gemerkt – wenns mal wieder eng wird, werde ich mich wieder melden.
DANKE DANKE DANKE
Danke sehr!! Ihr habt uns grad ein Wochenende gerettet :-))
Vielen Dank! Sehr hilfreicher Tipp!
Vielen vielen Dank für die Anleitung,
auch bei uns hat es dann geklappt mit dem Herunterstufen.
vg
Klasse. Hat auch mir sehr geholfen bei einem Kundenprojekt. Beschreibung vorbildlich.
Super Artikel, danke dir!
Hallo nach Winterberg,
perfekt, super dokumentiert, vielen Dank, Heiner Fritzemeier
Liebe Grüsse aus dem verschneiten Wien …
Danke für die Anleitung – Hat mir super geholfen
Hallo,
auch im Jahre 2024 hat mir die Anleitung super geholfen, eine Migration eines alten DCs sauber abzuschließen. In den beiden Einträgen war trotz vorheriger Übernahme der FSMO-Rollen auf einen der neuen DCs immer noch der alte Servername zu finden. Nach der Änderung in den neuen Namen ließ sich der alte sauber demoten. Wie einer meiner Vorredner schon sagte, hätte ich auch den Server per „force“ aus der Domäne entfernen können, aber irgendwann, wenn man es am wenigsten vermutet, fliegt einem ja so ein Konstrukt dann gerne mal um die Ohren.
Vielen Dank nochmal,
und schöne Grüße aus der Eifel!
Hallo Herr Kappen,
klasse Anleitung.
Hat mich auch davor bewahrt einen /forceremoval beim Kundenprojekt machen zu müssen und eine Altlast mitnehmen zu müssen.
Ich kann etwas zur Problem Entstehung beisteuern:
In meinem Fall handelte es sich um eine Small Business Domain welche zuvor von SBS 2003 auf SBS 2011 migriert worden war.
Hierbei waren die Einträge des alten SBS 2003 Servers nicht entfernet worden,
was jetzt bei der Ablösung mit einem Server 2022 zu diesem Problem geführt hat.
Vielen Dank dafür
und Grüße aus em Schwobaländle