10
Primary DCs Umzug in neue Subnetze
Hallo zusammen,
ich hoffe, ihr könnt mir zu folgendem Szenario einen oder mehrere gute Ratschläge geben:
Ich habe 2 Domänen: contoso.com und sub.contoso.com. Beide Domänen werden auf 2 DCs an der Main Site abgebildet, wobei sub.contoso.com auch noch 2 DCs an anderen SItes angehören. Es handelt sich um Windows Server 2019 Datacenter-Server.
2 der DCs der Main Site sind VMs (VMWare), welche via OVA-Export auf andere Hypervisoren (ESXi-Hosts) migriert werden sollen. Die Lokation, auf welcher die DCs vorher liefen, wird danach abgeschaltet. Um den Export zu ermöglichen, müssen die beiden DCs ebenfalls ausgeschaltet sein. Diese replizieren also nicht mehr. Nun die Knackpunkte:
Die DCs, welche exportiert werden sollen, sollen sämtliche FSMO- und Betriebsrollen innehaben. Ferner sollen diese auf den neuen ESXi-Hosts andere IP-Adressen/Subnetze erhalten. Kommunikation mit den secondary DCs am alten Standort ist nicht länger nötig, jedoch müssen die DCs nach wie vor mit den DCs der anderen Sites kommunizieren.
Kommunikation der alten mit den neuen Hypervisoren ist übrigens nicht möglich. Ich kann also nicht einfach dort neue DCs aufsetzen und die Rollen übertragen, was natürlich die sauberste Lösung wäre.
Wie würdet ihr hier vorgehen bzw. wie sieht die best practise für so einen Fall aus?
Ich freue mich auf jegliche Tipps/Ratschlage und sage schon einmal vielen Dank im Voraus,
Nick
ich hoffe, ihr könnt mir zu folgendem Szenario einen oder mehrere gute Ratschläge geben:
Ich habe 2 Domänen: contoso.com und sub.contoso.com. Beide Domänen werden auf 2 DCs an der Main Site abgebildet, wobei sub.contoso.com auch noch 2 DCs an anderen SItes angehören. Es handelt sich um Windows Server 2019 Datacenter-Server.
2 der DCs der Main Site sind VMs (VMWare), welche via OVA-Export auf andere Hypervisoren (ESXi-Hosts) migriert werden sollen. Die Lokation, auf welcher die DCs vorher liefen, wird danach abgeschaltet. Um den Export zu ermöglichen, müssen die beiden DCs ebenfalls ausgeschaltet sein. Diese replizieren also nicht mehr. Nun die Knackpunkte:
Die DCs, welche exportiert werden sollen, sollen sämtliche FSMO- und Betriebsrollen innehaben. Ferner sollen diese auf den neuen ESXi-Hosts andere IP-Adressen/Subnetze erhalten. Kommunikation mit den secondary DCs am alten Standort ist nicht länger nötig, jedoch müssen die DCs nach wie vor mit den DCs der anderen Sites kommunizieren.
Kommunikation der alten mit den neuen Hypervisoren ist übrigens nicht möglich. Ich kann also nicht einfach dort neue DCs aufsetzen und die Rollen übertragen, was natürlich die sauberste Lösung wäre.
Wie würdet ihr hier vorgehen bzw. wie sieht die best practise für so einen Fall aus?
Ich freue mich auf jegliche Tipps/Ratschlage und sage schon einmal vielen Dank im Voraus,
Nick
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 22779380391
Url: https://administrator.de/forum/primary-dcs-umzug-in-neue-subnetze-22779380391.html
Ausgedruckt am: 13.03.2025 um 09:03 Uhr
10 Kommentare
Neuester Kommentar
Moin,
Das würde ich a) von einem AD Spezialist verifizieren lassen und b) im Labor einmal nachstellen. Nicht das du hinterher gar kein AD mehr hast.
Wenn kein AD Spezialist im Haus ist, hol die ein Systemhaus. Wenn diese sagen sie kriegen das hin, sollen sie es tun. Ansonsten Finger heben und sagen "Geht so nicht".
Gruß,
Dani
Kommunikation der alten mit den neuen Hypervisoren ist übrigens nicht möglich. Ich kann also nicht einfach dort neue DCs aufsetzen und die Rollen übertragen, was natürlich die sauberste Lösung wäre.
Und wie sprechen die bestehenden Clients und Server mit der neuen Site bzw. den DCs? Mich würde brennend interessieren, wer solche Design Entscheidung trifft? Kann eigentlich nur ein Azubi oder Student sein.2 der DCs der Main Site sind VMs (VMWare), welche via OVA-Export auf andere Hypervisoren (ESXi-Hosts) migriert werden sollen.
Kann mir nicht vorstellen, dass das gut geht. Alleine schon bezüglich Verfügbarkeit des ADs für Clients, Replikationen zwischen DCs, Änderungen der IP Einstellungen. Was machst du wenn was schief geht? Du kannst meiner Meinung nach auch nicht mehr zurück auf die alten DCs. Weil ziemlich sicher andere Server und Clients Informationen ins AD geschrieben haben, die dann nicht mehr da sind. Da rede ich nicht mal von weiteren Microsoft Produkten wie Exchange Server, Sharepoint, etc. oder weitere 3rd Party Anwendungen.Das würde ich a) von einem AD Spezialist verifizieren lassen und b) im Labor einmal nachstellen. Nicht das du hinterher gar kein AD mehr hast.
Wie würdet ihr hier vorgehen bzw. wie sieht die best practise für so einen Fall aus?
Konnten dir die bestehenden 275 Fragen zu den Thema nicht weiterhelfen? Wenn kein AD Spezialist im Haus ist, hol die ein Systemhaus. Wenn diese sagen sie kriegen das hin, sollen sie es tun. Ansonsten Finger heben und sagen "Geht so nicht".Gruß,
Dani
Moin,
ich schließe mich voll und ganz @Dani an.
Wenn ich das Thema so auf den Tisch bekommen würde, dann wäre meine Aussage auch "nicht mit mir".
Gruß
Spirit
ich schließe mich voll und ganz @Dani an.
Wenn ich das Thema so auf den Tisch bekommen würde, dann wäre meine Aussage auch "nicht mit mir".
Gruß
Spirit
Moin...
Datensicherung natürlich vorher Prüfen und Testen ist Pflicht!
und natürlich wie @Dani schon geschrieben hat, wäre zu Prüfen, welche abhängigkeiten bestehen!
das du dir dazu Hilfe holen sollst, sehe ich auch so!
Frank
2 der DCs der Main Site sind VMs (VMWare), welche via OVA-Export auf andere Hypervisoren (ESXi-Hosts) migriert werden sollen.
da würde ich aus dem Bauch raus sagen, Transportiere den ESXI-Host zum neuen Standort, dort machst du dann eine ordentliche Migration der DCs... dann können die Bleche ja bei bedarf zurück.Datensicherung natürlich vorher Prüfen und Testen ist Pflicht!
und natürlich wie @Dani schon geschrieben hat, wäre zu Prüfen, welche abhängigkeiten bestehen!
das du dir dazu Hilfe holen sollst, sehe ich auch so!
Frank
Es ist ja recht egal auf welchem Hypervisor der DC läuft. DNS muss funktionieren. Alle DCs in allen neuen und alten Standorten müssen sich über DNS gegenseitig finden, und die Clients auch. Also IP Routing und DNS vorbereiten, dann klappt jeder Umzug.
Hi,
E.
Edit:
Beachte ggf. DNS-Clients, welche ggf. die alten DC als DNS-Server eingetragen hatten. So oder so - neue DC oder alte transportiert - die IP-Adresse wird sich ändern.
- Aktuelle Standorte und Subnetze sind bereits im AD abgebildet?
- Falls nein: Nachholen!
- Falls ja: Jetzt schon das neue Subnetz mit neuem Standort im AD anlegen und von allen DC's replizieren lassen.
- DC' NICHT per OVA-Export/Import transportieren, sondern statt dessen neue DC im neuen Subnetz aufsetzen. Wenn diese voll repliziert sind, dann die alten DC's, welche ursprünglich transportiert werden sollten, demoten und danach löschen.
E.
Edit:
Beachte ggf. DNS-Clients, welche ggf. die alten DC als DNS-Server eingetragen hatten. So oder so - neue DC oder alte transportiert - die IP-Adresse wird sich ändern.
Zitat von @emeriks:
Hi,
E.
Edit:
Beachte ggf. DNS-Clients, welche ggf. die alten DC als DNS-Server eingetragen hatten. So oder so - neue DC oder alte transportiert - die IP-Adresse wird sich ändern.
Hi,
- Aktuelle Standorte und Subnetze sind bereits im AD abgebildet?
- Falls nein: Nachholen!
- Falls ja: Jetzt schon das neue Subnetz mit neuem Standort im AD anlegen und von allen DC's replizieren lassen.
- DC' NICHT per OVA-Export/Import transportieren, sondern statt dessen neue DC im neuen Subnetz aufsetzen. Wenn diese voll repliziert sind, dann die alten DC's, welche ursprünglich transportiert werden sollten, demoten und danach löschen.
E.
Edit:
Beachte ggf. DNS-Clients, welche ggf. die alten DC als DNS-Server eingetragen hatten. So oder so - neue DC oder alte transportiert - die IP-Adresse wird sich ändern.
Hi,
aktuelle Sites und Subnetze sind in der Tat abgebildet. Auch habe ich bereits die neue Site und das neue Subnetz hinzugefügt. Problem hierbei ist, dass die "alte" Site keine Netzwerkverbindung zur "neuen" Site hat. Ich kann also die FSMO-Rollen nicht einfach übertragen.
Außerdem fände keine Replizierung von contoso.com statt, da die beiden anderen Standorte, auf welche sowohl die neue als auch die alte Site Zugriff haben, nur sub.contoso.com angehören. Aufgrund dieser Tatsache kann ich die beiden Forrest-Rollen auch nicht einfach "über Bande" transferieren. Bei den sub.contoso.com ginge das.
Ich weiß, dass man Rollen auch neu zuweisen kann, wenn ein Master dauerhaft offline ist. Wäre das evtl. eine Option in dem Fall?
Zitat von @Dani:
Moin,
Moin,
Kommunikation der alten mit den neuen Hypervisoren ist übrigens nicht möglich. Ich kann also nicht einfach dort neue DCs aufsetzen und die Rollen übertragen, was natürlich die sauberste Lösung wäre.
Und wie sprechen die bestehenden Clients und Server mit der neuen Site bzw. den DCs? Mich würde brennend interessieren, wer solche Design Entscheidung trifft? Kann eigentlich nur ein Azubi oder Student sein.Die bestehenden Clients und Server gehören nur sub.contoso.com an. Die können noch miteinander reden. Trotzdem kann ich contoso.com als root Domain und deren DCs eben nicht ignorieren, auch wenn die eigentlich gar keine Rolle spielen. Falls das bei meinem ersten Post missverständlich war: Die "alte" Site wird nach der Migration vollständig abgeschaltet. Es muss damit dann also auch nicht mehr kommuniziert werden.
2 der DCs der Main Site sind VMs (VMWare), welche via OVA-Export auf andere Hypervisoren (ESXi-Hosts) migriert werden sollen.
Kann mir nicht vorstellen, dass das gut geht. Alleine schon bezüglich Verfügbarkeit des ADs für Clients, Replikationen zwischen DCs, Änderungen der IP Einstellungen. Was machst du wenn was schief geht? Du kannst meiner Meinung nach auch nicht mehr zurück auf die alten DCs. Weil ziemlich sicher andere Server und Clients Informationen ins AD geschrieben haben, die dann nicht mehr da sind. Da rede ich nicht mal von weiteren Microsoft Produkten wie Exchange Server, Sharepoint, etc. oder weitere 3rd Party Anwendungen.Es gibt an der "alten" Site keine Clients mehr, welche ein AD bräuchten. Und die entfernten Sites haben je einen eigenen DC. Replikation wäre wahrscheinlich auch kein Thema, da sich die Branch Offices untereinander nicht sehen und die DCs an der "alten" Main Site einfach abgeschaltet werden. Im Grunde ist das also lediglich ein shutdown und power on für die Kisten, abgesehen vom neuen Subnetz.
Das würde ich a) von einem AD Spezialist verifizieren lassen und b) im Labor einmal nachstellen. Nicht das du hinterher gar kein AD mehr hast.
Absolut. Leider ist Zeit ein Faktor, wie bei fast allem.
Wie würdet ihr hier vorgehen bzw. wie sieht die best practise für so einen Fall aus?
Konnten dir die bestehenden 275 Fragen zu den Thema nicht weiterhelfen? Wenn kein AD Spezialist im Haus ist, hol die ein Systemhaus. Wenn diese sagen sie kriegen das hin, sollen sie es tun. Ansonsten Finger heben und sagen "Geht so nicht".Nach dem Lesen einiger Fragen habe ich entschieden, dass meine Situation hier so exotisch ist, dass sie einen eigenen Thread rechtfertigt. ;)
Keine Netzwerkverbindung?
Hast Du etwa vor, ein Sub-Domäne aus dem Forest "ausziehen" zu lassen? Also diese beiden Domänen dauerhaft zu "trennen"?
Hast Du etwa vor, ein Sub-Domäne aus dem Forest "ausziehen" zu lassen? Also diese beiden Domänen dauerhaft zu "trennen"?
Zitat von @emeriks:
Keine Netzwerkverbindung?
Hast Du etwa vor, ein Sub-Domäne aus dem Forest "ausziehen" zu lassen? Also diese beiden Domänen dauerhaft zu "trennen"?
Keine Netzwerkverbindung?
Hast Du etwa vor, ein Sub-Domäne aus dem Forest "ausziehen" zu lassen? Also diese beiden Domänen dauerhaft zu "trennen"?
Ne. Es wird quasi die Main Site gewechselt. Nur hat eben die alte Main Site keine Verbindung zur neuen, weshalb ich bei letzterer nicht einfach neue Kisten hochziehen und die Rollen übertragen kann.
Zitat von @TheNick:
Ne. Es wird quasi die Main Site gewechselt. Nur hat eben die alte Main Site keine Verbindung zur neuen, weshalb ich bei letzterer nicht einfach neue Kisten hochziehen und die Rollen übertragen kann.
Zitat von @emeriks:
Keine Netzwerkverbindung?
Hast Du etwa vor, ein Sub-Domäne aus dem Forest "ausziehen" zu lassen? Also diese beiden Domänen dauerhaft zu "trennen"?
Keine Netzwerkverbindung?
Hast Du etwa vor, ein Sub-Domäne aus dem Forest "ausziehen" zu lassen? Also diese beiden Domänen dauerhaft zu "trennen"?
Ne. Es wird quasi die Main Site gewechselt. Nur hat eben die alte Main Site keine Verbindung zur neuen, weshalb ich bei letzterer nicht einfach neue Kisten hochziehen und die Rollen übertragen kann.
Dann Bau temporär eine Verbindung für die Migration. Warum willst du alles sonst so kompliziert machen. Das ist auch nicht best practice.
