Wartungsfenster und Geschäftszeiten in SCCM

Ich wurde kürzlich von einem meiner Kunden gefragt, wie denn in SCCM der Zusammenhang zwischen einem Wartungsfenster und den Geschäftszeiten sei und ob sich diese Bereiche beeinflussen. Geschäftszeiten können von jedem Benutzer über das Software Center in gewissen Grenzen frei definiert werden und bringen zum Ausdruck, wann ein Benutzer nicht mit Software- oder Update-Installationen belästigt werden möchte oder positiv ausgedrückt, in welchem Zeitraum Wartungsaktionen bevorzugt stattfinden sollen. Meiner Erfahrung nach ist dies zwar ein Feature, das kaum jemand wahrnimmt oder gar aktiv benutzt, aber man sollte als SCCM-Administrator natürlich wissen, was es mit den Geschäftszeiten auf sich hat und wie diese z. B. die Installation von Software Updates beeinflussen.

Wartungsfenster

Ein Wartungsfenster bzw. Maintenance Window dient im SCCM-Umfeld dazu, den Zeitpunkt von Software- oder Update-Installationen zeitlich kontrollierbarer zu gestalten.

Ein Wartungsfenster wird im SCCM über Collections definiert, d. h. das Wartungsfenster ist eine Eigenschaft der Collection:

1

clip_image001

Das Wartungsfenster bestimmt sich über eine frei definierbare Startzeit, eine Dauer und ggf. ein Wiederholungsintervall. Außerdem kann festgelegt werden, ob das Wartungsfenster für alle Arten von Deployments, nur für Updates oder nur für Task Sequenzen gelten soll.

clip_image002

Wenn für ein Device ein Wartungsfenster definiert ist, werden Deployments (auch nach Erreichen der Deadline) so lange verzögert, bis der Startzeitpunkt des Wartungsfensters erreicht ist. Es gibt darüber hinaus einige weitere Faktoren, die das Installationsverhalten beeinflussen. Wenn, z. B. die Dauer des Wartungsfensters kürzer als die maximal erlaubte Installationsdauer ist, findet die Installation nicht statt, obwohl das Wartungsfenster erreicht worden ist. Die maximal erlaubte Installationsdauer kann bei einer Application im Deployment Type angegeben werden:

clip_image004

Bei einem Software Update Package gibt es diese Einstellmöglichkeit ebenfalls:

clip_image005

Mehrere Wartungsfenster

Was passiert nun, wenn für ein Device mehrere Wartungsfenster definiert sind? Dies kann vorkommen, wenn der Computer Mitglied einer Collection ist, für die mehrere Wartungsfenster definiert sind, oder wenn der Computer Mitglied in mehreren Collections ist, für die jeweils Wartungsfenster vorhanden sind. Hierbei muss man unterscheiden, ob sich die Wartungsfenster zeitlich überschneiden oder nicht. Falls sich die Wartungsfenster nicht überschneiden, gilt jedes Wartungsfenster unabhängig für sich betrachtet. Bei Überschneidungen wird ein einzelnes Wartungsfenster gebildet, das der Schnittmenge aller definierten Wartungsfenster entspricht, d. h. es wird das größtmögliche zeitliche Fenster definiert, dass allen Wartungsfenstern gerecht wird.

Wartungsfenster ignorieren beim Deployment?

Bei jedem Deployment kann sich der SCCM Administrator nochmals individuell entscheiden, ob er evtl. vorhandene Wartungsfenster überhaupt berücksichtigen möchte, oder nicht. Dies kann auf der Seite User Experience im Deployment Wizard bestimmt werden. Wenn, wie hier zu sehen, die Checkbox für Software update installation aktiviert ist, erfolgt nach Erreichen der Deadline die Update Installation auch außerhalb eines evtl. definierten Wartungsfensters. Mit dieser Einstellung lassen sich Wartungsfenster also de facto umgehen.

clip_image007

Geschäftszeiten / Business Hours

Was hat es nun mit den Geschäftszeiten auf sich, die jeder Benutzer auf seinem Gerät über das Software Center frei definieren kann?

clip_image009

Handelt es sich hierbei auch um ein Wartungsfenster? Die Antwort lautet: Ja, in gewisser Weise schon, allerdings hat dieses Wartungsfenster lediglich eine Bedeutung für den Zeitraum vor dem Erreichen der Deployment Deadline. Beim Erstellen eines Deployments kann der SCCM Administrator angeben, ab wann die Software auf dem Client erkennbar, also „Available“ sein soll, hier am Beispiel eines Update Deployments gezeigt:

clip_image011

Ab diesem Zeitpunkt bekommt der Benutzer die Installation der Software über Software Center angeboten und evtl. erscheint auch ein Meldungsfenster mit einer entsprechenden Ankündigung. Ob diese zusätzliche Meldung erscheinen soll oder nicht, wird auf der nächsten Seite des oben gezeigten Wizard festgelegt.

