Januar Updates 2022 - Server bootet in Dauerschleife (2012 R2)

[Thomas Maggnussen 2]

Hallo!

 

ich wollte heute einen Windows 2012 R2 endlich auf eine neuere Maschine migrieren. Vorher hab ich ihn mal neu gestartet und er wollte noch aktualisieren (also Aktualisieren und neustarten).
Anschließend bootete er ständig neu. Zwischendurch konnte ich mich in der Domäne anmelden aber nach einer Weile kam "Auf dem PC ist ein Problem aufgetreten. Er muss neu gestartet werden". Ließ sich durch "shutdown /a" auch nicht verhindern. Anschließend brachte er bei der Anmeldung "RPC-Server nicht verfügbar". Dummerweise war der Server nicht von mir und das Kennwort des Wiederherstellungsadmin mir nicht bekannt (blöder Fehler). Konnte also auch nicht in den abgesicherten Modus.

 

Jedenfalls hab ich dann nach Stunden die Ursache und Lösung gefunden. Zunächst habe ich ihn vom Netzwerk getrennt. Dann war immerhin eine Anmeldung an der Domäne möglich. Netzwerkkarten neu installiert, an netzt gehängt und siehe da: Nach ein paar Minuten wieder das runterfahren.

Prozedur wieder von vorne und die Windows Updates deinstalliert die heute installiert wurden. Jetzt läuft er seit 3 Stunden mit der Migration. Der Server läuft in eine VMWARE ESXI. Ich vermute die Updates hatten ein Problem mit dem VM-Netzwerkkartentreiber. Das System ist natürlich bei weitem nicht mehr auf dem aktuellsten Stand gewesen.

 

Würde mich interessieren ob es woanders auch derartige Probleme nach dem Installieren der Updates gab.

Muss am WE auch Servern von 2016 und 2019 ebenfalls Patchen die auch auf dem ESXI laufen.

 

Danke & LG

Thomas

 

 

 

 

[phatair 39]

Hi Thomas,

 

bekanntes Problem, siehe hier (die einzelnen Artikel sind in dem Artikel verlinkt) ->https://www.borncity.com/blog/2022/01/14/microsoft-patchday-probleme-jan-2022-bugs-besttigt-updates-zurckgezogen/

Gibt noch mehr Probleme mit den Januar Updates. Macht langsam kein Spaß mehr Windows Server zu administrieren bzw. zu aktualisieren...

[Thomas Maggnussen 2]

Ohhh Mann. Krass!

Ich hab langsam auch keine Lust mehr. Das ist doch Wahnsinn. Ich kann nicht jeden Tag irgendwo im Internet suchen ob die Patches klappen oder nicht und die Zeit zahlt mir auch keiner.

Aber vielen Dank, dann mach ich keine am Wochenende.

[cj_berlin 1.306]

Wir erzählen den Leuten seit 20 Jahren, dass man Patches testen soll, und alle nicken dabei verständnisvoll, tun's aber am Ende nicht oder höchstens als "Smoke-Test". Wer Code - egal ob es eine neue Anwendung oder ein Patch der bestehenden ist - ungetestet in die Produktionsumgebung rauslässt, hat keine Produktionsumgebung, sondern nur eine Testumgebung, die er produktiv benutzt.

[NorbertFe 2.027]

vor 53 Minuten schrieb Thomas Maggnussen:

Ich kann nicht jeden Tag irgendwo im Internet suchen ob die Patches klappen oder nicht und die Zeit zahlt mir auch keiner.

Tja, dann musst du hinterher eben aufräumen, oder willst lieber ne Dose Mitleid? :)

Und ja, ich finde die Patchqualität auch nicht prickelnd. :)

[Thomas Maggnussen 2]

vor 25 Minuten schrieb cj_berlin:

Wir erzählen den Leuten seit 20 Jahren, dass man Patches testen soll, und alle nicken dabei verständnisvoll, tun's aber am Ende nicht oder höchstens als "Smoke-Test". Wer Code - egal ob es eine neue Anwendung oder ein Patch der bestehenden ist - ungetestet in die Produktionsumgebung rauslässt, hat keine Produktionsumgebung, sondern nur eine Testumgebung, die er produktiv benutzt.

 

