We use Microsoft 365 Cloud PCs mainly for overseas contractors, since provisioning a cloud workstation is much faster than shipping corporate laptops internationally. Unfortunately, the experience has been frustrating. Provisioning can take anywhere from 40 minutes to several hours, even with a standard Microsoft image. Intune deployments are unreliable compared with physical laptops: apps and configuration profiles sometimes fail to apply, compliance status can fluctuate, and reboots often seem necessary. Performance also becomes noticeably worse after the machine has been running for a while, even though monitoring data shows that CPU, memory, and other resources are not heavily utilized. Resizing a Cloud PC by changing its license can remain stuck in a pending state for nearly an hour. We are currently using Windows 11 25H2 images and generally deploy 4 vCPU, 16 GB RAM, and 256 GB storage. Are these known limitations of the platform, or are there specific sizing, image, policy, or provisioning choices that make Cloud PCs more reliable?
5 Answers
The biggest issue seems to be undersizing. Two-vCPU Cloud PCs perform terribly once you add EDR, monitoring agents, Office, and other management tools. Several admins report that newer Windows builds are especially unpleasant on 2 vCPU and 8 GB configurations. A practical floor is 4 vCPU and 16 GB RAM, while heavier users may need 8 vCPU and 32 GB. Even then, the platform can still be expensive for what it provides.
Slow provisioning and resizing do appear to be recurring service issues rather than something unique to one tenant. Region selection, language packs, image availability, and Azure network configuration can all affect provisioning time. Resizing is also not an instant VM operation; the license change may sit pending while the service schedules and reprovisions the machine. If it remains stuck, checking service health and opening a support case is usually more productive than repeatedly changing the license.
We have had resizing take close to an hour, and occasionally it never completed until support intervened. It is much slower and less predictable than resizing a normal Azure virtual machine.
The inconsistent performance may not show up in ordinary CPU or memory averages. Remote desktop quality can be affected by host contention, storage latency, network conditions, profile synchronization, or short bursts that disappear in five- or ten-minute metrics. One particularly common issue is OneDrive placeholder files causing high Explorer usage shortly after login on shared Cloud PCs. Testing a larger SKU, a clean profile, and a session without OneDrive or heavy startup tools can help isolate that.
We noticed that performance could be excellent one day and awful the next, even with almost identical monitoring graphs. That made the backend or storage layer look more suspicious than simple CPU saturation.
The missing restart option is often caused by the default marketplace image setting a user-rights policy that removes the ability to restart locally. It can be overridden with your own policy if you want users to manage reboots inside Windows. Also check the image version: some earlier Windows 11 images had restart restrictions that were no longer present in newer releases. If Cloud PCs remain unreliable after using at least 4 vCPU/16 GB and a clean image, Azure Virtual Desktop or another hosted-desktop design may be a better fit, especially if you need more control over the underlying infrastructure.
That explains the restart behavior, although it is still a strange default for a workstation. We restored the user right through policy and users could restart normally afterward.
Some organizations have had the opposite experience, with thousands of Cloud PCs running reliably and Intune policies applying normally. That usually depends on keeping the image and policy stack simple, using supported gallery images, and separating provisioning from application installation. A useful troubleshooting method is to test one stock 4-vCPU/16-GB machine with no custom policies, then add EDR, apps, and configuration profiles in stages. That helps identify whether the problem is the service, the image, or a policy conflict.
We use them for contractors and generally find them effective after deployment. Provisioning time is still frustrating, but day-to-day reliability is good when the image and policy setup are kept clean.
We saw the same pattern. The resource graphs looked fine, but 2-vCPU machines were still sluggish under normal security and management workloads. Moving to 4 vCPU and 16 GB made a substantial difference.