Saturday, 26 August 2017 14:07

The Case of 'Something Went Wrong'

Written by
Rate this item
(2 votes)

image

As you’ve probably surmised by my blog posts and my Twitter ramblings, I like to push OSD to its limits. Besides keeping my deployments running smoothly, my vigilance sometimes helps me spot potential problems before they actually become an issue for my customers. The case opened wide when I started testing a pre-release Windows 10 1703 Insider Build based MDT task sequence. During the specialize phase, my VMs would run into a blue-ish screen stating that "Something went wrong".

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.

Read 8257 times Last modified on Saturday, 26 August 2017 14:17

Recent Posts

  • Windows 10 21H2 Built-In Apps: What to Keep
    The development of the Windows 10, version 21H2 is finished and the update will soon be available for download from…
    Written on Wednesday, 20 October 2021 11:41
  • Group Policy Changes in Windows 10 21H2
    As Windows 10, version 21H2 update development winds down, Microsoft is now preparing for the final release of the Windows…
    Written on Wednesday, 20 October 2021 07:20
  • Group Policy Changes in Windows 10 20H1 Preview
    As Windows 10 Vibranium Update (20H1) development winds down, Microsoft is now beginning the phase of checking in the final…
    Written on Tuesday, 14 January 2020 04:51
  • An alternative ESU MAK Activation Solution
    This blog post was shared with me by a colleague of mine, Daniel Dorner, a Microsoft Premier Field Engineer. It’s…
    Written on Wednesday, 04 December 2019 21:04
  • The Case of Missing UE-V Templates
    My customers often deal with unexpected Windows behavior and this case is no different. This particular one is especially interesting…
    Written on Tuesday, 03 September 2019 12:20
  • The Case of Changing Default Printer
    While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s…
    Written on Wednesday, 14 August 2019 20:36