Die Proxmox-DC-Migrationssaga: Wie die Proxmox-Community das Active-Directory-Chaos eines Unternehmens entwirrte

Ich schwöre, einen Domänencontroller wiederherzustellen ist das IT-Äquivalent dazu, mit verbundenen Augen eine Bombe zu entschärfen, die man nicht selbst gebaut hat. Und alle um einen herum rufen „Bau ihn doch einfach neu auf!", als wäre das irgendwie hilfreich, wenn das Management will, dass es JETZT funktioniert.

Stellen Sie sich das vor: Ein Unternehmen testet Proxmox und freut sich darauf, VMware loszuwerden und diese schönen Lizenzkosten zu sparen. Alles ist in Veeam gesichert, alle Häkchen sind gesetzt, der Restore läuft glatt, und dann, bumm, verschwindet die Netzwerkkarte einfach, als hätte es sie nie gegeben. Ohne NIC gibt es keinen Login, kein DNS, gar nichts, nur einen kaputten Domänencontroller, der einen mit diesem kalten, urteilenden Windows-Login-Bildschirm anstarrt. Genau da beginnt diese besondere Proxmox-Saga.

Der klassische Albtraum mit der verschwundenen NIC

Nach der Wiederherstellung der Domänencontroller in Proxmox konnte sich das Team nicht mit dem DSRM-Konto einloggen, weil die NIC nicht auftauchte. Eine klassische VirtIO-Treiber-Situation, die eigentlich einfach hätte sein sollen. Sie versuchten sogar den guten alten DISM-Trick, um die Treiber manuell einzuschleusen, aber Proxmox lachte nur und sagte: „Heute nicht, Freundchen."

Dann setzt die Panik ein. Wer nach einem Restore aus dem eigenen DC ausgesperrt ist, hat mehr als eine kaputte VM, nämlich eine unternehmensweite Zeitbombe. Jede Authentifizierung, jede DNS-Abfrage und jede Gruppenrichtlinie hängt plötzlich am seidenen Faden. Und dem Chef ist egal, dass es ein „Treiberproblem" ist, er hört nur: „Niemand kann sich einloggen."

Die Fraktion „Niemals DCs wiederherstellen" tritt auf den Plan

Sie wissen, wer als Nächstes auftaucht: die grauhaarigen Sysadmins, die schon zu viel gesehen haben und nicht einmal mehr mit der Wimper zucken. Ihr Rat ist immer derselbe: „Niemals Domänencontroller wiederherstellen. Baut sie einfach neu auf."

Falsch liegen sie damit nicht, aber wenn man mitten in einem Ausfall bis zum Hals drinsteckt, will man „neu aufbauen" als Letztes hören.

Die Logik ist einleuchtend. Hat man mindestens einen gesunden DC, lädt das Wiederherstellen eines weiteren aus dem Backup förmlich zu Korruption ein. USNs geraten aus dem Takt, die SYSVOL-Replikation bricht, und plötzlich sieht Ihr AD-Forest aus wie ein Tatort. Richtig wäre, eine saubere VM hochzuziehen, sie zum neuen DC zu befördern und die FSMO-Rollen ordentlich zu verschieben.

Versuchen Sie das aber mal jemandem zu erklären, der auf einen kaputten DC auf einem neuen Hypervisor starrt, während ihm der Chef im Nacken sitzt und wissen will, warum das Badge-System nicht geht.

Die Treiberprobleme, vor denen Sie niemand warnt

Nun zum NIC-Problem, denn es ist immer das NIC-Problem. Die Virtualisierungsschicht wechselte von VMware zu Proxmox, und der neue Hypervisor kann mit dem alten virtuellen NIC-Treiber nichts anfangen.

Jetzt stecken Sie in diesem seltsamen Fegefeuer fest, in dem Windows überhaupt keinen Netzwerkadapter sieht. Sie mounten das VirtIO-ISO, versuchen die Treiber manuell einzuschleusen, fluchen ein bisschen, versuchen es erneut, und es passiert immer noch nichts.

