Patchmanagement in Microsoft-Infrastrukturen ist eine Disziplin, die ebenso unbeliebt wie unabdingbar ist. Ständig werden neue Schwachstellen veröffentlicht, die Sie in Ihrer Umgebung schnellstmöglich schließen müssen, um Cyberangriffe zu verhindern. Allerdings haben Software-Updates bisweilen auch Nebenwirkungen, was Administratoren oft dazu veranlasst, bei deren Anwendung eher zögerlich vorzugehen. Ironischerweise sind es oft gerade die kritischen Systeme, die zuletzt gepatcht werden und somit am längsten der Bedrohung ausgesetzt sind.

Traditionell steht den IT-Abteilungen mit den Bordmitteln von Windows kein vollwertiges Patchmanagement zur Verfügung. Die bereits seit langem bekannten Windows Server Update Services (WSUS) sind zwar ein bewährtes und zuverlässiges Werkzeug, um Aktualisierungen für Win-dows und einige weitere Microsoft-Produkte innerhalb des Unternehmensnetzwerkes auszuliefern. Die Möglichkeiten einer gezielten Patch-Anwendung beschränken sich jedoch auf Freigaberegeln, die sich an Computergruppen binden lassen. Das Reporting über den angewendeten Update-Stand ist zudem notorisch unzuverlässig und bedarf stets einer Interpretation. IT-Verantwortliche, die ein Patchmanagement aus dem Hause Microsoft implementieren wollen, müssen auf den Microsoft Endpoint Manager (früher SCCM) setzen. Doch auch dort gehört das Patchmanagement zu den Features, deren Einrichtung und zuverlässiger Betrieb am aufwendigsten sind.

Die Weiterentwicklung der Microsoft-Produkte und die Veränderungen in der Arbeitswelt, unter anderem durch die COVID-Pandemie, bringen neue Herausforderungen für das Patchmanagement mit sich. So wird Microsoft Office ab der Version 2016 (wahlweise) beziehungsweise 2019 (ausschließlich) in der "Click-To-Run"-Installationsvariante ausgeliefert. Diese Bereitstellungstechnologie ist mit Windows Update nicht kompatibel, weshalb sich Office-Updates mittels WSUS weder ausliefern noch überwachen lassen – dies betrifft auch die Office-365-Apps.

Auch liefert Redmond Windows 10 erstmalig in einem "Current Branch"-Modell aus. Dieses beinhaltet große Feature-Updates, die ein gewisses Potential für Disruption mit sich bringen, da sie lange dauern, mehrere Reboots erfordern und in Ausnahmefällen zum Verlust von Benutzerdaten führen können. Wenden Admins dieses Feature-Updates allerdings nicht an, gerät das Windows-System spätestens nach drei Jahren aus dem Support und erhält auch keine Sicherheitsupdates mehr.

Schließlich kommunizieren durch die zuvor noch nie da gewesene Mobilität der Büroarbeitsplätze viele der Endgeräte nur sporadisch mit der zentralen Infrastruktur ihrer jeweiligen IT-Organisation. Damit ist eine Sicherstellung eines aktuellen Patchstands über den gesamten Gerätepark hinweg nicht möglich. Microsoft hat mehrere Versuche unternommen, Antworten auf diese Herausforderungen zu liefern. Es ist angesichts der technologischen Entwicklung der letzten Jahre nicht überraschend, dass Clouddienste ein fester Bestandteil dieser Antworten sind.

Es ist bereits seit fast 25 Jahren möglich, Updates für Microsoft-Produkte aus der Public Cloud zu beziehen. Microsoft stellte dafür 1998 zum Launch von Windows 98 "Windows Update" online, das spätere – nach Hinzunahme weiterer Produkte – "Microsoft Update". Für Windows-Endgeräte in Privathaushalten oder Kleinstfirmen ist dies nach wie vor der einzige Weg, das Betriebssystem stets aktuell zu halten. In größeren Unternehmen und Organisationen wird diese Art des Patchens als nicht granular genug empfunden, bietet der Webservice doch stets alle für das Endgerät passenden Updates zur Installation an.

Das granulare Steuern von Aktualisierungen durch Einzelfreigaben oder ausgeklügelte Freigaberegeln in WSUS oder Microsoft Endpoint Manager (MEM) ist ein aufwendiger Prozess, der viele Ressourcen in der IT bindet. Leider müssen Sie in der Regel die gesamte Klaviatur der Gruppenrichtlinien, WSUS-Gruppen und Freigaberegeln bespielen, um einen in Unternehmen typischen dreistufigen Patch-Rollout zu implementieren ("Smoke Test" – Pilot in einer kleinen Gruppe – Freigabe in die Produktion). Und Geräte, die sich über längere Zeiten außerhalb der Umgebung befinden, laufen Gefahr, diesen Patchzyklus zu verpassen.

