Kurzer Hinweis an Administratoren von Windows-Umgebungen. Die kumulativen Updates vom 14. Februar 2023 können Kollateralschäden bei den MIME-Typen-Definitionen in der Registrierung verursachen. Es kann Probleme mit dem IIS geben und auch der WSUS könnte tangiert sein. Ich stelle einfach mal vorsorglich einige Information-Fragmente ein, die ich auf die Schnelle zusammen geklaubt habe, nachdem mich eine Warnung erreichte.
Anzeige
Warnung vor MIME-Type-Kollateralschaden
Mir ist die Nacht der nachfolgende Tweet von MVP Mike Terrill ins Auge gesprungen, der allgemein warnt, dass die CUs von Februar 2023 selbst definierte MIME-Typen für den IIS beschädigen könnten.
Mike Terrill warnt, dass diejenigen, die .wim als MIME-Typ zur Standard-Website in IIS hinzugefügt haben, in Probleme laufen. Das Februar 2023 CU (kumulative Update) fügt .wim als als 'application/x-ms-wim' MIME-Typ zur Server-Ebene in IIS hinzu. Das könnte alle MIME-Typen, die auf unterer Ebene hinzugefügt wurden, zerstören.
Ergänzung: Mike hat auf Nachfragen noch geschrieben, dass er nur auf Windows Server 2019 getestet habe. Aber wenn es mit UUP zusammenhängt, könnte er sich vorstellen, dass es alle Versionen von Server betrifft.
Da war was mit .wim MIME-Type
Der Tweet hat sofort etwas bei mir im Hinterkopf getriggert, hatte ich doch gestern was zu MIME-Typen und Problemen mit WSUS im Blog (siehe meinen Blog-Beitrag Microsofts Februar 2023-Patchday: Falsche Updates in WSUS, Exchange und Windows). Hintergrund ist, dass einige Administratoren feststellten, dass Updates für Windows 11 22H2 von einigen Systemen nicht per Windows Server Update Services (WSUS) verteilt werden. Microsoft hat dazu den Eintrag WSUS might not offer updates to Windows 11, version 22H2 veröffentlicht.
Updates, die am 14. Februar 2023 oder später veröffentlicht wurden, werden von einigen Windows Server Update Services (WSUS)-Servern möglicherweise nicht für Windows 11, Version 22H2, angeboten. Die Updates werden zwar auf den WSUS-Server heruntergeladen, aber möglicherweise nicht an die Client-Geräte weitergegeben.
Betroffen sind nur WSUS-Server mit Windows Server 2022, die von Windows Server 2016 oder Windows Server 2019 aktualisiert wurden.
Dieses Problem wird durch die versehentliche Entfernung der erforderlichen Unified Update Platform (UUP)-MIME-Typen während des Upgrades auf Windows Server 2022 von einer früheren Version von Windows Server verursacht.
Betroffen von diesem Problem sind sowohl Windows 11 22H2 als Client als auch Windows Server 2022. Um dieses Problem zu beheben, schreibt Microsoft, können Administratoren die gelöschten MIME-Typen manuell hinzufügen (siehe den Techcommunity-Artikel Adding file types for Unified Update Platform on premises vom 8. Sept. 2022). Dort heißt es:
Two file types are required for the on-premises update management with Unified Update Platform. […]
Specifically, we have observed that if you use Windows Server Update Services (WSUS), you need to add .msu and .wim MIME types on your WSUS servers to support UUP on premises.
Da ist also der Grund genannt, warum ein Administrator ggf. mit dem .wim MIME-Type manuell basteln will.
MS Server-Updates beschädigen IIS
Und dann bin ich bei Recherchen noch auf den Artikel MS Windows Server Updates 14 Feb 2023 – breaks IIS for Alliance gestoßen, der ein weiteres Informations-Fragment beisteuert. Phil Seifert schreibt:
Anzeige
On 14 Feb 2023, the following two MS updates for Windows Server have caused issues with Alliance and IIS.
Windows 2016 KB5022838
Windows 2019 KB5022840
Users reported seeing IIS internal error messages, blank screens, etc. after these were deployed. This was reported impacting Astea Browser, Publisher website and Mobile Edge by our customers.
Im Beitrag beschreibt Pfeifer das Problem und eine Lösung für deren Szenario. Das sind zwar jetzt drei Fragemente, die nichts miteinander zu tun haben müssen. Behaltet das einfach als Gedächtnisstütze im Hinterkopf – falls es Probleme mit MIME-Zuordnungen geben sollte. Wer mehr Informationen hat, kann ja einen Kommentar hinterlassen.
Ähnliche Artikel:
Microsoft Security Update Summary (14. Februar 2023)
Patchday: Windows 10-Updates (14. Februar 2023)
Patchday: Windows 11/Server 2022-Updates (14. Februar 2023)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (14. Februar 2023)
Patchday: Microsoft Office Updates (14. Februar 2023)
Exchange Server Sicherheitsupdates (14. Februar 2023)
Windows Server 2022: Februar 2023-Patchday und das ESXi VM-Secure Boot-Problem
Februar 2023 Patchday: EWS-Probleme nach Exchange Server Sicherheitsupdate
Microsofts Februar 2023-Patchday: Falsche Updates in WSUS, Exchange und Windows
2015
Was mir ebenfalls aufgefallen ist, nach dem Februarupdate sind die Komponentenspeicher beschädigt (Windows Server 2016).
sfc /verifyonly
-> Vom Windows-Ressourcenschutz wurden Integritätsverletzungen festgestellt.
sfc /scannow
-> Vom Windows-Ressourcenschutz wurden beschädigte Dateien gefunden, und
einige davon konnten nicht repariert werden.
Das ist bei Windows Server 2016 ja quasi Buildin wenn man das erste Image 1607 verwendet, dieses hat einen extrem schlechten Servicing Stack. Schnell Upgraden/Migrieren.
Dein Bildschirmabzug zeigt wieder einmal, dass die LINKE Hand des Redmondschen Teufels (besser: Kaspers) nicht weis, was die rechte Hand gemacht hat: der MIME-Typ für .EFI (das sind wie .EXE, .DLL, .COM, .OCX, .AX, .ACM, .MUI … "portable executables") ist application/vnd.microsoft.portable-executable
Diesen MIME-Typ hat die RECHTE Hand vor 8 Jahren bei der IANA registriert: https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable
EINMAL mit Profis arbeiten…
"Betroffen sind nur WSUS-Server mit Windows Server 2022, die von Windows Server 2016 oder Windows Server 2019 aktualisiert wurden."
– Das liest sich für mich so, als ob nur WSUS Server betroffen sind, die per Inplace Upgrade von 2016/19 direkt auf 2022 gehoben wurden. Wer macht denn sowas?
>– Das liest sich für mich so, als ob nur WSUS Server betroffen sind, die per >Inplace Upgrade von 2016/19 direkt auf 2022 gehoben wurden. Wer macht >denn sowas?
Leider immer noch zu viele. Zuerst wird viele Stunden damit verbracht, nach Pro und Contra zu suchen. Anschließend noch in vielen Foren gefragt um später dann das Upgrade zu machen. Funktioniert es, feiern sie sich als Helden! ;) Funktioniert es NICHT, ist MS der Schuldige.
In der Zeit, die man mit den Vor- und Nacharbeiten und des Upgrades beschäftigt war, hätte man ganz ganz leicht einen WSUS neu aufgesetzt. Und dabei natürlich auch gleich das Content um 99% verkleinern können. Aber lieber ist man ein Held. :)
Da war doch die Tage was bei WindowsPro, dass man für UUP-Updates doch bitte MIME-Typen registrieren soll: https://www.windowspro.de/tipp/wsus-fuer-windows-1011-unified-update-platform-uup-vorbereiten
Hat Microsoft den DAAs (dümmsten anzunehmenden Admins) wohl abgenommen…
Ich glaube, da fehlt noch irgendeine wesentliche Information. Ich habe hier zwei Windows Server 2022, beide Upgrades von 2019. Der eine ist noch auf dem Januar-CU, der andere schon auf Februar. Aber beide haben MIME-Typen für .msu und .wim auf Serverebene eingetragen, ohne dass ich das von Hand hätte machen müssen. Das Februar-Update hat hier für mich nichts verändert.
Und ja, die Einträge befinden sich bei beiden Patchleveln in der C:\Windows\System32\inetsrv\Config\applicationHost.config, ohne dass deswegen der IIS "kaputt" wäre.
Die Einträge stehen aber zusammen mit dem nirgenwo erwähnten .esd am Ende der Liste, außerhalb der sonst vorhandenen alphabetischen Sortierung. Dass die drei Einträge irgendwann nachträglich hinzugefügt wurden, ist also gut möglich.
Stefan Kanthak: einen .efi-Eintrag habe ich hingegen überhaupt nicht. Kann es vielleicht sein, dass der gar nicht zum Standard gehört, sondern von dem Tweet-Ersteller selbst so (falsch) hinzugefügt wurde?
Meine Lösung:
Ich habe die Datei "C:\Windows\System32\inetsrv\Config\applicationHost.config" eines defekten WSUS mit einem funktionierendem WSUS verglichen. Bis auf ein paar IDs waren die Dateien identisch.
Wichtiger Teil: (bei mir alles gleich)
staticContent lockAttributes="isDocFooterFileName">
mimeMap fileExtension=".323" mimeType="text/h323" />
…
mimeMap fileExtension=".wim" mimeType="application/x-ms-wim" />
/staticContent>
In Zeile 428 ist folgender Eintrag zu finden:
add segment="web.config" />
Datei liegt unter folgendem Pfad:
"C:\Program Files\Update Services\WebServices\Root\web.config"
Inhalt bei mir:
?xml version="1.0" encoding="UTF-8"?>
configuration>
system.webServer>
staticContent>
remove fileExtension=".esd" />
mimeMap fileExtension=".esd" mimeType="application/octet-stream" />
mimeMap fileExtension=".msu" mimeType="application/octet-stream" />
/staticContent>
/system.webServer>
/configuration>
Hier fehlt die Zeile:
remove fileExtension=".msu" />
Wenn man diese Zeile einfügt funktioniert der WSUS wieder.
Jedoch ist die Datei bei meinem funktionierendem WSUS nicht vorhanden, somit habe ich die Datei erstmal auf "web.config_old" umbenannt damit die Anpassungen nicht mehr greifen. Außerdem sind die beiden erwähnten MIME-Types ".esd" und ".msu" bei uns bereits in der Datei "applicationHost.config" enthalten.
So konnte ich alle meine betroffenen WSUS reparieren.
Warum es nur bei manchen Servern meiner Umgebung passiert ist konnte ich bisher nicht feststellen. Es gibt leider keinen Zusammenhang aus Klonen, Upgraden oder der Konfiguration bestehender Server und dem aufgetretenen Problem.