Tuesday, 16 January 2018 12:57

The Case of "Just a Moment..."

Written by
Rate this item
(12 votes)


A key part of any complete end-to-end deployment project is analysis of the resulting logs to identify root causes for hiccups you may run into during your deployment process. This is part of the new "data driven" mentality because operating system deployment (OSD) is highly complex and contains many moving parts. You can save yourself a lot of time and energy if you know where to look for answers. I can’t stress enough how invaluable log files can be in tracking down deployment issues!

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.


  • 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:

SMSTS.LOG (Useful when investigating failed task sequence steps and when verifying the evaluation of conditions on task sequence steps and groups.)
  • %TEMP%\SMSTSLog (typically in Windows PE)
  • C:\_SMSTaskSequence\Logs
  • C:\SMSTSLog
  • X:\SMSTSLog
BDD.log (Main log file. Essential for figuring out what happened during any MDT task sequence.)
  • C:\MININT\SMSOSD\OSDLOGS (Installation running)
  • C:\WINDOWS\Temp\DeploymentLogs (Installation complete)
Read 29857 times Last modified on Tuesday, 16 January 2018 13:12

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