Für die meisten Unternehmen wäre ein einfaches Rollout-Management, kombiniert mit der hohen Verfügbarkeit des Microsoft-Update-Webdiensts, zumindest im Clientbereich vollkommen ausreichend. Hier betritt "Windows Update for Business" (WUfB) [1] die Bühne.

Der Grund, warum die Einrichtung eines passenden Workflows mithilfe von WSUS so komplex ist, liegt im Verhalten der Clientkomponente. Diese erhält vom Update-Dienst (Microsoft Update oder WSUS) einen Katalog an verfügbaren Patches, scannt den lokalen Computer gegen diesen Katalog und installiert alle angebotenen Aktualisierungen. Möchten Sie also ein Update zurückhalten, muss dies serverseitig passieren. Für Geräte, die keine Verbindung zu Ihrem WSUS haben und auf den Webdienst für den Bezug von Updates angewiesen sind, ist dies natürlich nicht möglich.

Windows Update for Business modifiziert dieses Clientverhalten. Für das Scannen des Computers und das anschließende Installieren von Updates setzt der Client weiterhin auf die bekannte Funktionalität von Windows Update auf. Er sorgt dafür, dass Feature- und Quality-Updates, Treiber und auch Aktualisierungen für weitere, mit der herkömmlichen MSI-Technologie installierten Microsoft-Produkte zeitnah auf das System kommen. Die Auswahl der zu installierenden Updates steuert der Client allerdings lokal, anhand von Konfigurationseinstellungen, die Sie ihm mittels Gruppenrichtlinien mitgeben. Falls Sie bereits modernes Gerätemanagement einsetzen, kommen stattdessen CSP-Einstellungen zum Einsatz.

WUfB kommt mit fünf Gruppenrichtlinien aus, die Ihnen erlauben, Ihre Roll-out-Gruppen zu definieren. Sie finden diese unter "Computer-Konfiguration / Administrative Vorlagen / Windows-Komponenten / Windows Update / Windows Update für Unternehmen". Mit der Richtlinie "Vorabversionen verwalten" entscheiden Sie, ob auch Preview-Releases an die betroffenen Gerätegruppen ausgeliefert werden sollen. Gerade in der Softwareentwicklung und in der Clientverwaltung kann es sinnvoll sein, solche Versionen regelmäßig zu erhalten. Für die breite Masse der Clients wollen Sie diese Einstellung vermutlich eher deaktiviert lassen. Um per WufB auf eine andere als die aktuellste Windows-Version upzudaten, können Sie dies in der Policy "Zielversion des Funktionsupdates" festlegen.

Das Kernstück der WUfB-Funktionalität bilden die Richtlinien "Zeitpunkt zum Erhalt der Vorabversionen auswählen" und "Beim Empfang der Qualitätsupdates auswählen". Mit diesen können Sie bereits am Client den Erhalt von Funktionsupdates um bis zu 365 Tage sowie der Qualitätsupdates um bis zu 30 Tage ab ihrer Veröffentlichung verzögern. Um diese Updatetypen für 35 Tage komplett zu pausieren (beispielsweise, wenn Ihre Organisation eine "Frozen Zone" für den Jahresabschluss festgelegt hat), tragen Sie hier das Startdatum der Pause im Format "YYYY-MM-DD" ein. Sicherheitsupdates und andere Updatetypen können Sie mittels WUfB nicht zurückhalten.

WUfB steuert lediglich den Zeitpunkt, zu dem Ihre Endgeräte bestimmte Updates erhalten, nicht jedoch die Benutzererfahrung bei deren Download und Installation. Dafür sind Sie auf dieselben Konfigurationen angewiesen, die Sie vermutlich bereits aus dem WSUS-Betrieb kennen. Diese Richtlinien sind zahlreich und ihr Zusammenspiel recht komplex. Um Ihnen den Einstieg in WUfB zu erleichtern, bietet Microsoft das "Update Baseline Toolkit" [2] an. Dieses beinhaltet einerseits ein PDF-Dokument, das die verschiedenen Funktionen von Windows Update erläutert und Empfehlungen des Herstellers zusammenfasst. Besonders wertvoll ist hier die Erklärung der neuen Deadline-Richtline vom August 2019 im Vergleich zur herkömmlichen Restart-Policy. Zweitens erhalten Sie ein ZIP-Archiv mit einem Gruppenrichtlinien-Backup, das Sie mit einem mitgelieferten PowerShell-Skript direkt in Ihr Active Directory importieren. Diese Richtline stellt eine Vielzahl von Systemparametern so ein, dass optimaler Betrieb von WUfB gewährleistet wird.