clip_image012

Ob nun die definierten Geschäftszeiten berücksichtigt werden oder nicht, hängt von der Wahl des Benutzers in dieser Benachrichtigung ab. Der Benutzer kann sich hier diesbezüglich entscheiden. Diese Wahlmöglichkeit ist allerdings nur solange gegeben, bis die Deployment Deadline erreicht ist. Der Zeitpunkt der Deployment Deadline wird vom SCCM-Administrator ebenfalls bei der Erstellung des Deployments festgelegt:

clip_image014

Mit Erreichen der Deadline finden die vom Benutzer definierten Geschäftszeiten keine Berücksichtigung mehr, wohl jedoch evtl. vorhandene Wartungsfenster, die über Collections definiert worden sind.

Der wichtigste Unterschied zwischen einem Wartungsfenster und den Geschäftszeiten eines Benutzers ist also der Zeitraum, in dem entweder das eine oder das andere seine Anwendbarkeit findet. Geschäftszeiten blockieren eine Installation vor Erreichen der Deadline, ein Wartungsfenster nach Erreichen der Deadline.

Gruß, Thomas Froitzheim…

Update Deployment mit SCCM

ich bin seit 18 Jahren in der IT als Berater tätig und beschäftige mich jetzt einige Jahre davon mit dem Thema Client Management, dies insbesondere vor dem Hintergrund von Microsoft System Center Configuration Manager, allgemein SCCM, oder auch einfach Config Manager genannt. Des Öfteren werde ich von Kunden angefragt, um die Einführung von SCCM im Unternehmen zu begleiten und meine Erfahrung zu diesem Thema einzubringen. Meistens ist es dann so, dass Anforderungen wie Softwareverteilung, OS Deployment, Software- und Hardware Inventur im Vordergrund stehen. Wenn ich dann nachfrage, wie es mit dem Thema Software Update Verteilung und SCCM aussieht, höre ich oft als Antwort „nein danke, das machen wir seit Jahren mit WSUS, da sind wir gut mit bedient, dafür brauchen wir den SCCM nicht“. Wenn die neu aufgebaute SCCM Infrastruktur dann in den Betrieb übergegangen ist und der Kunde eine gewisse Sicherheit im Umgang mit der Materie erlangt hat, erregt das Thema Software Updates mit SCCM dann meist doch früher oder später noch mal das Interesse. In diesem Artikel möchte ich gerne die grundsätzliche Vorgehensweise im Umgang mit Software Updates unter SCCM erläutern und eine „Best Practice“ vorstellen, wie sich der Software Update Prozess unter SCCM praktisch organisieren lässt.

SCCM Software Update Infrastruktur

Manchmal höre ich bei meinen Kunden Sätze wie „Der SCCM benötigt doch für Updates intern sowieso den WSUS, dann können wir doch unseren bereits vorhandenen WSUS Server bestimmt für SCCM verwenden?“. Diese Frage offenbart einige Hoffnungen und Hintergedanken, z. B. dass man eine WSUS Infrastruktur nicht ein weiteres Mal neu aufbauen, den Plattenplatz zur Ablage der Updates nicht doppelt bereithalten muss oder gar WSUS im Parallelbetrieb zu SCCM weiterhin wie gewohnt verwenden kann. Leider lassen sich diese Hoffnungen nicht alle erfüllen. Richtig ist, dass SCCM zwar eine WSUS-Instanz benötigt, allerdings nur als „Ausführungsgehilfe“, nicht als gleichberechtigter Partner. Insbesondere ein Parallelbetrieb derselben WSUS-Instanz ist nicht erlaubt, bzw. wird vom Hersteller nicht unterstützt. Selbstverständlich kann man in seiner IT-Landschaft sowohl einen dedizierten WSUS als auch SCCM parallel betreiben, allerdings müssen dann die mit Updates zu versorgenden Clients aufgeteilt werden in solche, die von SCCM mit Updates versorgt werden und solchen, die weiterhin „klassisch“ per WSUS ihre Updates erhalten. In manchen Situationen kann eine solche Aufteilung durchaus Sinn ergeben. Um einen solchen Parallelbetrieb zu ermöglichen, benötigt man dann allerdings auch mindestens zwei WSUS-Instanzen im Unternehmen, wobei eine Instanz exklusiv für SCCM reserviert ist. Auf der Clientseite wird SCCM ebenfalls technisch durch den Windows Update Agent (der Client-Komponente von WSUS) bei der Installation und Inventur der Updates unterstützt. Entweder ist der Client unter der Hoheit von SCCM, oder der Client bezieht seine Updates von einem autarken WSUS Server, ein Mischbetrieb im Sinne von „einige Updates kommen von WSUS, andere von SCCM“ ist nicht möglich. Wohl ist es denkbar, dass ein Client dauerhaft durch SCCM mit Software Paketen versorgt wird, seine Windows Updates aber gleichzeitig durch WSUS und somit nicht durch SCCM erhält.

