[English]Heute noch ein kurzer Blog-Beitrag für Administratoren im Windows Server 2012 R2-Umfeld. Bei den aktuell anstehenden Updates (Nov. 2018) kann es bei deren Installation zu einem Blackscreen kommen. Welches Update verantwortlich ist, steht noch nicht fest.
Anzeige
Blog-Leser Martin Feuerstein wies mich in einer Mail auf Erfahrungen hin, die er bzw. seine Kollegen gerade machten (danke für den Hinweis). Ich stelle die Informationen einfach mal kommentarlos ein – vielleicht hilft es dem einen oder anderen Administrator.
Mal schnell zwei Server updaten …
Martin schreibt: Mein Kollege hat heute Morgen „nur mal schnell" noch Updates auf zwei Servern mit Windows Server 2012 R2 einspielen wollen, bevor die Mitarbeiter anfangen – einer war unser Exchange-Server, der andere unser „Management"-Server (auf dem verschiedene Konsolen installiert sind sowie unser Helpdesk/Inventory-System).
Auf dem Exchange Server standen nur .NET 3.5 und 4.6/4.7-Updates an, am Management-Server vermutlich auch die monatliche „Wundertüte" in Form des „Security and Quality Rollups". Martin schreibt, dass er gerade nicht nachsehen kann, da das System noch nicht wieder läuft.
Blackscreen nach dem Reboot
Nach der Installation der anstehenden Updates und dem Neustart gab es beim Booten zwar noch das Windows-Logo. Danach verfing sich die Maschine mit Windows Server 2012 R2 in einem schwarzen Bildschirm. Martin schreibt dazu, dass der Exchange-Server mit ESXi virtualisiert sei, der Management-Server läuft auf Bare Metal (also keine Virtualisierung). Trotzdem tritt bei beiden ein Blackscreen auf und die Maschinen booten nicht mehr.
Reparaturversuche zum Fix des Blackscreens
Beim Exchange Server gestaltete sich die Reparatur, laut den Aussagen von Martin, recht schwierig: Das Wiederherstellen des Backups vom Vortag (vor der Update-Installation) in eine neue VM resultierte wieder im schwarzen Bildschirm. Die (anstehenden) .NET-Updates waren zu dem Zeitpunkt noch nicht installiert (und wären auch untypisch für ein nicht mehr startendes System – beim Systemstart läuft noch keine .NET-Anwendung).
„Gerettet" wurde der Exchange Server durch das Einspielen eines Backups des Ordners c:\windows\system32\config (also kompletter HKLM-Zweig) von einem Datum vor der Installation der monatlichen Updates – ohne zwischenzeitlich durch Updates geänderte Dateien zu beachten. Exchange- und weitere Dienste sehen soweit gut aus, der E-Mail-Verkehr läuft erstmal wieder.
Laufende Feldforschung
Martin Feuerstein schrieb mir dazu: Ich werde nun noch die Registry von heute Morgen (nach dem Update), gestern Abend (aus dem Backup) sowie von dem älteren Backup vergleichen und anschließend nochmal auf einem „unwichtigen" Server (mit vorherigem Snapshot) testen.
Anzeige
Die Updates haben wir bisher nur auf wenigen Servern in einer Einrichtung eingespielt (andere potentiell betroffene Server zeigen (noch) keine Problem – möchte diese aber momentan nicht neustarten), der Rollout für weitere Server und Einrichtungen ist erst einmal gestoppt.
An dieser Stelle mein Dank an Martin Feuerstein für die Beschreibung. Frage: Ist noch jemand von diesem Problem betroffen?
2015
Bei der Installation von Vorschauversionen muss man immer mit dem Schlimmsten rechnen. Deshalb weist Microsoft auch darauf hin, dass die Vorschauversionen nur zum Testen und nicht für den Produktionsbetrieb geeignet sind. Erfreulicherweise halten sich nicht alle daran und erlauben es Microsoft nachzubessern. Bleibt zu hoffen, dass Microsoft das hier beschriebene Problem bis zum kommenden "Update Tuesday" beseitigt hat.
Das waren ja auch keine Preview-Updates. Im ÖD muss der Kram jeden Tag laufen, naja am E-Mail-Server scheitert die Pass-Ausstellung zum Glück nicht.
Danke für den Hinweis. Da hat der Born sich wohl ausnahmsweise mal missverständlich — "Bei den aktuell anstehenden Updates (Nov. 2018)" — ausgedrückt. Aber heutzutage ist der Unterschied zwischen Vorschau- und Produktionsversion bei Microsoft ja sowieso kaum mehr wahrnehmbar, weshalb es sicherlich Sinn macht, alle "Updates" isoliert zu prüfen.
Vor einer Woche 14 Windows Server 2012 R2-Server aktualisiert und alle laufen wie am Schnürchen, davon 2 physisch, der Rest auf ESXi gehostet. .NET-Updates wurden jedoch nicht installiert.
Muss also eher eine spezielle Konstellation sein?
Das weiß ich erst, wenn ich den Fehler gefunden habe. Das Update der Intel-CPU-Treiber könnte ein Ansatz sein. Ich werde den Bare-Metal-Server mal als VM auf einem AMD-System wiederherstellen (kein Wort zur Performance, das war vorher mal ein Desktop-System – aber virtualisieren kann es!).
"Spezielle Konstellation" wäre schon sehr speziell, da es eine ältere ESXi-VM betrifft, aber auch eine relativ junge Bare-Metal-Installation.
Kann das Problem nicht bestätigen, hier laufen schon über 40 Server 2012 r2 auf dem November Update vom 13.11.2018 (Bare Metal und Hyper-V) und es gab nicht ein Problem beim Update.
Bei einer Testinstallation mit Windows Server 2019 hatten wir das gleiche Problem, dass nach Installation von Symantec Endpoint Protection 14.2 MP1 nach dem Startlogo der Server schwarz stehen blieb. Nach einigen Hardresets kam er hoch, jedoch lies sich der Server Manger nicht mehr starten, bzw. ging auf 60% CPU hoch ohne sich zu öffnen. Nach deinstallation von SEP lief alles wieder "normal"
Wurden hier die Preview-Updates vom 27.11.2018 eingespielt oder waren hier auch die ganzen 2012R2-Patches vom 13.11.2018 mit dabei?
Nix Preview, wir sind ja nicht lebensmüde ;-)
Haben heute – mit Snapshots davor/danach – noch einen weiteren Server mit Updates versorgt, dort keine Probleme (Mit VM-Snapshots davor/danach sowie Reg-Snapshots). Heute standen auf einem Server nur noch die .NET-Updates an – "eigentlich" ist es laut WUApp nur ein Update, installiert werden aber zwei KBs für .NET 3.5 und 4.6.
Hatte heute noch von der zuvor fehlgeschlagenen VM die Registry verglichen, sowohl HKLM\System als auch HKLM\Software\Microsoft\Windows NT als auch Microsoft\Windows… Mir kam eigentlich nur ein Intel-CPU-Update "spanisch" vor, aber auch, dass der WLIDSVC (Windows Live ID-Service) auf einmal von Start "manuell" auf "System" gesetzt wurde. In den CBS-Einträgen waren tonnenweise Änderungen, da sieht eh keine Sau durch.
Ein paar 2012 R2-VMs haben wir noch, dort ist das gleiche Prozedere mit Snapshots geplant, mal schauen was noch kommt. Die Mgmt-Kiste werde ich voraussichtlich einfach neu aufsetzen, paar Partitionen wiederherstellen, so speziell war der Kram nicht – Zeit habe ich dafür eigentlich nicht, aber hey.
habe hier dasselbe Problem beim versuch eines In Place Upgrades 2016 auf 2019. Black screen nach dem ersten Boot.
Ich schaue mal ob Secure Boot da ggf die Finger mit im Spiel hat
https://blogs.technet.microsoft.com/secguide/2019/01/25/issue-with-systemguard-launch-setting-in-windows-10-v1809-and-windows-server-2019/
Hm bisher kein Erfolg. Mal testweise Spectre / Meltdown Patche disabled. Er führt im Betrieb das Inplace Update vom top aktuellen 2016 Datacenter aus, will dann nach einem reboot weiter machen und dieser landet kurz nach dem Boot Logo in einem schwarzen Bildschirm, kein Cursor nix. Steht einfach idle mit Black Screen da. 30 min stehen lassen, geht nix. Dann reset und er sagt mir nach dem Boot dass was nich geklappt hat.
Spezielle Sw oder Av ist nicht drauf. Hyper V, AD Controller, storage spaces. Alle VMs aus. Einzig ein alter IBM 5014 / LSI 9248 könnte Probleme machen. Secure Boot is aus. Uefi boot an.
Ideen?
Hab das gleiche Problem.
Allerdings komme ich noch mit einem User per RDP drauf, mit einem anderen aber nicht. Dort bleibt der Screen schwarz. Gibt es schon eine Lösung dafür?