.png)
Hintergrund:
Mehrere ältere Windows Server 2003-Systeme müssen von VMware nach Azure migriert werden.
Ja, wir wissen, dass sie ein älteres Betriebssystem haben. Dennoch müssen wir sie am Laufen halten. Und das ist (zumindest teilweise)unterstützt durch Microsoft.
Ein kritischer Schritt ist natürlich die Installation von Hyper-V Integration Services auf den Servern, bevor diese nach Azure verschoben werden. Wir haben uns entschieden, diesen Schritt manuell durchzuführen, weilder offiziell dokumentierte Prozess, der auf Startskripten basierthat sich als etwas unzuverlässig erwiesen.
Daher werden in unserem Prozess die Server zuerst in Hyper-V-Maschinen konvertiert. Anschließend wird HVIS installiert und VMware Tools werden entfernt. Anschließend werden sie nach Azure verschoben.
Der Prozess wurde definiert, getestet und dokumentiert; er funktioniert einwandfrei.
JEDOCH.
Ein bestimmtes System hat ein sehr seltsames Problem mit Gerätetreibern. Es vertraut nichtbeliebigGerätetreiber, einschließlich nativer, und fordert vor der Installation eine manuelle Bestätigung anbeliebigHardware. Dies passiert nicht nur bei Hyper-V-Treibern, sondern auch beijedes einzelne Gerät, einschließlich derjenigen, deren Treiber native Windows-Treiber sind; Beispiel unten:
Dies ist mühsam (beim Wechsel von VMware zu Hyper-V gibt es 15-20 solcher Eingabeaufforderungen), kann aber überstanden werden, solange eine manuelle Interaktion mit dem Server erfolgt. Wenn der Server jedoch zu Azure verschoben wird, wartet er (vermutlich) auf dieselbe manuelle Bestätigung, bevor er die neuen Geräte von Azure installiert, einschließlich des neuen Netzwerkadapters. Dies bedeutet natürlich, dass kein Netzwerk vorhanden ist und kein Zugriff auf die Azure-VM möglich ist.
Warum passiert das? Wie kann das Problem behoben werden?
Wir haben versucht, das System so zu konfigurieren, dass es nicht signierte Treiber automatisch akzeptiert (obwohlSindsigniert und das sollte überhaupt nicht passieren):
Der Server macht jedoch weiterhin dasselbe und verlangt eine Bestätigung, bevor er neue Hardware installiert (und warnt, dass der Windows-Logo-Test nicht bestanden wurde).
Wir haben auch versucht sfc /scannow, was kein Problem erkannt und das Problem nicht behoben hat; chkdskauch hier wurde kein Fehler gefunden.
Warum verhält sich dieser spezielle Server so?
Wie können wir das beheben?
Hinweis: Dies wird nicht durch ein fehlendes Update und/oder ein abgelaufenes Zertifikat verursacht. Ich habe eine Neuinstallation von Windows Server 2003 auf Hyper-V unter Verwendung der Original-ISO (ich habe noch eine Kopie) versucht, also ohne jegliches Update, und es ist nichts dergleichen passiert.