Login

Blog

Hier blogge ich über Themen, die mich - und vielleicht auch andere - interessieren (könnten)

Anzahl der in einem Durchlauf installierten Patches begrenzen

Immer noch erfreut sich Windows 7 im Business-Bereich großer Beliebtheit. Um das in die Tage gekommene Client-Betriebssystem auf einen aktuellen Stand zu bringen, müssen jedoch zahlreiche Patches nachinstalliert werden, da das letzte offiziell von Microsoft verfügbare Image Windows 7 mit integriertem Service Pack 1 mittlerweile sechs Jahre "auf dem Buckel" hat. Zwar hat Microsoft im letzten Oktober die Patch-Strategie an den Windows 10 Mechanismus angepasst, sodass es seitdem nur noch kumulative monatliche Updates gibt, trotzdem ist die Zahl der nachzuinstallierenden Patch-Pakete auf einer "nackten" Windows 7 SP1 Installation exorbitant.

b2ap3_thumbnail_Windows-Update-nach-Windows-7-Installation.png

 

Wird also ein Original Microsoft-Image für die Grundinstallation von Rechnern verwendet, so führt dies zu extrem langen Installations-Zeiten. Daher sind mittlerweile Maßnahmen, ein benutzerdefiniertes Windows 7 Referenz-Image zu erstellen und für die Betriebssystem-Installation zu verwenden, nicht mehr – wie früher – optional, sondern beinahe "Pflicht geworden".

Mit DSM 2015.2 wurde daher ein neues Feature eingeführt, das genau diese Anforderung adressierte. Dazu prüfte der Installer vor der Ausführung eines Patch-Pakets die Menge des zur Verfügung stehenden virtuellen Speichers und wenn diese unter eine konfigurierbare Untergrenze fiel, wurde die Installation nicht ausgeführt und stattdessen ein Neustart eingeleitet. Nach dem Neustart wurde dann die Ausführung des Patch Management Execution Pakets fortgesetzt und die ausstehenden Patches installiert.

In den Release Notes von DSM 2015.2 war dazu folgender Passus zu finden:

b2ap3_thumbnail_DSM2015.2-Release-Notes.png

 

Leider ist dieser Abschnitt mittlerweile ohne Ankündigung wieder aus der Dokumentation verschwunden und eine interne Nachfrage ergab, dass dieser Registry-Eintrag mit DSM 2016.1 und höher nicht mehr ausgewertet wird und daher auch nicht mehr funktioniert.

Erfreulicherweise gibt es eine neue Möglichkeit, die Anforderung umzusetzen, die aber meines Wissens bis dato noch nirgends offiziell dokumentiert wurde. Der neue Registry-Wert muss als DWord-Value "MaxPatchCount" im Schlüssel "HKLM\SOFTWARE<\Wow6432Node>\NetSupport\PatchManagement" angelegt werden. Wie der Name des Values impliziert, gibt er an, wieviel Patch-Pakete innerhalb einer Installer-Session installiert werden dürfen. 

Im Installer-Log ist daher nachzuvollziehen wie vor jedem Patch-Paket geprüft wird, wieviele Patches bereits ausgeführt wurden (im Beispiel wurde der Value auf den Wert 50 gesetzt):

xniSPD.DLL: MaxPatchCount in one installer run is overwritten in registry to value 50

Wird diese Zahl überschritten, so wird folgendes protokolliert:

xniSPD.DLL: -----------------------------------------------------------------------------
xniSPD.DLL: Requesting session termination after 50 Microsoft patches have been installed
xniSPD.DLL: This feature is only activate on Windows Vista and Windows 7 systems with the RAM size less than 4 GiB and can be configured in registry
xniSPD.DLL: by setting the DWORD value MaxPatchCount under SOFTWARE\NetSupport\PatchManagement.
xniSPD.DLL: -----------------------------------------------------------------------------
System restart requested
Current request session termination flags: 'REBOOT|END_INSTALLER_SESSION'

Man sieht, wie festgestellt wird, dass die maximale Anzahl der in einem Durchlauf installierbaren Patches erreicht wurde, die aktuellen Installer-Session beendet und ein Neustart eingeleitet wird.

Wie ebenfalls zu sehen, wirkt diese Einstellung nur für Windows Vista und Windows 7 Systeme und auch nur dann, wenn weniger als 4 GB RAM verfügbar sind. Dies stellt aber insofern kein Problem dar, da Windows 8.1 ohnehin keine große Verbreitung hatte und Windows 10 von Anfang an nur mit kumulativen Patches gearbeitet hat, sodass nach der Betriebssystem-Installation in aller Regel nur ein Patch installiert werden muss, um das System auf den aktuellen Stand zu bringen.

 

 

Mit DSM 2015.2 wurde daher ein neues Feature eingeführt, das genau diese Anforderung adressierte. Dazu prüfte der Installer vor der Ausführung eines Patch-Pakets die Menge des zur Verfügung stehenden virtuellen Speichers und wenn diese unter eine konfigurierbare Untergrenze fiel, wurde die Installation nicht ausgeführt und stattdessen ein Neustart eingeleitet. Nach dem Neustart wurde dann die Ausführung des Patch Management Execution Pakets fortgesetzt und die ausstehenden Patches installiert.

 

 

 

Zugriff von APM/PL/WSUS-Clients auf Updates aus de...
User Centric Management in DSM

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Sunday, 08 December 2019

Captcha Image