mrhom3r
Goto Top

Umzug DC von Hyper-V auf Proxmox

Hallo zusammen,

ich plane bzw. bereite aktuell die Migration unserer Server vor.
Aktuell laufen diese auf Hyper-V (Server 2019) und sollen auf einen neuen Proxmox-PVE.

Grundsätzlich der Umzug klappt und habe ich auch bereits mehrfach getestet - jedoch mit folgenden Einschränkungen:
  • Maschinen sind beim Export im Hyper-V gelaufen
  • Die migrierten Maschinen sind "problemlos" gebootet - aber ohne Netzwerkverbindung (sonst ja doppelt im Netzwerk)

Plan wäre jetzt am Wochenende:
  • Herunterfahren der VMs im Hyper-V
  • Export der Festplatten
  • Konvertierung / Aufsetzen neue VM (mehrfach problemlos gelaufen)
  • (NEU) Hochfahren auf Proxmox mit Netzwerk (gleiche IP wie auf HyperV) --> laufen lassen und Hyper-V nicht mehr hochfahren

Danach die Clients testen und hoffentlich funktioniert alles ;)

Folgende Server sind betroffen: 2x SQL Server, 1x Domain-Controller (AD/DNS/DHCP).

Die SQL-Server sehe ich als unkritisch an.
Bedenken habe ich aktuell beim DC - hat hier jemand Erfahrung und weiß, ob es so klappen kann?

Als Rollback-Manöver hätte ich ja die Option, dass ich die Proxmox-VMs stoppe und Hyper-V wieder anwerfe.
Oder kann da was schief gehen und die Clients dann den alten DC auch nicht mehr akzeptieren (Hauptangst face-sad )

Freu mich auf Eure Erfahrungen und Ideen!

Viele Grüße aus dem verschneiten Bayern!
MrHom3r

Content-Key: 12193955210

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

Printed on: February 29, 2024 at 08:02 o'clock

Member: Der-Phil
Der-Phil Dec 06, 2023 at 07:36:32 (UTC)
Goto Top
Hallo!

Das würde ich mir nicht antun. Warum installierst Du nicht einen zweiten DC auf Proxmox. DNS ist dann sofort migriert. Bei DHCP eine Failoverbeziehung.

Dann den alten DC herunterstufen und raus nehmen.
Member: MrHom3r
MrHom3r Dec 06, 2023 at 07:43:57 (UTC)
Goto Top
Hi Phil,

naja dachte mir, wenn es mit dem Umzug so klappt, dann wäre es ggf. einfacher.

Hast du konkrete Bedenken oder weißt, dass so ein Umzug nicht klappen kann?
Member: Der-Phil
Der-Phil Dec 06, 2023 at 07:52:04 (UTC)
Goto Top
Wo soll ich da anfangen:
- Ein einzelner Domaincontroller: SEHR schlechte Basis
- Snapshots bei Domaincontrollern: SEHR schlechte Idee
- Einen neuen Domaincontroller hinzufügen: 20 Minuten Arbeit

--> Warum so viel Arbeit machen, wenn es einfach geht?
Member: departure69
departure69 Dec 06, 2023 at 08:02:26 (UTC)
Goto Top
@MrHom3r:

Die Sorge um den virtuellen DC wäre keine, wenn die (ver)alte(te) Weisheit, mind. einen DC in Blech zu führen, eben noch nicht als veraltet gälte.

Ich kann, was Funktionalität von Domäne, AD, DNS u. DHCP anbelangt, in meinen Hypervisoren treiben, was ich möchte oder muß, der phys. DC (der natürlich ein eig. Backup hat) steht wie ein Fels in der Brandung und hält alle wichtigen, vorgenannten zentralen Dienste, auch in solchen Umbauphasen. Das Henne-Ei-Problem bei der Verwendung von Hyper-V, wenn es nur einen virtuellen DC gibt, das ja angeblich gar keines sein soll, ist auf jeden Fall niemals eins, wenn der erste DC in Blech dasteht. Darauf werde ich niemals verzichten.

Viele Grüße

von

departure69
Member: erikro
erikro Dec 06, 2023 at 08:12:44 (UTC)
Goto Top
Moin,

Zitat von @MrHom3r:
Folgende Server sind betroffen: 2x SQL Server, 1x Domain-Controller (AD/DNS/DHCP).

