thenick
Goto Top

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

Content-Key: 22779380391

Url: https://administrator.de/contentid/22779380391

Printed on: May 11, 2024 at 10:05 o'clock

Member: Dani
Dani Sep 19, 2023 at 20:50:26 (UTC)
Goto Top
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.

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? face-wink 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
Member: Spirit-of-Eli
Spirit-of-Eli Sep 19, 2023 at 21:46:24 (UTC)
Goto Top
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
Member: Vision2015
Vision2015 Sep 20, 2023 at 04:30:16 (UTC)
Goto Top
Moin...

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
Member: NordicMike
NordicMike Sep 20, 2023 at 06:48:33 (UTC)
Goto Top
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.
Member: emeriks
emeriks Sep 20, 2023 updated at 10:19:20 (UTC)
Goto Top
Hi,
  1. Aktuelle Standorte und Subnetze sind bereits im AD abgebildet?
  2. Falls nein: Nachholen!
  3. Falls ja: Jetzt schon das neue Subnetz mit neuem Standort im AD anlegen und von allen DC's replizieren lassen.
  4. 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.
Member: TheNick
TheNick Sep 20, 2023 at 11:53:34 (UTC)
Goto Top
Zitat von @emeriks:

Hi,
  1. Aktuelle Standorte und Subnetze sind bereits im AD abgebildet?
  2. Falls nein: Nachholen!
  3. Falls ja: Jetzt schon das neue Subnetz mit neuem Standort im AD anlegen und von allen DC's replizieren lassen.
  4. 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?
Member: TheNick
TheNick Sep 20, 2023 at 12:06:58 (UTC)
Goto Top
Zitat von @Dani:

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? face-wink 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. ;)
Member: emeriks
emeriks Sep 20, 2023 at 13:50:22 (UTC)
Goto Top
Keine Netzwerkverbindung?
Hast Du etwa vor, ein Sub-Domäne aus dem Forest "ausziehen" zu lassen? Also diese beiden Domänen dauerhaft zu "trennen"?
Member: TheNick
TheNick Sep 21, 2023 at 04:11:14 (UTC)
Goto Top
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"?

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.
Member: Spirit-of-Eli
Spirit-of-Eli Sep 21, 2023 at 07:35:01 (UTC)
Goto Top
Zitat von @TheNick:

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"?

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.