First things to check

When a Windows 7 desktop is created in Unidesk it runs through the Microsoft Windows mini-setup  process which uses a file called unattend.xml to configure a variety of desktop settings. We recommend that you use the Unidesk unattend builder tool to create your unattend file. With the unattend builder you can specify all of the settings required to join the desktop to the domain during creation. If your desktop is not joining the domain correctly, here are some common issues and how to solve them.

Keep in mind that while you will look at logs on the desktop to identify your problem, you will update the unattend file in your OS layer or in an application layer to correct it so that newly created desktops will successfully join your domain.

Check the Setupact log on the desktop for errors

The following log file details the progress of the mini-setup process, including a summary line for each domain attempt. Check this log file for errors:

C:\Windows\Panther\UnattendGC\setupact.log

 Note: Be sure you are not looking at the setupact log in C:Windows\Panther. You want the log file that's in C:Windows\Panther\UnattendGC.

Search for DJoin.exe to see a log of the domain join operations:

DsGetDCName failed: 0x54b � check your fully qualified domain name
NetJoinDomain attempt failed: 0x89a � check your domain join credentials
NetJoinDomain attempt failed 0x2: check your OU specification

Still stumped? For other log files to check, go to the section on Advanced debugging later in this document.

Check your unattend file for common problems

Check your unattend file for issues. For example, let�s assume that you have this configuration:

fully qualified domain name: vdidomain.acme.com or vdidomain.local
short domain name: vdi
OU: acmegrp1
Domain account: Administrator

Open the unattend file on the desktop and check for some common problems. The unattend file is located in c:\windows\panther.

• Search for the <JoinDomain> tag and check the fully qualified domain name. It should look like this:

<JoinDomain>vdidomain.local</JoinDomain> or
<JoinDomain>vdidomain.acme.com</JoinDomain>

• Check the domain specification by searching for the Domain tag: <Domain>. The Domain tag must be the short domain name, not the fully qualified domain name.It should look like this:

Correct: <Domain>vdi<Domain>
Incorrect: <Domain>vdidomain.acme.com<Domain>

• Check the Username specification. It should look like this:

Correct: <Username>Administrator</Username>
Incorrect:<Username>vdi\Administrator<\Username>

• Check the processor architecture

In the "component" tag, make sure "processorArchitecture" is correct for your platform - either "amd64" or "x86".

Edit the unattend.xml to fix problems

Create a new version of your OS layer to update your unattend file. 

1. From the UDMC, click OS Layer > Add Version.  Allow the Operating System Layer to boot up in the Install Machine, and login.
2. Once logged in, run Notepad as Administrator and then open C:\Windows\Panther\unattend.xml. 
3. Review the file, make any edits, and save the file.  
4. Finalize the layer

Do not re-run the Unidesk Tools installer or the Unattend Generator.  Deploy a new desktop with your latest OS version and check for successful domain join.

Advanced debugging

Check the Netsetup log file for errors

One log file details the entire process of joining the domain:  C:\Windows\debug\NetSetup.log.  Look for the section with today's date to watch the process from the beginning, or go to the bottom of the file to see the last attempt and why it failed.  If an attempt fails, Windows makes another attempt every five seconds, up to 80 times, As a result, your log may contains many duplicate failure messages.

A successful domain join displays the following message:

05/01/2012 09:28:01:740 NetpDoDomainJoin: status: 0x0

This line appears at the bottom of the last attempt, and denotes that the domain join process succeeded.  Any return status other than 0x0 denotes a failure.  You may also see the following lines above it, which also show success:

05/01/2012 09:28:01:740 NetpCompleteOfflineDomainJoin: status: 0x0
05/01/2012 09:28:01:740 NetpJoinDomain: NetpCompleteOfflineDomainJoin SUCCESS: Requested a reboot :0x0

Failure, again, is a non-zero return code:

01/20/2012 10:53:01:232 NetpDoDomainJoin: status: 0x2

One of the most common failures is an error attempting to connect to the IPC$ share on the domain controller.  It will look like this:

05/02/2012 23:14:21:057 NetUseAdd to \\DC1.company.local\IPC$ returned XXXX

Get the returned message (XXXX) and run net helpmsg XXXX from a command prompt to see the specific error.  The following are common domain join errors and solutions to those errors.

