Device fails to join domain during a ConfigMgr OSD Task Sequence due to DC time synchronization issues

We have all dealt with mysterious task sequence failures while imaging. Owing to the number and types of issues we run into, I decided to put together a series of posts that discuss the unexpected and undocumented task sequence failures that are triggered by environmental issues and configurations. This is Post 1 of the series, and it concerns an interesting issue I worked recently. This will help in troubleshooting domain join scenarios during operating system deployment.

The core issue is that a task sequence fails to join the machine to the domain during the Windows imaging process via Configuration Manager.



We looked at the task sequence, made sure that the user name and password were typed correctly, and then we looked at the log files:

netsetup.log (c:\windows\debug)

12/20/2016 17:51:07:055 NetpValidateName: name '' is valid for type 3

12/20/2016 17:51:07:086 NetUseAdd to \\\IPC$ returned 2457

12/20/2016 17:51:07:086 NetpJoinDomain: status of connecting to dc '\\ 0x999

12/20/2016 17:51:07:086 NetpJoinDomainOnDs: Function exits with status of: 0x999



This server's clock is not synchronized with the primary domain controller's clock.


2017-01-06 10:18:51, Error                        [DJOIN.EXE] Unattended Join: NetJoinDomain failed error code is [2457]

2017-01-06 10:18:51, Error                        [DJOIN.EXE] Unattended Join: Unable to join; gdwError = 0x999


Error 2457 translated to:-

NERR_TimeDiffAtDC /* This server's clock is not synchronized with the primary domain controller's clock. */

Error 0x999 also translated to:-

NERR_TimeDiffAtDC /* This server's clock is not synchronized with the primary domain controller's clock. */

We tried a manual domain join with the logged-on user, and it was successfully joined to the domain. That tells us that the issue is specific to the domain join process during OS deployment only.

We checked on the domain controllers and found that the domain time was in sync. For that matter, if we joined the machine using the same service account that was used in the task sequence, we noticed the same error:

We tried another account and it went just as expected, so now it was clear that the issue was with the service account being used in the task sequence. We then took an ldifde dump of working users (successful domain joined accounts) and non-working users (failing accounts):

Non-Working user

ldifde -f test.ldf -d "CN=svc_SCCM,OU=Service,OU=Restricted Accounts,DC=Contoso,DC=com" -p subtree -s ""

Working user

ldifde -f test2.ldf -d "CN=Admin, ,OU=Users,DC=Contoso,DC=com" -p subtree -s ""

Upon comparison of these dumps, we determined that the UserAccountControl value for the bad account was 4260352, and for the good account it was set to 66048. We changed the UserAccountControl value of the failing account to 66048 and could now join the machine successfully through the task sequence.

Hope this helps! Do keep working and sharing! More on task sequence failures coming soon!

Anil Sood

Technical Advisor | Microsoft System Center Configuration Manager 

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights.


Comments (2)
  1. rahul sharma says:

    some more details on UAC values could have given a better insight , apart from that worth a dig 🙂

  2. L U says:

    Found flag explanations here:
    66048 dec = 0x010200
    4260352 dec = 0x410200
    Difference: 0x400000 – means: DONT_REQUIRE_PREAUTH – (Windows 2000/Windows Server 2003) This account does not require Kerberos pre-authentication for logging on.
    Not completely sure how that affects it in TS context, but it’s further detail.

Comments are closed.

Skip to main content