'joindomain' error with Windows Virtual Desktop


I have a single vnet with a subnet that has gateway and a subnet that has a Domain Controller successfully joined to our on-prem domain via VPN tunnel. 

I went through all the steps I've found online to getting Windows Virtual Desktop going.

Esssentially I've gotten to the deploy of the VM part however it fails with joindomain error:


VM has reported a failure when processing extension 'joindomain'. Error message: \"Exception(s) occured while joining Domain....


What could be causing this? A credential? I know it has permissions.  Do I need to change the subnet that this WVD Host Pool is on to the DNS server of the Domain Controller in the same VNet? 

13 Replies
best response confirmed by John Quile (Contributor)

@John Quile 

Hi John,


Is the VM in the same vnet as the DC?

What is the DNS server in the subnet where the WVD VM is created? The domain needs to be resolvable.

Another option is that the account used for joining the WVD VM to the domain is incorrect.


Looking forward to your feedback!



Hi ,

Yes the WVD VM subnet is in the same VNET as the DC.
From on prem I can connect to other servers (like a print server) that are in other subnets (within the same vNET) that do not have any special DNS settings (they’re just set to default).
The only place I have a DNS setting pointing to an on-prem Domain Controller is on the NIC properties of the DC virtual machine in Azure (and that’s not in Windows it’s in the Azure DNS settings for the VM).
I’m not reading anywhere beyond that to need DNS settings for WVD or the WVD subnet. But do I need to? Because the subnet for it I created during the create WVD pool pool wizard.
And actually I just realized now I wonder if it’s because my on-prem firewall doesn’t have a static route to this WVD subnet. Also I wonder if I need to add it to the Azure DC site in AD.

You mention that you do not have special DNS settings on the Vnet (which is pointing to azure dns instead then).

Make sure that your DC is acting as the DNS server in the WVD vnet so your domain is resolvable inside the vnet itself. I would retry deploying the VM if you have made that change.
The vnet does not know that you have a DC installed in it which is acting as a DNS server.

The reason why these things aren't mentioned in the WVD tutorials is because this is not related to WVD (same behavior on every azure vm)


Well I set the DNS of the VM DC to a DC on-prem.

But I don't know if I want to set the entire VNET to the same DNS, that seems a bit much.

And I can't set the DNS on a NIC for WVD because they can't provision for me to get to their NIC properties? 

Since this deployment fails, what do I do? The resource group is incomplete do I just delete it and start over? 


Ok so I manually created a VM in the subnet. I can ping the IP addresses of my on-prem and the Azure DCs. But not the host names.  

So I need to set DNS server to my Dc in Azure for the VMs in azure, but can i do that upon provisioning of the WVD? Or I have to literally set the DC as THE DNS server for the entire VNet just so this one subnet can allow WVD's to join the domain? 



So I think it's working now, at least with a one-off VM I deployed.


  • Created new VNet and subnet for the WVD network
  • Setup peering between it and the VNet that has the Domain Controller VM 
  • Set the WVD Vnet DNS server to the IP of the Domain Controller VM in the other VNet
  • Added on-prem Firewall static route to the new WVD subnet
  • I can join it to the domain.

I'm not sure if that's the best route or not. 

But I believe that will fix the WVD Host Pool deployment. 


Looks like it's all working now after the mentioned solution.


Good to hear, it was all related to the new created WVD VM not being able to resolve your domain name. As a default vnet has azure dns, it was unable to resolve anything you created.
Thanks again. Do you mind if you could point me in the direction for figuring out the following 3
1. When I login to, the icons are called "Session Desktop". Is there a way to rename those?
2. How would I upgrade software/applications on these servers for users who will be using them? Do I just mstsc /admin into each of them and pull them out of the pool, then upgrade? or does each user get individual apps installed?
3. I use Okta SAML/SSO. While I get the prompt when logging into rdweb website, after authentication I still get a user/password login screen so it's not passing through so I have to authenticate a second time.
1.Check out this page:

2. Your VM's should be a 1-on-1 representation of your golden image, you should be able to update the golden image, destroy your WVD VM's and redeploy. The FSLogix profiles should hold the user data, not the WVD VM. If you don't want to do this, WVD VM's are also manageable by SCCM and other management tools.

3. This is normal, when using the remote desktop app, it will cache your credentials so you don't have to authenticate twice (altough I'm not sure with Okta, haven't tested that myself).
@knowlite thanks that helps. And as far as performance is there some minor lag to be expected? Just wondering where I should start with optimizing the “snapiness” of the WVD. Suppose I could create other VMs to compare with WVD.
Important are the local disk type (ssd) and the FSLogix profile storage.
The actual cpu/memory load is different for each company.
Depending on how many users you would want to squeeze on 1 VM, the VM type will differ.