My Azure Virtual Desktop users suddenly can't connect unless I manually start the session host VM first. When the first user attempts to connect, they immediately receive a message saying there are no available resources. The VM starts normally from the Azure portal, but automatic startup through the host pool no longer works. I haven't changed anything in this environment for about a year, and the required auto-start roles and settings appear to be configured correctly. There's also no waiting notification in the client and nothing useful showing in the event logs. Has anyone else run into this recently?
3 Answers
There appear to be broader Azure Virtual Desktop issues happening at the same time. I’m seeing session host deployment operations report failure with a message that the host pool doesn’t exist, even though the VMs are actually being created and registering as healthy. The failed deployment state then prevents further changes. If your configuration hasn’t changed, compare the timing with Azure service health and allow for a platform-side incident rather than immediately rebuilding the environment.
Can you start the VM manually from the Azure portal? If so, that helps rule out a regional VM capacity problem. In this case the portal start works, but the connection attempt fails instantly without placing the user in a queue, which points more toward the AVD autoscale or startup permission path than the VM’s ability to run.
Yes, manual startup works without any issue. The client immediately reports that there are no resources available, and I don’t see a waiting message or anything useful in the event logs.
Since the VM starts successfully from the portal, this doesn’t look like a basic capacity problem with the VM itself. The immediate “no available resources” response suggests that the auto-start workflow may not be triggering or Azure Virtual Desktop may be having a service-side issue. Check the host pool’s start-on-connect configuration, the managed identity or service principal permissions, and the activity logs for failed scaling or VM-start operations. It may also be worth checking Azure service health for your region.
This has been happening for several days on my side, so I’m also wondering whether it’s a service issue rather than a local configuration problem.