Um mit SCCM Software Updates verteilen zu können, muss mindestens ein Software Update Point in der SCCM Landschaft vorhanden sein, d. h. es muss einen SCCM Server geben, bei dem diese Rolle aktiviert ist. In kleineren und mittleren Umgebungen wird dieser Server meist zugleich der Primary Site Server, also umgangssprachlich „der SCCM Server“ sein, weil es hier oft ohnehin nur einen SCCM Server gibt, wenn man von den Distribution Points einmal absieht. Um die Rolle eines Software Update Point installieren zu können, muss auf dem System bereits eine lokale WSUS-Instanz vorhanden sein. Falls das noch nicht der Fall sein sollte, muss die WSUS Rolle im Betriebssystem zunächst aktiviert und eingerichtet werden. Der Software Update Point ist quasi das Bindeglied zwischen WSUS und SCCM. Nachdem der Software Update Point eingerichtet worden ist, braucht und sollte man sich für die zugrundeliegende WSUS Instanz nicht mehr weiter interessieren, da sie vollständig unter der Kontrolle des SCCM belassen werden und nicht z. B. für die Verteilung von Updates „an SCCM vorbei“ verwendet werden darf.

SCCM Software Update Point Installation

Wie im vorigen Abschnitt beschrieben, benötigt man zur Einrichtung eines Software Update Point unter SCCM als Voraussetzung zunächst eine lokale WSUS Instanz. Diese lässt sich recht einfach bereitstellen. Ich möchte hier nicht allzu detailliert auf die WSUS Installation eingehen, darüber ist sicherlich schon an anderer Stelle genug geschrieben worden.

clip_image002

clip_image004

Die WSUS Rolle benötigt zur Funktion eine Datenbank, die entweder in Form der Windows Internal Database oder als externe SQL Server Datenbank implementiert werden kann. Im Laufe der WSUS Installation muss man sich zwischen diesen beiden Varianten entscheiden:

clip_image006

Da man im Zusammenhang mit SCCM ohnehin eine SQL Server Instanz betreiben muss, empfehle ich hier, die externe Datenbankvariante zu wählen, insbesondere dann, wenn der SQL Server „co-located“ also auf demselben Server betrieben wird, wie auch der SCCM Server. Microsoft empfiehlt in diesem Fall, die WSUS Datenbank sogar auf einer separaten SQL Server Instanz zu betreiben. Dies mag aus z. B. Performancegründen sinnvoll sein, ich persönlich halte mich aber i. d. R. nicht an diese Empfehlung.

Wenn man die Vorgabe akzeptiert, Updates lokal zu speichern, muss man einen Pfad zu einem Verzeichnis angeben, wo diese abgelegt werden sollen. Hierbei ist es wichtig, dass dieses Verzeichnis zum Zeitpunkt der Installation bereits existiert, da die Einrichtung sonst scheitert. Es wäre nett, wenn der Assistent spätestens beim Verlassen der Dialogseite auf diesen Umstand aufmerksam machen würde, was aber leider nicht der Fall ist.

clip_image008

Falls man sich dazu entschlossen hat, eine externe SQL Server Datenbank zu verwenden, wird man auf der nächsten Dialogseite nach dessen Server- und Instanznamen gefragt. Dass die Verbindung zu diesem Server getestet werden sollte – „Check connection“, versteht sich sicher von selbst.

clip_image010

Nach der Installation der WSUS Rolle wird man aufgefordert, die abschließende WSUS Konfiguration vorzunehmen. Dies ist allerdings in unserem speziellen Fall unnötig, da genau diese Konfiguration im Rahmen der Software Update Point Installation durch SCCM ohnehin durchgeführt wird.

clip_image012

clip_image014

Bevor es an die Installation des Software Update Point geht, sollte sichergestellt werden, dass das Windows Update KB 3095113 auf dem eingesetzten Server installiert ist. Fehlt dieses Update, kann es im Zusammenhang mit Updates für Windows 10 zu ärgerlichen Problemen mit der WSUS Datenbank kommen.

Nun können wir mit der eigentlichen Installation der Software Update Point Rolle auf dem SCCM Server beginnen. In der SCCM Konsole wechselt man in den Bereich Administration und hangelt sich im Menübaum nach Overview | Site Configuration | Servers and Site System Roles durch, markiert den Primary Site Server und wählt den Befehl Add Site System Roles:

clip_image016

Der Assistent Add Site System Roles öffnet sich:

clip_image018

Auf der ersten Seite akzeptiert man die Vorgaben und geht gleich zur zweiten Seite, wo es um die Proxy-Konfiguration geht. Falls in Ihrem Unternehmen ein Proxy verwendet werden muss, um eine Verbindung zum Internet herzustellen, müssen Sie auf dieser Dialogseite den Namen und den Port des Proxy Servers konfigurieren. Womöglich müssen Sie auch Benutzernamen und Passwort eines Users angeben, der sich gegenüber dem Proxy authentifizieren kann. Wenn dies der Fall sein sollte, wäre es an dieser Stelle sinnvoll, einen dedizierten User für diesen Zweck im Active Directory anzulegen.

clip_image020

Auf der folgenden Dialogseite wählt man die Rolle Software Update Point aus:

clip_image022

Auf der folgenden Dialogseite wird man gefragt, welche WSUS Ports verwendet werden sollen. Heute sollten dies (z. B. bei Verwendung von Windows Server 2012 R2) die Ports 8530 und 8531 sein. Bei älteren Windows Server Versionen kommt auch 80 und 443 in Frage.

clip_image024

Auf der nächsten Dialogseite kann man die Verwedung des Proxy Servers nochmals genauer festlegen. In meiner Testumgebung habe ich keinen Proxy Server, daher zeigt der Screenshot hier keine entsprechenden Einstellungen:

clip_image026

Auf der folgenden Dialogseite hat man die Möglichkeit, die Synchronisationsquelle zum Bezug der Updates zu konfigurieren. Üblicherweise wird man hier Synchronize from Microsoft Update auswählen. Es gäbe aber auch alternativ die Möglichkeit, einen bereits vorhandenen WSUS Server in ihrem Unternehmen als Update Quelle anzugeben:

clip_image028

Die nächste Dialogseite möchte wissen, mit welchem Intervall Updates synchronisiert, also „nach Updates gesucht“ werden soll. Hier dürfte die Vorgabe Run every 1 Days in den meisten Fällen passend sein und braucht daher nicht geändert zu werden:

clip_image030

Im nächsten Abschnitt geht es darum, wann genau Updates als expired eingestuft werden sollen. Ich bevorzuge hier die Standardeinstellung Immediately expire a superseeded software update. Hierbei werden solche Updates unmittelbar als expired eingestuft, sobald ein Update durch ein nachfolgendes Update abgelöst worden ist. In großen Unternehmen kann es sinnvoll sein, das ursprüngliche Update so lange zu behalten, bis man das nachfolgende Update gründlich getestet hat und solange das ursprüngliche Update weiterhin verteilen kann.
Der WSUS Cleanup Wizard ist sehr hilfreich, um den für Updates benötigten Plattenplatz nicht exorbitant anwachsen zu lassen, er sollte daher aktiviert bleiben.

clip_image032

Auf der nächsten Dialogseite gibt man an, welche Klassifikationen man bei der Suche nach Updates berücksichtigen möchte. In meiner Umgebung habe ich alles außer Feature Packs und Tools ausgewählt. Die Klassifikation Upgrades ist wichtig für Windows 10 OS Updates, sollte also aktiviert werden, falls Sie vorhaben, neue Windows 10 Builds mit SCCM zu verteilen. Wichtig ist hierbei, dass man vorher das weiter oben bereits erwähnte Update KB 3095113 installiert hat, weil sonst die WSUS Datenbank bei der ersten Updatesynchronisation in einen ungültigen Zustand gerät. Sollte das bereits passiert sein, bekommt man das aber auch wieder korrigiert, wie das geht, steht hier.

clip_image034

Die folgende Dialogseite fordert dazu auf, die Produkte auszuwählen, zu denen man Updates beziehen möchte. Hier sollte man wirklich nur die Produkte auswählen, die man benötigt, da sonst zum einen die Synchronisationsläufe unnötig lange dauern und man auch viel Plattenplatz bereithalten muss, es kommen im Laufe der Zeit doch eine ganze Menge an Updates zusammen.

clip_image036

Auf der vorletzten Dialogseite können noch die Sprachen ausgewählt werden. Auch hier sollte man sich darauf beschränken, was man wirklich braucht, obwohl die meisten Windows Updates sowieso „multilingual“ sind.

clip_image038

clip_image040

clip_image042

Mit Abschluss des Assistenten ist die Einrichtung des Software Update Point zunächst erledigt. Falls an der Konfiguration zu einem späteren Zeitpunkt Änderungen vorgenommen werden sollen, so kann dies im Bereich Administration über Overview |Site Configuration | Sites und dann Configure Site Components | Software Update Point erfolgen:

clip_image044

SCCM Client für Software Updates konfigurieren

