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.
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:
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.
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.
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.
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:
Der Assistent Add Site System Roles öffnet sich:
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.
Auf der folgenden Dialogseite wählt man die Rolle Software Update Point aus:
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.
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:
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:
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:
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.
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.
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.
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.
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:
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:
Die einzig wichtige Einstellung, die uns hier zunächst interessiert, ist Enable Software Updates on Clients.
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:
Auf diese Collection wendet man die zuvor erstellten Client Settings an, indem man ein entsprechendes Deployment für die Settings erstellt:
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:
Nach einer gewissen Wartezeit (Bei SCCM geht eigentlich immer alles mit „einer gewissen Wartezeit“ einher), sollte sich die Komponente Softwareupdate-Agent als Aktiviert zeigen:
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:
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:
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:
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:
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:
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:
Durch erneuten Aufruf desselben Kontextmenüs lässt sich die Liste dann nach Produkten gruppieren:
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:
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:
Der Dialog Download Software Updates Wizard öffnet sich:
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:
+- Updates
+- <Herstellername>
+- <Produktname>
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:
Auf der nächsten Seite können bei Bedarf noch Anpassungen an den Verteilungseinstellungen vorgenommen werden:
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:
Auf der nächsten Seite können die zu unterstützenden Sprachen ausgewählt werden, wobei heute die meisten Windows Updates sowieso „multilingual“ sind:
Nachdem man die Zusammenfassung mit Next bestätigt hat …
… 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:
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ü:
Der Deploy Software Updates Wizard öffnet sich:
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:
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:
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.
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:
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.
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.
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.
Nach Abschluss des Deploy Software Updates Wizard sind unsere Updates nun endlich auf den Weg gebracht:
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:
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:
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:
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:
Hier ist dann auch sichtbar, welche Computer sich in welchem Status befinden:
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:
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:
Durch Anklicken der im Reportergebnis angezeigten Hyperlinks lässt sich ein „Drilldown“ in die jeweils nächste Anzeigeebene durchführen:
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…