Non-persistent environments such as Citrix Virtual Apps and Desktops, Azure Virtual Desktop (AVD), and VMware Horizon are designed for one core purpose: predictability.
Whether you’re using a read-only image or refreshing machines daily or weekly, you know exactly what your environment should look like every morning. Same OS, same applications, same versions. That predictability is one of the main reasons enterprises choose non-persistent desktops—it delivers stability, simplifies troubleshooting, and makes performance far more consistent.
But there’s one silent disruptor that often goes unnoticed: auto-updates.
In this blog, I will dive into common auto-update scenarios and how our disk monitoring solution from the ControlUp Innovation Guild helps you stay in control.
Why do auto-updates break non-persistent environments? (Executive Summary)
- Write Cache Bloat: Updaters write to the RAM/Disk cache, causing latency.
- The Reboot Loop: Since disks are read-only, the update never “sticks,” causing the process to repeat every day.
- Resource Contention: Updates compete with FSLogix mounts and GPO processing during logon.
The Impact of Auto-Updates on Citrix, AVD, and VMware Horizon
Let’s walk through a situation most EUC admins will recognize.
You build a clean golden image.
All applications are tested, approved, and validated. Performance is solid, boot times are predictable, and logons are fast. You seal the image, publish it, and your non-persistent desktops start doing exactly what they’re supposed to do.
Everything looks fine.
Then, somewhere in the background, a small updater wakes up.
No user clicks anything. No admin triggers a deployment. It’s just an application doing what it was designed to do: check for updates.
In a Citrix PVS environment, the OS disk is read-only. The updater doesn’t know that—it simply starts writing. New binaries, temp files, extracted installers, log files. None of it goes to the image; all of it goes into the write cache.
At first, you don’t notice.
The cache absorbs the writes. CPU ticks up slightly. Disk I/O increases just enough to blend into the noise. But the updater doesn’t stop after one file. It downloads tens or hundreds of megabytes, extracts them, verifies versions, and retries failed writes—because from its perspective, something keeps “breaking”.
Eventually, the RAM cache fills.
Now every additional write spills over to disk, and suddenly:
- Logons take longer
- Applications feel sluggish
- Disk latency increases
- User complaints start coming in
Nothing has “changed” in the image, yet performance is clearly worse.
Your next step: the reboot illusion
You reboot the machine. Performance is back. Users are happy again.
Problem solved… right?
Except the machine boots from the same read-only image. The application is back to the old version. The updater sees this, assumes it’s out of date, and starts the entire process again.
Same writes. Same cache pressure. Same performance degradation. Every reboot resets the symptoms, not the cause.
And because the environment is non-persistent, the updater never actually succeeds. It just keeps trying.
What happens if you have the same issue, but you aren’t using PVS?
Now take the same story and move it to Azure Virtual Desktop or VMware Horizon.
You might not be using a read-only disk, but you are:
- Reverting to a snapshot/disk
- Recreating machines daily or weekly
- Resetting desktops to a known-good state
From the updater’s point of view, nothing has changed.
Each morning, the VM starts in an “outdated” state. The updater kicks in during boot or user logon, competing with:
- FSLogix profile mounts
- GPO processing
- Logon scripts
- Application launches
Users don’t see an update prompt. They just experience slower sessions.
And because the machine will be reset again anyway, the updater work is thrown away, only to be repeated the next day.
Common VDI Auto-Update Culprits (Microsoft, Edge, Chrome, Zoom)
Often, the biggest culprit is Microsoft itself. Not only Windows Updates, but also Microsoft 365 (Office) updates and Microsoft Edge browser updates can have a significant impact. In addition, other web browsers such as Google Chrome, and communication tools like Zoom and Slack, all rely on auto-update mechanisms.
Most of these auto-updates can be found in the Windows Task Scheduler. For example, Microsoft Office updates are triggered through scheduled tasks that periodically check for new versions and attempt to apply them, even in non-persistent environments.
They could also be due to Microsoft Edge updates, and you would need to make sure to remove all the auto-update scheduled tasks before sealing your images.
There are also some applications like Adobe Reader who use an auto-update service so make sure to also check that those services are disabled.
How to Monitor VDI Disk Writes and Identify Update Processes
This used to be a tough question—the same as “what’s filling up my PVS cache?” And we can now answer this easily! Last year, we released a disk monitor solution that can show you exactly which files are modified on the system drive by which processes.
One of our partners has recently successfully found out that Microsoft Edge was causing the PVS RAM Cache to fill-up with the Disk Monitor. They had already disabled the Office update scheduled task, but forgot the Edge ones. And the ControlUp Disk Monitor showed this to them easily.
Want to know more about the ControlUp Disk Monitor and see more use cases read everything you need to know here: https://support.controlup.com/docs/disk-monitor-overview
