FAQ: Updates werden nicht gefunden

Uns erreichen immer wieder Anfragen zum Thema ‘Windows Updates’ werden nicht gefunden. Hier soll erklärt werden, welche Schnittstelle die River dazu nutzt und was bei einem Patchlauf genau passiert.

Hinweis: Über die River können weiterhin keine folgenden Updates bezogen werden:

• Kumulative Updates für Exchange (CU’s für Exchange können mit einer Neuinstallation gleichgesetzt werden)
• Vorschau Updates (sorgen u.U. dafür, dass Gerät nicht mehr nutzbar sind, weil solche Updates gar nicht fertig sind)

Schnittstellen: #

• DCAT (wird von Drittanbietern verwendet, um z.B. Treiber über Windows Updates zur Verfügung zu stellen)

Treiber fallen hier drunter

• Microsoft Services (wird von der River verwendet, um die Patches von MS abfragen zu können)

Über Metadaten werden Vorschau Updates durch Microsoft speziell als BETA oder PreRelease gekennzeichnet.

Gefunden werden Updates, die mit einem Release gekennzeichnet und offiziell freigegeben sind. Da solche BETA oder PreReleases irgendwann nach 3-4 Monaten freigegeben werden, werden diese dann mit kommenden Updates mit installiert.

BETA Updates können auch nach 3-4 Monaten erst als Release gekennzeichnet sein, wenn dieses noch nicht fertig ist.

Patchlauf: #

Hinweis: https://riverbird.de/help/voraussetzungen-patchmanagement/ erklärt, welche Voraussetzungen erfüllt sein müssen, damit die River erfolgreich Updates finden und dann einspielen kann.

Wie läuft ein Patchlauf im Detail ab?

Riverbird RMM Agent:

• Ermittelt beim Start, ob eine Patchrichtlinie gesetzt ist
• Gibt es eine Patchrichtlinie, werden über die DB die Einstellungen (Policy) dazu geladen
• • Globale Einstellungen, Zeitplanung, Schweregrade für die Kategorien,
  • Aktionen für die Schweregrade, Ausnahmeregeln, Registry-Keys
  • Neustart des Geräts nach Installation der Patches
• Ruft Metadaten zu Updates von MS über deren WSUS ab
• Validiert die abgerufenen Metadaten über die Einstellungen
• Lädt entsprechende Patches herunter , installiert diese und schreibt Historieneinträge in die DB
• Setzt Registry-Keys erneut, um Patches ohne Kontrolle aus der River heraus nicht automatisch installieren zu können
• Führt lokale Inventarisierung durch

Abhilfe: #

Überprüfen der Datei C:\Windows\SoftwareDistribution\ReportingEvents.log

Hier stehen die Aktionen, die bei der Installation von Patches durchgeführt wurden. Dabei können auch die HRESULT Fehler eingetragen sein.

Über den folgenden Link können solche HRESULT Fehler nachgelesen werden.

https://docs.microsoft.com/de-de/windows/deployment/update/windows-update-error-reference

In den meisten Fällen kann ein Zurücksetzen des Windows Update Cache helfen

Windows: Update Cache zurücksetzen

Weitere Hinweise:

Die River bezieht die Metadaten von Updates über die von Microsoft entwickelte API. Diese bezieht Updates über den angegebenen Microsoft Update Service. Microsoft markiert intern diese Updates für diese API nochmals mit speziellen Parametern. Sofern diese auf den Status ‘Optional’ sind, hat die River keine Möglichkeit, diese Updates zu empfangen.

In der Regel, wird dieser Status nach einigen Tagen, jedoch spätestens nach 1-2 Wochen von Microsoft aufgehoben. Es kann jedoch sein, dass es spezielle Updates gibt, die manuell nochmals nachinstalliert werden müssen.

Hier gibt es Konstellationen, bei denen CU Updates (Cumulative Updates) irgendeine Vorinstallation eines vorhergehenden Updates voraussetzen, welche das Gerät bisher nicht hat. Damit wird die Metadatenabfrage gefiltert und das CU wird ebenfalls nicht mit ausgelesen, da es eventuell die Voraussetzungen nicht erfüllt, dieses Update zu installieren.

Hier ist zu beachten, sofern zu einem aktuellen Zeitpunkt Updates gepusht werden, immer noch die Asynchronität zwischen dem Betriebssystem und der aktuellen Datenbank besteht, da der Agent in einem Zeitintervall von 3 Stunden inventarisiert.