Kürzlich kam im deutschsprachigen DSM-Forum eine interessante Fragestellung auf, wie man denn in DSM bei Verwendung des Advanced Patch Managements mit den monatlichen Patches von Windows 10 umgehen könne. Die Diskussion ist unter http://forum.enteo.com/showthread.php?t=16367 nachzulesen.

Das dort angesprochene Problem besteht darin, dass wenn das APM nach Best Practices eingerichtet und betrieben wird, es passieren kann, dass ein neu zu installierender Rechner, keinerlei Windows 10 Patches erhält und daher völlig ungepatcht in die Produktion übergeben wird. Ein Zustand, den man natürlich tunlichst vermeiden sollte. Die Gründe, dass es zu diesem Problem kommen kann, sind in einer Kombination verschiedener Einstellungen und Randbedingungen zu suchen...

Der erste Aspekt ist, dass es für das Advanced Patch Management eine Konfigurationstabellen-Einstellung gibt, die es erlaubt, bereits ersetzte Patches (sogenannte Superseded Patches) im Scan-Ergebnis auszulassen. Dies ist eigentlich eine sinnvolle und naheliegende Einstellung, die zwar standardmäßig auf "Nein" steht, die ich aber in der Vergangenheit immer auf "Ja" geändert habe, um nur aktuelle Patches als fehlend zu ermitteln. Damit wird die Anzahl der zu installierenden Patch-Pakete minimiert, was das zu übertragende Datenvolumen auf den Client verringert, Plattenplatz im Repository-Cache spart und natürlich die für die Patch-Installation benötigte Zeit drastisch reduziert.

Der nächste zu betrachtende Aspekt ist, dass es durchaus gängig und auch ungeschriebenen Best Practices entspricht, wenn neue Patches nicht direkt produktiven Clients aktiv zugewiesen werden. Die Idee ist, dass ein gestaffelter Rollout implementiert wird, wobei über Rollout-Regeln neue Patches zunächst Test- oder Pilotgruppen aktiv zugewiesen werden und die Zuweisung auf Produktionssysteme mit einem Versatz auf die Aktivierung von einigen Tagen oder Wochen erfolgt.

Der dritte relevante Punkt ist, dass die monatlich erscheinenden Windows 10 Patches kumulativ sind, das heißt ein neuerer Patch ersetzt alle in der Vergangenheit veröffentlichten Patches. Beispielsweise ersetzt der Windows 10 Patch KB3163018 vom Juni 2016 den Patch KB3156421 vom Mai 2016 und dieser wiederum den April 2016 Patch KB3147458 und so weiter. Es gibt daher immer nur einen Windows 10 Patch, der nicht bereits veraltet beziehungsweise superseded ist.

Die Kombination dieser drei Aspekte führt nun dazu, dass kurz nachdem ein neuer Windows 10 Kumu-Patch veröffentlicht und in den APM Patchkatalog aufgenommen wurde und ein Client mit diesem Katalog nach Sicherheitslücken scannt, dieser neueste Windows 10 Patch als fehlend gemeldet wird (da ja alle älteren Windows 10 Patches durch diesen ersetzt sind). Der Patch Management Service lädt dann diesen Patch herunter, erstellt ein Patch-Paket daraus und weist es gemäß den Rollout-Regeln zu. Das Aktivierungs-Startdatum der Patch-Policy für die Produktionssysteme liegt aber noch einige Zeit in der Zukunft.

Wird nun ein neuer Windows 10 Produktionsclient installiert, so hat er nur eine Windows 10 Patch-Policyinstanz die auf diesen aktuellen Kumu-Patch referenziert, das Aktivierungs-Startdatum aber noch nicht erreicht hat. Dadurch wird der Patch zum jetzigen Zeitpunkt (richtigerweise) noch nicht installiert. Da die bisherigen Windows 10 Patches, da sie ja ersetzt wurden, garnicht als fehlend gemeldet werden, werden für diese – obwohl aktive Patch-Policies existieren – keine Patch-Policyinstanzen angelegt, sodass in der Konsequenz zum jetzigen Zeitpunkt garkein Windows 10 Patch installiert wird und der Client damit komplett ungepatcht bleibt.

Der einzig mögliche Ansatz zum jetzigen Zeitpunkt besteht darin, dass in der Konfigurationstabelle die Einstellung "Patches, die durch neuere ersetzt wurden, im Scan-Ergebnis auslassen" wieder auf den Standardwert "Nein" zurückgesetzt wird. Dadurch werden auch die älteren und bereits ersetzten Patches wieder als fehlend gemeldet und entsprechend werden Patch-Policyinstanzen für die zugehörigen Patch-Policies erzeugt. Da diese bereits seit längerer Zeit existieren, wurde deren Aktivierungs-Startdatum bereit erreicht und die Patches somit installiert. Wie oben beschrieben, führt das natürlich dazu, dass dann alle alten Patches installiert werden, mit den genannten negativen Konsequenzen, aber immerhin ist das Ergebnis ein gepatchter und sicherer Client.

Um die Installationszeit und die Datenmenge zu reduzieren und den unerwünschten Effekten entgegenzuwirken, bietet es sich an, in der Art einzugreifen, dass der Rollout von ersetzten Patches, die nicht installiert werden sollen, manuell gestoppt, deren Patch-Policy also auf inaktiv gesetzt wird. Dies ist sicherlich ein ungewollter manueller Aufwand, der dazu betrieben werden muss, allerdings haben meiner Ansicht nach in der Abwägung der Vor- und Nachteile die Vorteile ganz klar das Übergewicht, sodass diese Maßnahmen zum jetzigen Zeitpunkt auf jeden Fall von uns empfohlen werden.

Das bisher Gesagte betrifft im übrigen nicht nur das Advanced Patch Management, sondern auch das neue Modul PatchLink. Dort verschärft sich sich die Problematik aber noch mehr, da es dort die Einstellung, ob superseded Patches im Scan-Ergebnis enthalten sind oder nicht, garnicht mehr gibt. Ersetzte Patches werden per Definition nicht an den Server gemeldet. Es beseht daher zum jetzigen Zeitpunkt unserer Wissens nach keine Möglichkeit dafür zu sorgen, dass die bisher aktiven Kumu-Patches installiert werden. Die einzige Möglichkeit überhaupt gepatchte Systeme neu aufzusetzen besteht darin, das Aktivierungs-Startdatum der Patch-Policies solcher Patches nach vorne auf den aktuellen Zeitpunkt vorzusetzen.

Das Problem betrifft im Übrigen nicht nur Windows 10 Patches, sondern alle Produkte, die mit kumulativen Patches arbeiten wie den Adobe Reader oder die immer vollständige Builds veröffentlichten wie Google Chrome, 7-Zip oder viele andere. Es ist daher einerseits deutlich kritischer zu betrachten als wenn es "nur" Windows 10 betreffen würde, auch weil bisher vermutlich die wenigsten Geschäftskunden Windows 10 im großen Stil ausgerollt haben. Andererseits steigt der erforderliche manuelle Aufwand, wirklich veraltete Patch-Policies zu deaktiveren dadurch massiv an und ist in größeren Umgebungen kaum mehr zu vertreten.

In einem folgenden Blog-Artikel werde ich einen PSX-basierten Lösungsansatz vorstellen, der die beschriebene manuelle Arbeit versucht zu automatisieren. Dies ist zwar nur für APM-basierte Umgebungen möglich, da zum jetzigen Zeitpunkt die meisten Kunden aber die Migration auf PatchLink noch nicht vollzogen haben, ist dies für viele Umgebungen aber sicher eine interessante Option.