Geklonte Rechner erhalten keine Updates über den WSUS

Nach der Umstellung auf Windows 2012 Server hatten wir das Problem, dass die neuen Server keine Updates mehr von unserem WSUS-Server bekamen und auch in der Verwaltungskonsole des WSUS nicht auftauchten. Die bestehenden W2K3-Server, XP- und Win 7-Clients erschienen allerdings in der Konsole des WSUS. Da wir den WSUS unter Windows 2012 Server ebenfalls neu aufgesetzt hatten, setzten wir schon den WSUS in der Version 4.0 ein. Mit dieser Version werden out of the Box auch Windows 8 und Windows 2012-Installationen mit Updates versorgt. Wird der WSUS 3.0 SP2 eingesetzt, dann muss dieser Patch vom Microsoft installiert werden, damit es funktioniert: KB2734608.

Nach einigem Probieren und Suchen war folgendes auffällig: In der WSUS-Verwaltung tauchte ein neuer Server auf, den wir manuell installiert hatten. Zusätzlich tauchten abwechselnd für eine bestimmte Zeit die neuen Server auf, aber immer nur einer. Es sah tatsächlich so aus als würden sich die Server in der Konsole abwechseln. Die neuen Server tauchten seltsamerweise immer dann am WSUS auf, wenn der Befehl wuauclt /reportnow an einem der neuen Server ausgeführt wurde. Dieser Befehl zwingt Windows, einen Bericht des Updateclients an den WSUS zu schicken. Die Server die abwechselnd in der Konsole erschienen, waren alle über ein Template unserer vSphere-Centers installiert worden. Und genau das war das Problem: Durch die Installation mit Hilfe des Templates, hatten alle neuen Server die gleiche so genannte SUSClientID. Diese erhält jeder Rechner, der einmal mit einem WSUS in Kontakt stand und von diesem Updates bezogen hat. Da wir den Server auf dem das Template basierte in unsere Domäne gehoben haben und einmal über den bestehenden WSUS durchpatchen ließen, hatte das Template natürlich diese SUSClientID und somit auch jeder Server den wir mit Hilfe dieses Templates installierten. Der WSUS nutzt diese ID aber zu identifizierung der einzelenen Rechner und so waren diese für ihn natürlich nicht zu unterscheiden.

Lösung:

Die SUSClientID wird in der Registry gespeichert. Folgende Werte müssen aus der Registry gelöscht werden, damit die SUS-ID gelöscht und neu genertiert wird:

    HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAccountDomainSid
    HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdatePingID
    HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateSusClientId

Anschließend den Windows Updatedienst neu starten…

    net stop wuauserv
    net start wuauserv

…und den Update-Client nach Updates suchen lassen und ihn zwingen, sich beim WSUS zu melden:

    wuauclt /resetauthorization /detectnow

Umd die Arbeit etwas zu erleichtern, kann die Sache auch skriptgesteuert ablaufen. Das Skript kann zum Beispiel so aussehen:

rem Removing SUSClientID from cloned machines

reg delete HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v AccountDomainSid /f
reg delete HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v PingID /f
reg delete HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate /v SusClientId /f

@echo Forcing detection after deleting SUSClientID
net stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow

Und voilà; kurze Zeit später tauchten alle Server wieder in der WSUS-Console auf.

Wichtig: die Befehle bzw. das Skript müssen natürlich im administrativen Kontext ausgeführt werden.

2 Kommentare

  1. Thomas M.

    Tipp: In den Registry-Schlüsseln oben fehlen die Backslashes „\“. Ich musste bei mir erst die Backslashes einfügen, damit es bei mir funktionierte.

    Dein Beitrag hat mir sehr geholfen und das Problem gelöst. Danke!

    Antworten
  2. Alex

    Hi, spannender Artikel!
    Wird diese genannte ID nicht mit einem SYSREP entfernt bzw. bereinigt? Verwendet ihr über den vCenter Client die Vorlage für Templates? Danke vorab & Grüße, Alex

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.