Windows 7 – Sysprep Fails to Join Domain, error: 0x52e

This week I faced an issue with Windows 7 computers failing to join the domain during Sysprep.

I spent a good day trying to get this problem resolved, so I thought why not share it.

I’m preparing a Healthcare company for a 6000 seat Windows XP to Windows 7 upgrade. There’s about 16 hardware models which I developed all the drivers and Task Sequence in my Configuration Manager 2012 build environment. When it was ready, I exported the working Task Sequence from the Build environment and imported it into the brand new Configuration Manager 2012 environment (which I also built) in the clients production environment.

I setup a room with a row of desks and some of the hardware types constantly running OSD tests. The aim is to get the deployment testing and client User Acceptance Testing out of the way as efficiently as possible.

I managed get a few successful LTI builds done, then all of a sudden when I started ZTI builds, I started getting random failures with different computers failing to join the domain. The knock-on affect and first visible symptom was scripts running during the Task Sequence in the context of a Domain account would fail. In the case of a particular HP DC7600, it started failing to join the domain on every occasion, obviously I was asking myself, what on earth is going on?

The first thing I knew to do was check C:\Windows\Debug\NetSetup.log, but this is where I started to pull out my hair.

07/21/2012 03:24:43:921 NetUseAdd to \\DC05.the.clients.domain.fqdn\IPC$ returned 1326
07/21/2012 03:24:43:921 NetpJoinDomain: status of connecting to dc ‘\\DC05.the.clients.domain.fqdn: 0x52e
07/21/2012 03:24:43:921 NetpJoinDomainOnDs: Function exits with status of: 0x52e
07/21/2012 03:24:43:921 NetpDoDomainJoin: status: 0x52e

NetSetup.log shows me error code was 0x52e, a quick lookup using Configuration Manager Trace Tool showed me 0x52e equated to:

• Logon failure: unknown user name or bad password. Source: Windows

Ok, what I couldn’t understand was – why was this happening at random? I wasn’t making any changes to the Task Sequence and even if I was, I wasn’t making any changes to the Apply Network Settings step!?!?!

Naturally I went through the process of checking the account wasn’t locked out. I reset the password to what I thought it should have been, made sure the account wasn’t locked-out, and made sure time-sync on the client wasn’t an issue.

Next I plucked out a copy of the C:\Windows\panther\unattend\unattend.xml file (right before WinPE completed and the system was about to restart and execute Sysprep), at this point I could verify the Join Domain user name and password set in clear text were correct.

<Identification>
<Credentials>
<Username>svcSCCMJoinDomain</Username>
<Domain>CLIENTS-DOMAIN-NETBIOS-NAME</Domain>
<Password>the correct password in clear text</Password>
</Credentials>
<MachineObjectOU>OU=Workstations,DC=the,DC=clients,DC=domain,DC=fqdn</MachineObjectOU>
<JoinDomain>the.clients.domain.fqdn</JoinDomain>
</Identification>

 

At this stage I knew the user name and password was being inserted correctly into unattend.xml, but why was the Domain Join process still failing with an incorrect password error when it wasn’t?!?!

I tried joining the domain manually via Windows.

When I tried to join the domain using the user name: CLIENTS-DOMAIN-NETBIOS-NAME\svcSCCMJoinDomain, I did this a few times and the process continue to fail intermittently, doing the Join Domain via the UI made no difference (sometimes it worked, sometimes it didn’t, so no change). At this stage I got my first clue, I noticed when I switched the user name between the NETBIOS name and the Domain’s FQDN (the.clients.domain.fqdn), the UI would update accordingly…

Next I tried using the Domain FQDN instead of the NETBIOS name (though I’ve never had to do this before). In order to do this, it meant when entering the Domain Join account in the Task Sequence step, I had to key in the user account name instead of using the Browse button and letting the account resolve via AD.

 

Since changing to FQDN instead of NETBIOS, I’ve done at least 20 builds and not one has failed to Join the Domain (the DC7600 has been rebuilt at least 4 times with 100% success).

Naturally this means there really is nothing wrong with the user name and password (which I already knew), so there must be something funny going on with DNS….

Hope this potentially saves someone hours of wasted time