Es gibt diesen einen Moment in fast jedem PVS-Projekt. Ein Worker bootet nicht sauber, eine Policy greift nicht, und der Admin starrt auf ein Image, in das über die Jahre alles Mögliche hineingewandert ist. Niemand weiß mehr genau, warum dieser eine Dienst noch läuft oder wer damals diesen Registry-Key gesetzt hat.
Willkommen beim Thema Hygiene des Master Targets — dem vielleicht unterschätztesten Erfolgsfaktor im Provisioning.
Das Master Target ist eine Vorlage, kein Endgerät
Der häufigste Denkfehler: Man behandelt das Master Target wie einen normalen Server, den man eben ordentlich einrichtet. Aber das Master Target ist keine produktive Maschine. Es ist die Gussform, aus der alle Worker entstehen.
Und genau hier liegt der Kern des Provisioning-Modells: Ein schlankes, gemeinsames Image wird an viele Targets gestreamt. Die individuelle Konfiguration — vor allem die Gruppenrichtlinien — kommt erst beim Boot des jeweiligen Workers frisch über die normale GPO-Verarbeitung. Nicht aus dem eingefrorenen Image.
Das ist keine Nebensächlichkeit. Das ist das Fundament.
Gruppenrichtlinien gehören nicht ins Image
Wenn man Policies ins Master Target einbäckt, fängt man sich genau die Probleme ein, die später so schwer zu finden sind:
- Beim Worker-Boot entsteht ein unklarer Zustand. Werden die eingebackenen Policies mitgenommen? Überschrieben? Sauber überschrieben? Es entsteht ein Konflikt zwischen dem eingefrorenen Image-Stand und der frischen GPO-Verarbeitung.
- Ändern sich die Policies später im AD, driftet das Image auseinander. Der Image-Stand sagt das eine, die aktuelle GPO-Vorgabe das andere — ein instabiler, schwer diagnostizierbarer Zustand.
Die saubere Regel lautet deshalb: Das Master Target soll policy-arm sein. Idealerweise greift nur die Default Domain Policy. Dann ist die GPO-Verarbeitung beim Worker-Boot die einzige, klare Quelle der Wahrheit. Kein Drift, kein Rätselraten.
Hygiene heißt: Wissen, was im Image ist
Ein sauberes Master Target erkennt man nicht daran, dass es funktioniert — viele dreckige Images funktionieren auch. Man erkennt es daran, dass man erklären kann, warum jeder Bestandteil drin ist.
Drei Dinge, die man im Griff haben sollte:
Updates vor dem Versiegeln deaktivieren. Wenn der Imaging-Prozess den Zustand per VSS einfriert und im Hintergrund läuft noch ein Windows Update oder ein Agent-Self-Update, friert man einen halbfertigen Zustand ein. Updates also vorher aus, danach wieder an (das ist das Un-Sealing).
Pending Reboots ernst nehmen. Ein ausstehender Neustart, der ins Image wandert, ist eine Zeitbombe. Jeder Worker erbt den unfertigen Zustand. Ein zwingender Reboot vor dem Imaging ist hier keine Schikane, sondern Selbstschutz.
Telemetrie-Hygiene nicht vergessen. Ein gutes Beispiel ist CrowdStrike: Setzt man den Sensor nicht korrekt auf, taucht in der Falcon-Console nach dem Rollout plötzlich hundertmal derselbe Hostname auf — der des Masters. Kein Boot-Problem, aber ein klassisches Symptom eines unsauber versiegelten Images.
Der Lohn der sauberen Form
Ein gepflegtes Master Target zahlt sich nicht heute aus, sondern in sechs Monaten — wenn ein Worker zickt und man die Ursache in Minuten statt in Stunden findet, weil das Image keine Überraschungen birgt.
Hygiene am Master Target ist keine Pflichtübung für Perfektionisten. Es ist der Unterschied zwischen einer Farm, die man versteht, und einer, die man nur noch verwaltet.
PVS Forge automatisiert genau diese Disziplin: Pending-Reboot-Erkennung, Update-Deaktivierung vor dem Versiegeln und sauberes Un-Sealing danach — damit jedes Image so schlank und nachvollziehbar bleibt, wie es sein sollte.