Das Altgerät meldet sich auch

Ein Rollout gilt in vielen Werkzeugen als erledigt, sobald das Verteilwerkzeug Erfolg meldet. Das Paket ist raus, der Auftrag steht auf grün, die Liste wird kürzer. Ob die Software auf dem Gerät tatsächlich läuft, hat damit niemand geprüft. Das Verteilwerkzeug bestätigt sich an dieser Stelle selbst.

Im Rollout-Modul liegen deshalb zwei Statuswerte nebeneinander, die oft für dasselbe gehalten werden. Erledigt setzt der Techniker, wenn er fertig ist. Verifiziert setzt das System, wenn es den Zustand nachgeprüft hat. Der erste Wert ist eine Aussage, der zweite ein Nachweis.

Geprüft wird gegen Daten, die ohnehin da sind

Die Erfolgskontrolle braucht keine eigene Datenquelle. Sie greift auf die Konnektoren zu, die im System bereits laufen: ACMP, baramundi, Intune, Wazuh, PRTG, macmon und AssetPanda. Vier Kriterien lassen sich je Rollout aktivieren.

• Kontakt in Tagen. Hat sich das Gerät nach der Ausbringung innerhalb der Frist bei einem Konnektor gemeldet?
• Betriebssystem enthält. Steht am IT-System das erwartete Betriebssystem, zum Beispiel „Windows 11"?
• Software installiert. Ist die erwartete Software für diesen Host in der Softwareerfassung hinterlegt?
• Intune-Compliance. Meldet Intune das Gerät als konform?

Der Fehler, den eine naive Prüfung macht

Beim Kontakt-Kriterium zählt ausschließlich ein Kontakt nach dem Abschluss des Zielobjekts. Das klingt nach einer Feinheit, ist aber der Unterschied zwischen Prüfung und Selbsttäuschung. Beim Notebook-Tausch stand am Arbeitsplatz vorher schon ein Gerät, und dieses Altgerät hat sich wochenlang zuverlässig bei jedem Konnektor gemeldet. Wer nur fragt, ob es Kontakt gab, findet ihn immer und winkt jedes Ziel durch. Geprüft wird deshalb gegen den Abschlusszeitpunkt, nicht gegen ein Zeitfenster.

Zwei Asymmetrien mit Absicht

Im Modus Automatisch hebt ein nächtlicher Lauf erledigte Ziele, die alle Kriterien bestehen, selbsttätig auf Verifiziert. Ein Fehlschlag setzt dagegen nie zurück. Das ist bewusst unsymmetrisch: Ein Konnektor, der zwei Tage keine Daten liefert, würde sonst reihenweise korrekt verifizierte Ziele wieder entwerten. Am Ende stünde das Ergebnis der Prüfinfrastruktur da, nicht das des Rollouts.

Die zweite Asymmetrie betrifft die fehlende Datenbasis. Ist ein Kriterium nicht prüfbar, etwa weil das Lizenzmanagement-Modul nicht aktiv ist, lässt es die Prüfung nicht scheitern. Sind alle Kriterien nicht prüfbar, gilt das Ziel deswegen aber nicht als bestanden. Das Ergebnis bleibt „nicht prüfbar", und automatisch verifiziert wird ein solches Ziel nie. Nicht prüfbar ist kein Bestanden. Geprüft werden ohnehin nur IT-System-Ziele, denn Personen, Räume und Standorte haben keinen technischen Zustand.

Was das Modul nicht tut

Es verteilt nicht. Pakete und Images bleiben Sache des Client-Managements. Das Rollout-Modul plant die Ausbringung in Wellen, führt jedes Zielobjekt mit eigenem Status und Termin, protokolliert die Übergabe vor Ort und prüft hinterher das Ergebnis. In der ITIL-Kette ist das Deployment-Management, direkt hinter Change und Release.

Der Fortschritt rechnet entsprechend nüchtern. Er zählt erledigte und verifizierte Ziele. Bewusst ausgenommene Ziele werden als Übersprungen markiert und zählen weder im Zähler noch in der Grundgesamtheit. Ein Rollout mit zehn Zielen, davon zwei übersprungen und acht erledigt, steht auf hundert Prozent. Nicht weil gerundet wurde, sondern weil nachvollziehbar bleibt, warum die Zielmenge kleiner geworden ist.

Mehr auf der Modulseite zum Rollout-Management.