Azure Update Management – Einrichtung und Nutzung

Microsoft bietet unter Azure einen Dienst an, bei dem die Update-Installation zentral verwaltet werden kann. Diese Art von Update-Management soll ein Management per Windows Server Update Services (WSUS) ablösen. Ich habe mir die Einrichtung und die Handhabung mal angeschaut und werde die Schritte zur Installation und zur Einrichtung hier dokumentieren.

Azure Ressourcen erstellen

Wir beginnen mit der Erstellung einer neuen Ressource im Azure Portal. Hierzu wechseln wir zu All Services und erstellen einen neuen Dienst: Log Analytics.

Hier geben wir dem neuen Dienst einen Namen und eine Beschreibung. Zusätzlich wählen wir hier aus, wie die Abrechnung erfolgt.

Hat alles geklappt und der Dienst wird erstellt, bekommen wir dies nach der Erstellung direkt angezeigt.

Der zweite Dienst, der benötigt wird, ist ein Azure Automation Account. Am einfachsten findet man die Ressourcen im oberen Bereich über die Suche:

Wir müssen nun einen neuen Account erstellen

Nach der Erstellung können wir oben im Status sehen, dass die Erstellung passiert und eine kurze Zeit benötigt.

Nachdem die Erstellung abgeschlossen ist, sehen wir unseren Account.

Innerhalb von dem Automation Account können wir nun das Update-Management einschalten und aktivieren.

Nachdem wir nun das Update Management generell aktiviert haben, wechseln wir zurück in den Log Analytics Workspace. Ich möchte in meinem Fall testweise mal einen lokalen Windows Client mit aufnehmen und diesen über das Azure Portal verwalten.

Hier wählen wir aus, um was für ein Betriebssystem es sich handelt. In meinem Fall um ein Windows mit 64 Bit, daher lade ich mir den 64 Bit-Agenten herunter.

Installation des Agenten

Die Installation des Agenten ist recht schnell gemacht, hier die Installation in Bildern:

Bei den Agenten-Optionen aktivieren wir die Option, dass wir uns mit dem OMS verbinden.

Im nächsten Fenster müssen wir nun die Daten eingeben, die wir im Azure Portal sehen. Es geht hier um die ID von dem Workspace und dem dazugehörigen Kennwort.

Das war es dann auch schon, ein Klick auf Installieren bringt die Software auf das lokale System. Läuft alles rund, wird die Installation mit einem Erfolg bestätigt.

Aktivierung des Systems im Azure Portal

Wir wechseln nun zurück in das Azure Portal und gehen in den Bereich Automation Account -> Update Management.

Hier können wir erkennen, dass sich aktuell 0 Systeme in der Verwaltung befinden. Der PC, auf dem ich gerade den Agenten installiert habe, ist aber schon bekannt. Dies ist sichtbar an der Zeile, die im Screenshot rot markiert ist. Ich muss für dieses System nun noch das Update Management aktiv einschalten.

Nun dauert es einige Minuten, bis der lokale Agent die Daten übermittelt und der Status des Systems sichtbar wird. In meinem Fall dauerte es knapp 25 Minuten, bis das System das erste Mal aufgetaucht ist.

Wie man in dem Screenshot erkennen kann, ist das System noch nicht “eingelesen”. Dies passiert nun im Hintergrund. Nach einer weiteren halben Stunde tauchte dann der Status des Systems auf, hier wird dann das erste Mal sichtbar, dass Updates fehlen bzw. noch nicht installiert sind.

Die geplante Installation von Updates

Sollen nun Updates installiert werden, kann dies entweder einmalig per Hand gemacht werden, alternativ können Zeitpläne aktiviert werden (z.B. monatliche Installationen). Hierzu erstellen wir einen neuen Plan mit Schedule update deployment.

Innerhalb der Erstellung müssen wir nun diverse Einstellungen angeben.

Nachdem ich einen Namen für die Aufgabe eingegeben habe, können wir nun die Gruppe angeben, die Updates erhalten soll (Alternativ können wir auch in dem Punkt darunter Maschinen angeben, die ein Update erhalten sollen. Gruppen machen eine Auswahl allerdings einfacher).

Wichtig ist hier, dass in der oberen Leiste von Azure auf Non-Azure (local) umgeschaltet wird. Passiert dies nicht, tauchen nur Azure-Systeme auf. Wir sehen nun in meinem Screenshot, dass dort eine MicrosoftDefaultComputerGroup auftaucht sowie eine weitere Gruppe. Ich hätte mir an dieser Stelle eigentlich gewünscht, dass eine neue Gruppe erstellt werden kann mit den Systemen, die ich gerne in dieser Gruppe hätte. Dies geht aber leider nicht mal eben, man muss die Gruppe im Vorfeld an einer anderen Stelle anlegen.

Neue Computer-Gruppe anlegen

Damit nicht nur die Standard-Gruppe mit allen Systemen vorhanden ist, muss eine neue Gruppe angelegt werden. Dies geht leider nicht grafisch, sondern muss mit einer Abfrage gemacht werden. Hierzu wechseln wir im Log Analytics workspace in den Bereich Advanced Settings und dort in den Unterbereich Logs.

Wir können hier erkennen, dass dort die vorhin schon aufgeführte Standard-Gruppe vorhanden ist. Soll nun eine eigene Gruppe erstellt werden, müssen die Mitglieder der Gruppe über eine Abfrage bestimmt werden. Dies kann ein Name sein oder aber auch eine andere Eigenschaft, zum Beispiel das Betriebssystem.

Ist die korrekte Syntax eingegeben, kann die Abfrage gespeichert werden. Sie muss als Function gespeichert werden, weiterhin müssen wir einen aussagekräftigen Namen vergeben.

Sind die Einstellungen gespeichert, taucht diese “Gruppe” nun auf und kann als Grundlage für den Update-Job genutzt werden.

Fazit

Die Möglichkeit, viele Systeme gleichzeitig über Azure zu verwalten und upzudaten ist an sich eine gute und sinnvolle Idee. Das aktuelle Problem bei dem Azure Update Management ist, dass es mega kompliziert ist und bei weitem nicht das bietet, was ich mir unter diesem Produkt vorgestellt habe. Cool wäre eine Oberfläche gewesen, in der ich die Systeme (einfach!) in Gruppen sortieren kann, sie mit Tags versehen kann (z.B. je nach Kunde oder nach Art des Systems) und in der ich mir die Update-Stände als Report auswerfen kann (ebenfalls mal eben). Leider alles nicht gegeben, daher habe ich mich erstmal wieder ein bisschen von dieser Art des Managements entfernt, da gibt es zum jetzigen Zeitpunkt deutlich bessere Lösungen. Aber vielleicht wird es ja in Zukunft doch noch was…

Jan

Jan Kappen arbeitet sein 2005 in der IT. Er hat seine Ausbildung 2008 abgeschlossen und war bis 2018 als IT-Consultant im Bereich Hyper-V, Failover Clustering und Software Defined Storage unterwegs. Seit 2015 wurde er jährlich von Microsoft als Most Valuable Professional (MVP) im Bereich "Cloud & Datacenter Management" ausgezeichnet für seine Kenntnisse und die Weitergabe seines Wissens. Jan ist häufig auf Konferenzen als Sprecher zu finden, weiterhin bloggt er viel. Seit September 2018 ist Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

Schreibe einen Kommentar

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