Failure 1231

07/12/2012 14:38:52:122 NetUseAdd to \\DC1.company.local\IPC$ returned 1231
07/12/2012 14:38:52:122 NetpJoinDomain: status of connecting to dc '\\TDC1.company.local': 0x4cf
07/12/2012 14:38:52:122 NetpJoinDomainOnDs: Function exits with status of: 0x4cf
07/12/2012 14:38:52:122 NetpDoDomainJoin: status: 0x4cf

Pre-1.5 versions of Unidesk had a timing issue that could cause domain joins on Windows 7 x64 to fail randomly.  Upgrade to the latest version of Unidesk if you are using a version earlier than version 1.5.

This error may aslo be the result of mixing layers that were built from different OS layers. Resolve it by deploying with just the Operating System Layer.  Once you can identify which Application Layer is breaking the domain join process, recreate that layer with the current version of the current OS layer. 

If you cannot find conflicting layers, use the PowerShell script for joining the domain:

http://www.unidesk.com/support/kb/using-powershell-advanced-domain-join-operations

Failure 1326

05/02/2012 23:07:31:696 NetUseAdd to \\DC1.company.local\IPC$ returned 1326
05/02/2012 23:07:31:696 NetpJoinDomain: status of connecting to dc '\\DC1.company.local': 0x52e
05/02/2012 23:07:31:696 NetpJoinDomainOnDs: Function exits with status of: 0x52e
05/02/2012 23:07:31:696 NetpDoDomainJoin: status: 0x52e

Failure 1326 is a straightforward password error, "Logon failure: unknown user name or bad password."  Double-check the username and password in your unattend.xml file.

Failure 1909

05/02/2012 23:14:21:057 NetUseAdd to \\DC1.company.local\IPC$ returned 1909
05/02/2012 23:14:21:057 NetpJoinDomain: status of connecting to dc '\\DC1.company.local': 0x77
505/02/2012 23:14:21:057 NetpJoinDomainOnDs: Function exits with status of: 0x775
05/02/2012 23:14:21:057 NetpDoDomainJoin: status: 0x775

A 1909 error means "The referenced account is currently locked out and may not be logged on to."  Go to your Active Directory and unlock the account.  You should also determine how the account got locked.  Often the account becomes locked because the unattend.xml has an incorrect password.  Attempting to join a domain retries dozens of times. If the password is incorrect, you might get three password failures and dozens of "account locked" failures.

Bad OU specified

01/20/2012 10:53:01:232 NetpCreateComputerObjectInDs: NetpGetComputerObjectDn failed: 0x2
01/20/2012 10:53:01:232 NetpProvisionComputerAccount: LDAP creation failed: 0x2
01/20/2012 10:53:01:232 NetpProvisionComputerAccount: Cannot retry downlevel, specifying OU is not supported
01/20/2012 10:53:01:232 ldap_unbind status: 0x0
01/20/2012 10:53:01:232 NetpJoinDomainOnDs: Function exits with status of: 0x2
01/20/2012 10:53:01:232 NetpJoinDomainOnDs: status of disconnecting from '\\DC1.company.local': 0x0
01/20/2012 10:53:01:232 NetpDoDomainJoin: status: 0x2

The message "Cannot retry downlevel, specifying OU is not supported" means that the specified OU is invalid.  This error could indicate that the OU does not exist within the AD, or that you are attempting to specify the default Computers container.  Windows requires that the default OU be left unspecified, so if you want to put new desktops into the default Computers OU, you must delete the <MachineObjectOU> line entirely.  Look further up the log file for what the specified OU is:

01/20/2012 10:53:01:123    lpMachineAccountOU: OU=Computers,OU=VDI,DC=company,DC=local

Verify the existence of the specified OU and confirm that it is not the top-level Computers container.

Bad domain specified

If the domain name itself is invalid, a domain join makes no entries to NetSetup.log and does not create a log file.  In this situation, look in C:\Windows\Panther\UnattendGC\setupact.log for lines like this:

2012-07-13 16:11:15, Warning    [DJOIN.EXE] Unattended Join: DsGetDcName failed: 0x54b, last error is 0x0, will retry in 5 seconds...