Damit der SCCM Client überhaupt Software Updates anfragt und diese auch ggf. herunterlädt und installiert, müssen zunächst die Client Settings entsprechend angepasst werden. Hier empfiehlt es sich, nicht die Default Client Settings zu verändern, sondern ein neues Client Settings Objekt für diesen Zweck anzulegen:

clip_image046

clip_image048

Die einzig wichtige Einstellung, die uns hier zunächst interessiert, ist Enable Software Updates on Clients.

clip_image050

Um die so erstellten Client Settings wirksam werden zu lassen, benötigen wir noch eine Collection, in der die Computer aufgenommen werden und letztendlich die zu verteilenden Updates erhalten sollen. Ich habe diese Collection in meiner Umgebung Computers receiving updates from SCCM genannt:

clip_image052

Auf diese Collection wendet man die zuvor erstellten Client Settings an, indem man ein entsprechendes Deployment für die Settings erstellt:

clip_image054

clip_image056

Zum Test empfiehlt es sich, nun, einen oder mehrere Testcomputer in die zuvor erstellte Collection aufzunehmen und auf dem Client die Aktion Computerrichtlinienabruf und Auswertungszyklus auszuführen:

clip_image058

Nach einer gewissen Wartezeit (Bei SCCM geht eigentlich immer alles mit „einer gewissen Wartezeit“ einher), sollte sich die Komponente Softwareupdate-Agent als Aktiviert zeigen:

clip_image060

Falls in Ihrer Umgebung auch Updates über den klassischen WSUS-Weg verteilt werden, ist zu beachten, dass diejenigen Computer, die ab jetzt Updates durch SCCM erhalten, nicht von den Domain Group Policies der WSUS Konfiguration erfasst werden, da diese sonst die SCCM-seitigen Client Einstellungen möglicherweise überschreiben und damit wirkungslos werden lassen.

Zur Kontrolle, ob die SCCM Client-Einstellungen greifen, kann der Inhalt des WSUS Client Registry Schlüssels

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

geprüft werden. Die dort vorgefundenen URLs müssen auf den SCCM Server verweisen, auf dem sich der Software Update Point befindet:

clip_image062

Es kann durchaus einige Minuten bis Stunden dauern, bis sich die erwarteten Einstellungen auf dem Client zeigen. SCCM ist eher ein LKW und kein Formel 1 Rennwagen.

Update Synchronisation

Nachdem nun alle vorläufig notwendigen Konfigurationen der SCCM-Infrastruktur abgeschlossen sind, können wir die erste Update Synchronisation durchführen. Zu diesem Zweck wechselt man in den Bereich Software Library und dort in den Menüordner Overview | Software Updates | All Software Updates:

clip_image064

Beim ersten Aufruf dieses Bereichs werden hier wahrscheinlich noch keine Updates angezeigt. Gemäß Schedule haben wir bei der Installation eingestellt, dass einmal täglich eine Update Synchronisation durchgeführt werden soll. Es ist aber jederzeit möglich eine ad hoc Synchronisation durchzuführen:

SNAGHTML5193ba

Die erste durchgeführte Synchronisation kann durchaus lange, mitunter Stunden dauern. Um sich einen Überblick über den aktuellen Status zu verschaffen, empfiehlt sich die Beobachtung der Logdatei wsyncmgr.log:

clip_image068

Man beachte, dass zu diesem Zeitpunkt noch keine Update-Inhalte heruntergeladen werden. Zu diesem Zeitpunkt geht es lediglich um das „Suchen nach Updates“. Hierbei werden die zuvor konfigurierten Klassifizierungen und Produkte berücksichtigt.

Nach Abschluss der Synchronisation werden alle aufgefundenen Updates in der Ansicht All Software Updates angezeigt:

clip_image070

Nach der ersten Synchronisation werden dies erfahrungsgemäß sehr viele Updates sein, je nach Anzahl der ausgewählten Produkte womöglich tausende. Um sich einen Überblick zu verschaffen, empfiehlt es sich, die Updates erst einmal nach Produkten zu gruppieren. Hierzu blendet man sich zunächst die Spalte Product in die Listenansicht ein, indem man mit der rechten Maustaste auf eine beliebige Spaltenüberschrift klickt und aus dem Kontextmenü die entsprechende Spalte auswählt:

SNAGHTML90444f

Durch erneuten Aufruf desselben Kontextmenüs lässt sich die Liste dann nach Produkten gruppieren:

SNAGHTML528fec

