Tuesday, 16 January 2018 12:57

The Case of "Just a Moment..."

Written by
Rate this item
(5 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 482 times Last modified on Tuesday, 16 January 2018 13:12
More in this category: « The Case of My Mom's Slow System

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

Recent Posts

  • Automating Multi-node Tableau Server Environment
    After a few weeks off, I am delighted to announce that I have returned full time, once again delivering somewhat…
    Written on Monday, 19 February 2018 11:01
  • The Case of Missing TPM P@ssword
    As my regular blog readers will be aware (yes, all three of you), there is something increasingly traditional about me…
    Written on Thursday, 25 January 2018 10:04
  • The Case of "Just a Moment..."
    A key part of any complete end-to-end deployment project is analysis of the resulting logs to identify root causes for…
    Written on Tuesday, 16 January 2018 12:57
  • How to Automate Input Preferences during OSD
    A few days ago I stumbled upon a question on the Microsoft Deployment Toolkit (MDT) forum where a user asked…
    Written on Monday, 15 January 2018 12:36
  • Disabling Cortana Voice Support during OOBE
    Yesterday I came across a Twitter thread in which multiple users detailed their beef with the revamped setup experience of…
    Written on Tuesday, 12 December 2017 10:04
  • Fixing "Windows update reboot is pending" during OSD
    Automated OS deployment became common as IT professionals install systems using tools like Microsoft Deployment Toolkit or System Center Configuration…
    Written on Tuesday, 28 November 2017 08:44