The error text for 0x54b (1355) is "The specified domain either does not exist or could not be contacted."  You can look further up in the setupact.log to see exactly what domain you were trying to join.  Note that this is an error with the "JoinDomain" tag, not the credentials.

Insufficient user rights

07/17/2012 13:26:47:524 NetpMapGetLdapExtendedError: Parsed [0x5] from server extended error string: 00000005: SecErr: DSID-03152492, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
07/17/2012 13:26:47:524 NetpModifyComputerObjectInDs: ldap_add_s failed: 0x32 0x5
07/17/2012 13:26:47:524 NetpCreateComputerObjectInDs: NetpModifyComputerObjectInDs failed: 0x5
07/17/2012 13:26:47:524 NetpProvisionComputerAccount: LDAP creation failed: 0x5
...
07/17/2012 13:26:47:539 NetpDoDomainJoin: status: 0x5

The user account you specify must have rights to add machine accounts to the domain in the specified OU. This error appears when you have a valid account with insufficient privileges. Either try a different account or adjust the account privileges in the domain.

Use another approach to domain join: Add a script to the deployment process

If you are unable to make your domain join work automatically via the unattend file, you can try adding a PowerShell script to the deployment process to do the domain join.  For more information, see this article:

http://www.unidesk.com/support/kb/using-powershell-advanced-domain-join-operations

Want to know more about how domain join works?

The relevant section of the unattend.xml belongs in the 'pass="specialize"' settings block:

<settings pass="specialize" wasPassProcessed="true">

And the UnattendedJoin block within it looks like this.

<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Identification>

<Credentials>

<Domain>company</Domain>

<Password>thePassword</Password>

<Username>administrator</Username>

</Credentials>

<JoinDomain>company.local</JoinDomain>

<MachineObjectOU>OU=VDI,OU=lab,DC=company,DC=local</MachineObjectOU>

<DebugJoin>true</DebugJoin>

</Identification>

</component>

There are four elements of block that need to be correct: 

1. In the "component" tag, make sure "processorArchitecture" is correct for your platform - either "amd64" or "x86". 
2. In the "Identification" block, the "Credentials" block must be correct.  The "Domain" tag must be the short domain name, not the FQDN.  The "Domain" and "Username" tags are joined to create the account that the desktop will login to the domain as in order to create the Machine Account.  The account must exist and be a domain administrator or a service account with sufficient privileges to create Machine Account objects.  In this example, "company\administrator" logs in with password "thePassword".  Note that the password is stored in the gold as plain text, but is replaced with the string "*SENSITIVE*DATA*DELETED*" during deployment to preserve security.
3. The "JoinDomain" tag must contain the full domain as a FQDN.  The desktop logs in to and joins this domain using the credentials described above earlier.
4. The "MachineObjectOU" tag must refer to an existing OU.  It must not refer to the default Computers container.  If you want your desktops to appear in the default Computers container for your domain, you must delete the entire MachineObjectOU line.  The reason is that the MachineObjectOU field must refer to an OU, but Computers is actually a CN.  You cannot specify a CN there, and if you reference Computers as an OU, it's an error.  So to get the default, which you can't specify, you must not have the line at all.  (When using the Unattend Builder from Unidesk, specify the Computers container by putting nothing in the "OU to Place Desktops"  field.)

Note that if the machine already has a Machine Account in your domain (for instance because you are reusing names from desktops that have been created and deleted before), the domain reuses the existing Machine Account in whatever location it is already in, ignoring the one specified in  unattend.xml.

One log file details the entire process of joining the domain: C:\Windows\debug\NetSetup.log.  Review this file after deployment to determine why the attempt to join the domain failed.  Look for the section with today's date to watch the process from the beginning, or go to the bottom of the file to see the last attempt and why it failed.  If an attempt fails, Windows makes another attempt every five seconds, up to 80 times, As a result, your log may contains many duplicate failure messages.

A second log, C:\Windows\Panther\UnattendGC\setupact.log, details the progress of mini-setup, including a summary line for each domain attempt.  At least one type of failure (bad domain specified) results in no NetSetup.log being created, so you would have to see the failure information in setupact.log.  If you find no current information in NetSetup.log, or no log at all, check setupact.log.