ConfigMgr: FAQ zu SCUP und Update Services

markus

Einige typischen Fragen zu System Center Update Publisher (SCUP) und Update Services in System Center Configuration Manager (ConfigMgr). Das Produkt gibt es schon länger, aber trotzdem tauchen immer wieder Fragen auf.

 

Wofür gibt es den SCUP?

Der System Center Update Publisher ermöglicht es, dass Nicht-Microsoft Updates über den WSUS und somit den ConfigMgr verteilt werden können. Diese Updates sind in der WSUS Konsole im Normalfall nicht sichtbar und sollten über den ConfigMgr verwaltet werden.

Welche Updatekataloge gibt es?

Updatekataloge werden von bestimmten Herstellern angeboten und ermöglichen es schnell bestimmte Fremdprodukte zu patchen. Darunter fallen:

Direkt in der Oberfläche integrierbar:

  • Adobe für Flash, Acrobat Reader und Acrobat
    • HP Proliant mit Firmware Update Paketen und Treiber Update Paketen
    • HP Clients mit diversen Treibern, Firmware und sonstiger Software zu HP Workstations und Notebooks
    • Dell Server und Dell Clients

Drittanbieter bieten eigene kostenpflichtige Kataloge für weitere Software an.

Wo findet man die aktuelle Version des SCUP?

Die aktuellste Version ist SCUP 2011. Sie kann von Microsoft unter http://www.microsoft.com/en-us/download/details.aspx?id=11940 heruntergeladen werden.

Die Software sollte grundsätzlich mit Administratorrechten ausgeführt werden!

Welche Voraussetzungen müssen erfüllt sein?

Damit ein Client ein Nicht-Microsoft Update installiert, muss er diesem vertrauen. Der Windows Update Dienst vertraut grundsätzlich erst einmal nur Update, die von Microsoft signiert wurden.

Daher sind folgende Anpassungen notwendig:

  1. Im SCUP muss in den Optionen ein Zertifikat hinterlegt bzw. generiert werden.
  2. Der Public Key des Zertifikats muss exportiert werden und z.B. per Gruppenrichtlinie in den Trusted Publishern und (im Fall eines selbstsignierten Zertifikats) in die Trusted Root Certificates aufgenommen werden
  3. Per Gruppenrichlinie müssen Intranet Updates erlaubt werden:  “Allow signed updates from an intranet Microsoft update service location” unter “Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Update”

Ich erhalte die Fehlermeldung 0x800b0109 im WindowsUpdate.log

Updates wurden erfolgreich im ConfigMgr integriert und an die Clients verteilt. Eine Installation schlägt aber fehl. Im Windows Update Log ist folgende Meldung zu sehen:

WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\Download\e159f74f5d0131816acee05d4d39b19392fb9bea are not trusted: Error 0x800b0109

Dies ist ein eindeutiger Hinweis, dass die Voraussetzungen nicht erfüllt wurden, da das Update zwar heruntergeladen wurde, aber nicht überprüft werden kann.

Bitte folgende Punkte auf dem Client überprüfen:

  • Befindet sich das WSUS Zertifikat in den Trusted Publishern UND in den Trusted Root Store (falls es ein selbstsigniertes Zertifikat ist)
  • Wenn das Zertifikat auf dem Client geöffnet wird, ist es dann vertrauenswürdig?
  • Wurden die Intranet Update per Gruppenrichtlinie erlaubt? D.h. ist folgender Key in der Registry vorhanden und auf 1 gesetzt:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]

“AcceptTrustedPublisherCerts”=dword:00000001

Ist alles korrekt eingestellt, so sieht das Windows Update Log folgendermaßen aus:

2014-05-12         11:37:54:156      1576      14bc      Misc      Validating signature for C:\Windows\SoftwareDistribution\Download\e159f74f5d0131816acee05d4d39b19392fb9bea with dwProvFlags 0x00000080:

2014-05-12         11:37:56:471      1576      14bc      Misc      Microsoft signed: No

2014-05-12         11:37:56:472      1576      14bc      Misc      Trusted Publisher: Yes

Verteilung von HP Firmware und HP Treiber funktioniert nicht

Die Erkennung, ob ein Firmware- oder Treiberpaket notwendig ist, ist von HP relativ rudimentär umgesetzt. Dabei wird nur überprüft, ob ein Datumsstempel in der Registry kleiner als ein Wert im Paket ist. Wurde somit der Server nicht schon Initial mit einem Firmwarepaket installiert, so fehlt dieser Registry Wert und die Software wird nie angeboten.

Um dies zu umgehen, kann man über einen beliebigen Weg (GPO, Softwareverteilung, usw.) folgende Registry Keys auf dem Server hinterlegen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Hewlett-Packard\PUCBundles]

“proliantfw”=”2011.02.0.5”

“ws2012r2-x64″=”2011.02.0.5”

 

Dies setzt die beiden Schlüssel auf einem Windows 2012 R2 Server auf einen alten Datumswert zurück (aktuell ist 01-2014). Beim nächsten Patchscan wird die Software dann angeboten.