Es besteht meiner Erfahrung nach große Unsicherheit, wie man Windows bei Verwendung von Advanced Patch Management (APM) oder PatchLink (PL) konfigurieren soll, damit es nicht auf die Idee kommt, auf den Microsoft Servern selbständig nach Updates zu suchen, diese herunterzuladen und – insbesondere unter Windows 10 – zu einem völlig willkürlichen Zeitpunkt zu installieren. 

Die empfohlenen Einstellungen waren auch schon das ein oder andere mal Thema im DSM Forum, beispielsweise in diesem oder diesem Thread.

Während man bei Windows 7 und Windows 8.1 noch einfach über Gruppenrichtlinien den ungewollten Zugriff auf die Microsoft Upate Server unterbinden kann, stellt sich die Sache bei Windows 10 – auch für Clients, die für die Verwendung eines internen WSUS-Servers konfiguriert sind – etwas anders dar...

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...

Mit DSM 2014 wurden erstmals die Begriffe "Patch Kategorien" und "Patch Rollout Rules" eingeführt. Um diese neuen Konzepte zu verstehen, ist ersteinmal einiges herumprobieren notwendig. Der folgende Designvorschlag soll den Einstieg in dieses mittlerweile komplexe Thema erleichtern. Es wird folgend ausschliesslich auf die Konfiguration dieser neuen Features eingegangen. Für die vollständige Konfiguration von APM im jeweiligen DSM Umfeld müssen noch diverse weitere Dinge (Installationsreihenfolge von Patchen in Bezug auf Softwarepakete, Definition der Patchziele, Rolloutzyklen, Zusammenarbeit mit WSUS, etc.) betrachtet werden.

Ein Kunde von uns hatte die Anforderung, dass die Patches von Microsoft im späteren Workflow anders behandelt werden sollten als die Patches von Drittanbietern. Vereinfacht dargestellt sollten erstere auf eine Gruppe und die der Drittanbieter auf eine andere Computergruppe zugewiesen werden.

Der Patch Management Dienst ist so konfiguriert, dass alle Patches einer statischen Computergruppe namens "DownloadOnly" zugewiesen werden, die allerdings keine Computer enthält. Von da aus werden sie mittels Targetlistenerweiterung weiter an die Gruppen "Microsoft" bzw. "ThirdParty" verteilt.

Die Pilotgruppen sind hier ausser acht gelassen, es geht um die grundsätzliche Logik.

Während des Imports von Patches lädt der Patch Management Dienst die Patches herunter und entpackt diese in den temporärer Ordner "SPDTemp". Dieses Verzeichnis liegt standardmäßig im Verzeichnis "%CommonProgramFiles%\enteo", welches über die Infrastruktureinstellung "Directory on the computer for runtime data" (Site Einstellung) konfigurierbar ist.

Seit DSM 7.2.1 gibt es ja neben dem normalen Patch Management, das im Wesentlichen die Funktionalität bietet, die die Windows Server Update Services (besser bekannt als WSUS) auch bereitstellen, die erweiterte Variante des Avanced Patch Managements (APM).

Hauptmerkmal des APM ist, dass neben den üblichen Microsoft Produkten, die auch durch den WSUS mit Patches versorgt werden würden, eine große Anzahl von Dritthersteller-Produkten gepatcht werden kann. Fragt man jedoch, welche Produkte (oder zumindest wieviele) denn sonst noch mit Patchen versorgt werden können, erhält man oft ungenaue oder zum Teil sogar sich widersprechende Aussagen.

Da es sich beim APM um eine OEM-Version des Produkts "Shavlik Protect" handelt, kann man auf die Angaben des Herstellers zurückgreifen – sofern man diese findet...