Da man in der Regel nicht jedes Update einzeln verteilen möchte, empfiehlt es sich Update Groups zu verwenden. Eine Update Group bündelt quasi mehrere Updates zu einem logischen Paket. Microsoft empfiehlt allerdings, nicht mehr als 1000 Updates in eine Update Group aufzunehmen, was gerade für die Verarbeitung der “ersten Welle” von Updates mit SCCM ein gewisses Organisationstalent erfordert. Es gibt hier verschiedene Meinungen, wie man seine Update Groups einteilen sollte. Ich bevorzuge eine Einteilung in Produkte und Monate. D. h. jeden Monat bilde ich eine neue Update Group pro Produkt. Für die Verarbeitung der Updates, die bei der ersten Synchronisation eintreffen, möchte man sich natürlich diese Arbeit nicht machen, da die Updates ja u. U. aus sehr vielen vergangenen Monaten stammen. Hier bildet man am besten eine Gruppe pro Produkt und nimmt alle bis zum aktuellen Zeitpunkt aufgelaufenen Updates in diese Gruppe auf. Diese Gruppe nennt man dann z. B. Windows 7 Updates bis 07-2016. In den folgenden Monaten bildet man dann jeweils eine neue Gruppe und nennt diese dann z. B. Windows 7 Updates 08-2016, Windows 7 Updates 09-2016 usw.

Um eine Update Group zu erzeugen, markiert man diejenigen Updates, die eine Gruppe bilden sollen und wählt aus dem Kontextmenü den Befehl Create Software Update Group:

SNAGHTML55d321

SNAGHTML561c30

Nachdem man die gewünschten Update Groups gebildet hat, lassen sich alle Updates gruppenweise herunterladen und paketieren, wobei diese beiden Aktionen in einem Schritt geschehen. Um den Download einer Update Group zu starten, wechselt man in den Menüordner Software Update Groups, selektiert die gewünschte Update Group und wählt aus dem Kontextmenü den Befehl Download:

SNAGHTML56a95d

Der Dialog Download Software Updates Wizard öffnet sich:

clip_image082

Beim Download einer Update Group wird ein Deployment Package benötigt, das nun angelegt werden muss. Hierfür müssen ein Name und ein Pfad zu einem Ordner für das Package angegeben werden. Im Gegensatz zu der Anzahl von Updates innerhalb einer Update Group ist die Anzahl der möglichen Updates innerhalb dieses Deployment Package nicht eingeschränkt. Ich empfehle daher, pro Produkt ein Deployment Package anzulegen und dieses bei Neuerscheinen von weiteren Updates zu „recyclen“, d. h. de facto jeden Monat um weitere Updates zu ergänzen. Es ist nicht so, dass der Inhalt dieses Deployment Package bei der Update Installation jedes Mal komplett auf den Client heruntergeladen wird, wie dies bei einem klassischen Software Package der Fall wäre. Nur die Installationsdateien derjenigen Updates, die der Client aktuell benötigt, werden auch tatsächlich vom Distribution Point heruntergeladen.

Zur Ablage der Update Deployment Packages verwende ich folgende Ordnerstruktur:

\\<ServerName>\<ShareName>\
+- Updates
+- <Herstellername>
  +- <Produktname>

image

Wobei hier de facto als einziger Hersteller Microsoft auftaucht, theoretisch wären auch Updates anderer Hersteller, z. B. Adobe denkbar, die über System Center Updates Publisher 2011 importiert werden könnten.

Auf der folgenden Dialogseite wird man aufgefordert, einen Distribution Point für die Bereitstellung des Update Deployment Package zu wählen:

clip_image086

Auf der nächsten Seite können bei Bedarf noch Anpassungen an den Verteilungseinstellungen vorgenommen werden:

clip_image088

Anschießend hat man die Möglichkeit, die Herkunft der Updates zu bestimmen, falls man sie nicht aus dem Internet beziehen möchte bzw. kann:

clip_image090

Auf der nächsten Seite können die zu unterstützenden Sprachen ausgewählt werden, wobei heute die meisten Windows Updates sowieso „multilingual“ sind:

clip_image092

Nachdem man die Zusammenfassung mit Next bestätigt hat …

clip_image094

… erfolgt der eigentliche Download der Update-Installationsdateien. Eine der wenigen Stellen in SCCM, wo der Fortschritt tatsächlich „live“ mitverfolgt werden kann, ohne dass man hierfür in eine Logdatei schauen muss:

clip_image096

clip_image098

Update Verteilung

Nach all der Vorarbeit sind wir nun endlich in der Lage, die vorbereiteten Updates auszurollen. Dies kann entweder für jedes Update einzeln erfolgen, oder aber man verteilt die Update Group, letzteres ist natürlich die zu empfehlende Vorgehensweise. Um das Deployment anzulegen, startet man im Menüordner Software Update Groups, selektiert die zu verteilende Update Group und wählt den Befehl Deploy aus dem Kontextmenü:

clip_image100

Der Deploy Software Updates Wizard öffnet sich:

clip_image102

