Troubleshoot Active Directory Domain Join Errors

When a new VM is provisioned in Nerdio Manager, either as a desktop image or a session host, by default, it joins the AD domain using the AD information provided during the initial installation process.

The follow steps are performed by the new VM:

1. A new Azure VM is created and it obtains DNS server(s) specified on the VNet.

2. Using the AD domain name provided in AD Profiles under Settings, or in the host pool properties, the VM looks up the domain controller (DC) using the DNS server it obtained when created.

3. The DNS server provides the VM with a DC record.

4. The VM tries to join the domain by connecting to the provided DC using the user credentials provided during the installation, or in the host pool properties.

5. The VM tries to create an AD compute object in the OU provided in AD Profiles under Settings, or in the host pool properties.

A failure in any of the above steps results in an AD Domain join error. Here are some suggestions to try and troubleshoot the problem.

To troubleshoot AD domain join errors:

1. Review the C:\WINDOWS\Debug\NetSetup.log on the VM that is failing to join the domain.

   Note: This log should identify specific error codes or other details indicating why the domain join failed (failed to find the domain, incorrect or expired credentials, machine join limit exceeded, invalid OU path, or other errors).

2. There should be custom DNS servers specified on the VNet. This custom DNS must be AD-aware. If the DNS was not set properly, correct it and then restart the VM.

3. The VM should be able to communicate with this DNS server.

4. The VM should be able to communicate with the domain controller responsible for domain join. This should ideally be a VM in Azure "close" to the VM.

5. Make sure that the OU specified is in DN (Distinguished Name) format and is present on the domain controller that is used to join the domain. In addition, make sure that there are no domain replication problems (the domain should be in a healthy state to support joining new workstations).

6. The user (service account) being used to join the domain should have the ability to create (and disable) computer objects in the target OU. Try using a known working account, or domain admin user, to join the domain to verify if the service user is lacking permission.

   Note: By default, standard user accounts have the ability to join up to 10 session hosts to the domain. We recommend using a service account with delegated permissions for joining and removing an unlimited number of computers in the domain.

7. Make sure that the user account is specified in UPN (user@addomain.local) or domain\user format.

8. Test the validity of the OU by leaving the field blank, which creates the computer objects in the default location (for example, Computers container).

9. Ensure the specified credentials are valid and not expired. Be sure to re-enter the correct username and/or password.