The first time I ran into the issue I pressed the "Try again" button, but that made no difference and after an extensive waiting period looking at the "Wheel of Wait" I ended up with the same error message. Hitting "Cancel" would make the OSD proceed. I’d typically chalk up an error message like this to an Insider Build issue, but I hit the issue in the next Insider Build as well as in the shipping version of 1703, so I had to face the disappointing reality that there was an underlying issue that needed my attention.
This issue also only occured while trying to join machines to a domain, but not when doing workgroup based deployments. What made the situation especially frustrating was that neither the Deployment Summary nor the Windows setup logs showed any errors. Adding to the mystery, all machines ended up joined to a domain. Since I could not get visibility into what was going on, I plowed on and made an educated guess that the error was somehow related to the domain join being executed - and running into an unspecified issue - during the specialize phase: by default the unattend.xml specifies to join the domain. I quickly went through the ZTIDomainJoin log file and verified that my machines were in fact not domain joined after the first auto logon. This confirmed my assumption that the domain join step failed initially. Once the execution of the task sequence resumed and the "Recover from domain" step verified the target computer did not join a domain, the ZTIDomainJoin script performed the domain join and remedied the situation.
Confident I’d solved the mystery, I opened the unattend.xml associated with my Windows 10 1703 task sequence located in %DeployRoot%\Control\%TaskSequenceID% and removed the unattended domain join entry Microsoft-Windows-UnattendedJoin.
<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
<Identification>
<Credentials>
<Username></Username>
<Domain></Domain>
<Password></Password>
</Credentials>
<JoinDomain></JoinDomain>
<JoinWorkgroup></JoinWorkgroup>
<MachineObjectOU></MachineObjectOU>
</Identification>
</component>
I restarted the OS deployment to verify my workaround, and to my satisfaction, the task sequence completed without any hiccups. The case was closed! As for why the domain join issues started occuring in Windows 10 1703 "Creators Update", I haven’t had the time or need to investigate further. The point of this article is to highlight an issue in the shipping version of Windows 10 1703 that you might run into, especially if you deploy domain joined machines using MDT and / or SCCM.
