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!

012414 1407 Softwareupd1
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:012414 1407 Softwareupd2
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:
012414 1407 Softwareupd3

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:
012414 1407 Softwareupd4

Und die dazu passenden Softwareupdategruppen so:
012414 1407 Softwareupd5

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.

Veröffentlicht:

Autor:

Kommentare

Schreibe einen Kommentar

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

New articles in english

Werbung

Themen

Active Directory Administrative Vorlagen Anleitung AppV5 Autopilot Azure Azure AD ConfigMgr Deployment GPO Gruppenrichtlinien Guide How-To Linux Microsoft Microsoft Intune Office Office365 PowerShell Public Preview SCCM2012R2 SCSM2012R2 ServiceMgr Sicherheit TechNet Windows Windows 10 Windows10 Windows Server 2012 Windows Server 2012R2

Hinweise zum Affiliate-Marketing

Auf diesen Seiten werden auch Affiliate Marketing Links angezeigt. Diese sind meistens an dem kleinen „€“ oder einem „*“ dahinter zu erkennen. Der Betreiber dieser Seite erhält beim Kauf über diesen Link eine Provision, ohne das es den Verkaufspreis beeinflusst. Diese Einnahmen tragen zur Finanzierung der Seite bei.