AAD joined AVD - SessionHost is not joined to a domain

Copper Contributor

So, ive been testing the ability to using AAD to 'domain join' AVD Hosts. Its not working for me. I get "Status - Unavailable" shown against the host.


When I view the JSON I see -

"healthCheckName": "DomainJoinedCheck",
"healthCheckResult": "HealthCheckFailed",
"additionalFailureDetails": {
"message": "SessionHost unhealthy: SessionHost is not joined to a domain",
"errorCode": -2147467259,


During the deployment of the Host Pool the option is selected to join to AAD and also to enrol into Intune too.


Ive gone through the deployment guide https://docs.microsoft.com/en-gb/azure/virtual-desktop/deploy-azure-ad-joined-vm , and also reviewed other guides from the community and cant see im missing anything in the step.


Do you need AADDS for this to work? This is the key, and the big hype is that it will deploy to AAD, but some guides stating AZURE Virtual Desktop (so the new branding and I would assume the new features) mention AADDS too?!?!?!?


Thank you


5 Replies
Hi @Philip Luke,
The AAD Join feature doesn't need AADDS.
For the session hosts, is the extension installed on the vm's?
What do you see when you run dsregcmd /status in cmd on the session host?

Hi @Johan Vanneuville 

I can confirm the Microsoft.Azure.ActiveDirectory.AADLoginForWindows extension is enabled.


The results of the command show the following:



Which is odd indeed.

The status of the Host in AVD is still -



And the reason for it being 'Unavailable' is still - 


Thank you for your help on this.



Is the hostpool set as a validation environment?
What is the OS version you are using for the session host?
I have this same issue. I am trying to create a new host pool with default config.
As an update - there isnt one really. Ive continued to see issues around this. It seems the issue is down to some latency during deployment (maybe) - in that the same deployment config will work once and then fail next. If you deploy a Host Group of, say, five machines maybe one will fail, and then next type all will fail - same spec as its part of the same group build. Im sure MS will find the issue, but in the interim its a case of remove 'dead' hosts and re-add with the same spec... and around we go....