Übrigens: Windows Update for Business bedeutet nicht, dass Sie den tatsächlichen Bezug von Updates zwingend auf den Webservice von Microsoft umstellen müssen. Sie können WUfB auch zusammen mit Ihrem WSUS-Server verwenden, um Bandbreite zu sparen. Damit WUfB seine Funktionalität entfalten kann, müssen Sie die Updates dort aber bedingungslos und unmittelbar nach ihrem Erscheinen automatisch freigeben.

Ein wichtiger Punkt, bei dem WUfB keine Abhilfe bietet, ist die Überwachung der Patchstände Ihrer Geräte und eine Alarmierung, falls es Probleme mit der Anwendung von Patches gibt. WSUS hält dafür eine rudimentäre Funktionalität bereit, für WUfB müssen Sie auf Dienste aus der Azure-Cloud zurückgreifen, allen voran auf "Update Compliance" [3]. Hierfür wird in Ihrer Azure Subscription ein Log-Analytics-Workspace angelegt oder ein bestehender Workspace verwendet, was sich bei einer hohen Anzahl verwalteter Endgeräte durchaus auf der Azure-Rechnung bemerkbar machen kann.

Ferner müssen Sie einige relevante Telemetrie-Optionen auf den Endgeräten erlauben und die Übermittlung dieser Daten an die entsprechenden Endpoints von Microsoft in Ihrer Firewall zulassen. Hier tritt auch der Datenschutz auf den Plan: Bereits im oben verlinkten Docs-Artikel ist der Hinweis enthalten, dass die verwendete Datensammlung nicht den Kriterien der US-Regierung entspricht; die noch etwas schärferen europäischen Richtlinien dürften den Einsatz von "Update Compliance" in deutschen Behörden ebenfalls verbieten.

Kann Ihre Organisation mit diesen Rahmenbedingungen leben, steht Ihnen eine Fülle an Berichten zur Verfügung, die in Echtzeit aktualisiert werden und Ihnen den Überblick darüber bieten, wie aktuell Ihre Endgeräte in Bezug auf Microsoft-Patches sind. Ferner kommt bei Update Compliance ein selbstlernender Algorithmus zum Einsatz, der Funktionsaktualisierungen automatisch zurückstellt, wenn sie besonders viele Fehler und daraus resultierende Rollbacks verursachen.

Falls Sie eine höhere Granularität bei der Handhabung Ihrer Updates benötigen, steht Ihnen mit dem "Windows Update for Business Deployment Service" eine Schnittstelle zur Verfügung, mit deren Hilfe Sie solche Konfigurationen über Microsoft Graph auf die Geräte ausrollen können. Die Verwaltung der Konfigurationen können Sie im MEM oder per PowerShell erledigen. Die Geräte müssen dafür zum Azure AD hinzugefügt sein (ausschließlich oder hybrid). Anschließend aktivieren Sie mittels MEM oder Gruppenrichtlinien das "WFuB Cloud Processing".

Bei allen herkömmlichen Patchmanagement-Ansätzen spielt die Überwachung der Verteilung und Anwendung von Updates eine große Rolle. Doch sind viele IT-Abteilungen so überlastet, dass für die Verwaltung der Policies im AD, WSUS oder MEM ebenso wenig Zeit bleibt wie für die Zustandsüberwachung der Endgeräte. Gleichzeitig spielt die individuelle Konfiguration jedes einzelnen Clients eine viel geringere Rolle als noch vor einigen Jahren. Viele Anwendungen stehen inzwischen zentral über VDI oder Unternehmensportale bereit. Modernes Gerätemanagement erlaubt das Onboarding neuer Devices überall auf der Welt – selbst, wenn ein fehlgeschlagenes Update einen Computer außer Gefecht setzen sollte, ist es meistens wirtschaftlicher, das Gerät zurückzusetzen und neu zu provisionieren, als ein umfangreiches Troubleshooting eines Patches zu betreiben.

Diesen Ansatz verfolgt der neue Cloudservice, den Microsoft für das Patchmanagement auf in der Cloud verwaltete Windows-Clients anbietet: Windows Autopatch [4]. Ähnlich wie bei WUfB ist "Windows" hier nicht ganz wörtlich zu nehmen – neben dem Betriebssystem selbst gehören der Edge-Browser, der Teams-Client und die "Office 365 Apps for Enterprise" zum verwalteten Umfang. Office-Installationen, die aus dem Volume Licensing oder aus Retail-Käufen stammen, bleiben hingegen außen vor.

