Manche Windows 10 VPN-Clients mit SSTP-Verbindungen scheinen nach langem problemlosem arbeiten plötzlich ihre Zertifikatsanbieterlistensperrfunktion zu „verlieren“. Die Ursache kennen wir noch nicht.
Die VPN-Einwahl via SSTP Endet mit der Meldung „Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war“.
Lösung
Eine wirkliche Lösung ist das hier nicht, aber wenn man die Verbindung dringend benötigt, kann man Windows 10 dazu überreden, die CRL nicht abzufragen:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters]
"NoCertRevocationCheck"=dword:00000001
Dann funktioniert die Verbindung in aller Regel sofort wieder.
Als Admin ist man es gewohnt, mit dem PowerShell Cmdlet Install-Module erforderliche Module nachzuinstallieren. Doch das schlägt auf älteren Systemene mit PowerShell 4 mit fehl:
install-module : Die Benennung "install-module" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdateio der eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
install-module
CategoryInfo : ObjectNotFound: (install-module:String) [], CommandNotFoundException: FullyQualifiedErrorId : CommandNotFoundException
Die PowerShell Version lässt sich schnell prüfen:
PS C:\> $PSVersionTable.PSVersion
PS C:\Users\.admin> $PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
4 0 -1 -1
Lösung
Unter Server 2012R2 gibt es die PowerShell 5, die NuGet als Paketprovider mitbringt, noch nicht automatisch. Also muss man beides manuell installieren.
Die Outlook-Suche verhält sich ja häufiger etwas ungewöhnlich, das man aber sei einer Weile praktisch nicht mehr freigegebene Ordnern (Nicht freigegebene Postfächer) von anderen Nutzern suchen kann, ist merh als ärgerlich. Grade in Zeiten von Exchange Online ist das sehr ärgerlich.
Schuld ist Outlook in Verbindunge mit dem Windows Indexdienst. Freigegebene Ordner werden standartmäßig wie freigegebene Postfächer heruntergeladen; diese landen somit im Index. Leider beauftragt Outllook bei der Sucher nur noch „Eigenes Postfach“ und liefer somit bei freigegebenen Ordnern nur leere Ergebnismengen zurück.
Woraround
Man kann Exchange dazu zwingen, die Serverseitige Suche zu verwenden. Der Zugriff auf Microsoft 365 Exchange Online-Postfächer ist dann zwar etwas langsamer, dafür liefert die Outlook-Suche plötzliche wieder korrekte Ergebnisse. Bonus: Neu vergebene Berechtigungen greifen nun ebenfalls sofort.
Das geht unter den E-Mail Konten > E-Mail > Postfach auswähen und oben „Ändern“ > Weitere Einstellungen > Erweitert > Freigegebene Ordner herunterladen AUS schalten.
„Zugriff verweigert“ bekommen (lokale) Administratoren für den Zugriff auf \\server\c$ Admin-Freigaben. Die Freigabe ist aktiv, in der Freigabenverwaltung sichtbar, das Kennwort stimmt, aber Windows verweigert den Zugriff.
Schuld ist, mal wieder, die Benutzerkontensteuerung, genauer die Remote User Account Control (Teil der UAC) in Windows. Abhängig davon mit welcher Art von Konto man sich anmeldet, also Domänenkonto oder Lokal, schlägt die Filterung des UAC-Zugriffstokens zu. Diese wirkt sich in der Standardeinstellung nicht auf Domänenkonten in der Gruppe der lokalen Administratoren aus, sondern nur auf lokale Konten.
Lösung
Um die Filterung des Tokens zu deaktivieren:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001
Das kummulative Update vom 9. März 2021 (KB5000808) verursacht BSOD-Abstürze von Windows über die w2in32kfull.sys. Das passiert beim Drucken auf vielen verschiedenen Druckern von Kyocera, HP, Nashuatec und anderen. Unabhängig vom „echten“ Gerätetreiber oder einer Universal-Lösung.
Workaround und Lösung
Es gibt zwei halbwegs praktikable Möglichkeiten den Fehler zu umgehen, bis die Hersteller aktualisierte Treiber bereitstellen.
Nutzung des XPS Treibers (im Usermode). Einige Hersteller stellen einen Treiber bereit, der den Druckauftrag via XPS verarbeitet. Das funktioniert (bei uns bisher) fehlerfrei. HPE hat sowas aber beispielsweise nicht für alle Modelle.
Nutzung des Microsoft PCL6 printer drivers. Die Drucker verstehen alle PCL6, die Druckaufträge funktionieren also fehlerfrei. Leider verliert man den Zugriff auf die Drucker-Spezifischen Funktionen (PIN-Freigabe, Tackern …), aber einfache Drucke funktionieren erstmal wieder.
Update: Die Deinstallation von KB5000808 hilft natürlich auch 😎
Update: Die Hersteller arbeiten mit Hochdruck an aktualisierten Treibern (… „working hard on this problem …“).