Die SQL-Server sehe ich als unkritisch an.

Sehe ich auch so. Ich würde vorher noch ein Backup der DB machen für den Fall, dass doch was in die Grütze geht.

Bedenken habe ich aktuell beim DC - hat hier jemand Erfahrung und weiß, ob es so klappen kann?

Die hätte ich auch.

Als Rollback-Manöver hätte ich ja die Option, dass ich die Proxmox-VMs stoppe und Hyper-V wieder anwerfe.
Oder kann da was schief gehen und die Clients dann den alten DC auch nicht mehr akzeptieren (Hauptangst face-sad )

Das wäre auch meine Befürchtung. Deshalb auch mein Rat: Neuen DC aufsetzen, Replikation abwarten, alten DC demoten und dann ist alles gut. Ein zweiter DC wäre natürlich schön. face-wink

hth

Erik
Member: Dani
Dani Dec 06, 2023 at 08:28:06 (UTC)
Goto Top
Moin,
Aktuell laufen diese auf Hyper-V (Server 2019) und sollen auf einen neuen Proxmox-PVE.
hast du Langeweile weil es so viel Schnee hat oder warum willst du wechseln? Weil mit dem Wechsel des Hypervisor ändert sich auch grundlegend deine Backup-Strategie. Was sich erst einmal nicht kompliziert anhört, aber du wirst mehr oder weniger dazu verdonnert, die Backup-Lösung von Proxmox zu nutzen.


Gruß,
Dani
Member: MrHom3r
MrHom3r Dec 06, 2023 at 08:40:54 (UTC)
Goto Top
Hi Dani,

klar ich komm nicht mehr aus dem Büro - daher die Idee mal zu Wechseln.
Das Hyper-V ist aktuell nur notdürftig konfiguriert und läuft auf 10 Jahre alter Hardware... Da muss was neues her face-smile
Backup Strategie wird auch neu.

Aber ich seh es schon - der Trend beim DC geht zum Neu-Aufsetzen.

Falls nicht doch noch jemand Erfahrung mit dem Umzug hat, bleibt mir wohl nichts anders übrig.
Member: Crusher79
Crusher79 Dec 06, 2023 updated at 08:52:07 (UTC)
Goto Top
Hallo,

für Testumgebung auch mal DCs mnter wiederhersgestellt.

Man kann Backup mit Application aware einkaufen oder Bordmittel nehmen. Die Windows Server Sicherung läuft problemlos. Die VM muss nur die gleiche Plattenaufteilung und größe haben - fertig.

Auf die gleiche Weise lässt sich auch ein Exchange Online sichern und im Anschluss mit eseutil kontrollieren oder fixen. Die Log Dateien liegen ja noch in der VM.

Altbacken, steif und etwas unflexibel. Aber im Ergebnis läuft es damit....

Anosnsten vorher Passwort für DSRM festlegen: https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/f ...

Ein reiner DC ist ja recht klein, was die Laufwerke angeht. Da du eh alles umstellst wäre nocho eine Offline Sicherung mögich. Vorher alles runterfahren und Image ziehen. Dann sollte es gut sein.

Treiber kann man nachinstallieren oder vorher hinterlegen. Windows ist Windows. Würde es mit einer normalen VM oder einer Server Trial testen, wie scih die Dinger verhalten. Hardware wird erkannt?

Wenn das in der Trockenübung schon so schön geht, sollte es im Ernstfall auch keine Probleme geben....

Kurzer VM Test: einfach mal machen! Gilt auch für den DC. Du kannst es ja wiederholen. Wenn die VMs in unterschiedlichen VLANs laufen passiert ja nichts. Dann hast du gleich eine Übersicht was so geht und was nicht.

mfg Crusher
Member: KleinProfi
KleinProfi Dec 06, 2023 at 09:13:05 (UTC)
Goto Top
Zitat von @Der-Phil:

Wo soll ich da anfangen:
- Ein einzelner Domaincontroller: SEHR schlechte Basis
- Snapshots bei Domaincontrollern: SEHR schlechte Idee
- Einen neuen Domaincontroller hinzufügen: 20 Minuten Arbeit

--> Warum so viel Arbeit machen, wenn es einfach geht?