Autopatch steht ausschließlich IT-Verantwortlichen zur Verfügung, die ihr Win-dows im Rahmen eines Enterprise-Abonnements lizenzieren: Entweder als Teil eines Microsoft-365-E3-/E5-Tarifs oder explizit als "Windows Enterprise E3/E5". Die auf den Clients ausgeführte Windows-Version muss 1809 oder höher sein. Es empfiehlt sich, eine noch unter Support stehende Version vor dem Enrollment in Autopatch zu installieren; andernfalls wird Autopatch anschließend versuchen, die Version zu aktualisieren.

Die Geräte und deren zugewiesene Benutzer müssen aus dem Azure AD stammen oder in dieses von einem lokalen AD synchronisiert werden. Ferner müssen die Endgeräte bereits in Intune vorhanden sein – entweder als reines Cloudmanagement oder im Co-Management mit dem loaklen MEM. Damit ist Autopatch zum gegenwärtigen Zeitpunkt nur für Client-Betriebssysteme und nicht für Server verfügbar. Letztere müssen Sie mit herkömmlichen Mitteln auf dem aktuellen Stand halten.

Sind alle Voraussetzungen erfüllt, übernimmt Autopatch nach dem Enrollment des Tenants und der Endgeräte die Bereitstellung von Updates für die oben aufgezählten Produkte. Dabei verfolgt der Dienst das Ziel, innerhalb einer vorgegebenen Zeitspanne 95 Prozent des Endgeräteparks erfolgreich auf den aktuellen Stand zu bringen. Die Benutzererfahrung ist dabei ähnlich wie bei privat genutzten Endgeräten – die Installation erfolgt zum schnellstmöglichen Zeitpunkt nach Freigabe des jeweiligen Patches, der notwendige Neustart der Maschine orientiert sich an den gemessenen Nutzungszeiten – auch bei Autopatch spielt die Telemetrie eine große Rolle. Anders als im Privatbereich ist hier jedes Update mit einer Deadline versehen. Bei Erreichen dieser Deadline wird der Neustart erzwungen, falls der Nutzer ihn nicht vorher ausführt.

Für die zeitliche Steuerung der Update-Verteilung nutzt Autopatch das Konzept der "Ringe", das Microsoft auch intern einsetzt, um neue Patches produktiv auszurollen. Es gibt in Autopatch vier fixe Ringe, für die Microsoft die Veröffentlichungsdaten und Deadlines einheitlich definiert:

- Test: In diesem Ring werden neu erschienene Funktions- und Qualitätsupdates sofort freigegeben. Damit können Sie ohne Verzögerung die Updates auf Ihren Testsystemen ohne Beeinträchtigung der Produktion testen.

- First: In diesen Ring, der normalerweise um ein bis drei Tage verzögert ist, kommen produktive Endgeräte, an denen Sie den "Smoke Test" der neuen Updates unter Produktionsbedingungen durchführen können. Oft beschränkt sich dieser Ring auf IT-Mitarbeiter, was ein verzerrtes Bild erzeugt. Sie sollten auch für diesen "riskanten" Ring Verbündete aus den Fachbereichen suchen, die spezielle Fachanwendungen nutzen.

- Fast: Mit sechs bis zehn Tagen Verzögerung ab Release versorgt dieser Ring Computer ohne Spezialkonfigurationen sowie solche, die einem besonderen Angriffsrisiko ausgesetzt sind.

- Broad: Es ist der Ring für Ihren Massen-Rollout, wenn alle Spezialfälle durchgetestet und die Nutzergruppen mit Disruptionspotential benachrichtigt wurden. Dieser Ring ist in der Regel zehn bis vierzehn Tage gegenüber dem Release verzögert.

Die Verzögerungen zwischen den Ringen können Sie mithilfe von "Modern Workplace Update Policies" steuern, die Autopatch beim Enrollment Ihres Tenants automatisch für Sie konfiguriert. Auch lässt sich jeder Ring separat pausieren und wieder fortsetzen. Jede Policy entspricht per Default einer entsprechend benannten Sicherheitsgruppe, in die Sie Computer aufnehmen können, die für den jeweiligen Ring bestimmt sind. Sie können auch eigene Gruppen erstellen und den Autopatch-Policies zuweisen. Dies ist jedoch nicht empfohlen, denn Autopatch überprüft jede Stunde, ob nicht zufällig ein Gerät in mehreren Gruppen enthalten ist, und entfernt (zufällig) alle Mitgliedschaften bis auf eine, damit eine eindeutige Gerätezuordnung zu Update-Ringen gewährleistet ist.

