Voraussetzungen Patchmanagement

Bevor das Patchmanagement der River aktiviert wird, sollten folgende Voraussetzungen geprüft und umgesetzt werden. Das gilt besonders dann, wenn vorher bereits ein anderes Patchmanagement eingesetzt wurde.

WICHTIG: Support kann nur auf das jeweilig aktuelle Release, oder das des Vorläufers gewährt werden. Der Grund sind Bugfixes in den Releases.

• Gibt es ein anderes Patchmanagement, das bisher eingesetzt wurde?

Ein Parallelbetrieb zweier verschiedener Patchmanagement Produkte führt unweigerlich zu unvorhersehbaren Schwierigkeiten. Agents und Einstellungen müssen daher entfernt werden. Auch sollte ggf. der Windows Update Cache zurückgesetzt werden.

=> https://riverbird.de/help/windows-update-cache-zuruecksetzen <=

• Sind GPO’s aktiv, die das Windows Update beeinflussen?

Diese müssen zuerst zurückgenommen und dann ausgeschaltet werden. (Es nützt nichts, diese GPO’s einfach abzuschalten. Dabei bleiben evtl. Registry Keys aktiv)

• Gibt es zusätzliche Registry Keys, außer den beiden hier genannten? (diese Registry Keys werden durch den Riverbird RMM Agent eingetragen, wenn das Patchmanagement aktiviert wurde)

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

WUServer (REG_SZ) = http://localhost

Abb. 1

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

NoAutoUpdate (REG_DWORD) = 1

Abb .2

Hinweis: Diese beiden Subkeys werden vom Agent dann gesetzt, wenn in der River eine aktive Patchrichtlinie existiert, die das jeweilige Gerät beinhaltet. Beide Subkeys werden bei jedem Neustart des Agents (also im Abstand von 3 Stunden) erneut gesetzt. Sollten diese also verschwinden, sind sie nach spätestens 3 Stunden wieder da.

Wichtig: Es gibt Updates, die in mehr als einer Kategorie gelistet sind. Alle Kategorien müssen auf ‘Zulassen’ stehen, damit ein Update installiert wird.

• Überprüfungen (Ports und Firewall)

Sind die Zielgeräte mit dem Netzwerk verbunden und kann über RPC- und TCP/IP-Ports mit diesen kommuniziert werden?

Grundsätzlich müssen die Ports 135 und 445 zwischen dem Server und den Clients geöffnet werden, damit eine RPC Kommunikation stattfinden kann. In vereinzelten Fällen ist hierfür auch noch Port 137 und 139 notwendig. Mit einem Tool, wie z.B. Telnet kann geprüft werden, ob die Verbindung über die Ports 135, 139 und 445 auf die Zielgeräte herzustellen sind.

Lokale Firewall Einstellungen auf dem Zielgerät, können die Kommunikation zwischen Server und den Clients unterbinden. Die o.g. Ports müssen daher auf der lokalen Firewall (eingehende/ausgehende Regeln) geöffnet sein.