Nicht sauber, sondern unbekannt

Patch-Berichte sind erstaunlich beruhigend. Achtundneunzig Prozent grün, zwei Prozent offen, eine Liste zum Abarbeiten. Die Zahl beantwortet aber nicht die Frage, die dahinter steht: Wie viele Geräte sind in diesen achtundneunzig Prozent, weil sie tatsächlich gepatcht sind, und wie viele, weil sie nie gefragt wurden?

Ein Gerät, das seit sechs Wochen nichts gemeldet hat, erscheint in den meisten Auswertungen nicht als Problem. Es erscheint gar nicht.

Drei Zustände, nicht zwei

Deshalb führt das Modul den Patchstand nicht als Ja-Nein-Frage, sondern kennt drei Antworten: Update installiert, Update fehlt, nie erhoben. Der dritte Zustand hat ein eigenes Feld mit dem Zeitpunkt der letzten Erhebung. Steht dort nichts, heißt das nicht „in Ordnung", sondern „unbekannt".

Im Code steht der Satz, der den Unterschied trägt: Ein Gerät ohne Erhebung ist nicht sauber, sondern unbekannt. Das klingt nach einer Kleinigkeit. Es entscheidet darüber, ob eine Kennzahl eine Aussage ist oder eine Beruhigung.

Die Erhebung selbst läuft nur lesend, als gewöhnlicher zeitgesteuerter Lauf, nicht über den signierten Auftragskanal, über den alle verändernden Aktionen gehen. Sie ändert nichts, also braucht sie weder Signatur noch Freigabe. Dazu kommt ein Betriebsargument: Jeder Agent hat nur wenige Plätze für offene Aufträge, und ein reiner Erhebungsauftrag hätte einen davon belegt.

Zwei Listen, die sich unterschiedlich verhalten

Der Katalog der bekannten Updates wird fortgeschrieben, der Bestand je Gerät wird ersetzt. Der Grund: Ein fehlendes Update verschwindet aus der Meldung, sobald es installiert ist, unabhängig davon, wer es installiert hat. Der Benutzer klickt selbst auf Windows Update, ein Administrator fährt von Hand ein Upgrade, ein anderes Werkzeug greift ein. In keinem dieser Fälle bekommt die Plattform ein Ereignis. Würde der Bestand nur ergänzt, bliebe die alte Zeile stehen und das Gerät sähe für immer ungepatcht aus.

Umgekehrt darf der Katalog nicht bei jedem Lauf schrumpfen: Ein Zyklus, in dem zufällig kein Gerät ein bestimmtes Update meldet, dürfte keine dauerhafte Entscheidung mitreißen.

Und diese Entscheidungen stehen woanders

Welche Updates ausgebracht werden dürfen, steht bewusst nicht am Katalog, sondern in einer eigenen Tabelle. Der Katalog wird bei jedem Scan maschinell fortgeschrieben, die Freigaben schreiben ausschließlich Menschen. Ein zu breit geratener Schreibvorgang, und eine dauerhafte Ausschlussentscheidung wäre weg, ohne dass es jemand merkt.

Dieselbe Trennung trägt die Nachweisführung. Der Katalog wird nicht revisionssicher protokolliert, denn ein maschineller Befund ist kein Nachweis und ein Eintrag je Scan wäre eine Flut. Die Freigaben schon. Nachweisbar sein muss die menschliche Entscheidung: dass ein Update im März bewusst ausgeschlossen wurde, mit Begründung und mit Namen.

Wann eine Freigabe gilt

Geprüft wird sie nicht beim Planen des Rollouts, sondern jedes Mal beim Bauen eines Auftrags. Der Unterschied wird an einem Vormittag sichtbar: Eine um neun Uhr zurückgezogene Freigabe ist wenige Minuten später aus jedem Auftrag draußen. Würde beim Planen geprüft, lieferte ein am Montag eingereichter Rollout am Freitag noch Updates aus, die am Mittwoch ausgeschlossen wurden.

Zwei Bremsen vor jeder Ausbringung

Software-Verteilung ist das mächtigste Werkzeug im Clientbetrieb, und deshalb das gefährlichste: Ein fehlerhaftes Paket wäre ohne Bremse binnen eines Abfragezyklus auf der ganzen Flotte. Also läuft ein Rollout in Ringen, jeder mit Reifezeit und Abbruchschwelle, der nächste startet erst, wenn der vorige beides übersteht. Dazu Wartungsfenster, außerhalb derer schlicht kein Auftrag entsteht.

Am Ende landet der Patchrückstand als Zahl am IT-System, damit sich Regeln wie „Rückstand über dreißig Tage" ohne Sonderweg formulieren lassen. Mit der Einschränkung, die im Code gleich danebensteht: Diese Zahl ist eine Anzeige, keine Wahrheit.

Mehr auf der Modulseite Client Management.