10
DC FSMO Rollen übertragen
Hallo,
bei uns ist gerade durch ein Infrastrukturumstellung auch der Austausch der DCs auf der Liste. Aktuell haben wir zwei 2016er am laufen. Die neuen DCs sind dann 2022er. Einen der DCs habe ich schon auf einem zweiten Host unter Hyper-V installiert und zum DC heraufgestuft. Die Replikation lief problemlos.
Jetzt wollte ich den 2022er als neuen Master einrichten und die FSMOs per Powershell übertragen. Wie das geht ist mir bewusst. Meine Frage ist jetzt, wie ich größere Probleme vermeide.
Bei den zwei 2016er ist immer der andere DC als Primär und 127.0.0.1 als Sekundäre eingetragen. Das gibt einem Microsoft so auch als Best Practice an(es sei denn, da hätte sich was geändert).
Ich würde also jetzt beim 2022er irgendeinen der beiden 2016er DCs als Primär eintragen und dann 127.0.0.1 wieder als Sekundär. Danach die FSMOs übertragen. NTP Einstellungen prüfen.
Danach an den Clients den neuen 2022er DC als Primär eintragen und flushdns ausführen.
Ein paar Tage alles beobachten.
Sollte alles korrekt ablaufen einen der beiden 2016er herabstufen(idealerweise nicht den, der im 2022er eingetragen wurde :D ).
Habe ich hier den Ablauf soweit korrekt dargestellt?
Muss der User, der die FSMO Rollen überträgt Mitglied einer bestimmten Gruppe sein oder reicht "Domänen-Admins"?
Grüße
bei uns ist gerade durch ein Infrastrukturumstellung auch der Austausch der DCs auf der Liste. Aktuell haben wir zwei 2016er am laufen. Die neuen DCs sind dann 2022er. Einen der DCs habe ich schon auf einem zweiten Host unter Hyper-V installiert und zum DC heraufgestuft. Die Replikation lief problemlos.
Jetzt wollte ich den 2022er als neuen Master einrichten und die FSMOs per Powershell übertragen. Wie das geht ist mir bewusst. Meine Frage ist jetzt, wie ich größere Probleme vermeide.
Bei den zwei 2016er ist immer der andere DC als Primär und 127.0.0.1 als Sekundäre eingetragen. Das gibt einem Microsoft so auch als Best Practice an(es sei denn, da hätte sich was geändert).
Ich würde also jetzt beim 2022er irgendeinen der beiden 2016er DCs als Primär eintragen und dann 127.0.0.1 wieder als Sekundär. Danach die FSMOs übertragen. NTP Einstellungen prüfen.
Danach an den Clients den neuen 2022er DC als Primär eintragen und flushdns ausführen.
Ein paar Tage alles beobachten.
Sollte alles korrekt ablaufen einen der beiden 2016er herabstufen(idealerweise nicht den, der im 2022er eingetragen wurde :D ).
Habe ich hier den Ablauf soweit korrekt dargestellt?
Muss der User, der die FSMO Rollen überträgt Mitglied einer bestimmten Gruppe sein oder reicht "Domänen-Admins"?
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 31654921601
Url: https://administrator.de/forum/dc-fsmo-rollen-uebertragen-31654921601.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
10 Kommentare
Neuester Kommentar
Hi,
das Eine hat mit dem Anderen nichts zu tun.
Die Reihenfolge der DNS-Server in der TCP/IP-Konfiguration des DC/DNS sollte man so einrichten, wie von Dir geschrieben. Primär der/ein Partner DC/DNS und sekundär sich selbst. Immer unter der Voraussetzung, dass die DNS-Zonen AD-integriert sind und auf alle DC übertragen werden. Das ist zwar seit einiger Zeit Standard, muss aber im konkreten Fall nicht unbedingt so eingestellt sein. Das könnte jemand einmal geändert haben - sollte man also explizit überprüfen.
Das Übertragen der FSMO hat aber damit überhaupt nichts zu tun. Der DNS-Dienst auf einem DC ist keine FSMO-Rolle.
Wenn Du die Clients eh umstellen willst, dass sie den neuen DC/DNS als primären DNS-Server nutzen sollen, dann kannst Du das vollkommen losgelöst von der Übertragung der FSMO tun. Es sollte nur vor dem Herunterstufen des alten DC/DNS erfolgen, wenn dieser am Client als DNS-Server eingetragen ist, weil der Server dabei auch seine DNS-Zonen verliert.
E.
Edit: Wenn es Timing-Probleme im Ablauf geben sollte, dann kann man nach dem Herunterstufen eines alten DC/DNS diesen auch weiterhin als DNS-Server für die diesen noch verwendenden Clients verfügbar machen. Entweder dadurch, dass man seine IP-Adresse an einen der neuen DC/DNS überträgt oder indem man den DNS-Server auf dem heruntergestuften Server anschließend so einrichtet, dass er alle Anfragen an einen der neuen DC/DNS weiterleitet (Cache-Only-Betrieb). Damit gewinnt man Zeit bei der Umstellung der DNS-Clients.
das Eine hat mit dem Anderen nichts zu tun.
Die Reihenfolge der DNS-Server in der TCP/IP-Konfiguration des DC/DNS sollte man so einrichten, wie von Dir geschrieben. Primär der/ein Partner DC/DNS und sekundär sich selbst. Immer unter der Voraussetzung, dass die DNS-Zonen AD-integriert sind und auf alle DC übertragen werden. Das ist zwar seit einiger Zeit Standard, muss aber im konkreten Fall nicht unbedingt so eingestellt sein. Das könnte jemand einmal geändert haben - sollte man also explizit überprüfen.
Das Übertragen der FSMO hat aber damit überhaupt nichts zu tun. Der DNS-Dienst auf einem DC ist keine FSMO-Rolle.
Wenn Du die Clients eh umstellen willst, dass sie den neuen DC/DNS als primären DNS-Server nutzen sollen, dann kannst Du das vollkommen losgelöst von der Übertragung der FSMO tun. Es sollte nur vor dem Herunterstufen des alten DC/DNS erfolgen, wenn dieser am Client als DNS-Server eingetragen ist, weil der Server dabei auch seine DNS-Zonen verliert.
E.
Edit: Wenn es Timing-Probleme im Ablauf geben sollte, dann kann man nach dem Herunterstufen eines alten DC/DNS diesen auch weiterhin als DNS-Server für die diesen noch verwendenden Clients verfügbar machen. Entweder dadurch, dass man seine IP-Adresse an einen der neuen DC/DNS überträgt oder indem man den DNS-Server auf dem heruntergestuften Server anschließend so einrichtet, dass er alle Anfragen an einen der neuen DC/DNS weiterleitet (Cache-Only-Betrieb). Damit gewinnt man Zeit bei der Umstellung der DNS-Clients.
1
Moin @preysa,
ich würde die Vorgehensweise einen Ticken anders machen, dann muss man an den Clients genau 0 umstellen.
Und zwar folgend.
Als erstes natürlich Backups durchlaufen lassen! 😁
Dann, da du eh zwei DC's hast, würde ich Abends oder am WE, sprich ausserhalb der Kernarbeitszeiten, einen der alten DC und zwar als erstes denn, der nicht die FSMO Rollen hat, herunterstufen, vollständig aus der Domäne schmeissen (unjoinen) und auschalten. Danach sollte man im AD kontrollieren ob das entsprechende Computer-Objekt des gerade "gelöschten" DC's, beim "Domain Unjoin” auch tatsächlich gelöscht wurde, wenn nicht dann muss dieses als nächstes von Hand gelöscht werden.
Im nächsten Schritt würde ich eine neue Windows-Server-VM Aufsetzen und dieser mindestens die gleiche IP geben, wie auch der vorher heruntergestufte DC hatte. Man kann dieser auch denselben Namen des vorher heruntergestuften DC's geben, doch das ist nicht notwendig, wenn der vorherige DC auch nur DC und sonst nichts anderes war.
Dann würde ich diese neue VM zu einem DC heraufstufen, danach die AD und DNS Konfiguration noch kurz prüfen und auch ob die SYSVOL Replikation sauber durchgelaufen ist und wenn alles OK ist, dann ist der erste DC schon mal migriert.
Am nächsten Tag würde ich die FSMO Rollen von dem noch vorhandenen 2016er auf den neuen 2022er schieben und Abends oder am WE mit diesem das gleiche Spielchen durchspielen wie auch mit dem vorherigen 2016er.
Sprich, den noch verbliebenen 2016er DC, heruntergestuften, unjoinen, AD Putzen und an seiner Stelle kommt dann mit der gleichen IP, wie auch im vorherigen Schritt, einfach ein neuer 2022er DC.
Und so haben die neuen DC's die gleiche IP's wie auch die alten DC's hatten und somit musst du an den Clients auch genau 0 umstellen. 😉
Ähm, ja, apropos IP, respektive DHCP.
Wenn auf den alten DC's auch auf einem oder beiden auch ein DHCP Server läuft, dann muss dieser bei der Umstellung natürlich auch mitberücksichtigt werden.
Hier kommt es jedoch auf die Komplexität der bisherigen Konfiguration an.
Ist diese relativ übersichtlich, so würde ich die auf einem der neuen DC's einfach nachkonfigurieren.
Wenn diese jedoch etwas umfangreicher ist, dann würde ich denn DHCP Server ähnlich migrieren wie auch die DC Dienste, denn auch der DHCP Server kann redundant betrieben werden, sprich seine Konfiguration zu einem anderen Spiegeln und natürlich auch umgekehrt. 😉
Gruss Alex
bei uns ist gerade durch ein Infrastrukturumstellung auch der Austausch der DCs auf der Liste. Aktuell haben wir zwei 2016er am laufen. Die neuen DCs sind dann 2022er. Einen der DCs habe ich schon auf einem zweiten Host unter Hyper-V installiert und zum DC heraufgestuft. Die Replikation lief problemlos.
ich würde die Vorgehensweise einen Ticken anders machen, dann muss man an den Clients genau 0 umstellen.
Und zwar folgend.
Als erstes natürlich Backups durchlaufen lassen! 😁
Dann, da du eh zwei DC's hast, würde ich Abends oder am WE, sprich ausserhalb der Kernarbeitszeiten, einen der alten DC und zwar als erstes denn, der nicht die FSMO Rollen hat, herunterstufen, vollständig aus der Domäne schmeissen (unjoinen) und auschalten. Danach sollte man im AD kontrollieren ob das entsprechende Computer-Objekt des gerade "gelöschten" DC's, beim "Domain Unjoin” auch tatsächlich gelöscht wurde, wenn nicht dann muss dieses als nächstes von Hand gelöscht werden.
Im nächsten Schritt würde ich eine neue Windows-Server-VM Aufsetzen und dieser mindestens die gleiche IP geben, wie auch der vorher heruntergestufte DC hatte. Man kann dieser auch denselben Namen des vorher heruntergestuften DC's geben, doch das ist nicht notwendig, wenn der vorherige DC auch nur DC und sonst nichts anderes war.
Dann würde ich diese neue VM zu einem DC heraufstufen, danach die AD und DNS Konfiguration noch kurz prüfen und auch ob die SYSVOL Replikation sauber durchgelaufen ist und wenn alles OK ist, dann ist der erste DC schon mal migriert.
Am nächsten Tag würde ich die FSMO Rollen von dem noch vorhandenen 2016er auf den neuen 2022er schieben und Abends oder am WE mit diesem das gleiche Spielchen durchspielen wie auch mit dem vorherigen 2016er.
Sprich, den noch verbliebenen 2016er DC, heruntergestuften, unjoinen, AD Putzen und an seiner Stelle kommt dann mit der gleichen IP, wie auch im vorherigen Schritt, einfach ein neuer 2022er DC.
Und so haben die neuen DC's die gleiche IP's wie auch die alten DC's hatten und somit musst du an den Clients auch genau 0 umstellen. 😉
Ähm, ja, apropos IP, respektive DHCP.
Wenn auf den alten DC's auch auf einem oder beiden auch ein DHCP Server läuft, dann muss dieser bei der Umstellung natürlich auch mitberücksichtigt werden.
Hier kommt es jedoch auf die Komplexität der bisherigen Konfiguration an.
Ist diese relativ übersichtlich, so würde ich die auf einem der neuen DC's einfach nachkonfigurieren.
Wenn diese jedoch etwas umfangreicher ist, dann würde ich denn DHCP Server ähnlich migrieren wie auch die DC Dienste, denn auch der DHCP Server kann redundant betrieben werden, sprich seine Konfiguration zu einem anderen Spiegeln und natürlich auch umgekehrt. 😉
Gruss Alex
Moin,
+1 für @MysticFoxDE vorgehen
Ich würde aber immer mal noch vor dem Herabstufen des ersten DCs einen dritten, temporären DC hochziehen. Nur für den Fall, dass dir der kurzzeitig einzige DC wegbricht. Murphys Law und so.
Diese gesamte Vorgehensweise hat auch den Vorteil, dass man nichts an sämtlichen Switches und sonstige Netzwerkdevices ändern muss. An den Clients ist das ja, dank DHCP easy going.
Ist diese relativ übersichtlich, so würde ich die auf einem der neuen DC's einfach nachkonfigurieren.
Ich würde die DHCP-Rolle immer ex- und dann am neuen importieren. Man bedenke die ganzen Leases. Sonst kann es (kurzweilen) noch zu Ip-Konflikten kommen. Achja, falls VLANs zum Einsatz kommen: an die Helper-Adressen denken, sollte sich dann doch die IP ändern. Oder direkt mal ein DHCP-Cluster aufsetzen
+1 für @MysticFoxDE vorgehen
Ich würde aber immer mal noch vor dem Herabstufen des ersten DCs einen dritten, temporären DC hochziehen. Nur für den Fall, dass dir der kurzzeitig einzige DC wegbricht. Murphys Law und so.
Diese gesamte Vorgehensweise hat auch den Vorteil, dass man nichts an sämtlichen Switches und sonstige Netzwerkdevices ändern muss. An den Clients ist das ja, dank DHCP easy going.
Wenn auf den alten DC's auch auf einem oder beiden auch ein DHCP Server läuft, dann muss dieser bei der Umstellung natürlich auch mitberücksichtigt werden.
Hier kommt es jedoch auf die Komplexität der bisherigen Konfiguration an.Ist diese relativ übersichtlich, so würde ich die auf einem der neuen DC's einfach nachkonfigurieren.
Ich würde die DHCP-Rolle immer ex- und dann am neuen importieren. Man bedenke die ganzen Leases. Sonst kann es (kurzweilen) noch zu Ip-Konflikten kommen. Achja, falls VLANs zum Einsatz kommen: an die Helper-Adressen denken, sollte sich dann doch die IP ändern. Oder direkt mal ein DHCP-Cluster aufsetzen
Danke an die ganzen Tipps und Vorschläge. Tatsächlich habe ich es jetzt einfach auf die konventionelle Art gemacht. Bis auf die nicht vorhandenen Berechtigungen hat es keine Fehler gegeben. Aber Powershell ist ja so nett und sagt einem gleich welcher Gruppe man angehören muss Danach ging die Übergabe problemlos. Alle Member Server sind schon umgestellt und funken jetzt den 2022er an. Bei den Clients habe ich zwei Maschinen getestet und hier ebenfalls keine Probleme feststellen können. DHCP läuft bei uns tatsächlich keiner in der Domäne. Sind alle statisch vergeben. Bei den handvoll Clients auch kein Problem. Jetzt laufen gerade 3 DCs gleichzeitig. Sollte im Laufe der nächsten Woche nichts auffälliges passieren werde ich den ersten DCs herabstufen und dann schauen was passiert.
Danach ging die Übergabe problemlos. Alle Member Server sind schon umgestellt und funken jetzt den 2022er an. Bei den Clients habe ich zwei Maschinen getestet und hier ebenfalls keine Probleme feststellen können. DHCP läuft bei uns tatsächlich keiner in der Domäne. Sind alle statisch vergeben. Bei den handvoll Clients auch kein Problem. Jetzt laufen gerade 3 DCs gleichzeitig. Sollte im Laufe der nächsten Woche nichts auffälliges passieren werde ich den ersten DCs herabstufen und dann schauen was passiert.
Leider bin ich heute über ein Problem mit dem PDC gestoßen.
Die Rollen wurden alles verschoben.
zeigt mir den aktuellen richtigen PDC an.
Auf den Clients wird aber immer noch auf den alten Domain Controller Master verwiesen.
liefert mir das:
DC2022-01 ist der neue und richtige PDC.
Ich habe schon unregister/register durchgeführt.
Ebenso
Ich bin quasi diesem Thema gefolgt:
Windows Clients synchronisieren Zeit nicht mit DC
Leider schauen die ganzen Clients und Server noch immer auf den alten PDC obwohl ich den in de GPO abgeändert habe und mehrfach gpupdate probiert hatte.
Wo kann ich noch suchen?
Vielen Dank
Die Rollen wurden alles verschoben.
dsquery server -hasfsmo pdczeigt mir den aktuellen richtigen PDC an.
Auf den Clients wird aber immer noch auf den alten Domain Controller Master verwiesen.
w32tm /monitorliefert mir das:
dc1.domain.de[[fe80::f957:97c:1a11:d985%5]:123]:
ICMP: 0ms Verzögerung
NTP: +66.1418476s Offset von dc2022-01.domain.de
RefID: sv1.ggsrv.de [144.76.76.107]
Stratum: 3
dc2.domain.de[192.168.11.101:123]:
ICMP: 0ms Verzögerung
NTP: +66.1557937s Offset von DC2022-01.domain.de
RefID: DC1.domain.de [192.168.11.100]
Stratum: 4
DC2022-01.domain.de *** PDC ***[192.168.11.102:123]:
ICMP: 0ms Verzögerung
NTP: +0.0000000s Offset von DC2022-01.domain.de
RefID: ntp4.lwlcom.net [193.203.3.171]
Stratum: 2DC2022-01 ist der neue und richtige PDC.
Ich habe schon unregister/register durchgeführt.
w32tm /unregister
w32tm /registerEbenso
w32tm /config /syncfromflags:domhier /updateIch bin quasi diesem Thema gefolgt:
Windows Clients synchronisieren Zeit nicht mit DC
Leider schauen die ganzen Clients und Server noch immer auf den alten PDC obwohl ich den in de GPO abgeändert habe und mehrfach gpupdate probiert hatte.
Wo kann ich noch suchen?
Vielen Dank
Bzgl. des Zeitabgleichs ist das ok so. Domain Member synchronisieren nicht bevorzugt mit dem PDC Emulator sondern mit jenem DC, über welchen der letzte Kontakt zur Domäne hersgestellt wurde. z.B. bein Start (Computer Login), beim Login eines Benutzers oder beim GpUpdate.
Nur DC's synchronisieren bevorzugt mit dem PDC Emulator der selben Domäne. Bei Multi Domain AD sychroniseren PDS's bevorzugt mit dem PDC der Stammdomäne. Und den PDC der Stammdomäne kann man mit einer externen Zeitquelle synchronisieren.
Nur DC's synchronisieren bevorzugt mit dem PDC Emulator der selben Domäne. Bei Multi Domain AD sychroniseren PDS's bevorzugt mit dem PDC der Stammdomäne. Und den PDC der Stammdomäne kann man mit einer externen Zeitquelle synchronisieren.
3
Leider synchronisiert sich einer der alten DCs auch noch mit dem alten PDC. Auf dem DC, der nicht Master und nicht mehr PDC ist steht jetzt
Free-running System Clock
Ich denke da kann was nicht stimmen :/
EDIT: Hat etwas Zeit benötigt. Nach einem resync stand da dann der neue PDC drin. Trotzdem will der zweite DC immer noch nicht den neuen PDC abfragen...
Zumindest haben jetzt alle Geräte wieder die Richtige Zeit. Ich plane allerdings einen der beiden alten DCs offline zu nehmen. Was passiert dann mit den Anfragen, wenn bei manchen Geräte noch der alte DC als PDC hinterlegt ist?
Free-running System Clock
Ich denke da kann was nicht stimmen :/
EDIT: Hat etwas Zeit benötigt. Nach einem resync stand da dann der neue PDC drin. Trotzdem will der zweite DC immer noch nicht den neuen PDC abfragen...
Zumindest haben jetzt alle Geräte wieder die Richtige Zeit. Ich plane allerdings einen der beiden alten DCs offline zu nehmen. Was passiert dann mit den Anfragen, wenn bei manchen Geräte noch der alte DC als PDC hinterlegt ist?
Moin @preysa,
ähm, dieses Rätsel kann glaube ich auflösen. 😁
Das kommt daher, weil per Default in den Einstellungen der VM unter Integrationsdienste die Zeistynchronisierung aktiv ist. Diese muss man insbesondere bei allen DC's und auch SQL und Exchange jedoch deaktivieren, sonst synchronisieren diese VM's die Zeit nicht wirklich mit den DC's, sondern mit dem entsprechenden Hyper-V Node auf dem diese gerade laufen. 🙃
Und nachdem du das gemacht hast, solltest du auf dem DC mit dem folgenden Befehl ...
... noch die richtigen Zeitserver für seine eigene Synchronisation eintragen.
Die ptp.de Server kannst du natürlich nach eigenem Gusto ersetzen.
Gruss Alex
Leider synchronisiert sich einer der alten DCs auch noch mit dem alten PDC. Auf dem DC, der nicht Master und nicht mehr PDC ist steht jetzt
Free-running System Clock
Ich denke da kann was nicht stimmen :/
Free-running System Clock
Ich denke da kann was nicht stimmen :/
ähm, dieses Rätsel kann glaube ich auflösen. 😁
Das kommt daher, weil per Default in den Einstellungen der VM unter Integrationsdienste die Zeistynchronisierung aktiv ist. Diese muss man insbesondere bei allen DC's und auch SQL und Exchange jedoch deaktivieren, sonst synchronisieren diese VM's die Zeit nicht wirklich mit den DC's, sondern mit dem entsprechenden Hyper-V Node auf dem diese gerade laufen. 🙃
Und nachdem du das gemacht hast, solltest du auf dem DC mit dem folgenden Befehl ...
w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de ptbtime4.ptb.de" /syncfromflags:all /reliable:yes /update ... noch die richtigen Zeitserver für seine eigene Synchronisation eintragen.
Die ptp.de Server kannst du natürlich nach eigenem Gusto ersetzen.
Gruss Alex
Tatsächlich leider nicht. Die Host Synchronisation haben ich schon bei allen deaktiviert. Ich habe aber mittlerweile mit folgendem Befehl dann was bewirkt
danach haben alle DCs den neuen PDC erkannt. Leider gibt es noch bei manchen Clients ein offset von unter 15 Sekunden.
Ich werde das noch beobachten. DCDIAG zeigt alles positiv. Ich hoffe dann steht dem demoting nichts im Wege.
W32tm /resync /rediscoverdanach haben alle DCs den neuen PDC erkannt. Leider gibt es noch bei manchen Clients ein offset von unter 15 Sekunden.
Ich werde das noch beobachten. DCDIAG zeigt alles positiv. Ich hoffe dann steht dem demoting nichts im Wege.
Es wäre jetzt auch kein Drama gewesen, wenn die Clients bis zum Herabstufen des alten DC diesen als Zeitquelle genutzt hätten. Spätestens, wenn dieser kein DC mehr oder gar komplett offline ist, werden sich die Clients einen anderen DC als Zeitquelle suchen.
Entspann Dich!
Entspann Dich!
1