Also du meinst so: Ich habe 16 Server die ich bei jedem Patchday aus dem Backup zurücksichern soll. Dann mach ich da überall die Updates und schau mir dann an ob alle Anwendungen und Dienste laufen?
Bis ich damit fertig bin, kommt der nächste Patchday. Ausserdem brauch ich die doppelte Menge an TB für eine "Testumgebung".

Man sollte ja davon ausgehen, dass die Patches von MS "getestet" werden oder haben die so krass andere Server als wir, dass es bei denen Funktioniert und bei uns nicht? MS schreibt die Patche, testet sie hoffentlich in seiner Testumgebung und stellt sie dann aufs Windows Update - was man als Produktivumgebung ja betrachten kann. Ich soll dann die selbe arbeit nochmal machen? Das ist doch absurd meinst du nicht?

Vor 20 Jahren galt "Never touch a running System". Das geht heute auch nicht mehr bzw. schön langsam überlege ich mir das. Sicherheitsprobleme auch auf ungepatchen Systemen gabs bisher (Gottseidank) nicht. Was es gab war z.B. heute ein Ausfall von 4 Stunden heist: Keine Viren und kein Sicherheitsproblem sorgt für ausfall sondern "Updates"

Wenn du mir veräts, wie du das so testest bin ich ganz Ohr

 

vor 27 Minuten schrieb NorbertFe:

Tja, dann musst du hinterher eben aufräumen, oder willst lieber ne Dose Mitleid? :)

Und ja, ich finde die Patchqualität auch nicht prickelnd. :)

Man sollte ja davon ausgehen, dass die Patches von MS "getestet" werden oder haben die so krass andere Server als wir, dass es bei denen Funktioniert und bei uns nicht? MS schreibt die Patche, testet sie hoffentlich in seiner Testumgebung und stellt sie dann aufs Windows Update - was man als Produktivumgebung ja betrachten kann. Ich soll dann die selbe arbeit nochmal machen? Das ist doch absurd meinst du nicht?

Also Analog: ich kauf mir am ersten Tag ein neues Auto (Verkaufsstart) und nach einem Tag stelle ich fest, dass die Sitze locker werden, der Motor nicht mehr geht und die Lichter ausgebrannt sind. Am selben Tag lese ich es dann das dem Hersteller die Probleme bekannt sind...

Alles klar ;_)

Aber um es zusammen zu fassen. Es ist eigentlich ganz klar:
Patches für On-Premise Server werden noch halbherzig gemacht oder gar mit Absicht fehlerhaft. Die Lösung "Komm in unsere Cloud, hier haben wir keine Probleme"

Dahin geht es ja auch. Lieber wäre mir von mir aus eine monatliche Pauschale für die On-Premise Server updates. Aber es geht wohl auch darum möglichst alle Firmen in der eigenen Cloud zu haben um eine Abhängigkeit herzustellen, die Preise jederzeit erhöhen zu können (schon längst geschehen) und damit man es schlecht Rückängig machen kann (Abhängigkeit). Bin echt kein Verschwöhrungstheoretiker und habe nie an das "Böse MS" geglaubt. ABER da hab ich mich wohl getäuscht.

Mein Leben lang habe ich mit MS gutes Geld verdient. Aber mittlerweile ist das Umfeld um das ich mich kümmern muss viel größer geworden und andere Aufgaben als "Serverwartung" verlangen meine Aufmerksamkeit.

Naja, immerhin regte mich das schon letztes Jahr auf insofern wird jetzt nach und nach auf GPL umgestellt oder eben Hyprid mit der MS Cloud.

[phatair 39]

vor 46 Minuten schrieb cj_berlin:

