Software Update Strategie
markus
Ein wesentlicher Bestandteil vom System Center Configuration Manager 2012 R2 (ConfigMgr) ist die Software Update Verteilung. Sie basiert im Hintergrund auf den Updatedefinitionen von WSUS, aber erweitert die Steuerung und Anpassbarkeit extrem.
Daraus ergibt sich zwangsweise, dass viele von den Möglichkeiten zuerst überrascht sind und sich zum einfachen Konzept des WSUS zurücksehnen.
Daher sollen in diesem Blogpost und in nachfolgenden Post verschiedene Strategien zur Softwareupdateverteilung vorgestellt werden.
Seit ConfigMgr 2012 gibt es die Automatic Deployment Rules, die vom Aufwand wieder an die Einfachheit des WSUS herankommen.
Daher kann man die Strategien auf zwei Achsen anordnen:
- Flexibilität: Wie stark kann ich die zu verteilenden Updates filtern und testen.
- Aufwand: Wie viele Schritt müssen bis zur Verteilung getan werden.
Strategie 1: Verteilung WSUS-like
Die erste Strategie setze ich bei vielen Mittelstandskunden um. Bei ihnen ist der ConfigMgr nur eines der vielen Produkte, die täglich betreut werden müssen. Daher ist das oberste Ziel, dass der Aufwand minimiert wird.
Daher wird hier stark auf die Automatic Deployment Rules gesetzt. Dazu gibt es zwei Collections:
- Test Clients: Eine Auswahl von repräsentativen Clients, die die Updates sofort bekommen.
- Produktive Clients: Alle anderen Clients, die die Updates verzögert bekommen.
Die Automatic Deployment Rule (Software Library\Overview\Software Updates) der Test Clients hat als Besonderheit, das beim automatischen Überprüfen keine neue Software Update Gruppe angelegt wird. Die Software Update Gruppe steuert unter anderem, wann ein Update installiert wird (optional oder erzwungen). Da die Updates hier sofort installiert werden sollen, reicht uns eine Gruppe.
Als Auswahlregeln kann die nachfolgende Einstellung als Basis gewählt werden:
Die Auswahl beinhaltet nur Updates, die auch benötigt werden (required >0). Ebenso nur Updates, die von Microsoft kommen, noch nicht durch ein neueres Updates ersetzt wurde und bei denen es sich um ein Security Updates (hat eine MSyy-xxx Nummer, also ein MS in der Bulletin ID).
Zur Überprüfung der Auswahl bietet sich der Preview Button an.
Da wir die Updates für die Testclients direkt freigeben, hängen wir den Evaluation Schedule an den WSUS Sync Zeitpunkt. Bei Deployment Schedule wählen wir bei beiden Zeitfenstern “As soon as possible”.
Neustart unterdrücke ich in den meisten Fällen auf der “User Experience” Seite.
Die Updates kommen in ein Deployment Package mit dem Namen “Microsoft Updates”. Dieses Paket wird von allen Microsoft Updates Verteilungen genutzt. Das verhindert, dass das Update mehrfach heruntergeladen werden muss.
Für die Produktiven Clients gehen wir ähnlich vor. Dabei gibt es folgende Abweichungen:
- General: Create a new Software Update Group: Notwendig, da wir pro Patch-Day neue Zeitfenster definieren wollen
- Evaluation Schedule: Every 2 weeks on Wednesday: angelehnt an den Microsoft Patchday, aber häufiger pro Monat, da u.U. neue Clients hinzukommen, denen noch Updates fehlen, die aber bereits auf allen anderen Clients installiert sind. (Dies ist notwendig, da wir im Gegensatz zu den anderen Strategien hier mit keiner Baseline von Softwareupdates arbeiten)
- Deployment Schedule: Software available time: 1 week (ermöglicht, dass die Testclients mögliche Fehler bereits erkannt haben), Installation deadline: 1 week (erzwingt die Installation eine Woche nach der Available time, d.h. Updates werden ca. zwei Wochen nach der Veröffentlichung auf den Clients erzwungen)