Irgendjemand, irgendwo, sagt unweigerlich: „Nimm doch einfach E1000, das funktioniert immer."

Technisch stimmt das sogar. Der E1000-Adapter ist der zuverlässige alte Packesel unter den Netzwerktreibern: langsam und simpel, aber er bootet garantiert. Das ist, als würde man 2025 ein Klapphandy benutzen. Es synchronisiert Ihre Kontakte nicht, aber Sie können damit immerhin Hilfe rufen.

Der eigentliche Trick besteht darin, der neuen NIC die MAC-Adresse der alten zu geben, weil Active Directory und DNS da pingelig werden können. Wenn Sie endlich drin sind, installieren Sie die VirtIO-Treiber richtig, wechseln zurück und tun so, als wäre das alles von Anfang an der Plan gewesen.

Die ungeschriebene Regel: Niemals einen DC zurückrollen

Einer der kampferprobteren Admins in der Diskussion ließ eine Weisheit fallen, die ehrlich gesagt auf ein Poster gehört:

„Der entscheidende Punkt ist, NICHT zurückzurollen, sobald der DC das Netzwerk erreicht hat."

Das klingt einfach, ist aber der Fehler, den Leute am häufigsten machen. Sobald ein Domänencontroller das Netzwerk berührt, zählen seine internen Replikationsnummern, die USNs, weiter hoch. Rollen Sie danach den VM-Snapshot zurück oder stellen ein Backup wieder her, schreiben Sie die Geschichte um, und Active Directory hasst Zeitreisen.

Am Ende haben Sie Lingering Objects, verwaiste Replikationspartner und im schlimmsten Fall einen ausgewachsenen USN-Rollback, der Ihren Forest lahmlegt.

Sicher ist nur eine Migration „just in time": einen DC hochfahren, ihn vollständig replizieren lassen, dcdiag laufen lassen und erst dann den nächsten angehen. Nie mehr als einen gleichzeitig, wirklich niemals.

Warum das Management die richtige Lösung hasst

Frustrierend ist auch, dass die richtige Lösung oft nach mehr Arbeit klingt. Als jemand vorschlug, einfach einen neuen DC zu bauen, zögerte das Team, weil dann die DNS-Einstellungen auf einem ganzen Stapel statisch konfigurierter Geräte hätten angepasst werden müssen: Drucker, Scanner, Legacy-Kisten und was sonst noch herumsteht.

Das tut weh, keine Frage. Niemand will alte Hardware anfassen, die seit 2012 brav vor sich hin läuft. Dieser Schmerz ist aber technische Schuld, und genau dieses Zeug geht zuerst kaputt, wenn Sie Ihre Infrastruktur modernisieren.

Wer das ignoriert, schiebt das Problem nur auf bis zur nächsten Migration, zum nächsten Restore oder zum nächsten Notfall um 3 Uhr morgens, bei dem alle fragen, warum sich niemand einloggen kann. DCs neu aufzubauen klingt also nach zusätzlicher Arbeit, ist aber auch der sauberste Weg, diese Schuld abzutragen.

Der versteckte Bösewicht: VMware Tools und Hyper-V-Geister

Ein anderer Admin wies auf etwas hin, das die meisten vergessen: Vor der Migration sollten Sie VMware Tools und die Hyper-V-Integrationsdienste entfernen. Die klammern sich wie Seepocken ans Betriebssystem und sorgen für jede Menge Merkwürdigkeiten, sobald die VM in Proxmox landet.

Das ist ungefähr so, als würde man eine Tesla-Batterie in einen Ford-Truck einbauen. Beides sind Fahrzeuge, aber nichts passt richtig zusammen.