Bitte den Beweis ins Studio. Eine Anleitung wo das in 20 Min. getan ist!
Member: markaurel
markaurel Dec 06, 2023 at 09:26:25 (UTC)
Goto Top
Hello!

Ich darf mich den Kollegen anschließen: einen DC auf diese Weise umzuziehen ist vermutlich keine so gute Idee. Tatsächlich wäre wohl ein zweiter DC die bessere Wahl. Diese dann abgleichen lassen und dann entsprechend "umstufen" ist bestimmt der sicherere Weg.

MfG

M.A.
Member: Dani
Dani Dec 06, 2023 at 09:28:41 (UTC)
Goto Top
Moin,
Bitte den Beweis ins Studio. Eine Anleitung wo das in 20 Min. getan ist!
wenn das AD sauer eingerichtet wurde und die "Standards" eingehalten worden sind, ist das 30 Minuten erledigt.
Wir reden an der Stelle von "Hinzufügen". D.h. die Zeiten für die Replication von LDAP, Sysvol, etc. sind da nicht berücksichtigt.


Gruß,
Dani
Member: erikro
erikro Dec 06, 2023 at 09:35:05 (UTC)
Goto Top
Moin,

Zitat von @KleinProfi:

Zitat von @Der-Phil:
- Einen neuen Domaincontroller hinzufügen: 20 Minuten Arbeit
Bitte den Beweis ins Studio. Eine Anleitung wo das in 20 Min. getan ist!

1. VM erstellen: Aufwand ca. 3 Minuten
2. Windows Server installieren: Nettoaufwand ca. 5 Minuten
3. DCpromo-Assistenten abarbeiten: Aufwand ca. 5 Minuten.

Et voilà

Liebe Grüße

Erik
Member: Crusher79
Crusher79 Dec 06, 2023 at 09:39:30 (UTC)
Goto Top
Naja oder einfach mal machen... Erfahrungen sammeln....

Hab öfters mal in Testumgebung VMs geschoben. 3x DC 2016 + 2x DC 2003 R2. ESXi 5.x auf 7.x.

Hardware Erkennung unter 2003 lief zwar, aber es dauerte. Vor allem musste ich noch die alten VMware Tools besorgen. Die sind nicht mehr inkludiert für 2003 face-wink

Es stehen ja noch alle Wege offen. Man kann es ja auch einfach testen. Extra VLAN. Möchte man noch Internet dazu haben, einfach weiteres VLAN und Router dazwischen. Da kollidiert nichts und man hat 1:1 die gleichen IPs etc wie im echten Netz.

Dann ist die Fallhöhe relativ gering. Meine Testumgebung umfasste neben 2016 + 2003 DCs auch Exchange.

Es sind ja nur ein paar Klicks bis Recovery startet. Dann Geduld bis die neue Hardware eingebunden wurde und fertig. Auch da muss man nicht permanent dabei sitzen.

Sicherlich kann man über 2. DC + Replikation schneller sein. Nur hier hätte der TO gleich die Chance, sein DaSi Konzept zu prüfen. Online Exchange Sicherung sauber? etc. etc.


Auch wenn es nicht zwingend nötig ist wäre es eine gut Gelgenheit - 2. Hypervisor + unteschidliche Hardware - um mal Recovery durchzuspielen.

Auf gleicher Hardware später fällt dann so einiges raus. Aber man hat zumindest alles mal gesehen....

Windows Backup kann auch aus Netzwerk recovern. Kommt nur die Warnmeldung. Alles punkte die einen irritieren. Darum finde ich es nicht verkehrt das mal gemacht zu haben....
Member: Crusher79
Crusher79 Dec 06, 2023 at 09:47:18 (UTC)
Goto Top
Zitat von @erikro:

Moin,

Zitat von @KleinProfi:

Zitat von @Der-Phil:
- Einen neuen Domaincontroller hinzufügen: 20 Minuten Arbeit
Bitte den Beweis ins Studio. Eine Anleitung wo das in 20 Min. getan ist!

1. VM erstellen: Aufwand ca. 3 Minuten
2. Windows Server installieren: Nettoaufwand ca. 5 Minuten
3. DCpromo-Assistenten abarbeiten: Aufwand ca. 5 Minuten.

Et voilà

Liebe Grüße

Erik

Ah du bist das also mit den 5-minute craft youtube Videos face-big-smile

