We are trying to use the session host configuration for a new AVD host pool. We have confirmed that it can join computer to the specified OU without difficulty when we do it manually, and that the key vault access is intact since the local admin is created without issue.
But any new session hosts fail to join to the domain. They're created with all other specifications.
If we try to add them manually it seems to create some kind of instability in the FSLogix where it will then permanently hang for users when trying to log off.
It would be good if we had insight to the domain join failures so we don't have to manually join them.
In the deployment I can see the network, the VM, and a DSC, but that DSC is only for joining to the AVD Host pool. I don't see anything in it to join using the key vault credentials.
2 Comments
Did you manage to solve this issue? We are experiencing the same problems and Microsoft has been of no help for us. The keyvault rights are set up correct, I'm using the full upn for the account name and I am able to join the VM manually with the same account that is used.
When looking at the generated ARM template it looks like the domain credentials aren't even used
NmicroSince you have solved the issue, could you mabe post the ARM output from your build? I wonder if there is a bug that for some reason doesn't use the join step in the deployment sometimes
I had the same issue. I came across your post when I was researching a solution and thought that I would come back with the answer that at least fixed the problem for me. This blog post - Session Host Update Part 1: the Prerequisites - helped me verify that I had the Keyvault set up correctly with the right permissions. I used this article - Update session hosts using session host update in Azure Virtual Desktop (preview) - to make sure that my joiner account had the appropriate OU permissions to reuse computer accounts in AD. My ultimate problem was that I was putting in the username rather than the User Principal Name (UPN) for the account joining VMs to Active Directory, e.g. I needed to use vmjoiner @mydomain.com rather than just vmjoiner in the Keyvault secret (I had to put in a space before the @ in the UPN in this comment so that it would allow it to not be seen as an email address and not be blocked by this site). When I was testing joining devices on the Host pool after the VMs had been created and the join process had failed I was testing with a Powershell command using my Active Directory short name, e.g. contoso\vmjoiner. So, in this instance the AD join process worked from a VM that had already been created.
