Kategorie-Archiv: Windows

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.

In vielen Szenarien möchte man auf dem localhost die HTTP-Authentifizierung verwenden. Das gilt für alle lokalen URLs, wie zum Beispiel

• http://localhost
• http://127.0.0.1
• http://SERVERNAME
• http://SERVENAME.FQDN.TEST

Lokale Webserver-Software auf einem Terminalserver, Test- und Dev- Systeme, Reverse-Proxys und ähnliches. Vor allem SharePoint mit seinen zahlreichen Scripts und automatismen benötigt gerne „logged on“ Zustand (auf dem SP-Server).

In der Standardkonfiguration erlaubt Windows Server seit 2008R2 das nicht mehr, alle Loopback-Authentifizierungen schlagen fehl und man sieht die Kennwort-Eingabeauffordeung wieder und wieder (und eine 403er Antwort im Log).

Lösung

Man muss die Loopback-Prüfung deaktivieren – oder zumindest anpassen. Diese verhindert by design Reflection-Attacken und ist grade bei teurer schlechter Software sinnvoll.

In Produktivumgebungen kann man einfach den vom Client verwendeten Hostnamen anpassen, zum Testen reicht es in der Regel die Prüfung komplett zu deaktivieren.

Prüfung deaktivieren

In die Registry eintragen, ist sofort (ohne Neustart) aktiv:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"DisableLoopbackCheck"=dword:00000001

Erlaubte Hostnamen eintragen

In die Registry eintragen, ist erst nach einem Neustart aktiv. Das ist eine „mehrteilige Zeichenfolge“ (oder „Multi-String Value“) die beim Export in Hex-Werte umgewandelt werden. Das hier ist ein Beispiel mit „SERVERNAME“ und „LOCALHOST“ darin:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]

"BackConnectionHostNames"=hex(7):53,00,45,00,52,00,56,00,45,00,52,00,4e,00,41,\
  00,4d,00,45,00,00,00,4c,00,4f,00,43,00,41,00,4c,00,48,00,4f,00,53,00,54,00,\
  00,00,00,00

Problem

Als Dienstleister bewegen wir uns ständig in Kunden-VPNs und nutzen sehr gern den Windows-Integrierten SSTP VPN-Client. Leider lässt dieser standardmäßig nur 2 gleichzeitige Verbindungen zu.

Versucht man eine weitere Verbindung herzustellen bekommt man direkt eine Fehlermeldung:

Verbindung mit VPN nicht möglich. Das Modem (oder ein anderes Gerät) wird bereits verwendet oder ist nicht richtig konfiguriert.

Lösung

Die Anzahl der Miniports kann mittels netsh erhöht werden. Dazu an einer administrativen shell einfach folgendes netsh-Command ausführen:

netsh ras set wanports device="WAN Miniport (SSTP)" maxports=3

Eine Erhöhung auf mehr als 3 Ports ist mittels netsh aber leider auch nicht möglich. (Der Wert für den Parameter „maxports“ ist ungültig.)