Naja er schrieb ja: "Migration unserer Server". Da ist ggf. noch Zeit zum Spielen drin. Durch die unterschiedlichen Plattformen sieht man schön wie sich die Server verhalten.

Auch wenn final 2. DC am einfachste wäre, ist es nicht vekehrt alles mal mitgemacht zu haben.

Wenn der TO angsetellt ist, sind es ja eh nur So-Da-Kosten. Gerade wenn man auf einmal neue Ressoucen hat bietet es sich an damit kurz zu spielen.
Member: goscho
goscho Dec 06, 2023 at 10:06:51 (UTC)
Goto Top
Moin
Zitat von @departure69:
Die Sorge um den virtuellen DC wäre keine, wenn die (ver)alte(te) Weisheit, mind. einen DC in Blech zu führen, eben noch nicht als veraltet gälte.
Kann man so machen, muss man aber auch die Lizenzen und die Technik erwerben.
Das Henne-Ei-Problem bei der Verwendung von Hyper-V, wenn es nur einen virtuellen DC gibt, das ja angeblich gar keines sein soll, ist auf jeden Fall niemals eins, wenn der erste DC in Blech dasteht. Darauf werde ich niemals verzichten.
Ständig kommen diese Mythen wieder hoch.

Nein, es gibt kein Henne-Ei-Problem. Ich betreue mehr als ein dutzend solcher Umgebungen mit jeweils genau einem virtuellen DC als VM auf Hyper-V. In meiner Donäne ist es identisch.
Ich kann jetzt sofort den einzigen DC herunterfahren und mich anschließend trotzdem per RDP auf dem Hyper-V-Host anmelden und alles mögliche erledigen, wozu ich kein AD brauche.
Der Hyper-V-Host ist auch Domänen-Mitglied.
Bei einem Neustart des Hyper-V-Hosts wird die DC-VM als 1. gestartet und die anderen zeitverzögert.

BTT:
Ich habe keinerlei Erfahrungen mit Proxmox, daher kann ich dazu nichts sagen.

Einige Umgebungen, die ich betreue wurden von mir von veralteten ESXi auf Hyper-V umgezogen. Dabei habe ich Tools von Veritas genutzt, um die VMs zu konvertieren. Die Server wurden sowieso von Backup Exec gesichert.
In mindestens einer dieser Umgebungen gab es damals nur einen virtuellen DC, den ich umgezogen habe, ohne einen zusätzlichen DC zu haben. Das macht man natürlich dann, wenn niemand im Netzwerk arbeitet.

Wenn man ein vernünftiges Backup (kein Snapshot) des DC hat, sehe ich da auch keine Probleme. Dieses kann man - wenn die Migration aus irgendeinem Grund nicht geklappt hat, in sehr kurzer Zeit wiederherstellen und dann von vorn anfangen.
Member: jsysde
jsysde Dec 06, 2023 at 10:17:31 (UTC)
Goto Top
Moin.

Zitat von @goscho:
[...]Ich kann jetzt sofort den einzigen DC herunterfahren und mich anschließend trotzdem per RDP auf dem Hyper-V-Host anmelden und alles mögliche erledigen, wozu ich kein AD brauche.
Und an dieser Stelle irrst du gewaltig - du brauchst das AD zur Anmeldung. Dass du dich auch ohne AD anmelden kannst, liegt einzig daran, dass du schon mal angemeldet warst und dich mittels Cached Credentials anmelden kannst. Wenn du mal komplett auf Kerberos umgestiegen bist, gehen da schnell die Lichter aus.

Kommen weitere Dienste wie z.B. Exchange ins Spiel, ist ein laufendes AD Grundvoraussetzung für deren Funktion. Daher sind zwei DCs in einem AD eigentlich Pflicht. Wenn einer spinnt => ausschalten, neu machen. Aber alles andere läuft weiter. Wenn dein Exchange steht und du dort den Fehler suchst, obwohl er beim einzigen DC zu suchen ist - viel Erfolg bei der Fehlerlösung.

*Just my 5 Cent*

Cheers,
jsysde
Member: HansDampf06
HansDampf06 Dec 06, 2023 at 11:05:08 (UTC)
Goto Top
Ich werfe einmal meine 5 Pfennige in den Ring:

Wer den absolut sicheren Weg gehen will, mag einen neuen Domänkontroller installieren, diesen dem Active Directory hinzufügen und schließlich den ersetzten Hyper-V-VM-DC demoten. Er mag auch so bei den anderen virtuellen Maschinen verfahren.

Ob für eine Virtualisierung wirklich Proxmox gebraucht wird, mag ebenfalls jeder für sich entscheiden. Egal wie ändert das aber nichts daran, dass Promox lediglich eine Webshell um QEMU/KVM ist. Alternative bietet der Virtual Machine Manager (VMM) eine dem Hyper-V-Manager sehr ähnliche, intuitiv bedienbare Bedienoberfläche. Mit den (zugehörigen) Konsolentools virtsh und virt-viewer ist sogar eine powershell-vergleichbare Steuerung ohne GUI möglich. Wer nicht per ssh zugreifen möchte, kann den VMM - wie auch beim Hyper-V-Manager - auf jeder anderen Linux-Maschine installieren und so QEMU/KVM bequem fernbedienen. Alles ganz leicht.

Das vorab.

Eine Migration einer Windows-/Linux-VM nach QEMU/KVM ist äußerst simpel und funktioniert problemfrei. Dazu ist es "lediglich" erforderlich, die VHDX-Dateien mit qemu-img nach QCOW2 zu konvertieren und (im VMM) eine neue virtuelle Maschine anzuleigen. Dank der Fähigkeiten von QEMU können bei gravierenden Hardwareunterschieden geeignete Einstellungen zu CPU und Chipsatz getroffen werden, so dass die alte Hyper-V-VM nunmehr freudig als QEMU/KVM-VM werkelt. Das gilt auch und gerade für einen oder mehrere Domänkontroller.
Auf diese Art und Weise lässt sich sogar adhoc ein Umzug von Hyper-V auf QEMU/KVM auf ein und derselben Hardware erfolgreich umsetzen. Der Zeitbedarf liegt dann lediglich darin, die VHDX-Dateien zu konvertieren und die bisherigen virtuellen Maschinen nunmehr unter QEMU/KVM anzulegen. Bei guter Planung ist das je nach Umfang der Dateien innerhalb weniger Stunden durchgezogen und alles läuft so, als sei alles noch wie vorher.

So jedenfalls mein praktisches Erfahrungsbild.

Viele Grüße
HansDampf06
Member: MrHom3r
MrHom3r Dec 06, 2023 at 12:09:41 (UTC)
Goto Top
Zitat von @HansDampf06:

Bei guter Planung ist das je nach Umfang der Dateien innerhalb weniger Stunden durchgezogen und alles läuft so, als sei alles noch wie vorher.

Hallo Hansdampf,

da gebe ich dir Recht - wie gesagt ich habe alle betroffenen Maschinen bereits zum Test umgezogen. Einzig Zeit kostet der Export und das Konvertieren - Rest geht easy von der Hand...

Einzige Einschränkung ist, dass ich alle Maschinen ohne Netzwerk betreibe - damit keine Konflikte mit den "echten" Maschinen. Beim DC startet der AD-Service aktuell nicht sauber - ich denke, dass könnte aber auch der Tatsache geschuldet sein, dass kein Netzwerk verbunden ist...

Ich denke ist handelt sich um diesen Fehler:
Der Dienst "Standortübergreifender Messagingdienst" wurde mit folgenden Fehler beendet: Der angegebene Server kann den angeforderten Vorgang nicht ausführen. Quelle: Service Control Manager  

Kann jemand bestätigen, dass der Fehler auf fehlendes Netzwerk hindeutet?

Ansonsten muss/werde ich die Server in einen eigenen VLAN "koppeln" und dann nochmal einen Client auf dem PVE herstellen und dort dann alles testen. Ist halt mehr Aufwand, dafür hat man ja dann eine ziemlich vergleichbare Migration.

Grüße
Hom3r
Member: Crusher79
Crusher79 Dec 06, 2023 at 12:16:10 (UTC)
Goto Top
@MrHom3r Oder mit VLANs und Router alles ausräumen.

VLAN 1 = 192.168.10.0 normales Netz
Router 1
VLAN 2 = 10.10.20.0 Netz zwischen Prod und Test
Router 2
VLAN 3 = 192.168.10.10 Testumgebung

Können auch VM Router sein - pfsense/ OPNsense.

