Wenn man neue Admins an PVS oder MCS heranführt, gibt es einen Satz, nach dem plötzlich vieles Sinn ergibt — und nach dem man einen ganz bestimmten Fehler nie wieder macht.
Die Regel ist denkbar einfach:
Wenn ein nicht persistentes VDI-System startet, darf im Hintergrund absolut nichts automatisch aktualisiert werden — egal welche Software es ist.
Vor dem Imaging gilt dasselbe in der anderen Richtung: Alle Auto-Updater müssen aus sein, bevor die vDisk versiegelt wird. Klingt banal. Ist es nicht — denn die Quittung für einen Verstoß kommt nicht immer sofort und nicht immer in derselben Form.
Das offensichtliche Symptom: Black Screen at Logon
Der Anruf kommt meist morgens. Die Worker booten, der Benutzer meldet sich an — und dann: schwarz. Kein Desktop, kein Fehler, einfach nichts. Manchmal kommt der Desktop nach einer gefühlten Ewigkeit, manchmal gar nicht.
Die erste Reaktion ist fast immer, an den üblichen Verdächtigen zu schrauben: Profile, FSLogix, irgendein VDA-Registry-Wert. Und ja, dafür gibt es auch legitime Ursachen. Aber überraschend oft ist die wahre Ursache viel simpler und liegt ganz woanders: Im Hintergrund läuft ein Auto-Updater los, genau während sich der Benutzer anmeldet — und würgt den Logon ab, weil er im falschen Moment um CPU, Disk und Write Cache konkurriert.
Das ist self-inflicted, hausgemacht. Und es ist vermeidbar.
Das tückische Symptom: der Einbruch mitten im Betrieb
Hier liegt der eigentlich gemeine Teil — und der Grund, warum die Regel so wichtig ist: Nicht jeder Updater startet beim Boot. Das Black-Screen-Szenario ist nur das offensichtliche Beispiel.
VDAs laufen in der Praxis oft eine bis vier Wochen am Stück durch. Und man weiß nie, wann ein bestimmter Updater loslegt. Adobe zum Beispiel triggert sein Update irgendwann mitten in der Laufzeit — Tag drei, Tag elf, völlig unvorhersehbar. Plötzlich werden im Hintergrund Aktualisierungen heruntergeladen und installiert, ganz ohne Reboot, ohne dass jemand etwas angestoßen hätte.
Und dann passiert das hier:
- Mitten im Arbeitstag bricht die Performance ein, weil ein Updater Bandbreite, IO und Write Cache frisst — auf einem System, das das gar nicht behalten kann.
- Schlimmer noch: Ein Geschäftsprozess setzt eine bestimmte Version einer Anwendung voraus. Der Auto-Updater zieht die Software unbemerkt auf eine neue Version — und plötzlich funktioniert ein unternehmenskritischer Workflow nicht mehr. Niemand hat etwas „geändert“, trotzdem ist es kaputt.
Jetzt ist alles heruntergeladen und installiert. Der VDA wird neu gestartet, um die Lage zu bereinigen — und beim Reboot ist der ganze Update-Kram aus dem Write Cache wieder weg, das Image ist wieder im alten Stand. Beim nächsten Mal beginnt das Drama von vorn: Der Updater triggert erneut, lädt erneut, bricht erneut etwas — eine endlose Schleife, die niemand sauber greifen kann, solange die Ursache im Image schlummert.
Genau das macht das Problem so heimtückisch: Es ist nicht reproduzierbar auf Knopfdruck. Es schlägt zu, wann der Updater es will, nicht wann der Admin testet.
Warum das im Provisioning so brutal durchschlägt
Bei einer eigenständigen Maschine ist ein Hintergrund-Update Alltag: einmal runterladen, installieren, fertig, persistent. Beim nächsten Boot ist Ruhe.
Bei einem nicht persistenten Image ist es anders — gleich doppelt schädlich:
- Es bringt nichts. Jedes Update, das ein Worker zur Laufzeit zieht, landet im Write Cache und ist beim nächsten Reboot weg. Der Updater lädt also bei jedem Zyklus von jedem Worker dasselbe erneut herunter. Sinnlose Arbeit, tausendfach verworfen.
- Es schadet aktiv. Diese sinnlose Arbeit passiert nicht im Leerlauf, sondern beim Logon oder mitten in der Produktivzeit — und kann obendrein eine vorausgesetzte Software-Version unter dem Benutzer wegziehen.
Die Lösung folgt direkt aus der Regel: Auto-Updates gehören konsequent deaktiviert — vor dem Versiegeln des Images. Updates fährt man kontrolliert ein, indem man bewusst ein neues Image baut und testet, nicht indem man die laufenden Worker sich selbst aktualisieren lässt. So bleibt man Herr darüber, welche Version produktiv geht und wann.
Der gleiche Denkfehler, anderes Gesicht: der Trust-Bruch
Es gibt ein weiteres Lehrbeispiel, das exakt aus derselben Wurzel wächst — das berüchtigte „trust relationship failed“.
Windows rotiert regelmäßig das Computerkonto-Passwort. Bei einem nicht persistenten Image schreibt es den neuen Stand brav ins AD, speichert das lokale Secret aber im flüchtigen Write Cache. Beim nächsten Reboot ist dieses Secret weg, das Target fällt auf den Stand aus dem Image zurück. AD und Target kennen nun unterschiedliche Passwörter — Vertrauensbruch.
Wieder dasselbe Muster: Etwas „aktualisiert sich“ zur Laufzeit und erwartet, dass das Ergebnis überlebt. Tut es aber nicht. Die saubere Lösung ist auch hier zentral statt lokal — PVS bringt einen eigenen Mechanismus mit, der die Computerkonten konsistent von der Infrastruktur aus verwaltet.
Enterprise-VDI funktioniert nicht „out of the box“
Das ist am Ende die unbequeme Wahrheit hinter der Regel: Eine nicht persistente Umgebung funktioniert nicht einfach, weil man sie aufsetzt. Sie funktioniert, weil jemand sie konfiguriert hat — und der erste, wichtigste Schritt dabei ist, jedem automatischen Update im Image den Stecker zu ziehen.
Das ist kein Detail für Perfektionisten. Es ist die eine Regel, die den Unterschied macht zwischen einer Farm, die vorhersehbar läuft, und einer, bei der irgendwann — man weiß nie genau wann — das Telefon klingelt.
Vor dem Imaging gilt immer: erst alle Auto-Updates aus, dann versiegeln. Wer das verinnerlicht, hat den häufigsten und am schwersten zu fassenden selbstgemachten PVS-Fehler bereits hinter sich gelassen.
PVS Forge macht genau diesen Schritt verlässlich: Vor dem Versiegeln werden Auto-Updates deaktiviert und der Zustand sauber eingefroren, nach dem Imaging erfolgt das kontrollierte Un-Sealing. Kein vergessener Updater, der Tage später beim Logon oder mitten im Betrieb zuschlägt.