Write cache exhaustion at 700 concurrent logons, and 300 new desktops in Azure

Mechanism. With cache in device RAM with overflow to disk, all writes inside the session land first in RAM (capped at 8 GB) and then in the overflow file (10 GB). That budget is shared with everything that writes to the system volume: the page file, Windows Update staging, antivirus signature and scan activity, event logs, and user profile writes when profiles are local rather than managed. Putting the page file on the cache disk makes it worse, because page file traffic becomes cache traffic. Once the overflow file fills, the device stops committing writes; applications hang, the profile service cannot create a profile hive, and the device either blue-screens or drops out of the farm. "No available boot device" is the boot-time variant: the stream service or its cache cannot complete the boot in the retry window at peak, which the 900 Mbps streaming plateau corroborates.

Remediations, ranked by benefit-to-risk:

1. Remove the page file from the cache disk, or size it deliberately. This alone often reclaims several GB per device.
2. Give the overflow file its own virtual disk with 20-40 GB and monitor usage, alerting at 80%.
3. Reconsider the 8 GB RAM cap on a 16 GB VM: a smaller RAM cache (2-4 GB) with a properly sized disk cache is more predictable than starving the OS.
4. Shrink the vDisk. An 80 GB base for a non-persistent Windows 11 desktop is usually over-provisioned and makes every update layer larger.
5. Exclude the vDisk, PVS server directories and cache paths from antivirus, and stagger logons with power management to flatten the 08:00 spike.
6. Confirm 32 KB block size is still appropriate for the vDisk size - keep it unless you have a measured reason to change.

Verify: per-device cache utilisation in the PVS console and a 24-hour peak logon run before declaring the incident closed.

Use MCS for Azure. The decisive argument is that PVS streams the operating system image over the network from a provisioning server that must be network-adjacent to its target devices. In Azure that means placing PVS servers in the same virtual network and region as the targets, accepting Azure storage and inter-VM throughput as the streaming bottleneck, and working around the lack of PXE by booting from BDM media. You would be exporting the very write-cache and streaming problems currently causing 30-60 tickets a day into a platform where you have less control over the disk and network path.

MCS instead uses the platform's native APIs to compose VMs from a snapshot of a prepared master image, with no streaming tier to size or troubleshoot. It also aligns with the operational features the business will want immediately: Autoscale for cost control on 300 non-persistent desktops, and image updates delivered by rolling out a new snapshot rather than publishing vDisk versions.

Design consequences to plan for:

• A separate Azure hosting connection and hosting unit, with the resource group, subscription and identity used for provisioning documented and least-privileged.
• A machine catalog with cache in RAM or cache on disk, sized from measured write behaviour - do not copy the on-premises numbers.
• Profile and Microsoft 365 containers on a storage service designed for it (Azure Files or Azure NetApp Files), not on the OS disk.
• Controllers: keep the Site's Delivery Controllers on-premises only if the ExpressRoute/VPN latency to the Azure region is proven acceptable for registration and brokering; otherwise this is the moment to evaluate Citrix Cloud for that workload.
• A decision on whether the Azure desktops join the existing Site or form their own, given the same locality reasoning that applies to any two-location design.

Never update the version the fleet is currently booting. The process should be version-based and reversible.

1. Prepare. Check out a new version of the vDisk on the provisioning server, boot one or two non-production maintenance devices privately from it, apply patches and application changes, then shut down. Never join a maintenance device to the production catalog and never let it write back to a version in production use.

2. Test group. Promote the new version to test and assign it to a small group of production-representative devices (8-10 per site, covering the noisiest applications and both PVS servers). Run them through a full logon peak, including the 08:00 window, and check write cache consumption, boot time and stream throughput against the current baseline. Test the rollback: set the test devices back to the previous version.

3. Promote. Assign the new version as the production version, then reboot devices in controlled waves - for example 10% at a time, spaced so the boot storm and streaming do not collide with the logon peak. Watch the PVS server's streaming throughput and retries during each wave. Keep the previous version retained and assigned to nothing until the next cycle, with a documented one-command way to point the devices back.

4. Exceptions. Devices that need write-back (for troubleshooting or a certified application) stay on a private image or a dedicated catalog; they must not become a shadow production path that bypasses version control.

5. Record. Version number, change contents, test evidence, wave timings and rollback point, stored with the change ticket. Automate the mechanical steps with PowerShell against the PVS provider so the wave pacing and version assignment are repeatable rather than run from memory at 02:00.