Entfernen Sie die alten Tools und fügen Sie die VirtIO-Treiber schon vor der Migration hinzu, dann fühlt sich Ihr Restore plötzlich nicht mehr wie ein Exorzismus an.

Backups sind nicht immer wiederherstellbar

Dieser Satz tut weh: Dass Sie ein Backup haben, heißt noch nicht, dass Sie es auch gefahrlos wiederherstellen können.

Domänencontroller funktionieren anders als Fileserver oder SQL-Kisten. Sie sind lebendige, ständig replizierende Maschinen, die es hassen, in der Zeit eingefroren zu werden. Wer einen wiederherstellt, belebt eine Version seines Active Directory wieder, über die der Rest des Forests längst hinweg ist.

Stellen Sie sich vor, Sie klonen Ihren Freund, und der Klon glaubt immer noch, es sei 2023. Jetzt laufen beide herum und bestehen darauf, der „echte" zu sein. Raten Sie, was dann passiert: Chaos.

Das Licht am Ende: Die Weisheit der Community siegt

Nach viel Chaos und Hin und Her war der weitere Weg klar:

• Das VirtIO-Treiber-ISO mounten.
• Die Treiber manuell installieren.
• Eine temporäre NIC (E1000 oder RTL8139) hinzufügen, um die Konnektivität wiederherzustellen.
• Die ursprüngliche NIC mit den richtigen Einstellungen neu aufbauen.
• Die Replikation testen, bevor der nächste DC online geht.
• Um alles in der Welt keinen DC noch einmal wiederherstellen.

Magie war das nicht, nur gesammelte Erfahrung von der Sorte, die entsteht, wenn man Dinge kaputt macht und sie auf die harte Tour repariert.

Was diese Saga wirklich lehrt

Die eigentliche Erkenntnis hat wenig mit Proxmox, Veeam oder VirtIO zu tun. Sie betrifft die Frage, was ein Domänencontroller eigentlich ist. Er ist ein Grundpfeiler Ihrer Identitätsinfrastruktur, und wer ihn wie eine beliebige VM mit Backup und Restore behandelt, lädt Schmerzen förmlich ein.

Wenn Sie den Hypervisor wechseln oder die Umgebung umbauen, bauen Sie Ihre DCs sauber neu auf, migrieren die Rollen ordentlich, prüfen die Replikation und aktualisieren DNS. Das ist mühsam, aber nur so schlafen Sie ruhig, wenn sich der Staub der Migration gelegt hat.

Fällt Ihr DC aus, liegt nämlich nicht ein einzelnes System lahm, sondern alles. Die Drucker drucken nicht mehr, die Logins funktionieren nicht mehr, und die Kaffeemaschine im Büro will plötzlich ein Passwort, an das sich niemand erinnert.

Neuaufbauen nervt also, aber es ist die Sorte Nerverei, die Sie vor einem karriereendenden Ausfall bewahrt.

Das letzte Wort

Am Ende hat die Proxmox-Migration funktioniert. Die DCs waren wieder online, die VirtIO-Treiber benahmen sich endlich, und das Unternehmen hat auf die harte Tour gelernt, dass es bei Domänencontrollern keine Abkürzung gibt.

Proxmox ist großartig, schlank, Open Source und leistungsstark. Dem Active Directory ist es aber egal, wie cool Ihr Hypervisor ist. Es will saubere Replikation und ein stabiles Netzwerk, und wenn Sie versuchen, es mit einem schnellen Restore und einem verzweifelten DISM-Befehl auszutricksen, zeigt es Ihnen gern, wer der Chef ist, und sperrt Sie aus Ihrem eigenen Netzwerk aus.

Wenn also das nächste Mal jemand sagt: „Wir stellen einfach den DC wieder her, das wird schon", tun Sie sich einen Gefallen. Knallen Sie Ihren Kaffee auf den Tisch, schauen Sie der Person in die Augen und sagen Sie:

„Wir bauen neu. Oder wir sterben beim Versuch."