20
Hyper-V AD Umgebung "einfrieren" und später wiederverwenden
Hallo liebe Gemeinde,
ich habe eine Frage zu einer WIN2019 Umgebung, die aus diversen physischen hosts besteht, auf denen mittels Hyper-V eine AD Umgebung (zwei DCs, diverse Accounts, einige GPOs) mit Windows Fileservern und diversen anderen VMs laufen wird. Es gibt irgendwann Tag X bei der Installation bzw. Konfiguration, an dem dieser Stand in irgendeiner Art und Weise gesichert werden soll, um ein halbes Jahr bis Jahr später genau diesen Stand an einem anderen Standort (mit anderen Nutzernamen, sonst bleibt alles gleich) auf identischer Hardware ebenfalls in Produktion übernehmen zu können.
Was wäre hierzu die mit am wenigsten Aufwand beste Vorgehensweise? Ein Windows Image von sämtlichen hosts ziehen (während die VMs runtergefahren sind) und dieses dann zu gegebener Zeit im neuen Standort wieder installieren? Und wird das AD diese lange Verweildauer überleben?
Für input wäre ich sehr dankbar. Auch ganz andere Ansätze, die mir die Sache erleichtern, sind herzlich willkommen.
Servus,
Badde
ich habe eine Frage zu einer WIN2019 Umgebung, die aus diversen physischen hosts besteht, auf denen mittels Hyper-V eine AD Umgebung (zwei DCs, diverse Accounts, einige GPOs) mit Windows Fileservern und diversen anderen VMs laufen wird. Es gibt irgendwann Tag X bei der Installation bzw. Konfiguration, an dem dieser Stand in irgendeiner Art und Weise gesichert werden soll, um ein halbes Jahr bis Jahr später genau diesen Stand an einem anderen Standort (mit anderen Nutzernamen, sonst bleibt alles gleich) auf identischer Hardware ebenfalls in Produktion übernehmen zu können.
Was wäre hierzu die mit am wenigsten Aufwand beste Vorgehensweise? Ein Windows Image von sämtlichen hosts ziehen (während die VMs runtergefahren sind) und dieses dann zu gegebener Zeit im neuen Standort wieder installieren? Und wird das AD diese lange Verweildauer überleben?
Für input wäre ich sehr dankbar. Auch ganz andere Ansätze, die mir die Sache erleichtern, sind herzlich willkommen.
Servus,
Badde
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: 585430
Url: https://administrator.de/forum/hyper-v-ad-umgebung-einfrieren-und-spaeter-wiederverwenden-585430.html
Ausgedruckt am: 27.12.2024 um 16:12 Uhr
20 Kommentare
Neuester Kommentar
Hi,
das kann man so machen. Alle DC-VM zusammen herunterfahren und die VM-Dateien zusammen als Satz kopieren.
Dann kann man diese VM-Satz später irgendwo anders wieder hochfahren, egal, wie lange diese inzwischen aus waren. Unter der Voraussetzung, dass diese beiden Instanzen dieser Domäne und der DC sich dann untereinander nicht "sehen" und das auch niemals angedacht ist.
E.
das kann man so machen. Alle DC-VM zusammen herunterfahren und die VM-Dateien zusammen als Satz kopieren.
Dann kann man diese VM-Satz später irgendwo anders wieder hochfahren, egal, wie lange diese inzwischen aus waren. Unter der Voraussetzung, dass diese beiden Instanzen dieser Domäne und der DC sich dann untereinander nicht "sehen" und das auch niemals angedacht ist.
E.
Moin,
Zieh doch einfach ein Image aller Platten des Hyper-V-Servers und restauriere das am Tag X
lks
Zieh doch einfach ein Image aller Platten des Hyper-V-Servers und restauriere das am Tag X
lks
Hallo,
zu den prinzipiellen Problemen eines solchen Vorgehens hatten wir neulich schon mal eine angeregte Diskussion: Active Directory (DC) klonen
Grüße
lcer
zu den prinzipiellen Problemen eines solchen Vorgehens hatten wir neulich schon mal eine angeregte Diskussion: Active Directory (DC) klonen
Grüße
lcer
Verstehe. Das würde also bedeuten, mein AD zerlegt es da in keinster Weise? Ich hab da was im Hinterkopf, dass es nach einiger Zeit Probleme gibt, wenn das AD nicht mehr online/erreichbar ist. Die anderen VMs können sich nach Zeit X ganz normal am AD authentifizieren? Gilt das auch für die Clients? Oder warte ich da besser mit der Integration am anderen Standort?
Auch eine gute Idee. Was für Software würdest Du dazu empfehlen?
Hallo,
wie @emeriks richtig schreibt:
Die kopierten VMs haben dann ja alle die SIDs ihrer Originale. Und dass man geklonte Rechner, noch dazu Server und DCs nicht zusammenbringen soll, ist ja hinlänglich bekannt.
Das nächste wäre die Lizenz-Problematik: eine solche "Doppelnutzung" der Server-Lizenzen und CALs dürfte M$ sicher nicht erfreuen.
Jürgen
wie @emeriks richtig schreibt:
dass diese beiden Instanzen dieser Domäne und der DC sich dann untereinander nicht "sehen" und das auch niemals angedacht ist.
Die kopierten VMs haben dann ja alle die SIDs ihrer Originale. Und dass man geklonte Rechner, noch dazu Server und DCs nicht zusammenbringen soll, ist ja hinlänglich bekannt.
Das nächste wäre die Lizenz-Problematik: eine solche "Doppelnutzung" der Server-Lizenzen und CALs dürfte M$ sicher nicht erfreuen.
Jürgen
dd oder ddrescue von einem linux-live-System (z.B. knoppix).
lks
1
Oh, das liest sich ja fast wie meine Umgebung. Kein Internet weit und breit, der zweite Standort (evtl. noch ein paar mehr) ebenfalls autark und völlig andere Nutzer der Umgebung. Das evtl. ein Laptop der Ursprungsdomäne in die Verlegenheit kommt, sich am neuen Standort zu befinden, ist zwar unwahrscheinlich, aber wie schon im link geschrieben steht, soll man niemals nie sagen. 
Hinzu kommt noch ein WSUS VM, die "von außen" mit Updates werden soll, da das Produktivsystem wie gesagt keinen Internetanschluß hat, aber eben mit updates versorgt werden soll. Soll ich hierzu eine neue Frage stellen, oder gibt es zu diesem Zweck "die eine" Lösung?
Hinzu kommt noch ein WSUS VM, die "von außen" mit Updates werden soll, da das Produktivsystem wie gesagt keinen Internetanschluß hat, aber eben mit updates versorgt werden soll. Soll ich hierzu eine neue Frage stellen, oder gibt es zu diesem Zweck "die eine" Lösung?
Guter Punkt. Danke dafür.
Das nächste wäre die Lizenz-Problematik: eine solche "Doppelnutzung" der Server-Lizenzen und CALs dürfte M$ sicher nicht erfreuen.
Der andere Standort bzw. die Standorte bekommt natürlich eigene Lizenzen.
Das nächste wäre die Lizenz-Problematik: eine solche "Doppelnutzung" der Server-Lizenzen und CALs dürfte M$ sicher nicht erfreuen.
Zitat von @emeriks:
Hi,
das kann man so machen. Alle DC-VM zusammen herunterfahren und die VM-Dateien zusammen als Satz kopieren.
Dann kann man diese VM-Satz später irgendwo anders wieder hochfahren, egal, wie lange diese inzwischen aus waren.
Das ist auch noch ein offenes Thema. Beide hosts greifen auf einen shared storage zu, auf dem die VMs liegen. Wenn nun z. B. host1 aus irgendwelchen Gründen ausfällt (und dann natürlich sämtliche VMs erst einmal nicht mehr erreichbar sind), was wäre der schnellste Weg, die VMs auf host2 gestartet zu haben?Hi,
das kann man so machen. Alle DC-VM zusammen herunterfahren und die VM-Dateien zusammen als Satz kopieren.
Dann kann man diese VM-Satz später irgendwo anders wieder hochfahren, egal, wie lange diese inzwischen aus waren.
Sorry, dass ich so viele Zusatzfragen habe. Mit Hyper-V hatte ich bisher nicht so viel zu tun.
Ich könnte natürlich das letzte Backup auf host2 einspielen, aber da die VM grundsätzlich auf dem shared storage liegt, müsste ich diese doch verwenden können, oder?
Zitat von @baddeit:
Das ist auch noch ein offenes Thema. Beide hosts greifen auf einen shared storage zu, auf dem die VMs liegen. Wenn nun z. B. host1 aus irgendwelchen Gründen ausfällt (und dann natürlich sämtliche VMs erst einmal nicht mehr erreichbar sind), was wäre der schnellste Weg, die VMs auf host2 gestartet zu haben?
Ein HA-Cluster.Das ist auch noch ein offenes Thema. Beide hosts greifen auf einen shared storage zu, auf dem die VMs liegen. Wenn nun z. B. host1 aus irgendwelchen Gründen ausfällt (und dann natürlich sämtliche VMs erst einmal nicht mehr erreichbar sind), was wäre der schnellste Weg, die VMs auf host2 gestartet zu haben?
Sers,
deine Idee funktioniert nur dann, wenn die Tombstone Lifetime im AD größer ist als die Offline Periode der beiden DCs. Standardmäßig sind das 180 Tage (seit WS2003SP1). Sprich, wenn einer oder beide DCs 181 Tage offline sind und danach wieder hochgefahren werden, dann ist die Vertrauensstellung kaputt und der 2te DC (der ohne FSMO Rollen) muss repariert werden.
Eine Anleitung findest du hier: Fixing a Tombstoned Domain Controller
Deutlich einfacher:
Mit dem ADSIEdit.msc im Namenskontext Konfiguration der Domäne unter CN=Configuration, CN=Services, in den Eigenschaften von CN=Windows NT den Wert "tombstoneLifetime" anpassen.
Nachdem das Tombstone-Lifetime attribute 4 Byte groß ist kannst du theoretisch bis auf 2147483647 Tage hoch gehen. Praktisch ist das natürlich nicht.
1095 würde dir 3 Jahre geben. Bis dann wirst du eine neue Referenz gebaut haben.
Grüße,
Philip
deine Idee funktioniert nur dann, wenn die Tombstone Lifetime im AD größer ist als die Offline Periode der beiden DCs. Standardmäßig sind das 180 Tage (seit WS2003SP1). Sprich, wenn einer oder beide DCs 181 Tage offline sind und danach wieder hochgefahren werden, dann ist die Vertrauensstellung kaputt und der 2te DC (der ohne FSMO Rollen) muss repariert werden.
Eine Anleitung findest du hier: Fixing a Tombstoned Domain Controller
Deutlich einfacher:
Mit dem ADSIEdit.msc im Namenskontext Konfiguration der Domäne unter CN=Configuration, CN=Services, in den Eigenschaften von CN=Windows NT den Wert "tombstoneLifetime" anpassen.
Nachdem das Tombstone-Lifetime attribute 4 Byte groß ist kannst du theoretisch bis auf 2147483647 Tage hoch gehen. Praktisch ist das natürlich nicht.
1095 würde dir 3 Jahre geben. Bis dann wirst du eine neue Referenz gebaut haben.
Grüße,
Philip
1Zitat von @emeriks:
Wie sind da die Erfahrungen? Bisher habe ich nur gelesen oder als Antwort bekommen: "Lass die Finger davon, da pain in the a...". Das wär natürlich die charmanteste Lösung. Hast du da einen link parat, wo ich mich dazu einlesen kann?Zitat von @baddeit:
Das ist auch noch ein offenes Thema. Beide hosts greifen auf einen shared storage zu, auf dem die VMs liegen. Wenn nun z. B. host1 aus irgendwelchen Gründen ausfällt (und dann natürlich sämtliche VMs erst einmal nicht mehr erreichbar sind), was wäre der schnellste Weg, die VMs auf host2 gestartet zu haben?
Ein HA-Cluster.Das ist auch noch ein offenes Thema. Beide hosts greifen auf einen shared storage zu, auf dem die VMs liegen. Wenn nun z. B. host1 aus irgendwelchen Gründen ausfällt (und dann natürlich sämtliche VMs erst einmal nicht mehr erreichbar sind), was wäre der schnellste Weg, die VMs auf host2 gestartet zu haben?
Zitat von @psannz:
Deutlich einfacher:
Mit dem ADSIEdit.msc im Namenskontext Konfiguration der Domäne unter CN=Configuration, CN=Services, in den Eigenschaften von CN=Windows NT den Wert "tombstoneLifetime" anpassen.
Nachdem das Tombstone-Lifetime attribute 4 Byte groß ist kannst du theoretisch bis auf 2147483647 Tage hoch gehen. Praktisch ist das natürlich nicht.
1095 würde dir 3 Jahre geben. Bis dann wirst du eine neue Referenz gebaut haben.
Merci, das erleichtert die Sache ungemein. Einstellen, image machen, Staub ansetzen lassen, image auf neues System spielen, hochfahren, freuen. Deutlich einfacher:
Mit dem ADSIEdit.msc im Namenskontext Konfiguration der Domäne unter CN=Configuration, CN=Services, in den Eigenschaften von CN=Windows NT den Wert "tombstoneLifetime" anpassen.
Nachdem das Tombstone-Lifetime attribute 4 Byte groß ist kannst du theoretisch bis auf 2147483647 Tage hoch gehen. Praktisch ist das natürlich nicht.
1095 würde dir 3 Jahre geben. Bis dann wirst du eine neue Referenz gebaut haben.
Einfach im Web nach "Hyper-V HA Cluster" suchen.
Das ist ein einfaches Failover Cluster.
Einfache Konfig (je nach Vorkenntnisse) und ebenfalls einfache Handhabung.
Wofür sonst hast du einen Shared Storage?
Einfache Konfig (je nach Vorkenntnisse) und ebenfalls einfache Handhabung.
Wofür sonst hast du einen Shared Storage?
Stimmt schon. Wie oben erwähnt, wurde mir davon immer abgeraten. Aber es gleicht sich hier gerade aus. Ich hab bereits ein paar Artikel gelesen, aber wenn hier jemand "den einen link" hat, bin ich natürlich sehr empfänglich dafür.
Ich hab bereits ein paar Artikel gelesen, aber wenn hier jemand "den einen link" hat, bin ich natürlich sehr empfänglich dafür.
Also der welcher dir davon abgeraten hat hatte schlichtweg keine Ahnung oder war stand von 2008.
Hier mal im Blog schauen
https://www.hyper-v-server.de/
Die Jungs von Rachfahl (MVP) haben es echt gut drauf. Da findest bestimmt einen Artikel zu deinem Thema.
Hier mal im Blog schauen
https://www.hyper-v-server.de/
Die Jungs von Rachfahl (MVP) haben es echt gut drauf. Da findest bestimmt einen Artikel zu deinem Thema.
1
Hab meinen Cluster damals auch mit den Anleitungen von Rachfahl aufgesetzt. Bedenke aber, wenn du einen Shared Storage nutzt, dann kann der auch ausfallen, im schlechtesten Fall brauchst du dann Ewigkeiten um deine VMs aus dem Backup wiederherzustellen, das heißt, auch hier brauchst du Redundanz.
Storages mit interner Redundanz sind relativ teuer, die etwas besseren QNaps und Synology und Konsorten können auch mal ein faulty Update haben wodurch dein zentraler Storage dann ggf. eine Zeit lang tot ist.
Microsoft bietet jede Menge Möglichkeiten, deine Dienste redundant aufzusetzen, ohne zu Clustern, bei Fileservern z.B. Stichwort DFS, bei Domain Controllern solltest du ja sinnvollerwiese immer mehrere haben, bei Exchange dann mit DAG usw. Ist ein komplexes Thema, die eine allgemeingültige Lösung gibts da nicht, es kommt immer auf das Budget an und was damit für ein Service Level inkl. geplanter Ausfallzeiten erreicht werden soll.
Storages mit interner Redundanz sind relativ teuer, die etwas besseren QNaps und Synology und Konsorten können auch mal ein faulty Update haben wodurch dein zentraler Storage dann ggf. eine Zeit lang tot ist.
Microsoft bietet jede Menge Möglichkeiten, deine Dienste redundant aufzusetzen, ohne zu Clustern, bei Fileservern z.B. Stichwort DFS, bei Domain Controllern solltest du ja sinnvollerwiese immer mehrere haben, bei Exchange dann mit DAG usw. Ist ein komplexes Thema, die eine allgemeingültige Lösung gibts da nicht, es kommt immer auf das Budget an und was damit für ein Service Level inkl. geplanter Ausfallzeiten erreicht werden soll.
1
Wenn das Storage ausfällt, können wir auf die Daten von BackupExec zurückgreifen. Ein Host wird hoffentlich immer da sein, "the last host standing".
Die Fileserver werden ebenfalls via BE gesichert, die Überlegung ist auch, DFS zu verwenden. Vielleicht zusätzlich sogar. Auch zwei DCs werden vorhanden sein.
Leider weiß ich noch nicht, welche Hardware es letztlich werden wird, darum ist das im Moment noch recht theoretisch. Aber ich hoffe, die meisten Fail-Szenarien sind bis dahin bedacht.
Merci für die Hinweise,
Badde
Die Fileserver werden ebenfalls via BE gesichert, die Überlegung ist auch, DFS zu verwenden. Vielleicht zusätzlich sogar. Auch zwei DCs werden vorhanden sein.
Leider weiß ich noch nicht, welche Hardware es letztlich werden wird, darum ist das im Moment noch recht theoretisch. Aber ich hoffe, die meisten Fail-Szenarien sind bis dahin bedacht.
Merci für die Hinweise,
Badde
