Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

16Mrz/152

SCCM + WSUS + SCUP: Updates für 3rd-Party-Anwendungen mit Hilfe des Update Publishers über SCCM verteilen

Mit Hilfe des System Center Configuration Manager 2012 / 2012 R2 ist es sehr einfach möglich, Windows- und Microsoft-Updates an die Clients und Server des eigenen Netzwerkes zu verteilen. Im Hintergrund arbeitet hierzu der bekannte WSUS-Dienst, welcher wiederum mit Microsoft kommuniziert, um die Updates von dort zu beziehen.

Wäre es nicht auch gut, wenn man auf ähnliche Weise auch Anwendungen von anderen Herstellern patchen könnte? JA! Und man kann!

Das einzige was man neben WSUS und dem SCCM braucht, ist der System Center Update Publisher, kurz SCUP. Mit diesem kann man Updates anderer Hersteller aus “externen Katalogen” beziehen. Und das beste: SCUP ist kostenlos!

Im Folgenden möchte ich die Installation und Einrichtung von SCUP zeigen. Ausgangslage ist ein installierter SCCM mit einer einzigen Primary Site (stand-alone), einem installierten WSUS und einem darauf laufenden Software Update Point (SUP).

Installation SCUP

Als erstes muss SCUP heruntergeladen werden. Dies geht über diese Quellen:

https://technet.microsoft.com/de-de/systemcenter/bb741049.aspx

bzw.

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940

Nach dem Download kann die Installation durchgeführt werden, welche jedoch Admin-Rechte benötigt:

scup2 scup3 scup4

Wenn es sich bei dem WSUS-Server um einen Windows Server 2008 R2 oder älter handelt, dan ist die Installation eines Patches nötig, der während des SCUP-Setup angeboten wird:

 scup5

Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!

scup6

Konfiguration WSUS-Berechtigungen

Um nun überhaupt Updates via SCUP auf dem WSUS veröffentlichen zu können, ist noch etwas Vorarbeit nötig. Diese Vorgänge sind etwas genauer hier dokumentiert (dies betrifft idR nur den Windows Server 2012 / 2012 R2):

https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012

Folgende Schritte sind im Wesentlichen nötig:

Regedit.exe, dort bis HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} durchhangeln und dann den Eigentümer von diesem Pfad ändern sowie für “SYSTEM” und die “Administratoren” den Vollzugriff vergeben (Durch einen Klick auf die Bilder werden diese in größerer Auflösung gezeigt):

scup10  scup11 scup12 scup13 scup14

 

Einrichtung SCUP

Nun kann der “System Center Update Publisher” über das Startmenü gestartet werden – dies sollte aber “Als Administrator” geschehen, da es sonst später zu einem Fehler kommt / kommen kann.

scup7

Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:

scup9

Als erstes sind die Optionen zu öffnen:

scup8

Dort muss nun die Verbindung zum WSUS-Server konfiguriert werden (dabei Port beachten – WSUS 4.0 läuft auf 8530 (non-SSL) bzw. 8531 (SSL)):

scup16

Nun fehlt noch ein Zertifikat zum signieren der Updates. Hier kann auch ein selbstsigniertes Zertifikat erzeugt und verwendet werden. Dies geschieht über den “Create”-Button:

scup16b

Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:

scup17

Zertifikat passend einbinden

Das WSUS-/SCUP-Zertifikat muss nun in die “Trusted Publishers” (Vertrauenswürdige Herausgeber) und die “Trusted Root Certificates” (Vertrauenswürdige Stammzertifizierungsstellen) des Computer-Kontos (WSUS/SCUP-Server) importiert werden, vorher muss es natürlich exportiert werden:

scup18 scup18b scup19 scup20

Updates über SCUP an den WSUS veröffentlichen

Nun können die ersten Updates über den SCUP veröffentlicht werden. Dazu muss zunächst ein Katalog hinzugefügt werden:

scup21

Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:

scup22

Danach können die Updates aus diesem Katalog in den SCUP importiert werden:

scup23

scup24

scup25

scup26

scup27

Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:

scup28

scup29

