Microsoft System Center Configuration Manager (SCCM, ein typischer Microsoft-Produktname, irgendwann überschreiten sie noch die maximale Zeichenanzahl von NTFS-Dateipfaden) ist ein mächtiges Werkzeug (fast so mächtig wie Ansible). Wer SCCM einmal einsetzt, wird damit sehr wahrscheinlich auch die Windows-Updates, mindestens die der Clients abwickeln wollen. Updates werden dann auf dem sogenannten Softwareupdatepunkt, den es zunächst einzurichten gilt, von den Microsoft-Update-Servern oder optional von einem eigenen Server mit installierten Windows Server Update Services (WSUS, ein weiteres Beispiel) heruntergeladen und dann nach eigenem Gutdünken an die mit SCCM verwalteten Systeme verteilt. Anleitungen zur Installation und Konfiguration des Softwareupdatepunktes findet man schnell, darum möchte ich hier stärker auf die Entscheidungen, die SCCM-Administratoren treffen müssen, auf Möglichkeiten der Überwachung und typische Fehlerursachen eingehen.
Welche Update-Produktgruppen brauche ich?
Bevor Updates verteilt werden können, muss der Softwareupdatepunkt sich erst einmal mit dem Update-Katalog synchronisieren; anderenfalls bleibt die Liste aller Software-Updates leer, weil der Softwareupdatepunkt noch keine kennt. Für Betriebssystemaktualisierungen bietet sich zum Beispiel das Produkt „Windows 10“ an. Die Produkte mit spezifischeren Namen beziehen entweder auch die Windows-Treiber mit ein (und blähen die SCCM-SQL-Datenbank stark auf) oder sind für bestimmte Windows-Versionen gedacht.
Welche Update-Klassifizierungen brauche ich?
Updates, kritische Updates, Sicherheitsupdates sind für den Anfang nicht schlecht. Definitionsupdates sind Aktualisierungen für den Windows Defender. Und Upgrades wählt man an, wenn man Featureupdates (Upgrades) auf neuere Windows-Versionen bereitstellen möchte.
Was sind automatische Bereitstellungsregeln, und wozu brauche ich sie?
Mit den ADR (Automatic Deployment Rules) lassen sich nach festzulegenden Kriterien ausgewählte Updates (Sprache, Produkt, Titel, etc.) in regelmäßigen Abständen (jeden Tag, jede Woche, jeden letzten Freitag im Monat, etc.) herunterladen und für eine bestimmte Sammlung nach einem bestimmten Zeitplan (sofort verfügbar, spätestens zu installieren bis, etc.) bereitstellen. ADR sind für regelmäßige, fehlerbereinigende Windows-Updates sinnvoll.
Was spricht für jeweils neue Softwareupdategruppen, was für das Wiederverwenden von Softwareupdategruppen?
Eine automatische Bereitstellungsregel kann Updates entweder in einer neuen Softwareupdategruppe oder immer in der gleichen speichern. Wenn die Updates in der bestehenden Softwareupdategruppe gespeichert werden, werden die bisher dort gruppierten Updates durch die für die angegebenen Kriterien gefundenen Updates ersetzt. Wenn es kein zeitliches Kriterium gibt und die anderen Kriterien (Produkte, Klassifizierungen, etc.) gleich bleiben, wird diese Gruppe natürlich immer größer. Sucht die automatische Bereitstellungsregel nur nach Updates, die in den letzten sechs Monaten veröffentlicht wurden, werden kontinuierlich Updates aus der Gruppe entfernt und neue hinzugefügt. So könen sich veraltete und nicht mehr benötigte Updates gar nicht erst ansammeln. Wenn allerdings irgendwann ein Client auf einem viel älteren Update-Stand auftaucht und diese Updates noch nicht installiert hat, müssen sie unter Umständen erneut heruntergeladen werden. Jedes Mal automatisch neu angelegte Softwareupdategruppen hingegen bilden immer genau die Updates ab, die zum Zeitpunkt der Ausführung den Kriterien entsprachen, und alte Updates werden folglich nicht automatisch entfernt – andererseits ist es trivial, nach einer Weile einfach die ganze Gruppe zu löschen, wenn man sie nicht mehr braucht. Diese Gruppen sind am Zeitstempel der Regelausführung in ihrem Namen zu erkennen. Bequemer ist sicher das Weiterverwenden der gleichen Softwareupdategruppe, doch besonders dann sollte man ein Auge auf die Deadline der Bereitstellung und den Ausführungsintervall der automatischen Bereitstellungsregel haben, damit alle Clients die bereitgestellten Updates installieren, bevor die Updates wieder aus der Gruppe entfernt werden,
Wie verteile ich Featureupdates (Windows-Upgrades)?
Microsoft veröffentlicht neue Windows-Versionen nun vorzugsweise halbjährlich mit dem Anspruch, möglichst wenig Arbeit für Anwender und Administratoren zu schaffen, und daher in Form eines Windows-Updates. Das Prinzip bleibt aber das gleiche wie bei einem Upgrade, weil es ein Upgrade bleibt: Es wird ein komplettes Windows-Installationsmedium heruntergeladen und bis zum irgendwann fälligen Neustart im Hintergrund installiert. Weil es von SCCM allerdings wie ein Update behandelt wird, verteilt man es rein technisch gesehen auch genauso wie jedes andere Update. Microsoft geht so weit, die Upgrade-Installation optional zu automatisieren, was zu der Frage führt:
Was sind Windows-10-Wartungspläne, und wozu brauche ich sie?
Genau für diese Automatisierung von Windows-10-Upgrades sind Wartungspläne gedacht. Genau wie automatische Bereitstellungsregeln ermöglichen sie den automatischen Download und die automatische Bereitstellung, in diesem Fall von Windows-10-Upgrades. Grundsätzlich gilt es zu beachten, den richtigen „Update“-Kanal zu auszuwählen: Der halbjährliche Kanal (gezielt), übrigens wieder ein sehr aussagekräftiger Name von Microsoft, richtet sich an Gruppen, die man gleich nach der Veröffentlichung der Upgrades damit beglücken möchte, also in der Regel erst einmal die Administratoen oder Testgruppen. Der halbjährliche Kanal (nicht gezielt) wird ein halbes Jahr später mit dem Upgrade versorgt. Entscheiden sich die Administratoren also nach ihren Erfahrungen im gezielten Kanal gegen das Ausrollen des Upgrades in der Organisation, bleibt ihnen genügend Zeit, den Wartungsplan zu deaktivieren. Wenn man davon ausgeht, dass jede Organisation ein Upgrade erst einmal testet, stellt sich allerdings die Frage, warum man das Upgrade, wenn nach der Testphase nichts dagegen spricht, nicht einfach ganz herkömmlich auswählt, herunterlädt und bereitstellt. Das ist nämlich wie bei jedem anderen Update ganz einfach möglich.
Welches Featureupdate ist das richtige für Windows 10 Pro?
Es gibt separate Featureupdates für Anwendereditionen und Businesseditionen mit der gleichen KB-Nummer. Bei Windows Home oder Enterprise ist die Einordnung klar, aber Windows 10 Pro gibt es sowohl als OEM- oder Retail- als auch als für Volumenlizenzinstallationen gedachte Version. Auf Windows-10-Pro-Rechnern aus dem Handel lässt sich also das Featureupdate für die Anwendereditionen installieren, auf Windows-10-Pro-Rechnern, die von der Organisation mit einem Installationsmedium aus dem Volumenlizenzportal „betankt“ wurden, hingegen das Featureupdate für Businesseditionen. Die Verwirrung ist natürlich unglücklich, zeigt aber einmal mehr Microsofts schlechtes Händchen für Produktnamen.
Wieso werden bereitgestellte Updates nicht installiert, obwohl die Deadline erreicht ist?
Die Deadline ist nicht so kompromisslos, wie das Wort vermuten lässt: Sie wirkt erst im ersten Wartungsfenster nach dem angesetzten Installationsdatum. Wenn die Bereitstellung nicht konfiguriert ist, Wartungsfenster zu ignorieren, aber kein Wartungsfenster für den betreffenden Client verfügbar ist, werden Updates auch nicht installiert. Falls ein Wartungsfenster gesetzt ist, aber die erwartete Installationszeit des Updates für das Wartungsfenster zu lange ist, wird das Update ebenfalls nicht installiert.
Warum schlägt ein Update im Softwarecenter nach einer Stunde Installationszeit fehl?
Wenn eine Update-Installation nach einer gewissen Zeit plötzlich abbricht, könnte für die Bereitstellung des Updates eine zu niedrige maximale Installationszeit angegeben worden sein, oft 60 oder 120 Minuten. Auf langsamen Rechnern reicht diese Zeit nicht aus. Eine Erhöhung der maximalen Installationszeit und eine gewisse Wartezeit, bis der Configuration Manager Client diese Veränderungen bemerkt hat, können dieses Problem lösen. Eine andere Ursache könnte unzureichender Speicherplatz auf der Systempartition sein, wenn zwar der Download, aber nicht die Installation des Updates gelang. Natürlich lohnt sich zur Vergewisserung ein Blick auf den kryptischen Fehlercode, den das Softwarecenter ausspuckt.
Wie erfahre ich, für welchen Fehler ein Fehlercode im Softwarecenter steht?
Im Installationsverzeichnis des Configuration Manager findet sich im Unterordner tools das Programm cmtrace. Dabei handelt es sich um einen einfachen, aber nützlichen Logfile-Viewer, der die damit geöffnete Textdatei in Echtzeit aktualisiert. Etwas versteckt bietet es aber die Option, Beschreibungen für SCCM-Fehlercodes zu liefern (Tools – Error Lookup…).
Wo sehe ich den Status der Softwareupdate-Synchronisation?
Mit cmtrace öffnet man im Installationsverzeichnis des Configuration Manager im Unterordner Logs die Log-Datei wsyncmgr.log. Hier wird die Synchronisation jedes einzelnen gefundenen Updates und zwischendurch auch der Gesamtfortschritt in Anzahl und in Prozent protokolliert.
