Die Windows Server Update Services (WSUS) sind schnell installiert und bieten dem Administrator eine hervorragende Möglichkeit Clients und Server mit den benötigten Microsoft Updates zu versorgen. Doch hin und wieder schleichen sich Probleme ein, die auf den ersten Blick nicht zu erklären sind: Z.B. ein Client verschwindet.
Computer verschwindet aus WSUS – und taucht wieder auf
Im konkreten Fall äußerten sich die Probleme beim Kunden folgendermaßen:
Die Windows-Arbeitsstationen bekamen den WSUS per Gruppenrichtlinie zugewiesen und registrierten sich auch dort ordnungsgemäß. Updates wurden erkannt, heruntergeladen und auch installiert. Alles schien in bester Ordnung. Am nächsten Tag wurde aber bemerkt, dass die Anzahl der registrierten Clients nicht der Anzahl Clients entsprach, die die Gruppenrichtlinie zugewiesen bekommen haben.
Eine erste Überprüfung ergab, dass aber sämtliche Clients angaben, dass die Windows Updates über den Systemadministrator verwaltet werden, also die Gruppenrichtlinie erfolgreich verarbeitet wurde. Dann fiel auf, dass die registrierten Computernamen im WSUS sich änderten. Mal fehlte der eine Client in der Liste, mal der andere Client.
Wie kann es sein, dass ein registrierter Client aus dem WSUS verschwindet und nach Stunden wieder auftaucht. Im ersten Moment dachte ich an einen Fehler in der Datenbank und ließ ein Skript zur Reorganisation laufen. Doch auch das änderte nichts daran, dass immer wieder Clients aus dem WSUS verschwanden und andere Clients dafür auftauchten.
Client zeigte falsche Update-Statistiken an
Der Lösung kam ich erst auf die Sprünge, als ich herausfand, dass die im WSUS angezeigten Zahlen zu den noch benötigten Updates falsch waren. Ein zuvor komplett „durchgepatchter“ Client zeigte an, dass ihm noch über 100 Updates fehlten. Die Überprüfung per Onlineupdate ergab aber, dass keine Updates mehr zur Verfügung standen.
Wurden hier eventuell die Zahlen des falschen Clients angezeigt? Gar ein doppelter Client? Ja und Nein – Denn nach kurzer Recherche in den bekannten Pfaden der Windows Registry stellte ich fest, dass alle betroffenen Clients den identischen Eintrag für den Wert SusClientID besaßen. Eine kurze Kontrolle auf anderen Clients und Servern ergab, dass diese sich normalerweise unterscheiden sollten.
Ein schneller Test – Wert gelöscht, Client neu gestartet – ergab, dass diese ID beim Start des Dienstes „Windows Update“ neu generiert wird und dann bestehen bleibt. Der Client tauchte anschließend im WSUS auf und sein vormaliger „Konkurrent“ verschwand nun nicht mehr aus dem WSUS.
Wie kam es zu diesem doppelten Wert? Ganz einfach, der Kunde hatte die Rechner geklont ohne zuvor Sysprep auszuführen. Bei der Einrichtung des ursprünglichen Clients wurde eine SusClientID erstellt, die dann auf sämtlichen geklonten Computern identisch war. Wer seine Windows Images mit Sysprep generalisiert, der kann diesen Wert ignorieren, denn dadurch wird (u.a.) die SusClientID zurückgesetzt.
Wer diesen Wert ohne Neustart zurücksetzen möchte, kann auch einmalig die folgenden Befehle ausführen oder diese z.B. in ein Anmeldeskript einbauen:
net stop wuauserv
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
net start wuauserv
wuauclt /resetauthorization /detectnow
Ebenfalls interessant:
- WSUS Datenbank verschieben
- 0x800708c5 – Kennwort kann nicht festgelegt werden
- Registry Schlüssel direkt öffnen
Dieser Artikel ist wie alle anderen auf dieser Seite kostenlos für Dich und ich hoffe, ich konnte Dir weiterhelfen. Wer möchte, kann diesem Blog eine kleine Aufmerksamkeit in Form einer kleinen Spende (PayPal) oder über die Amazon Wunschliste zukommen lassen.
Herzlichen Dank René, du bist mein Held des Tages.
Das ist eine geniale Site mit sehr gut geschriebenen Erklärungen, gratuliere!
Hallo Stefan. Freut mich sehr, dass ich Dir damit helfen konnte.
Danke