Archiv des Autors: weed

Bei „großen“ Updates wie den CU’s oder dem Upgrade auf eine neue Version taucht gerne mal Fehlercode 0x800f0922 auf. In der Fehlerdatenbank ist das ein CBS_E_INSTALLERS_FAILED, was nicht viel weiterhilft. Der Fehlercode ist aber (immerhin) also nicht spezifisch für Windows-Update, es ist ein Rollen- oder Softwareinstallationsfehler.

Lösung(en)

Es gibt, wie immer, mehrere Ursachen für 0x800f0922. Am häufigsten begegnet uns die defekte Zählerdatenbank des PerfCounterInstallers, das sollte man vieleicht zuerst ausprobieren.

Möglichkeit 1 (PerfCounterInstaller)

Die Performance Counter (PerfCounterInstaller) Zählerdatenbank ist kaputt. An der „als Administrator“ ausgeführten Shell kann man selbige (und den WMI-Zugriff) aber schnell zurücksetzen:

lodctr /R
winmgmt.exe /RESYNCPERF

Meistens funktioniert die Installation danach sofort ohne Fehler.

Möglichkeit 2 (RestoreHealth)

Das Windows Base-Image ist kaputt. Das kommt schon mal bei verwickelten .NET FrameWork Installationen vor oder mehrfachem hinzufügen/entfernen von Windows Sever Rollen. Aber auch das ist meistens schnell behoben.

dism /Online /Cleanup-Image /RestoreHealth

Möglichkeit 3 (Edge „not found“)

Microsoft Edge wurde „falsch“ deinstalliert oder die Preview wurde nicht richtig aktualisiert. Einige Updates, vor allem KB5003173, versuchen zusätzliche Dateien für Edge aktualisieren. Das schlägt aber fehlt, wenn der Ordner %ProgramFiles(x86)%\Microsoft\Edge\ leer ist. Die Lösugn besteht darin, diesen leeren (!) Ordner einfach zu entfernen.

rd "%ProgramFiles(x86)%\Microsoft\Edge"

Möglichkeit 4 (.NET Framework)

Der Aktualisierungsvorgang kann auch mit Fehler 0x800f0922 fehlschlagen, wenn die .NET Framework 3.5 Komponenten nicht aktiviert sind. Das kann man an der „Als Administrator“ Shell ebenfalls schnell ändern, nachdem man die Windows-CD mit dem „WinSXS“ Ordner eingelegt (oder gemountet) hat:

Dism /online /enable-feature /featurename:NetFX3 /All /Source:<LAUFWERK>:\sources\sxs /LimitAccess

Hat man keine CD zur Hand, findet man den „.NET Framework 3.5 Offline Installer“ hier:

https://dotnet.microsoft.com/en-us/download/dotnet-framework/net35-sp1

Der „Open SSTP Client“ von KOBAYASHI Ittoku ist schon länger ein gerne gewählter Client zur Verbindung Microsoft SSTP (MS-SSTP) Protokoll.

Seit Windows Server 2016 (auch 2019 und 2022) gibt es einen Verbindungsfehler („receiveChapFailure„) wenn man sich einwählen möchte.

Die Fehlermeldung im Ereignisprotokoll lautet:

Der Benutzer DOMAIN\USERNAME, der eine Verbindung mit <IPAADRESS> hergestellt hat, konnte sich aus folgendem Grund nicht authentifizieren: Die Remoteverbindung wurde verweigert, weil die angegebene Kombination aus Benutzername und Kennwort nicht erkannt wird oder das ausgewählte Authentifizierungsprotokoll nicht für den RAS-Server zulässig ist.

Lösung

Die Verwendung von „@“ (UPN) anstelle der alten Syntax „\“ (NT-Logon) ist erforderlich, um den Fehler beim Herstellen einer Verbindung zu vermeiden.

Sobald man die Verbindung auf „[email protected]“ umstellt, ist die Einwahl sofort wieder da.

Thx Dariusz!

Der IIS braucht für Websockets (WS:// oder WSS://) ein bisschen Nachhilfe. Der IIS, oder auch die Internetinformationsdienste unterstützen WS/WSS nativ (und auch sehr performant), aber Secure-by-Default mit dem Setting „off“. Das gilt genauso auch für den ARR mit (pro-site) aktivem ReverseProxy.

Die Aktivierung ist aber im Wesentlichen in drei Schritten erledigt.

Lösung

1. Das Windows-Feature (IIS-Feature) Websockets via PowerShell installieren

PS C:\> Install-WindowsFeature -name Web-WebSockets

… oder das selbe im GUI (Server-Manager) erledigen. Features Hinzufügen > Webserver > Anwendungsentwicklung > WebSocket-Protokoll

2. Die Nutzung (Inhaltsänderung) der Servervariable HTTP_SEC_WEBSOCKET_EXTENSIONS Serverweit erlauben.

Serverweit: Internetinformationsdienste-Manager > links auf den Serverknoten > rechts „URL Rewrite“ öffnen

Dann die „Servervariablen anzeigen“ …

… und über den „Hinzufügen“ Link die Variable HTTP_SEC_WEBSOCKET_EXTENSIONS anlegen.

3. Die Nutzung für die Proxy-Site erlauben

Dazu die ARR-Site „Inbound“ Regel bearbeiten…

… unter „Servervariablen“ die HTTP_SEC_WEBSOCKET_EXTENSIONS Variable mit dem Wert „0“ und dem Haken „Vorhandenen Wert ersetzen“ hinzufügen.

⚠️ Das GUI lässt hier leider keine leeren Werte zu. Das kann manche Web-Apps (SAP, Sales-Apps, Visitenkartenscanner) verwirren.

Um das zu verhindern kann man in der zu der Site gehörigen web.config einfach die „0“ als Wert löschen und die config wieder speichern. Sobald der Wert dort leer ist, leitet der IIS auch Header ohne Inhalt unverändert weiter.

Update (Windows Server 2022)

Unter Windows Server 2022 sind uns einige Maschinen untergekommen, die aus „irgendeinem Grund“ die Websockets trotz dieser Konfiguration nicht eingeschaltet haben.

Wir konnten bisher noch nicht herausfinden, warum das sporadisch so ist, aber der Fix ist zum Glück einfach.

Im IIS-Konfigurationseditor der Site muss man unter system.webServer/webSocket den Wert enabled auf true setzen.