This post has been republished via RSS; it originally appeared at: Configuration Manager Archive articles.
First published on TECHNET on Mar 06, 2017We 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.
Assessment:
===========
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 'contoso.com' is valid for type 3
12/20/2016 17:51:07:086 NetUseAdd to \\machine1.contoso.com\IPC$ returned 2457
12/20/2016 17:51:07:086 NetpJoinDomain: status of connecting to dc '\\ DC1.contoso.com: 0x999
12/20/2016 17:51:07:086 NetpJoinDomainOnDs: Function exits with status of: 0x999
Seuperr.log
This server's clock is not synchronized with the primary domain controller's clock.
Seupact.log
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 "DC1.Contoso.com"
Working user
ldifde -f test2.ldf -d "CN=Admin, ,OU=Users,DC=Contoso,DC=com" -p subtree -s "DC1.Contoso.com"
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.