Im Wesentlichen muss man hier lediglich eine Collection auswählen, auf die die Updates verteilt werden sollen. Wir wählen hier die von uns zu diesem Zweck zuvor angelegte Collection:

clip_image104

clip_image106

Im Grunde könnte man für den Namen des Deployments die Vorgabe „Microsoft Software Updates …“ beibehalten. Ich übernehme für den Namen des Deployments immer den Namen der Software Update Group, aber das ist schließlich Geschmackssache:

clip_image108

clip_image110

Auf der Seite Deployment Settings kann festgelegt werden, ob das Deployment Required oder Available sein soll. Falls das Deployment für Client Computer, also „Nicht-Server“ Systeme vorgesehen ist, empfiehlt es sich, das Deployment als Required einzustufen. Falls das Deployment für Server Systeme eingestellt wird, ist es auf jeden Fall sinnvoll, ein optionales, also Available Deployment zu wählen, um den Zeitpunkt der Installation und ggf. Neustartes genau unter Kontrolle zu haben. Manche meiner Kunden verwenden SCCM zur Updateverteilung ausschließlich auf Client Systemen, Server Systeme werden dann „klassisch“ mit WSUS versorgt. Der Grund dafür ist oft, dass SCCM Lizenzen für Server erheblich teurer sind, als für Clientbetriebssysteme.

Auf der nächsten Dialogseite kann festgelegt werden, ab wann das Deployment starten soll und ab wann die „Deadline“ des Deployments erreicht sein soll. Spätestens bei Erreichen dieser Deadline, wird die Installation eines Required Deplyoments gestartet. Auch erforderliche Neustarts werden ggf. ab diesem Zeitpunkt erzwungen.

clip_image112

Auf der nächsten Dialogseite kann die User Experience der Update Installation beeinflusst werden. So kann der Grad der Benutzerbenachrichtigungen und die „Aufdringlichkeit“ der Installation eingestellt werden:

clip_image114

Manchen meiner Kunden bevorzugen es, hier sämtliche Benachrichtigungen zu unterdrücken, um „keine schlafenden Hunde zu wecken“. Ich persönlich bevorzuge es allerdings hier, sämtliche Benachrichtigungen anzuzeigen. Meiner praktischen Erfahrung nach ist es sinnvoll, den erzwungenen Neustart bei den Servern sowieso, aber insbesondere auch bei Workstations zu unterdrücken, da man es sonst häufig erlebt, dass sich Kollegen darüber beschweren, dass gerade in einem denkbar ungünstigen Moment ein Neustart erzwungen wird und wie man das „jetzt eben schnell in den kommenden Minuten doch noch unterbinden könnte“.

Auf der folgenden Dialogseite können diverse Alarmierungen, insbesondere im Zusammenhang mit System Center Operations Manager eingestellt werden, worauf ich hier aber nicht näher eingehen möchte.

clip_image116

Die nächste Dialogseite ermöglicht ein Feintuning des Downloadverhaltens. Ich empfehle hier, die Option Downlad software updates from distribution point and install zu aktivieren, die sich darauf bezieht, wie sich der SCCM Client verhalten soll, falls er sich in einer Network Boundary befindet, die als slow eingestuft ist. Falls diese Option nicht aktiviert ist, wenn also stattdessen die Einstellung Do not install software updates ausgewählt wird, kommt es auf dem Client im Softwarecenter zu dem Phänomen, dass die Software Updates zwar angezeigt und scheinbar auch heruntergeladen werden, der Downloadfortschritt jedoch dauerhaft bei „0 %“ hängen bleibt. Dieses Verhalten ist etwas unglücklich, es wäre mir lieber, wenn auf dem Client eine Meldung in der Art „Wird wegen langsamer Netzwerkverbindung nicht heruntergeladen“ angezeigt würde. Ein scheinbar hängengebliebener Downlaod führt an der Stelle immer wieder zu Verwirrung und erhöhtem Supportaufwand.

clip_image118

Ich persönlich wähle hier auch die Option, Software Updates im Zweifelsfall von Microsoft Updates aus dem Internet herunterzuladen, falls kein Distribution Point gefunden werden kann der das Update bereithält.

clip_image120

Nach Abschluss des Deploy Software Updates Wizard sind unsere Updates nun endlich auf den Weg gebracht:

clip_image122

Um bei der Menge an Updates halbwegs den Überblick zu bewahren, verschiebe ich diejenigen Updates, die bereits verteilt worden sind in einen Unterordner. Hierzu wechsle ich wieder in den Menüordner All Software Updates, markiere die erledigten Updates und wähle aus dem Kontextmenü den Befehl Move:

clip_image124

clip_image126

Der Archivordner muss natürlich zuvor bereits angelegt worden sein. Die auf diese Art verschobenen Updates verschwinden dann aus All Software Updates und geben den Blick auf diejenigen Updates frei, die noch nicht verteilt worden sind. Ich betrachte den Ordner All Software Updates quasi als meinen Posteingang für neue Updates, die verteilt werden müssen.

