Softwareupdates Management im SCCM 2012

Eine der Funktionen die sich im SCCM 2012 und neueren Versionen geändert haben, ist die Updateverwaltung. Die neue Updateverwaltung ist etwas schlanker als das Update Management im SCCM 2007. Dennoch muss man durch das Konstrukt zunächst durchsteigen um es zu verinnerlichen.
Versuchen wir uns dem Thema der Reihe nach zu nähern.
Die „Softwareupdates“ sind im SCCM 2012, SCCM 2012 SP1 und SCCM 2012 R2 zu finden unter: „Softwarebibliothek | Übersicht | Softwareupdates“.
Dieser Bereich ist in 4 weitere Unterpunkte unterteilt: „Alle Softwareupdates“, „Softwareupdategruppen“, „Bereitstellungspakete“ und „Automatische Bereitstellungsregeln“. Letzteren Punkt möchte ich hier nicht näher betrachten.
Nach grundsätzlich erfolgreicher Konfiguration der Updatefunktion im SCCM kann das eigentliche Update Management beginnen. Darauf soll der Focus in diesem Blog-Artikel liegen.

Wie ist der Weg vom Update zur Update Bereitstellung

Nach erster erfolgreicher Synchronisation der Softwareupdates gegen den Microsoft Update Server im Internet, werden entsprechend der gewählten Update Klassifizierungen alle grundsätzlich zur Verfügung stehenden Updates in „Alle Softwareupdates“ angezeigt. Zu diesem Zeitpunkt sind noch keine Updates heruntergeladen worden!


In dieser Ansicht kann man nach einer Vielzahl von Kriterien filtern lassen.

Ausgewählte Updates aus „Alle Softwareupdates“ werden über „Softwareupdategruppen“ gruppiert, diese werden dann durch Bereitstellungen auf Sammlungen angewendet. Gespeichert werden die Updates in Bereitstellungspaketen; diese benötigen einen jeweils eigenen Ordner, in dem die Updates als Quelle für die daraus automatisch gebauten Updatepakete enthalten sind. Die Bereitstellungspakete werden dann auf die Verteilungspunkte geschoben.

Damit aus ausgewählten Updates aus „Alle Softwareupdates“ die „Softwareupdategruppen“ gebaut werden können, benötigt man einen Speicherort für die herunterzuladenden Updates. Eine solche Ordnerstruktur könnte beispielsweise so aussehen:
Jeder einzelne Ordner repräsentiert ein Bereitstellungspaket.

ACHTUNG:
sollte man fälschlicherweise in diesem Konstrukt für eines seiner Bereitstellungspakete nicht sauber in einem Unterordner von, hier, _WSUS speichern, sondern direkt in _WSUS, dann werden in der Folge die selbsterzeugten Quellordner der anderen Pakete gefressen, gelöscht, oder wie auch immer man es nennen möchte. Das Löschen der Unterordner stellt sich nicht sofort ein. Ebenfalls ist es möglich in Zukunft weitere Unterordner zu erzeugen, welche dann aber auch irgendwann verschwinden.

Der Inhalt der einzelnen Ordner sind die im Bereitstellungspaket enthaltenen Updates. Das sieht beispielsweise folgendermaßen aus:


Beim Prozedere von „Alle Softwareupdates“ zu den „Softwareupdategruppen“ wird im Assistent der der Download der Updates verlangt und gleichzeitig ein Paket gebaut. (Natürlich kann auch ein bereits existierendes Paket gewählt werden.)

Die Updatepakete können in diesem Konstrukt z.B. so aussehen:


Und die dazu passenden Softwareupdategruppen so:


Ein paar Gedanken zur Management-Strategie

Die zu betrachtenden Elemente der Update-Strategie sind die folgenden:
Das Sammelsurium in „Alle Softwareupdates“, die „Softwareupdategruppen“, „die „Bereitstellungspakete“ und die selbsterzeugte Ordnerstruktur welche als Quelle für die Bereitstellungspakte dient.
Die Verbindung von Bereitstellungspaket zu selbsterzeugtem Quellordner ist 1:1. Es ist ratsam ein Konstrukt zu finden, welches die Größe der Bereitstellungspakete in irgendeiner Form deckelt oder abschließt. Es würde technisch zunächst funktionieren mit einem einzigen Bereitstellungspaket zu arbeiten und daraus viele Softwareupdategruppen zu versorgen. Die Softwareupdategruppen sind es, die per Bereitstellung an die SCCM Sammlungen angekündigt werden. Allerdings ist ein solches Updatepaket auch schnell auf ein Volumen jenseits des GB Horizonts angewachsen.
Ein bewährtes Konstrukt ist z.B.: 1 Bereitstellungspaket pro Softwareupdategruppe und diese Thematisch, nach Prozessorarchitektur getrennt und nach Zeitperiode organisiert. Ähnlich ist es hier in diesem einfachen Beispiel in den Screenshots auch gemacht. Ob die Zeitperiode ein Jahr, Quartal oder Monat ist, obliegt natürlich dem zugrundeliegenden Konzept und Arbeitsweise der jeweiligen Administratoren.

VN:F [1.9.22_1171]
Beitrag bitte hier bewerten:
Rating: 4.8/5 (10 votes cast)
Softwareupdates Management im SCCM 2012, 4.8 out of 5 based on 10 ratings

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.