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 zum Entschärfen einer Bombe, die man nicht selbst gebaut hat – mit verbundenen Augen –, während alle um einen herum „Bau ihn doch einfach neu auf!" rufen, als wäre das irgendwie hilfreich, wenn das Management will, dass es JETZT funktioniert.
Stellen Sie sich das vor: Ein Unternehmen testet Proxmox und fühlt sich gut dabei, 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 – die Netzwerkkarte verschwindet einfach. Als hätte sie nie existiert. Keine NIC, kein Login, kein DNS, gar nichts. Nur ein kaputter Domänencontroller, der einen mit diesem kalten, urteilenden Windows-Login-Bildschirm anstarrt.
Und genau da beginnt diese besondere Proxmox-Saga.
Der klassische „Die NIC ist verschwunden"-Albtraum
Nach der Wiederherstellung der Domänencontroller in Proxmox konnte sich das Team nicht mit dem DSRM-Konto einloggen, weil die NIC nicht auftauchte. Klassische VirtIO-Treiber-Situation – nur dass es 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. Denn wenn man nach einem Restore aus dem eigenen DC ausgesperrt ist, hat man nicht einfach nur eine kaputte VM – man hat eine unternehmensweite Zeitbombe. Jede Authentifizierung, jede DNS-Abfrage, jede Gruppenrichtlinie hängt plötzlich am seidenen Faden. Und dem Chef ist es egal, dass es ein „Treiberproblem" ist – er hört nur: „Niemand kann sich einloggen."
Die „Nie-DCs-wiederherstellen"-Fraktion tritt auf den Plan
Sie wissen, wer als Nächstes auftaucht. Die grauhaarigen Sysadmins, die schon zu viel gesehen haben. Die zucken nicht einmal mehr mit der Wimper. Ihr Rat? Immer derselbe: „Niemals Domänencontroller wiederherstellen. Baut sie einfach neu auf."
Und sie liegen nicht falsch – aber wenn man mitten in einem Ausfall bis zum Hals drinsteckt, ist „neu aufbauen" das Letzte, was man hören will.
Die Logik ergibt Sinn: Wenn man mindestens einen gesunden DC hat, 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. Der richtige Weg ist, eine saubere VM hochzuziehen, sie zum neuen DC zu befördern und die FSMO-Rollen sauber zu verschieben.
Aber versuchen Sie das mal jemandem zu erklären, der auf einen kaputten DC auf einem neuen Hypervisor starrt, während der Chef im Nacken sitzt und wissen will, warum das Badge-System nicht funktioniert.
Die Treiberprobleme, vor denen Sie niemand warnt
Nun zum NIC-Problem. Es ist immer das NIC-Problem. Die Virtualisierungsschicht wechselte von VMware zu Proxmox, und der neue Hypervisor weiß nichts mit dem alten virtuellen NIC-Treiber anzufangen.
Jetzt stecken Sie in diesem seltsamen Fegefeuer fest, in dem Windows überhaupt keine Netzwerkadapter sieht. Sie mounten das VirtIO-ISO, versuchen die Treiber manuell einzuschleusen, fluchen ein bisschen, versuchen es erneut, und immer noch nichts.
Irgendjemand, irgendwo, sagt unweigerlich: „Nimm doch einfach E1000 – das funktioniert immer."
Und ja, technisch gesehen stimmt das. Der E1000-Adapter ist dieser zuverlässige alte Packesel unter den Netzwerktreibern – langsam, simpel, aber garantiert bootfähig. Es ist, als würde man 2025 ein Klapphandy benutzen. Es synchronisiert Ihre Kontakte nicht, aber immerhin können Sie damit Hilfe rufen.
Der eigentliche Trick besteht darin, die MAC-Adresse der neuen NIC auf die alte zu setzen, denn Active Directory und DNS können dabei pingelig werden. Wenn Sie dann 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 gedruckt gehört:
„Der entscheidende Punkt ist, NICHT zurückzurollen, sobald der DC das Netzwerk erreicht hat."
Das klingt einfach, aber es ist der Fehler Nummer eins, den Leute machen. In dem Moment, in dem ein Domänencontroller das Netzwerk berührt, bewegen sich seine internen Replikationsnummern – die USNs – vorwärts. Wenn Sie danach diesen VM-Snapshot zurückrollen oder ein Backup wiederherstellen, ist das, als würden Sie die Geschichte umschreiben.
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.
Der sichere Weg ist immer, die Migration „just in time" durchzuführen – einen DC hochfahren, ihn vollständig replizieren lassen, ein dcdiag laufen lassen, und erst dann zum nächsten übergehen. Nie mehr als einen gleichzeitig. Niemals.
Warum das Management die richtige Lösung hasst
Hier kommt der andere frustrierende Teil – die richtige Lösung klingt oft nach mehr Aufwand. Als jemand vorschlug, einfach einen neuen DC zu bauen, zögerte das Team, weil das bedeutet hätte, die DNS-Einstellungen auf einem ganzen Stapel statischer Geräte zu aktualisieren: Drucker, Scanner, Legacy-Kisten, was auch immer.
Und ja, das ist schmerzhaft. Niemand will alte Hardware anfassen, die seit 2012 still vor sich hin funktioniert. Aber hier ist der Punkt – dieser Schmerz ist technische Schuld. Es ist das Zeug, das zuerst kaputtgeht, wenn Sie Ihre Infrastruktur modernisieren.
Es zu ignorieren schiebt das Problem nur bis zur nächsten Migration, dem nächsten Restore oder dem nächsten „Warum können wir uns nicht einloggen?"-Notfall um 3 Uhr morgens auf.
Also ja, DCs neu aufzubauen klingt nach zusätzlicher Arbeit, ist aber auch der sauberste Weg, diese Schuld zurückzusetzen.
Der versteckte Bösewicht: VMware Tools und Hyper-V-Geister
Ein anderer Admin wies auf etwas hin, das die meisten Leute vergessen: Vor der Migration sollten Sie VMware Tools und die Hyper-V-Integrationsdienste entfernen. Diese Dinger klammern sich wie Seepocken ans Betriebssystem und verursachen jede Menge Merkwürdigkeiten, sobald die VM in Proxmox landet.
Es ist das virtuelle Äquivalent dazu, eine Tesla-Batterie in einen Ford-Truck einzubauen. Klar, beides sind Fahrzeuge, aber nichts passt richtig zusammen.
Entfernen Sie die alten Tools, fügen Sie vor der Migration die VirtIO-Treiber hinzu, und plötzlich fühlt sich Ihr Restore nicht mehr wie ein Exorzismus an.
Die harte Wahrheit: Backups sind nicht immer wiederherstellbar
Das ist der Satz, der wehtut: Nur weil Sie ein Backup haben, heißt das nicht, dass Sie es auch sicher wiederherstellen können.
Domänencontroller sind nicht wie Fileserver oder SQL-Kisten. Es sind lebendige, atmende, ständig replizierende Maschinen, die es hassen, in der Zeit eingefroren zu werden. Einen wiederherzustellen bedeutet, eine Version Ihres Active Directory wiederzubeleben, von der der Rest des Forests längst weitergezogen ist.
Es ist, als würden Sie Ihren Freund klonen, und der Klon denkt immer noch, es sei 2023. Jetzt laufen beide herum und bestehen darauf, der „echte" zu sein. Raten Sie, was als Nächstes passiert? Chaos.
Das Licht am Ende: Die Weisheit der Community siegt
Nach dem Chaos und dem Hin und Her wurde 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.
Es war keine Magie. Es war einfach kollektive Erfahrung. Die Art, die entsteht, wenn man Dinge kaputt macht und sie auf die harte Tour repariert.
Was diese Saga wirklich lehrt
Die große Erkenntnis hier hat nichts mit Proxmox, Veeam oder VirtIO zu tun. Es geht darum zu verstehen, was ein Domänencontroller wirklich ist – und was er nicht ist.
Er ist nicht einfach nur eine weitere VM. Er ist ein Grundpfeiler Ihrer Identitätsinfrastruktur. Ihn wie einen gewöhnlichen Backup-und-Restore-Workload zu behandeln, lädt Schmerzen förmlich ein.
Wenn Sie den Hypervisor wechseln oder die Umgebung ändern, bauen Sie Ihre DCs sauber neu auf. Migrieren Sie die Rollen ordentlich. Validieren Sie die Replikation. Aktualisieren Sie DNS. Ja, das ist mühsam. Aber es ist auch der einzige Weg, wie Sie ruhig schlafen, sobald sich der Staub der Migration gelegt hat.
Denn hier ist der Punkt – wenn Ihr DC ausfällt, liegt nicht nur ein System lahm. Es liegt alles lahm. Die Drucker drucken nicht mehr. Die Logins loggen nicht mehr ein. Die Kaffeemaschine im Büro will plötzlich ein Passwort, an das sich niemand erinnert.
Also ja, Neuaufbauen ist nervig. Aber es ist die Art von nervig, 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 verhielten sich endlich wie gewünscht, und das Unternehmen lernte eine Lektion auf die harte Tour: Bei Domänencontrollern gibt es keine Abkürzung.
Proxmox ist großartig – schlank, Open Source, leistungsstark –, aber Active Directory ist es egal, wie cool Ihr Hypervisor ist. Es will einfach nur saubere Replikation und stabile Netzwerke.
Und wenn Sie versuchen, es mit einem schnellen Restore und einem verzweifelten DISM-Befehl auszutricksen, erinnert es Sie gerne daran, wer der Chef ist – indem es Sie aus Ihrem eigenen Netzwerk aussperrt.
Wenn also das nächste Mal jemand sagt: „Wir stellen einfach den DC wieder her, das wird schon", tun Sie sich selbst einen Gefallen. Knallen Sie Ihren Kaffee auf den Tisch, schauen Sie der Person direkt in die Augen und sagen Sie:
„Wir bauen neu. Oder wir sterben beim Versuch."