We use Windows 365 Cloud PCs for overseas contractors so we can avoid shipping company laptops internationally. That part is convenient, but the overall experience has been frustrating. Provisioning can take hours even with Microsoft's standard Windows 11 image. Intune deployment is inconsistent: apps, configuration profiles, and compliance policies sometimes fail to apply or only recover after a reboot. Performance also becomes sluggish after a day or two, despite monitoring metrics showing that the assigned CPU and memory are not heavily utilized. Restarting is awkward because the restart option is missing from some machines, and resizing a Cloud PC can sit in a pending state for nearly an hour after changing the license. We are currently using Windows 11 25H2 with Microsoft 365 Apps, generally with 4 vCPUs, 16 GB of RAM, and 256 GB of storage. Are these problems caused by undersizing, image or policy configuration, backend capacity, or limitations in Windows 365 itself?
4 Answers
The biggest factor seems to be sizing. Two-vCPU Cloud PCs perform terribly once you add EDR, RMM agents, Office, and other management tools. We found 4 vCPUs and 16 GB of RAM to be the practical minimum, while 8 vCPUs and 32 GB tends to provide a much smoother experience. Windows 11 24H2 and 25H2 also seem to be harder on the smaller sizes than older images were.
Our experience has been much better, but we run a large deployment using the Microsoft gallery image, Intune, and Autopilot-style app provisioning. Provisioning usually takes around 40–45 minutes, although Azure Network Connection configurations and certain language packs can make it longer. Intune compliance and application deployment have generally worked reliably for us. Before blaming the service, I would test a plain 4-vCPU/16-GB machine with no custom policies, then add security tools and applications back in stages. That quickly identifies whether the issue is the image, a policy conflict, or the assigned size.
That kind of controlled test is probably worthwhile. We have seen custom images fail with vague provisioning errors, so we moved back to the stock image and pushed most of the configuration through Intune instead.
The missing restart option may be intentional rather than a platform limitation. Some marketplace images apply a user-rights setting that removes the ability to restart from inside Windows. That can be overridden with an Intune policy or custom configuration. On newer images, the normal restart option is available unless another policy removes it. Also, Windows 365 and Azure Virtual Desktop are different products: Windows 365 gives each user a persistent, license-based Cloud PC, while Azure Virtual Desktop is more of an infrastructure and session-hosting service.
That explains the restart behavior, although it still seems like an odd default for a normal Windows desktop. The inconsistent provisioning and performance issues are the bigger concerns for us.
There are some known rough edges. Smaller Cloud PCs can become nearly unusable after Windows updates or after running for a while, and resizing is not always immediate. We have also seen Explorer consume high CPU on shared machines while it processes OneDrive placeholder files. In practice, newer Windows versions plus security tooling can turn an 8-GB or 2-vCPU machine into a support problem. Some organizations have moved back to Azure Virtual Desktop or another hosted-desktop model when the recurring Windows 365 license cost is not justified.
We have seen the same pattern: the machines look fine in long-term averages, but users experience intermittent sluggishness. Rebooting temporarily fixes it, which makes the service feel inconsistent even when the dashboards do not show a bottleneck.
We are already using 4 vCPUs and 16 GB, so I would expect them to be adequate. The strange part is that the monitoring data looks healthy even when users report terrible performance, which makes me suspect the platform or host rather than normal resource exhaustion.