This particular case opened when I modified an existing MDT Windows 10 task sequence, which was based on VLSC ISO as a starting point and applied all modifications at installation time, to use a reference image. The build & capture task sequence was highly complex and used a wide range of utilities, scripts, and other pieces stitched together into a complex end-to-end deployment process. When I tried to deploy the resulting image, I ran into the dreaded "Just a moment..." loop during he closing stages of Windows 10 OOBE. Besides highlighting what you shouldn't do, this case outlines location of important log files.
The first time I ran into the "Just a moment..." loop I restarted the OSD process because I thought it had hung, but when the loop happened a second time I had to face the disappointing reality that something was going terribly wrong, so I set out to investigate.
There is a lot of misconception on the net as to how to deal with this issue. A quick Google search will yield dozens results - all have one in common: add SkipMachineOOBE to unattend.xml and set the corresponding value to true. Thing is: don't go down this route. This setting has been deprecated in Windows 8 and needs to hit the landfill. You should never ever ship a computer with the SkipMachineOOBE setting configured to true. Some Windows features may not function, as they depend on Windows Welcome values such as ProtectYourPC, which does not include a default value. So, while setting the value SkipMachineOOBE to true helped me bypass the OOBE loop, I would never stoop to that kind of troubleshooting hack as it is beneath my dignity.
My goal was to determine what was holding up the OOBE process. I had to somehow get visibility into what was going on behind the scenes. The way that immediately jumped to mind as the easiest was to take a look at setupact.log (which is the main log file written by the Windows 10 installation process) and setuperr.log log files.
My first step was to power off the VM I was using for testing and mount the vhdx disk so I could access the log files. It is important to note that the location of the logs move around depending on what portion of setup we are talking about.
Location:
- C:\$WINDOWS.~BT\Sources\Panther (for early errors)
- X:\$WINDOWS.~BT\Sources\Panther (in Windows PE)
- C:\Windows\Panther (for specialize)
- C:\Windows\Panther\UnattendGC (for OOBE)
The key to the solving the mystery was in the C:\Windows\Panther\UnattendGC\setuperr.log file. It contained just one line:
2017-12-20 14:04:21, Error [msoobe.exe] StartService for wlidsvc failed [0x80070422]
wlidsvc is the Microsoft account Sign-in Assistant (formerly Windows Live ID) service which I routinely disable in an Enterprise scenario. Combined with the OOBE loop this led me to conclude that OOBE process ended up waiting for the Microsoft account Sign-in Assistant to start and with it being disabled during reference image creation, this never happened. Confident I have solved my mystery, I removed the wlidsvc start type configuration from the optimization script, regenerated my Windows 10 images and to my immense satisfaction, the issue was gone.
I did not have neither the time nor need to look deeper into the issue. The point of this post was to showcase the importance of log files and troubleshooting techniques to solve problems occuring during OSD. It took me five minutes to identify the root cause and implement a fix without any detrimental effects to supportability (*cough* SkipMachineOOBE *cough*).
Finally, here is a breakdown of the notable log locations during an MDT install task sequence:
- %TEMP%\SMSTSLog (typically in Windows PE)
- C:\_SMSTaskSequence\Logs
- C:\SMSTSLog
- X:\SMSTSLog
- C:\MININT\SMSOSD\OSDLOGS (Installation running)
- C:\WINDOWS\Temp\DeploymentLogs (Installation complete)
