When you introduce new admins to PVS or MCS, there is a sentence after which many things suddenly make sense - and after which you never make a certain mistake again.
The rule is very simple:
When a non-persistent VDI system starts, absolutely nothing must be updated automatically in the background - regardless of the software.
Before imaging, the same applies in the other direction: All auto-updaters must be from before the vDisk is sealed. Sounds trivial. It is not - because the receipt for a violation does not always come immediately and not always in the same form.
The obvious symptom: Black screen at logon
The call usually comes in the morning. The workers boot up, the user logs in - and then: black. No desktop, no error, simply nothing. Sometimes the desktop appears after what feels like an eternity, sometimes not at all.
The first reaction is almost always to tweak the usual suspects: profiles, FSLogix, some VDA registry value. And yes, there are legitimate reasons for this. But surprisingly often the real cause is much simpler and lies somewhere else entirely: An auto-updater runs in the background while the user is logging in - and stalls the logon because it competes for CPU, disk and write cache at the wrong moment.
This is self-inflicted, homemade. And it is avoidable.
The insidious symptom: a break-in in the middle of operation
This is the really nasty part - and the reason why the rule is so important: Not every updater starts on boot. The black screen scenario is just the obvious example.
In practice, VDAs often run for one to four weeks at a time. And you never know when a particular updater will start. Adobe, for example, triggers its update at some point in the middle of the runtime - day three, day eleven, completely unpredictably. Suddenly, updates are downloaded and installed in the background, without a reboot and without anyone having triggered anything.
And then this happens:
- Performance collapses in the middle of the working day because an updater eats up bandwidth, IO and write cache - on a system that can't even keep it.
- Worse still, a business process requires a specific version of an application. The auto-updater pulls the software to a new version unnoticed - and suddenly a business-critical workflow no longer works. Nobody has „changed“ anything, but it is still broken.
Now everything is downloaded and installed. The VDA is restarted to clean up the situation - and when it reboots, all the update stuff from the write cache is gone again, the image is back to its old state. The next time, the drama starts all over again: The updater triggers again, loads again, breaks something again - an endless loop that nobody can grasp cleanly as long as the cause remains dormant in the image.
This is exactly what makes the problem so insidious: it cannot be reproduced at the push of a button. It strikes when the updater it wants, not when the admin tests.
Why this has such a brutal impact in provisioning
With a standalone machine, a background update is part of everyday life: download once, install, done, persistent. The next boot is quiet.
It is different with a non-persistent image - doubly damaging:
- It's no good. Every update that a worker pulls at runtime ends up in the write cache and is gone at the next reboot. The updater therefore loads each Cycle from each Worker down the same again. Pointless work, discarded a thousand times over.
- It actively harms. This pointless work does not happen in idle mode, but at logon or in the middle of productive time - and can also remove a required software version from under the user.
The solution follows directly from the rule: auto-updates belong consistently deactivated - before sealing the image. Updates can be introduced in a controlled manner by deliberately new image, not by letting the running workers update themselves. That way you remain in control, which version goes live and when.
The same mistake, different face: the trust breach
There's another textbook example that grows from exactly the same root - the infamous „trust relationship failed“.
Windows regularly rotates the computer account password. In the case of a non-persistent image, it writes the new status to AD, but saves the local secret in the volatile write cache. At the next reboot, this secret is gone and the target falls back to the status from the image. AD and target now know different passwords - breach of trust.
The same pattern again: something „updates itself“ at runtime and expects the result to survive. But it doesn't. The clean solution here is also centralized instead of local - PVS comes with its own mechanism that manages the computer accounts consistently from the infrastructure.
Enterprise VDI does not work „out of the box“
In the end, this is the uncomfortable truth behind the rule: a non-persistent environment does not work simply because you set it up. It works because someone configured and the first and most important step is to pull the plug on every automatic update in the image.
This is not a detail for perfectionists. It's the one rule that makes the difference between a farm that runs predictably and one where at some point - you never know exactly when - the phone will ring.
Before imaging, always turn off all auto-updates first, then seal. If you internalize this, you have already left the most common and most difficult to grasp self-made PVS error behind you.
PVS Forge does exactly this step reliably: before sealing, auto-updates are deactivated and the status is frozen cleanly; after imaging, controlled unsealing takes place. No forgotten updater that strikes days later at logon or in the middle of operation.