Wenn du alles vorher testen willst mach separates Testnetz. Wenn die IPs gleich bleiben sollen und du nur ein 1x Internet Gateway hast geht das z.B. wie oben beschrieben.

Oder eben zumindest mit einen getrennten VLAN die Maschinen starten.

Ohne Netzwerk bekommst du Fehler oder komisches Verhalten. 1:1 vorab Test gelingt nur, wenn Netzwerk vorhanden ist. Sollte aber kein Problem sein.
Member: Crusher79
Crusher79 Dec 06, 2023 at 12:34:20 (UTC)
Goto Top
https://www.virtualizationhowto.com/2015/02/create-isolated-test-environ ...

Da auch nochmal eine techn. Umsetzung, wo in Prod und Test environoment die gleichen IPs beibehalten werden.

Alternativ kannst du auch ans test VLAN LTE Router hängen und hast da nochmal dedizierten Zugriff.

Gibt mehrere Varianten. Am einfafchsten ist es die Netze zu trennen und Routing - zwecks I-Net Zugriff - zu realisieren.


Mailserver haben nochmal eine Besonderheit. Ggf. liegt da ein Mailgateway vorweg. Aber für reinen DC Test sollte das ausreichend sein. Einschl. Internet für Updates - neue Hardware....
Member: goscho
goscho Dec 06, 2023 at 14:28:39 (UTC)
Goto Top
Zitat von @jsysde:
Und an dieser Stelle irrst du gewaltig - du brauchst das AD zur Anmeldung. Dass du dich auch ohne AD anmelden kannst, liegt einzig daran, dass du schon mal angemeldet warst und dich mittels Cached Credentials anmelden kannst.
Es gibt auf dem Hyper-V Horst natürlich auch einen lokalen Benutzer, den man anmelden kann.
Warum muss ich mir ständig von jemandem erklären lassen, was geht und was nicht.
Ich betreue seit mehr als 25 Jahren ausschließlich KMU.
Kommen weitere Dienste wie z.B. Exchange ins Spiel, ist ein laufendes AD Grundvoraussetzung für deren Funktion. Daher sind zwei DCs in einem AD eigentlich Pflicht.
Ich habe ja auch nix dagegen, dass du mehr als einen DC einsetzt.
Jetzt erkläre mir bitte, warum ich bei meinem Unternehmen mehr als einen haben sollte?
2-Mann-Firma - Hyper-V 2019 mit diversen VMs (u.a. DC, Exchange, etc)
Wenn der DC spinnen sollte und ich den fehler nicht zeitnah finde, stelle ich den DC oder nur AD aus dem Backup wieder her.
Wenn einer spinnt => ausschalten, neu machen. Aber alles andere läuft weiter. Wenn dein Exchange steht und du dort den Fehler suchst, obwohl er beim einzigen DC zu suchen ist - viel Erfolg bei der Fehlerlösung.
Mein 1. eigener Exchange war ein 4.5 auf NT aus einer Zeit, da gab es (auch für mich schon) DM -> Mitte/Ende 90-er.
Seither habe ich keine Exchange-Version ausgelassen.
Member: Dani
Dani Dec 06, 2023 at 14:43:52 (UTC)
Goto Top
Moin @goscho,
du hast beim ersten Zitat den letzten Satz (unbewusst) abgeschnitten. Das ist nämlich an der Stelle wichtig. Die Aussage von @jsysde in Kombination mit Kerberos ist nämlich elementar. In dieser Konstellation funktioniert nämlich wirklich die lokale Anmeldung nicht mehr. Das "Local kdc" wird erst mit der nächsten Windows Server Edition funktionieren.


Gruß,
Dani
Member: surreal1
surreal1 Dec 06, 2023 updated at 16:53:25 (UTC)
Goto Top
Unfassbar wie viel Offtopic in den ersten Kommentaren abgegeben wird. Auch die Frage wieso man von Hyper V auf Proxmox migrieren möchte. Alleine dafür gibt es mehr als genug Gründe, warum man genau dies in Erwägung ziehen kann.

Ich würde wie folgt vorgehen:

1. Alle wichtigen Maschinen herunterfahren
2. DC runterfahren und migrieren
3. DC auf Proxmox starten und die jeweiligen Treiber via WinRE installieren, wenn nicht im Vorhinein angepasst.
4. DC hochfahren und und die Startkonfiguration (msconfig) sowie die ursprüngliche IP Adresse statisch setzen.
5. Fertig