Wir erzählen den Leuten seit 20 Jahren, dass man Patches testen soll, und alle nicken dabei verständnisvoll, tun's aber am Ende nicht oder höchstens als "Smoke-Test". Wer Code - egal ob es eine neue Anwendung oder ein Patch der bestehenden ist - ungetestet in die Produktionsumgebung rauslässt, hat keine Produktionsumgebung, sondern nur eine Testumgebung, die er produktiv benutzt.

Sorry aber das ist vollkommen unrealistisch und klingt so als wäre jedes Unternehmen/IT Abteilung dazu in der Lage.  Du lässt aber die Realität dabei komplett außen vor. 

 

Bei Windows clients mag das zum Teil noch zutreffen

Server aber nur sehr schwer. Große Unternehmen können das machen, aber doch nicht jedes KMU.

 

Nicht jedes Unternehmen hat eine Test Domäne und kann jedes System in einer Testumgebung abbilden. Das ist oft finanziell oder/und von der IT Mannschaft gar nicht zu bewältigen. 

 

Davon abgesehen sind in letzter Zeit die Microsoft Updates so miserabel, dass es dir passieren kann, dass in der Testumgebung alles sauber läuft und dann in der Produktivumgebung etwas schief geht. 

 

Außerdem sind das so gravierende Fehler, dass man sich fragt ob Microsoft überhaupt noch eine Qualitätssicherung hat. Admins sind keine beta tester und in einer einigermaßen normalen Windows IT Umgebung sollten solche Fehler nicht passieren, wenn Microsoft seinen Job machen würde. 

[cj_berlin 1.306]

Der Vergleich mit dem Auto hinkt insofern, als dass der Hersteller das fertige Auto in seiner Gewalt hatte, bevor es an Dich ausgeliefert wurde, und somit eine Qualitätssicherung des gesamten Konstruktes prinzipiell möglich war. Bei Dir ist ja nicht "das Windows" in die Bootschleife gegangen, sondern ein von Dir gebauter und konfigurierter Server mit diesem Windows drauf, der auch noch Teil einer größeren Umgebung ist. Diesen Server als Ganzes hat der Hersteller noch nie gesehen, Und ja, vielleicht haben sie auch krass andere Server. Entzieht sich meiner Kenntnis. Sie sind aber definitiv nicht identisch mit unseren.

 

Produktionsserver aus Backup zum Testen zurückholen ist ein Ansatz und wird auch bei manchen Firmen praktiziert, um den Preis der "doppelten TB". Natürlich wird es nicht händisch gemacht. Der andere Ansatz ist eine Testumgebung parallel zur Produktion zu betreiben, halt mit weniger Daten drin. Dort wird dann alles Neue zuerst eingespielt und geschaut, ob die Umgebung wieder hochkommt. Da Du in Deiner "Produktion" ja bestimmt Monitoring am Start hast, kannst Du doch maschinell beurteilen, wie der Gesundheitszustand der Umgebung so ist.

 

Auch ich wünsche mir das mit der Patch-Qualität anders. Aber am Ende des Tages, wenn ich die Umgebung betreiben soll, kann ich nicht Teile dieser Betriebsverantwortung stillschweigend auf die Hersteller auslagern, ohne dass sie wissen, dass sie diese Verantwortung jetzt tragen, und dem zugestimmt haben.

[mwiederkehr 373]

vor 10 Minuten schrieb Thomas Maggnussen:

Also du meinst so: Ich habe 16 Server die ich bei jedem Patchday aus dem Backup zurücksichern soll. Dann mach ich da überall die Updates und schau mir dann an ob alle Anwendungen und Dienste laufen?
Bis ich damit fertig bin, kommt der nächste Patchday. Ausserdem brauch ich die doppelte Menge an TB für eine "Testumgebung".

Die Testumgebung muss keine 1:1-Kopie der Produktivumgebung sein. (Sie sollte eigentlich keine Produktiv-Daten und -Passwörter enthalten, aber das ist ein anderes Thema.) Ich halte es in normalen Umgebungen auch für unrealistisch, alles zu testen. (Wer den Fehler bei der Outlook-Suche beim Dezember-Update bei eigenen Tests bemerkt hat, darf mir gerne widersprechen. ) Ich „teste“ auch hauptsächlich, indem ich die Meldungen im Internet verfolge. Aber ich installiere die Updates gestaffelt und auf den unwichtigsten Servern zuerst.

 