Monitoring und Reporting

Nachdem erklärt wurde, wie Updates mit SCCM verteilt werden können, möchte ich nun abschließend noch zeigen, wie man sich einen Überblick über den Verteilungsgrad der Updates verschaffen kann.

Einen ersten groben Überblick erhält man im Menüordner Software Update Groups. Durch Selektion derjenigen Update Group, deren Verteilungsgrad man ermitteln möchte, wird im Bereich Summary ein Diagramm angezeigt, das den Anteil der Clients darstellt, deren Zustand bgzl. Der Update Group Compliant, Non-Compliant oder Unknown ist:

clip_image128

Leider lässt sich die Frage, die sich hier unmittelbar aufdrängt, nicht beantworten, nämlich für welche Computer dieser Status gilt. Um dies zu erfahren kann man z. B. den Status des zugehörigen Deployments im Bereich Monitoring unter Overview | Deployments abrufen. Dazu muss man leider das zugehörige Deployment erneut heraussuchen. Hierbei hilft die zuvor empfohlene Gepflogenheit, das Deployment einer Update Group genauso zu benennen, wie die Update Group selbst:

clip_image130

Unter den Deployments werden die Diagramme pro Collection angezeigt, Unter den Software Update Groups wird der Status für alle Collections zusammengefasst dargestellt, dadurch ergeben sich in den beiden gezeigten Screenshots unterschiedliche Zahlenwerte. Durch Anklicken des Links View Status, können weitere Detailinformationen abgerufen werden:

clip_image132

Hier ist dann auch sichtbar, welche Computer sich in welchem Status befinden:

clip_image134clip_image136

In den meisten Fällen dürfte dieses ad hoc Reporting schon ausreichend sein. Wenn man genauer hinsehen möchte, oder den genauen Status zu einem einzelnen Update erfahren möchte, kann sich einem der zahlreichen Reports bedienen, die zu diesem Zweck existieren. Wenn man z. B. den Verteilungszustand eines bestimmten Updates erfahren möchte, so merkt man sich de KB Artikelnummer des Updates und ruft den Report Software Updates – A Compliance | Compliance 2 – Specific software update auf:

clip_image138

Durch Auswahl einer Collection und Angabe der KB Artikelnummer (nur die Nummer, ohne „KB“ davor), erhält man einen ausführlichen Report zu genau diesem Update:

clip_image140

Durch Anklicken der im Reportergebnis angezeigten Hyperlinks lässt sich ein „Drilldown“ in die jeweils nächste Anzeigeebene durchführen:

SNAGHTML75b83b

SNAGHTML8d3bc3

Zusammenfassung

Niemand kommt um das Thema Update Deployment herum. Ob es sich lohnt, hierfür SCCM einzusetzen, oder ob man hierfür eine meist ohnehin schon vorhandene WSUS Infrastruktur nutzen soll, lässt sich nicht pauschal beantworten. Falls man aber SCCM bereits im Unternehmen eingeführt hat, lohnt es sich meiner Ansicht nach sehr wohl, über eine Update Verteilung mit SCCM nachzudenken, weil die Integration dieses Themas in SCCM sehr gut gelungen ist. Wer z. B. die Verteilung von Softwarepaketen im Zusammenhang mit SCCM bereits kennt, dem dürfte der Einstieg in die Updateverteilung nicht sonderlich schwerfallen, da die verwendeten Mechanismen untereinander sehr ähnlich sind.

Je nach Vertragsverhältnis, dass man mit Microsoft unterhält, kann es auch durchaus Sinn ergeben, einen gemischten Ansatz zu verfolgen, bei dem die Updateverteilung auf den Workstations mit SCCM erfolgt und die Verteilung auf Servern klassisch mit WSUS durchgeführt wird, insbesondere vor dem Hintergrund, dass SCCM Server Management Lizenzen deutlich teurer sind, als Client Lizenzen.

Das Thema Update Deployment mit SCCM lässt sich nicht nebenbei erklären oder erlernen, dass zeigt allein der Umfang dieses Blogbeitrags. Dabei wurden bisher gerade mal nur die Grundlagen gezeigt. Ich habe vor, weitere Fortsetzungen zu diesem Beitrag zu erstellen, wo ich auf Automatic Deployment Rules, Offline Servicing und Update Verteilung im Rahmen von OS Deployments mit SCCM eingehen möchte. Diese Features machen die Verteilung von Updates mit SCCM erst richtig spannend und bieten Möglichkeiten, die sich mit einer reinen WSUS Infrastruktur nicht ohne weiteres abbilden lassen.

Grüße,

Thomas Froitzheim…