Codequalität: Microsoft und die Patches

Codequalität: Microsoft und die Patches

Gefühlt mehren sich die Probleme nach dem Patchen von Windows-Systemen bereits seit geraumer Zeit. Neben Fehlerbildern, die man der großen Vielfalt unterschiedlicher Hardware unterschieben zuschreiben kann, so lassen manche Fehler aber auch darauf schließen, dass einfach nicht richtig getestet wird und die Codequalität einfach nicht mehr stimmt.

Zum Thema Testen hatte ich ja schon einmal geschrieben, aber es ist mal wieder nötig.

Ein solches Beispiel ist das “Security Update for Exchange 2016 CU7” bzw. CU8:

Der “tödliche Witz Patch”

Da ich hier nicht nach dem Prinzip der Waschweiber einfach tratsche, folgt nun ein Tatsachenbericht, der mich den Großteil eines Montagmorgens gekostet hat. Der fragliche Patch mit der KB4073392 wurde mit einem Schwung anderer Updates installiert, schlug jedoch ohne besonders viele Informationen fehl. Dumm war hier aber, dass sämtliche Exchange-Dienste und ein paar Weitere, wie z.B. der IIS nicht nur gestoppt, sondern deaktiviert waren.

Einem genervten ändern des Startverhaltens auf “automatisch” und dem manuellen Starten verschiedener Dienst folgten diverse Fehlermeldungen von nicht verfügbaren Sockets und ASP-Exceptions, kurz: Einmal durchs Gemüsebeet und der Server war ein Totalausfall.

Die Lösung im Web

Eine Recherche (könnten Exchange-Admins eigentlich ohne Suchmaschinen bei dieser Codequalität existieren?) ergab dann, dass das Update tatsächlich ein echter Killer ist. Einzelheiten auf der Webseite von meinen tiefsten Respekt für Philipp Hungerbühler

Warum, Microsoft? Warum???

Hier nur soviel: Bei der Installation des Patches wird ein Powershell Cmdlet aufgerufen, dass out of the Box so nicht existiert. Anstatt stop-service wird stop-setupservice aufgerufen. Der Workaround besteht im Grunde darin, ein Alias in der Powershell anzulegen, damit stop-setupservice als stop-service interpretiert wird. Das ist ärgerlich!

Was mich hier aber richtig auf die Palme bringt und gleichermaßen frustriert ist, dass das auf keinem Normalsystem je getestet worden sein kann, oder gibt es da draußen Admins, die Aliase für stop-service in der Powershell anlegen, “falls mal was kommt”?

Zwar hat nach diesem Eingriff der Patch dann erfolgreich installiert, aber sämtliche Dienste musste ich dennoch händisch auf automatischen Start ändern und manuell starten.

Microsoft hat es also aufgrund unzureichender Qualitätssicherung geschafft, einen Patch zu verteilen, der aufgrund eines falschen cmdlets jeden Exchange-Server auf dem es ohne Alias (also im Grunde jeden) installiert wird, crasht. Und das Sahnehäubchen: Das Update ist seit März im Umlauf und noch immer wird es mit diesen fatalen Folgen verteilt!

 

Schreibe einen Kommentar