Forum Discussion
Solved
Add or Update Session Host failed
Hi,
We have a Host Pool with 3 session hosts. We are using the "Session Host Configuration" feature (in preview). So far, we were able to update the Host Pool with a new image template or add a new session host to the pool without any errors; everything was working as expected.
However, for the past few days, whenever we try to update or add a session host to the Host Pool, the session host fails to join the Active Directory. We encounter the errors "DomainJoinedCheck" and "DomainTrustCheck" failed.
When I check the NetSetup log in C:\Windows\debug, it shows that the virtual desktop (VD) didn't attempt to reach the domain and remains in a workgroup state. The RD Agent is functioning as expected, and all related services are up and running. If I manually join the session host to the domain, it works, and the session host remains available.
Do you have any ideas on what might be causing this issue?
I spoke with the the product team today and my specific issue was related to the our key vault configuration.
TLDR (Key Vault requires public network access to be enabled for the credentials to be retrieved)
The process that runs the domain join is now a part of the RD host session host agent. Previously it could access your Key Vault using "Azure Resource Manager for template deployment". There is an existing limitation with this new agent approach which requires public network be enabled for your key vault to retrieve the domain join secrets.
I spoke with the the product team today and my specific issue was related to the our key vault configuration.
TLDR (Key Vault requires public network access to be enabled for the credentials to be retrieved)
The process that runs the domain join is now a part of the RD host session host agent. Previously it could access your Key Vault using "Azure Resource Manager for template deployment". There is an existing limitation with this new agent approach which requires public network be enabled for your key vault to retrieve the domain join secrets.I'm in the exact same boat as Axel, I have a new host pool using Session Host Configuration preview and no matter what I try (combinations of UPN, Domain etc.) it fails to join.
I've confirmed the AVD principal can read from the key vault as I'm able to use the local admin credentials after the VM is deployed. I can also manually join the domain from the VM without any issues.
I can't find anything that stands out in the PowerShell DSC logs and my NetSetup logs similarly only reference adding the machine to the original Workgroup and nothing about the AD domain it should be trying to join.
Hello,
In my opinion, there may be many reasons why session hosts fail to join the domain. The common ones for me include connectivity issues with the domain controller, incorrect DNS settings, or changes in Active Directory policies. It’s also possible that the image template wasn’t properly Sysprepped, or the domain join credentials in Azure are incorrect or maybe they lack sufficient permissions.
Check the NetSetup log for detailed errors and also ensure that the Azure Virtual Desktop agent is up to date. If manual domain join works, you can compare it with the automated process to identify differences. If none of these resolve the issue, you can try to review Azure activity logs and consider contacting Microsoft Support for further investigation.
Hope it helps!Hi,
All the suggestions you mentioned have already been checked, and everything is fine.When I check the NetSetup log in C:\Windows\debug, I can see that there was no attempt to join the domain. It seems as though the workflow responsible for adding the VD to the host pool, installing the AVD agents, etc., stops before attempting to join the VD to the domain and leaves it in this incomplete state.
Do you know where I can find logs on the VD that could help me better understand why the workflow didn’t complete?
Hello,
If i'm not wrong the VD agent logs are in C:\ProgramData\Microsoft\Azure\Config\AVDLogs\ and also you can check the RDAgentBootLoader log in C:\Windows\Temp\RDAgentBootLoader.log. These should provide you some insights about where the process failed. Additionally, reviewing the Event Viewer (Application and System logs) on the VM and Azure Activity Logs in the portal might help pinpoint the issue.
Let me know what you find! I hope it helps, cause I'm running out of ideas =)
