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 - https://johanvanneuville.com/automation/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 - https://learn.microsoft.com/en-us/azure/virtual-desktop/session-host-update-configure?tabs=portal - 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.
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 ke...