Ich kenne deine Infrastruktur nicht, jedoch ist nichts an deiner Idee auszusetzen, da du es ja im Vorhinein getestet hast, was auch funktioniert hat..

Im Endeffekt ist es jedem seine eigene Entscheidung, ob er einen oder fünf DC laufen lässt, ob er die Backup Strategie abgewogen hat oder auch nicht. Jeder der in dem Bereich arbeitet, sollte wissen, womit er es zu tun hat und nicht von jedem stetig belehrt werden, wie man was genau umsetzt. Jeder Infrastruktur hat spezielle Bedürfnisse und kann nicht gleichgesetzt werden.
Member: HansDampf06
HansDampf06 Dec 06, 2023 at 18:27:30 (UTC)
Goto Top
Zitat von @goscho:
Es gibt auf dem Hyper-V Horst natürlich auch einen lokalen Benutzer, den man anmelden kann.
Warum muss ich mir ständig von jemandem erklären lassen, was geht und was nicht.
Ich betreue seit mehr als 25 Jahren ausschließlich KMU.
Das ist völlig zutreffend. Ist hier in einem KMU über zehn Jahre hinweg so nutzbar gewesen.

Vorteil: Ist die Domäne nicht da, weil der (einzige oder mehrere) DC auf dem Hyper-V als VM laufen und diese eine/mehrere VM's noch nicht gestartet sind, kann trotzdem auf den Hyper-V-Host zugegriffen und alle relevanten Arbeiten erledigt werden. Das lokale Konto war somit immer die Rückversicherung. Unter dieser Maßgabe ist es nicht wirklich tragisch, dass kein weiterer DC auf einem anderen Blech/Hypervisor läuft, obschon das von Microsoft und auch hier im Forum so empfohlen wird.

Freilich: In einem größeren Netzwerk sind die Dinge natürlich ganz anders zu stricken.

Ich habe ja auch nix dagegen, dass du mehr als einen DC einsetzt.
Jetzt erkläre mir bitte, warum ich bei meinem Unternehmen mehr als einen haben sollte?
2-Mann-Firma - Hyper-V 2019 mit diversen VMs (u.a. DC, Exchange, etc)
Wenn der DC spinnen sollte und ich den fehler nicht zeitnah finde, stelle ich den DC oder nur AD aus dem Backup wieder her.
Auch hier kann ich Dir aus langjähriger praktischer Erfahrung bestätigen, dass mit einem einzigen DC in einem kleinen Netzwerk alles ruhig läuft. Ein DC, der nur als DC (AD, DNS und vielleicht noch DHCP) werkelt, läuft sogar eher unscheinbar vor sich hin. Viele Faxen muss man da nicht wirklich machen, außer eben die ganz normale Wartung / Pflege.
Dennoch habe ich den subjektiven Eindruck, dass ein zweiter DC (oder mehr) für eine gewisse Beschleunigung zu sorgen scheint. Das dürfte vor allem dem dennoch nicht geringen DNS-Anfrage-Aufkommen auch in einem kleinen Netzwerk geschuldet sein. Denn der Syslog-Mitschnitt von einem Samba-AD-DC offenbart einen äußerst regen Anfrageverkehr und das zu einem großen Teil die AD-bezogenen FQDN.

Viele Grüße
HansDampf06
Member: HansDampf06
HansDampf06 Dec 06, 2023 at 18:37:01 (UTC)
Goto Top
Zitat von @goscho:
Wenn du mal komplett auf Kerberos umgestiegen bist, gehen da schnell die Lichter aus.
Zitat von @Dani:
du hast beim ersten Zitat den letzten Satz (unbewusst) abgeschnitten. Das ist nämlich an der Stelle wichtig. ... Das "Local kdc" wird erst mit der nächsten Windows Server Edition funktionieren.
Bis es soweit ist, wäre es aus meiner Sicht ein Konfiguration-GAU, wenn mangels eines (lokal) erforderlichen KDC keine Anmeldung mehr möglich ist. Denn dann dürfte die Kerberos-Umstellung höchstwahrscheinlich für das gesamte Netzwerk gelten. Also wenn dann nicht wenigstens ein DC / KDC autonom hochgebracht werden kann, dann "Gute Nacht!". Das wäre nämlich wie in dem von @goscho beschriebenen Fall das Fehlen eines lokalen Kontos, dass nicht auf das Active Directory angewiesen ist.

