Windows Server 2016: Updates über WSUS funktionieren nicht – 0x80072EE2

Folgendes Szenario: Windows Server 2016 und 2019 Clients versuchen über einen WSUS, welcher im Intranet steht, Updates zu installieren. Die Clients an sich haben allerdings keine Internetverbindung. Das bedeutet, sie sind von der Außenwelt abgeschottet und können auch nicht mit den Microsoft Servern sprechen. Der WSUS wurde über die GPO korrekt definiert. In der WSUS-Konsole selbst scheinen die einzelnen W2k16 Clients auf und geben regelmäßig einen Statusreport ab. Soweit sieht die Welt in Ordnung aus. Klickt man allerdings auf „Check for Updates“ wird der Server keine Updates finden, sondern nur den Fehlercode 0x80072EE2 zurückliefern. Am Windows Server Update Service wurden aber zweifelsfrei neue Updates confirmed und die Verbindung zum Server ist uneingeschränkt verfügbar. Warum ist das so?

Das Windows Dual Scan Feature

An dieser Stelle kommt ein neues Feature von Microsoft ins Spiel: Dual Scan. Mit dieser Funktion greift ein Windows Client, trotz definierter GPO für den lokalen WSUS, auf die Microsoft Server zu. Das Problem an der Sache ist, dass Clients ohne Internetzugriff auf jene nicht zugreifen können. Ob man betroffen ist, lässt sich relativ leicht an zwei Punkten feststellen:

Einstellen prüfen

Man öffne eine Powershell und führt folgende zwei Befehle aus:

PS C:\Users\anxadmin> $MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
PS C:\Users\anxadmin> $MUSM.Services | select Name, IsDefaultAUService
 
Name                          IsDefaultAUService
----                          ------------------
Windows Server Update Service               False
Windows Update                              True

Erhält man ein „True“ beim „Windows Update“ zurück, versucht der Client ständig eine Verbindung mit den Microsoft Servern aufzunehmen und synchronisiert sich eben nicht über den WSUS.

Logs prüfen

Wird auf „Check for Updates“ geklickt, erhält man nach einer Weile ziemlich sicher folgenden Fehlercode: 0x80072EE2. Das ist schon ein Indiz dafür, dass der Windows Update Service nicht auf die Update Server zugreifen kann. Weiters kann per Powershell der Befehl „Get-WindowsUpdateLogs“ ausgeführt werden. Dabei werden die Logs ausgewertet und in ein Logfile am Desktop gespeichert. Prüft man die Datei, sollte  am Ende folgender Eintrag auffindbar sein: „Making request with URL HTTPS://sls.update.microsoft.com/SLS/….“

Kurz darauf bricht der Updateprozess ab. Damit hat man zwei Möglichkeiten um festzustellen, ob das Feature Dual Scan Schuld an der Misere hat.

Die Lösung

Keine Sorge, es gibt eine Lösung für das Problem. Werden die Update-Einstellungen per GPO verteilt, kann man zusätzlich die Richtlinie „Do not allow update deferral policies to cause scan against Windows Update“ aktivieren.

Um zu überprüfen, ob die GPO erfolgreich verteilt wurde, hilft die Windows-MMC „rsop.msc“. Die Richtlinie macht nichts anderes, als folgenden Registry-Key zu setzen (kann auch manuell erstellt werden):

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\
DisableDualScan REG_DWORD 1

Ist der Key gesetzt, schadet es nicht den Windows Update Service zu stoppen und den Ordner C:\Windows\SoftwareDistribution vollständig zu löschen. Danach dürfte, sollten die restlichen Einstellungen korrekt gesetzt sein, der Client wieder Updates finden und installieren können.