failed to join to the domain

Copper Contributor

hi All

when running a deployment i received the flowing error even after enabling AD service endpoint.

should the vnet have a vpn connection to on premise DC? 


{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see for usage details.","details":[{"code":"Conflict","message":"{\r\n \"status\": \"Failed\",\r\n \"error\": {\r\n \"code\": \"ResourceDeploymentFailure\",\r\n \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\",\r\n \"details\": [\r\n {\r\n \"code\": \"VMExtensionProvisioningError\",\r\n \"message\": \"VM has reported a failure when processing extension 'joindomain'. Error message: \\\"Exception(s) occured while joining Domain ''\\\".\"\r\n }\r\n ]\r\n }\r\n}"}]}
11 Replies

 I need information on this also !!!@saarc 

@saarc @tommy_barnes : Yes, the virtual machine needs to domain-join to an Active Directory that is synchronized with Azure AD. This is so the service can resolve the "on-prem" user when connecting them to a session on the VM.


One alternative to a VPN is using Azure AD Domain Services, since the users created in Azure AD Domain Services also exist in Azure AD. This would satisfy that requirement.

@Christian_Montoya I am struggling with this too.  Trying to deploy WVD and getting same error message.  I have Azure AD only and Domain Services in Azure already.

@Alberto Rodriguez : If you are using Azure AD Domain Services, can you try providing credentials of a user in the "AAD DC Administrators" group for the credentials?


Also, adding my response to a different thread, for more visibility:

Do you have access to those VMs? If you can RDP into them, please look at C:\Packages and navigate down to the JsonADDomainExtension folder, you should be able to find a "status" file (or equivalent). If you open it up, it will typically give you the reason that it errored out. Unfortunately, I do not have too many details at the moment because the documentation on the extension is fairly light.



Same here, site-to-site connectivity is working fine.  Plenty of other VMs living in this subnet without issues contacting local AD.  Something is broken in the extension or deployment process.  I've tried dedicate service account and super users (Domain Admin, Enterprise Admin, etc.) no luck.



@ChristopherB2175 : If you go to these VMs after the domain join extension fails and you provide the same domain join credentials and the same "domainToJoin", does it then join the domain correctly?

@Christian_Montoya I've come across the same error while evaluating WVD preview. When the error occurs  after the domain join extension fails, the VM instance are not accessible. Tried connecting to the VM's to resolve the domain issue, but it looks like the VM that is created does not have a Public IP address assigned. 


I see the comment about "One alternative to a VPN is using Azure AD Domain Services, since the users created in Azure AD Domain Services also exist in Azure AD. This would satisfy that requirement". Is there some tutorial on how to set this up as part of following the the WVD tutorial? Looking for tutorial that will allow evaluation of WVD from scratch, no current use of Azure services.

@hankchi95 : to address your first question, that is correct in that the template does not create a Public IP address for the VMs, since all connections are completed using reverse connect. To connect to the VM through a public IP address, you'll first need to do this by:

  1. Creating a public IP address
  2. Assigning it to the VM


To address your 2nd question on "if there's a tutorial to set up Azure AD Domain Services", here is the link to get started: . 

Was there ever a final resolution to this. I'm in the same boat. 

On-prem AD and I got AADDS working with password hash enabled. 


My error says exceptions occurred during the joindomain. 

Do I still need a site/point-to-site VPN to Azure? 
DC VM on Azure? 



@Bionicjoe : It depends on which domain you are attempting to join. If you are attempting to join the "on-prem" AD, then yes, there would need to be some line of site back to that DC.


Just for full clarity, Azure AD DS stands up a brand new domain controller that is independent of any possible existing ones, just that it has the logic to create users based from your Azure Active Directory.



I had the same issue, turns out my OU Path was formatted incorrectly