Viele Grüße
HansDampf06
Member: HansDampf06
HansDampf06 Dec 06, 2023 updated at 18:46:05 (UTC)
Goto Top
Zitat von @surreal1:
3. DC auf Proxmox starten und die jeweiligen Treiber via WinRE installieren, wenn nicht im Vorhinein angepasst.
Ich würde diesen Schritt - Treiberinstallation und Anpassungen an die neue Hardware - sogar möglichst immer schon als ersten Schritt ausführen, weil es nämlich nach der Migration schwieriger sein kann - Windows grüßt sehr gerne mit BlueScreens etc. Freilich vorausgesetzt, dass sich die Treiber ohne das Vorhandensein der (neuen) Hardware bereits installieren lassen. Andernfalls geht es natürlich erst nach der Migration auf der neuen Hardware.

Viele Grüße
HansDampf06

PS: Durch die vorherige Virtualisierung unter Hyper-V ist das aber ohnehin nicht wirklich tragisch, sofern der neue Hypervisor keine völlig abweichende Hardware präsentiert. Denn dann läuft die virtuelle Maschine ja schon auf einer "abstrahierten" Basis.
Member: MrHom3r
MrHom3r Dec 07, 2023 at 07:59:53 (UTC)
Goto Top
Hallo zusammen,

vielen Dank für den ganzen Input!
Ich konnte gestern nochmal alle Maschinen "testmigrieren" und werde nun versuchen diese in einem separaten Netz sauber mit Netzwerk zum Laufen zu bringen.

Sobald ich mehr weiß, gibt's ein Statusupdate - ggf. ist es ja zukünftig für den ein oder anderen auch relevant!

Viele Grüße
MrHom3r
Member: kogansnet
kogansnet Dec 10, 2023 updated at 14:22:38 (UTC)
Goto Top
Evtl bereits zu spät - aber als Idee:

1zu1 Migration funktioniert perfekt mit Veeam. Die alten Server mit Veeam sichern(Veeam Windows Agent free), Veeam Boot ISO oder USB Stick mit Virtio-Treibern erstellen, booten, die Server in den Proxmox wiederherstellen.

Beim AD/DC müsste ggfs "bcdedit /deletevalue safeboot" notwendig sein.

Ansonsten surren die Maschinen, als wäre nichts gewesen....

Gruß Alex

ps: Vorteil von Veeam ist - die Virtio SCSI/Sata Treiber werden im Widerherstellungsprozess installiert, automatisch.
ps2: VIEL sauberer als vhdx zu konvertieren.
Member: MrHom3r
Solution MrHom3r Dec 11, 2023 at 14:50:22 (UTC)
Goto Top
Hallo zusammen,

nochmal vielen Dank für Euren zahlreichen Input - ich möchte Euch nun mal kurz vom Wochenende berichten.

Kurzform: VM --> Export Hyper-V | Import mit Konvertieren --> Hochfahren unter gleicher IP --> Fertig

Und nochmal etwas ausführlicher face-smile
Zunächst einmal die gute Nachricht - ich habe den DC und 2x SQL Server erfolgreich umgezogen.
Wie geplant und vorab auch schon ausprobiert mit Export der VM im Hyper-V, Import mit Konvertierung, 1:1 Übernahme IP und mehrfachen Boot kamen die Maschinen dann auf die Beine. Laufen seitdem gut und ich konnte noch keine Probleme feststellen. Drückt mir die Daumen...

Nächster Schritt ist dann noch ein Server Bare-Metal-Umzug mittels Synology Active Backup for Business. Klar, einige würden wohl Veeam / [dein Favorit einfügen] bevorzugen, aber mir steht ABB zur Verfügung und die Maschinen werden ja auch mit ABB weiter gesichert. Klappte zum Test bereits sehr gut und ich denke das klappt auch nochmal face-smile

Insgesamt bin ich aktuell zufrieden und hoffe, dass die Maschinen jetzt nicht doch irgendwann die Grätsche machen... Wenn Ihr auch sowas vor habt oder Detailfragen - schreibt mir einfach ne PM.

Viele Grüße
MrHom3r

ps: Ich markiere das Thema mal als gelöst - danke!