Tuesday, 16 January 2018 12:57

The Case of "Just a Moment..."

Written by
Rate this item
(10 votes)

image

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.

image

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:

SMSTS.LOG (Useful when investigating failed task sequence steps and when verifying the evaluation of conditions on task sequence steps and groups.)
Location:
  • %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.)
Location:
  • C:\MININT\SMSOSD\OSDLOGS (Installation running)
  • C:\WINDOWS\Temp\DeploymentLogs (Installation complete)
Read 5836 times Last modified on Tuesday, 16 January 2018 13:12
More in this category: « The Case of My Mom's Slow System
  1. Comments (10)

  2. Add yours

Comments (10)

This comment was minimized by the moderator on the site

HI! which script did you do this in, to disable wlidsvc?

Thanks!

This comment was minimized by the moderator on the site

Basically it is a set of customizations geared towards an Enterprise environment. I actually pushed the script yesterday into my GitHub repository: take a look. Will post a blog article explaining the inner workings of the script in a few days.

This comment was minimized by the moderator on the site

This looks like it might help me with my "just a moment" issue. I have no idea how or when to implement the disabling of this service though? I'm using an MDT task sequence to deploy operating system images.
Thanks!

This comment was minimized by the moderator on the site

The thing is: I had to re-enable the service in order to work around the issue. If I were in your shoes, I would start by examining Panther logs as outlined in my post above.

This comment was minimized by the moderator on the site

Setupact gives me
2018-06-25 14:40:33, Info [taskhostw.exe] OOBE Monitor task background thread started
2018-06-25 12:42:52, Info [taskhostw.exe] OOBE Monitor timer expired for event: 100

No...

Setupact gives me
2018-06-25 14:40:33, Info [taskhostw.exe] OOBE Monitor task background thread started
2018-06-25 12:42:52, Info [taskhostw.exe] OOBE Monitor timer expired for event: 100

No errors, it's almost like the whole system is literally doing nothing

Read More
This comment was minimized by the moderator on the site

For closure, it turned out that some Group Policy Hardening that had been applied to computers was preventing the OOBE from running. There was nothing showing that this was what was happening really.

This comment was minimized by the moderator on the site

I am glad you could figure it out on your own. Well done!

This comment was minimized by the moderator on the site

github link is broken. We have this issue too (only in 1803)

This comment was minimized by the moderator on the site

I doubt it is related, but here is the accompanying blog post.

This comment was minimized by the moderator on the site

@MRAYBONE

What group policies was it that was hardening it please?

I am having this issue, and group policy is whats stopping it, as when i disable them all, it goes away.

We are a school and have many policies applied, so this is taking a...

@MRAYBONE

What group policies was it that was hardening it please?

I am having this issue, and group policy is whats stopping it, as when i disable them all, it goes away.

We are a school and have many policies applied, so this is taking a while to diagnose.

Read More
There are no comments posted here yet

Leave your comments

  1. Posting comment as a guest.
0 Characters
Attachments (0 / 3)
Share Your Location

Recent Posts