Und, da man wie erwähnt nicht alles testen kann, ist es wichtig einen Plan zu haben, wie man im Falle eines Problems wieder auf den alten Stand zurückkommt. Wenn man per RDP einen Server beim Kunden patcht und der nicht mehr online kommt, sollte man Zugriff auf die Remotekonsole und das ISO von Veeam haben. In einem Hyper-V-Cluster patcht man nicht alle Hosts gleichzeitig, ebenso patcht man nicht alle DCs gleichzeitig. In dem Sinne sind die aktuellen Probleme zwar mühsam, aber nicht kritisch. Man bemerkt die Probleme ja immerhin unmittelbar. Mühsamer sind die Fehler, die erst nach ein paar Tagen auftauchen, wenn man nicht einfach den Snapshot wiederherstellen kann.

 

vor 21 Minuten schrieb Thomas Maggnussen:

Vor 20 Jahren galt "Never touch a running System". Das geht heute auch nicht mehr bzw. schön langsam überlege ich mir das. Sicherheitsprobleme auch auf ungepatchen Systemen gabs bisher (Gottseidank) nicht.

Ich halte viele der dauernden Neuerungen ebenfalls für überflüssig. Aber Deine Aussage bezüglich Sicherheitsproblemen kann ich leider nicht bestätigen. Klar muss man schauen, welche Fehler behoben werden und auf einem isolierten Hyper-V ohne Internetzugang ist eine Lücke im Browser nicht so kritisch wie auf einem Terminalserver. Ich hatte jedoch schon öfter mit Systemen zu tun, die wegen fehlender Updates aufgemacht wurden. Besonders Systeme, die aus dem Internet erreichbar sind.

 

vor 26 Minuten schrieb Thomas Maggnussen:

Man sollte ja davon ausgehen, dass die Patches von MS "getestet" werden oder haben die so krass andere Server als wir, dass es bei denen Funktioniert und bei uns nicht? MS schreibt die Patche, testet sie hoffentlich in seiner Testumgebung und stellt sie dann aufs Windows Update - was man als Produktivumgebung ja betrachten kann. Ich soll dann die selbe arbeit nochmal machen? Das ist doch absurd meinst du nicht?

Von der Qualität der letzten Updates bin ich auch enttäuscht. Es ist mir unverständlich, dass die Probleme bei den Tests nicht entdeckt wurden und dass es dann noch so lange gedauert hat, bis die Updates zurückgezogen wurden. Aber Microsoft kann trotzdem nicht in Deiner Umgebung testen. Sie haben nicht Deine Kombination an Hardware und nicht Deine Software.

[NorbertFe 2.027]

vor 34 Minuten schrieb Thomas Maggnussen:

MS schreibt die Patche, testet sie hoffentlich in seiner Testumgebung und stellt sie dann aufs Windows Update - was man als Produktivumgebung ja betrachten kann. Ich soll dann die selbe arbeit nochmal machen? Das ist doch absurd meinst du nicht?

Ja man "sollte" davon ausgehen können, und doch stöhnen alle auf, wie schlecht das doch immer alles ist. Wenn also alle immer davon ausgehen, dass MS so schlecht ist (was in dem Fall ja auch so ist), warum sind dann alle erstaunt, wenn es mal schlecht läuft? :)

vor 35 Minuten schrieb Thomas Maggnussen:

Also Analog: ich kauf mir am ersten Tag ein neues Auto (Verkaufsstart) und nach einem Tag stelle ich fest, dass die Sitze locker werden, der Motor nicht mehr geht und die Lichter ausgebrannt sind. Am selben Tag lese ich es dann das dem Hersteller die Probleme bekannt sind...

Nicht alles was hinkt ist ein Vergleich. Und Auto und IT sind selten treffend. :)