Die User Experience bei Einsatz von Autopatch ähnelt der unter WUfB mit Telemetrie-Übermittlung: Das Gerät berücksichtigt die historisch ermittelten Arbeitszeiten des Nutzers und weist auf die nahende Deadline des jeweiligen Update-Ringes hin.

Um Autopatch für Ihre mit Intune gemanagten Endgeräte einzusetzen, stellen Sie zuerst sicher, dass alle Voraussetzungen [5] erfüllt sind. Die abschließende Prüfung liefert das "Readiness Assessment Tool", das Sie im "MEM Admin Center" (endpoint.microsoft.com) unter "Tenant Administration / Windows Autopatch / Tenant Enrollment" finden. Das Tool prüft Ihren Tenant und die bereits vorhandenen Endgeräte und liefert Warnungen, Fehler und Hinweise zu ihrer Behebung.

Anschließend müssen Sie im Tenant Ihr Einverständnis dafür geben, dass Microsoft auf bestimmte Telemetrie- und Zustandsdaten im Supportfall zugreifen kann. Außerdem müssen Sie zwei administrative Kontakte aus Ihrer Organisation benennen, jeweils mit E-Mail-Adresse und Telefonnummer. Die E-Mail-Adresse muss nicht aus der Exchange-Online-Organisation Ihres Tenants stammen – es kann sich dabei beispielsweise auch um einen von Ihnen beauftragten externen Dienstleister handeln. Achten Sie bei der Eingabe der Telefonnummer darauf, eine Leerstelle nach dem Ländercode einzufügen, damit das Portal Ihre Eingabe richtig als Telefonnummer erkennt.

Nach dem Tenant Enrollment, das je nach Auslastung des Dienstes durchaus bis zu einer Stunde in Anspruch nehmen kann, stehen Ihnen im Endpoint-Management-Portal die "Windows Autopatch"-Seiten zur Verfügung. Hier können Sie die Liste der erfassten Endgeräte einsehen, diese zwischen den Update-Ringen verschieben sowie neue Devices aus Ihrem Intune-Bestand zu Autopatch hinzufügen. Dies erledigen Sie durch die Aufnahme der entsprechenden Computerobjekte im Azure AD in die Gruppe "Windows Autopatch Device Registration".

Ein wichtiges Feature ist die separate Supportgruppe bei Microsoft, die sich um die Belange des Updatemanagements kümmert. Für die Kommunikation mit dieser finden Sie im Autopatch-Abschnitt des Portals die Möglichkeit, einen neuen Support-Request abzusetzen oder vorhandene Tickets zu verwalten. Die Kommunikation seitens Microsoft zu diesen Anfragen erfolgt an die von Ihnen hinterlegten Admin-Kontakte. Diesen können Sie jeweils in den Kategorien "Devices" und "Updates" das Recht zuweisen oder entziehen, Changes und Datenzugriff durch Microsoft freizugeben.

Da hier stets auch ein Zugriff auf die Telemetriedaten der betroffenen User notwendig ist, sollten Sie diese Vorgänge zusammen mit Ihrem Datenschutzverantwortlichen "durchspielen". Eine besondere Art einer Autopatch-Supportanfrage ist die Aufforderung, den Tenant von Autopatch abzumelden. Microsoft lässt sich diesen Wunsch noch einmal bestätigen und löscht anschließend die eigenen Zugriffsberechtigungen und die für Autopatch erhobenen Telemetriedaten. Gruppen, Richtlinien und natürlich Computerobjekte bleiben indes unverändert in der Konfiguration Ihres Tenants gespeichert.

Das zeitnahe und sichere Ausrollen von Funktions- und Sicherheitsupdates auf große Mengen von Clients beschäftigt Administratoren bereits seit Jahrzehnten. Da die Kompatibilität der Updates zu den vorhandenen Hard- und Softwarekonfigurationen nicht immer hundertprozentig gesichert ist, gibt es keinen Königsweg.

Microsoft bietet jedoch für klassisch gemanagte Clients mit Windows Update for Business und für modern gemanagte Endgeräte mit "Windows Autopatch" Verwaltungsansätze an, die eine schnelle Implementierung von Update-Ringen erlauben und so für einen geregelten Rollout mit Möglichkeit zum Anhalten sorgen. Bevor Sie die cloudbasierten Funktionen von WUfB oder das Autopatch-Feature in Ihrer Umgebung einsetzen, sprechen Sie unbedingt mit Ihrem Datenschutzverantwortlichen über den notwendigen Umfang der an Microsoft übermittelten Daten.