Diese neue Veröffentlichung (Bei mir heißt sie “März 2015”) kann nun veröffentlicht werden. Dazu wird sie unter “Publications” ausgewählt, die jeweiligen Updates markiert und dann auf “Publish” geklickt.

scup30

Dabei sollten die Updates vom SCUP signiert werden:

scup31

scup32 scup33

Updates über SCCM verteilen

Nun kann im SCCM eine erste Synchronisierung durchgeführt werden. Diese ist nötig, damit der SUP (SCCM) “erfährt”, dass es nun auch Adobe als neuen Hersteller und Adobe Reader als Produkt gibt:

scup34 Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren:

scup35 scup36 scup37scup38

Die letzte Meldung zeigt an, dass die Synchronisierung abgeschlossen ist. Nun kann das neue Produkt (in meinem Fall der Adobe Reader) für die Verteilung durch den SUP aktiviert werden:

scup39 scup40

Dabei ist auch der Reiter “Klassifizierungen” zu beachten – wenn das gewünschte Update ein “Sicherheitsupdate” ist, SUP aber nur “Wichtige Updates” synchronisiert, dann wird man nicht zu einem positiven Ergebnis kommen.

Nun ist noch einmal eine Synchronisierung des SUP nötig, damit dieser die bekannten Updates vom WSUS “kennenlernt”.

scup34

Danach stehen die Updates, in meinem Fall für den Adobe Reader, im SCCM wie ein reguläres Windows Update zur Verfügung und können verteilt und bereitgestellt werden:

scup41

Viel Spaß damit!

8Dez/140

Windows Server 2012 R2: WSUS automatisch bereinigen

Mit der Zeit sammeln sich auf einem WSUS (Windows Server Update Service) einige Updates an. Da können auch schnell mehrere hundert Gigabyte an Daten zusammenkommen. Nicht jedes Update, welches auf dem WSUS gespeichert ist, wird aber noch benötigt. Daher ist es aus Gründen der Speicherplatzeffizienz sinnvoll, von Zeit zu Zeit etwas aufzuräumen. Dafür gibt es schon seit längerem einen passenden Assistenten in der WSUS-Konsole:

wsus_cleanup_00

Dieser Assistent ließ sich “früher” (also z.B. unter Windows Server 2008 R2, WSUS 3.0 SP2) nur manuell oder über komplizierte Skripte ausführen.

wsus_cleanup_01

wsus_cleanup_02

Seit Windows Server 2012 lässt sich WSUS aber auch über PowerShell steuern. Hier gibt es ein passendes Commandlet “Invoke-WsusServerCleanup”, welches die Bereinigung durchführt. Als Parameter kann verwendet werden:

Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates]

[-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates]

[-DeclineSupersededUpdates] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf]

 

Damit lässt sich unkompliziert steuern, welche Komponenten beräumt werden sollen.

wsus_cleanup_03

Dieses PowerShell-Commandlet kann nun z.B. im Rahmen eines kleinen Skriptes regelmäßig und automatisch (z.B. per Aufgabenplanung) ausgeführt werden. Damit spart man sich die regelmäßige, manuelle (aufwändige) Bereinigung mit Hilfe des Assistenten.

Die komplette Syntax zum angesprochenen PowerShell-Commandlet findet sich hier: http://technet.microsoft.com/en-us/library/hh826162.aspx 

10Apr/130

WSUS offline installieren / Abhängigkeiten automatisch installieren

Will man den WSUS-Server ohne eine Internetverbindung installieren, ist der klassische Weg über den Server-Manager ("Rolle hinzufügen") nicht geeignet, da dieser die notwendigen Daten aus dem Internet bezieht.

Als Alternative kann man sich das WSUS-Setup bei Microsoft frei herunterladen. Allerdings benötigt dieses einige Rollen und Rollendienste sowie Features, die man nun "von Hand" installieren muss (Beim Weg über den Servermanager wären sie automatisch mit ausgewählt worden).

Um nun diese Installation der Abhängigkeiten zu vereinfachen, ist dieses kurze PowerShell-Skript geeignet:

1
2
Import-Module ServerManager
Get-WindowsFeature OOB-WSUS | Select -exp DependsOn | Add-WindowsFeature
veröffentlicht unter: Windows Server 2008 R2, WSUS keine Kommentare