[cj_berlin 1.306]

vor 2 Minuten schrieb phatair:

Admins sind keine beta tester und in einer einigermaßen normalen Windows IT Umgebung sollten solche Fehler nicht passieren, wenn Microsoft seinen Job machen würde. 

Wo steht das denn bitte? Woraus leitet sich bei Dir dieser Anspruch ab? Der "Job" von Microsoft steht in der EULA, der die Admins bei der Installation des Produktes zugestimmt haben. Willst Du den Wortlaut der "Jobdefinition" nochmal hören? Gerne:

 

The SOFTWARE is provided AS-IS.

 

Für den Hersteller ist es eine Abwägung: Wenn ich 300 hochqualifizierte Leute mehr einstellen muss, um QA zu verbessern, kostet mich das im Jahr 50 Millionen. Wenn X Kunden zu Linux wechseln, kostet mich das im Jahr Y Millionen. an verlorenem Lizenzumsatz. Wir haben doch freie Marktwirtschaft, oder nicht? Die Theorie ist, der Kunde hat die Wahl  

[phatair 39]

vor 56 Minuten schrieb cj_berlin:

Wo steht das denn bitte? Woraus leitet sich bei Dir dieser Anspruch ab?

Ähm... diesen Anspruch sollte man an eine Software haben dürfen. Komischerweise schaffen das auch viele Hersteller und MS hat das auch lange Zeit geschafft. 

 

Ich wußte nicht, dass "The SOFTWARE is provided AS-IS." bedeutet, dass die Software bei jedem Update nicht mehr wie gewünscht funktioniert.

 

Wir kommen hier wohl nicht zusammen. 

Ich bleibe dabei, dass MS hier aktuell einen miesen Job macht und man das nicht einfach mit "ihr müsst halt Updates testen" abtun kann! Das ist vollkommen an der Realität vorbei argumentiert. 

Testen gehört grundsätzlich dazu, aber die Menge an fehlerhaften Updates von MS die grundlegende Features zerstören sind ein Unding und dürfen so einen Unternehmen nicht in der Regelmäßigkeit passieren. 

 

In der Theorie hat der Kunde natürlich die Wahl, in der Praxis aber nicht, da dafür die meisten Umgebungen viel zu sehr auf MS ausgerichtet und komplex sind. 

 

Vielleicht sorgt es dafür, dass zukünftige Projekte an andere Herstellern gehen und damit die Umgebung dann weniger MS lastig wird. Ich glaube aber eher nicht daran. 

[cj_berlin 1.306]

vor 8 Minuten schrieb phatair:

Ähm... diesen Anspruch sollte man an eine Software haben dürfen. Komischerweise schaffen das auch viele Hersteller und MS hat das auch lange Zeit geschafft. 

Ach, komm. Ich mach seit den 90ern mit MS Produkten rum, und die Patchqualität von MSFT war schon immer Gegenstand des lauten Gejammers. Das war mal mehr und mal weniger schlimm. Besser als diesmal war es meistens, aber da liegt die Latte auch nicht besonders hoch. That said, in meinem Dunstkreis hat es kaum jemanden erwischt. Vielleicht haben meine Kunden Server, die eher so sind wie die von Microsoft?

vor 10 Minuten schrieb phatair:

Ich wußte nicht, dass "The SOFTWARE is provided AS-IS." bedeutet, dass die Software bei jedem Update nicht mehr wie gewünscht funktioniert.

Dass die Software wie von Dir gewünscht funktioniert, darauf bestand bei Standardsoftware noch nie ein Anspruch.

vor 11 Minuten schrieb phatair:

Das ist vollkommen an der Realität vorbei argumentiert. 

"Die Realität" musst Du erst mal akzeptieren, dann kommen wir auch zusammen. Du musst nämlich zwischen Schuld und Verantwortung unterscheiden.

 

In "der Realität" hat Dein Arbeitgeber (in der Annahme, dass Du interne IT bist) zwei Verträge:

1. Mit Microsoft. In dem steht: The software is provided as-is. Er ist diesen Vertrag aus Gründen eingegangen, die Du vermutlich nicht beeinflussen kannst.
2. Mit Dir. In dem steht: Dein Job ist es, die Umgebung am Laufen zu erhalten. Nach bestem Wissen und Gewissen, versteht sich - Du sollst weder zaubern noch hellsehen können. Aber nichtsdestotrotz ist die Lauffähigkeit der Umgebung DEIN Job.

Merkst Du es? DEIN Job. Wie Du das Ergebnis erreichst, ist Dir überlassen. Wenn Dir dafür Mittel fehlen, musst Du das nach oben melden, erst ab dann bist Du entlastet, und es ist der Job der GL. Wenn Du nichts sagst, meint der Arbeitgeber, Du hast es im Griff, und ist um so mehr verwundert, wenn der Kram am Montag steht. Du hast nämlich Deinem Arbeitgeber gar nicht die kaufmännische Entscheidung überlassen, X Tausend ins Testen zu investieren oder ein Risiko einzugehen, sondern Du hast beschlossen, dass das Testen eh an der Realität vorbei ist und man es deswegen gleich lassen kann.

 

Aber es ist nicht der Job von Microsoft oder auch von irgendeinem anderen Hersteller, dafür zu sorgen, dass Deine Umgebung läuft. Es gibt Ausnahmen: Azure Stack zum Beispiel. Da garantiert Dir Microsoft zusammen mit dem Hardware-Hersteller eine gewisse Verfügbarkeit. Aber da hast Du auch keine administrative Gewalt mehr über die Plattform, auch wenn sie bei Dir on prem steht.

 

Und man kann es nicht oft genug wiederholen: An der miserablen Qualität der MSFT-Patches gibt es nichts zu diskutieren. Das ist eines Weltkonzerns unwürdig, und wir sind alle sehr enttäuscht. Es steht Dir frei, Deinen Job besser zu machen. Sobald Du die Qualitäts Deines Jobs der Microsoft-Qualität unterordnest, sieht auch Deine Arbeit bescheiden aus.

[mwiederkehr 373]

Ohne Microsoft für die jüngsten Probleme in Schutz nehmen zu wollen, sollte doch erwähnt werden, dass sie eine schwierige Aufgabe haben. Ein Patch muss nicht nur ein (Sicherheits-)Problem beheben, das System muss danach auch noch kompatibel zu allen unterstützten Versionen von Windows sowie Office, Exchange, SQL Server etc. sein. Das führt dann zwangsläufig zu „Verrenkungen“ wie Registry-Keys, die je nach Datum/Updatestand eine andere Funktion haben.

[phatair 39]

vor 28 Minuten schrieb cj_berlin:

Dass die Software wie von Dir gewünscht funktioniert, darauf bestand bei Standardsoftware noch nie ein Anspruch

Meinst du das ernst?

Jede Software sollte grundsätzlich so funktionieren wie vom Hersteller definiert. Es geht doch nicht darum, wie ich mir das wünsche...

Ein DC darf nicht einfach neu starten... das ist doch nicht nur mein persönlicher Anspruch...

 

Deine Logik ist ja interessant. Danach kann jeder Hersteller machen was er will und einfach sagen, ist halt so. Bist a Depp

 

Keine Software ist fehlerfrei, dass ist klar, aber hier muß man auch unterscheiden. 

 

Und ich bin auch seit knapp 20 Jahren it admin und habe die unterschiedlichsten Netzwerke administriert. Aus meiner Sicht hat sich die Qualität bei MS und den Updates in den letzten 2 Jahren deutlich verschlechtert. Es war früher sicherlich nicht top, aber besser. 

 

Aber die Aussagen mit dem testen und dem  Anspruch an Software ist und bleibt für mich eine sehr fragwürdige und klingt eher nach Theorie als nach der Realität. 

 

Aber gut. Für mich ist hier Schluss mit der Diskussion. Das führt zu nichts und jeder hat so seine Ansichten. 

bearbeitet 14. Januar 2022 von phatair