Fix – Windows 10 1703 – “Something went wrong” during OSD

By | April 19, 2017

I have been setting up a new environment for Windows 10 deployments – SCCM 1702, and Windows 10 1703.

When creating the initial reference image and deployment task sequences, I noticed an annoying issue during the OOBE phase of sysprep.

My VM would run through the build, join the domain etc, but at the end of the build an error popped up saying “Something went wrong, try again or skip”.

Skipping continues the task sequence and the machine is fine after that. Hitting try again does nothing.

This only happens in my deployment task sequence, not the build & capture. As a test, I modified my deployment task sequence to join a workgroup instead of domain, and the error disappeared. Changing back to domain join and the error comes back – however my domain join actually works fine, and there are no errors in the setupact log regarding domain join.

Digging through the setupact and setuperr panther logs further, I noticed the line – “[CloudExperienceHostBroker.exe] Disabling default account failed [hr=0xD00000E5]”

In my task sequence, on the Apply Windows Settings step, the default option of “Randomly generate the local administrator password and disable the account on all supported platforms” is selected. I have not made any changes to the unattend.xml file regarding the default administrator account.

Changing that setting to leave the account enabled and set a password, did not help. So, at this point, I had tried several things but the only one that made a difference, was making the TS join a workgroup instead of the domain. Since the domain join itself is not failing, I started looking at group policy. I noticed the existing environment had a legacy GPO that was configuring the local administrators group members using Group Policy Preferences.

Disabling this GPO fixed the issue. I am in the process of overhauling and hardening the GPO’s in this environment, so I will update this post on how Restricted Groups affects this issue.

 

**UPDATE**

There is a lot of info out  there now regarding this error with various fixes, but since I now having a working solution this update to the post is what worked for me.

  • Restricted Groups is still being used to lock down the administrators group
  • the UAC settings are on the most strict setting (always prompt on the secure desktop

These were hard requirements for my situation, to pass security audits. Relaxing either or both of  these settings has resolved the issue for some people, but was not an option for me.

What appears to be working :

  • Using a non-captured reference WIM file. Previously I had a captured WIM from a build & capture task sequence. I have changed this to using the default install.wim from installation media and doing the minimal customisations in the deployment TS
  • Applied May 2017 updates to the install.wim via offline servicing
  • Setting SkipMachineOOBE and SkipUserOOBE to true on the unattend.xml

I did test each of these in isolation, and they didn’t work. The install.wim didn’t work with or without the updates, and the unattend changes didn’t work on the previous captured WIM. This current setup appears to be working.

28 thoughts on “Fix – Windows 10 1703 – “Something went wrong” during OSD

  1. Ryan Engstrom

    Thanks for the info in your post. I had tested OSD with 1703 on my lab. I got this problem on two of our seven models. I don’t have the same GPO preference configured, but I do have Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups set to modify the BUILTIN\Administrators group. It is interesting that I only got the problem on two of seven. I plan to unlink that GPO and deploy again. I am also still on ConfigMgr 1610, but I am unsure if that would also cause issues.

    Reply
    1. Matt Post author

      Hey Ryan,

      I can confirm that for me the behavior is the same for Restricted Groups or GP Preferences. I agree that it is odd that some hardware models display different behaviour, but there are definitely some bugs in this build of Windows. I’ve had this issue confirmed with other consultants. It would be interesting to review the SETUPACT and SETUPERR logs on your different hardware models, and also check that your GPO restricted groups settings are actually applying to the models that seem to work.

      Cheers,

      Matt

      Reply
  2. jason tayler

    Hi matt

    Had the same issues this week, have found that if the computer account is existing in AD and computer is a member of a group of which Gpo is targeted problem will occur
    If new computer object where not a member of the targeted GPO group yet problem goes away
    Looks like GPO is applying earlier than it used too
    From memory GPO shouldn’t apply during osd 🤔

    Reply
    1. Matt Post author

      In my testing, this occurs after the task sequence completes, before the logon screen is displayed after the final reboot. So, SCCM does appear to be suspending GPO processing during the task sequence.

      Reply
  3. Craig Jarvis

    We’ve experienced this also. What we found was that it wasn’t a restricted group or GPP for the Administrators group, but UAC. Try turning off (setting as “Not Defined”) all your UAC policies and see if the build run through.

    Alternatively, to confirm that you are experiencing the same as we are, get to the “Something went wrong” screen on a VM you can directly access (not via RDP), and do an alt-tab. You might see a OOBE UAC prompt hiding behind.

    If I find a solution that doesn’t involve putting the machine in a temporary OU, I’ll post back here.

    Regards,

    CJ

    Reply
  4. Matt Post author

    Thanks Craig, I did see the elevation prompt, but this occurred even when those UAC GPO’s are not set. Literally the only GPO being set was the local admin group membership. Removing this fixed the problem.

    Reply
  5. Craig Jarvis

    Ok, from our side I can confirm that this is a bug relating to the UAC GPO setting of “User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode”. If this is set to anything other than “Not Defined” or “Prompt for consent for non-Windows Binaries” then the issue will occur.

    My testing showed that the Restricted Groups setting was a red herring. This should be able to be proven by changing from a restricted group to a GPP to Update (not replace) the members of the BUILTIN\Administrators group, which leaving the UAC setting above in a non-error setting.

    Regards,

    CJ

    Reply
    1. Craig Jarvis

      Hey Daniel,

      Thanks for the heads up. I tried applying the May Cumulative update to my 1703 WIM and still had the problem afterwards, so it’s probable that that OOBE updated wasn’t related unfortunately.

      Our support call to MS has had some results. Known bug, to be fixed in a future version of Windows (no mention of whether or not this will be a Feature update or Quality update fix though).

      Regards,

      CJ

      Reply
      1. Arvind

        Hello CJ, Is it possible for you to share the response from MS, you can remove any confidential information and can share the rest of the stuff. I am sure it will be valuable information where Microsoft themselves agree that this is a known bug and the whole internet is full of people crying about this issue.

        Arvind

        Reply
  6. Tim

    Hey guys I know its not specifically related to the same error but I am having some strange issues with our Workgroup deploy task sequence in what what I believe is in a similar vein.

    See this post over on windows-noob for more info:

    https://www.windows-noob.com/forums/topic/15289-sccm-1702-win10v1703-deploy-just-a-moment/

    When you get towards the very end of the TS, our machines get stuck on “Just a Moment” forever. I can’t see anything obvious in the panther logs or smsts logs either. We are SCCM 1702 and Windows 10 1703. It looks like something wrong with OOBE. We don’t use random computer names as we specify it via a HTA menu file before we start imaging (via a variable). We are using ADK 1607 as 1702 is still flaky the last time I checked (31/05/17) and there wasn’t anything that appeared to necessary (Secureboot related not for our environment). I should also mention that the same image works fine in our Domain version of the task sequence. Both use the same sysprep answer file to enable things like en-au region/language, skip WiFi setup etc. My gut feeling is there are a bunch of new things in OOBE including Cortana that might be doing something funky that I haven’t seen before as both my 1607 Task Sequences work perfectly (have done since day 1)

    If anyone has any ideas or further infomation, It would be greatly appreciated.!

    Reply
    1. Matt Post author

      Hi Tim,

      When you get stuck at “just a moment” – can you alt tab and see if there is a UAC prompt hiding? I have the opposite experience, no issues with non-domain TS, but issues with domain joined when the GPO’s kick in.

      *EDIT* – I actually have seen it get “stuck” at the Just a moment screen, but in the background the TS is still running, if i check the status logs coming in to SCCM. The TSProgressUI is hidden, but the TS does continue. I’ve noticed this when testing BIOS to UEFI conversion mid-TS with MBR2GPT.

      Cheers,

      Matt

      Reply
      1. Tim

        Hi Matt,

        That’s whats weird about it. You can’t alt-tab or do anything besides switch it off.

        I haven’t been able to find anything else where just yet. I am trying an updated build (same reference machine from a snapshot before capture media) that this time round includes the most recent Cumulative Update that came out a couple of days ago to see if that helps.

        I thought that it might have also been an issue with something trying to get out to the internet so i tested it on a VM that had open internet access (no auth etc) to see if something like Cortana or something else was trying to phone home…unfortunately that didn’t work. As mentioned my domain joined task sequence works perfectly fine (insert hair pulling noises here!) When I looked at the logs, there was nothing obvious to me which makes me think that the TS has handed off to the OS and something else is stuck in the background and I can’t see what that “thing” is. I’d love to show this to someone in person lol. It just doesn’t make any sense 😛

        I know that not a lot of people do workgroup only TS’s and that makes it harder to find a fix combined with a new OS, new SCCM + Workgroup = somewhat rare at the moment!

        Reply
        1. Matt Post author

          If you open the SCCM status message viewer during OSD, and refresh while it’s stuck, do you see any status messages coming in from the machine?

          I’ve noticed that after setup windows and configmgr step, I will get the “just a moment” screen, but the TS is still running in the background, and I can see that in the status msg viewer. After the next reboot, it goes back to normal – yours may have a failure and be hidden?

          Try adding a restart in the TS at the point where you normally see the Just a moment screen.

          Also, not sure if you tried already, but try the deprecated SkipMachineOOBE setting in your unattend.xml – that seems to get past your issue for others

          Reply
  7. Blake

    I also encountered this issue with an MDT OSD TS using SCCM 1702 and Windows 10 Enterprise 1703. I have both GPOs to set the local administrators group and lock UAC into MS defaults. I was able to resolve the issue by modifying the unattend.xml in use with the image by ensuring that the following entries were present:

    true
    Work
    true
    true

    I found this solution at: https://www.windowsmanagementexperts.com/osd-issue-with-windows-10-1703/osd-issue-with-windows-10-1703.htm

    I would love to hear if this works for any of you.

    Reply
  8. Matt Post author

    Hey Blake,

    not sure what the settings are that correspond to your values

    I will say that today I was able to resolve the issue with the SkipMachineOOBE and SkipUserOOBE set to true, using a non-captured wim file.

    Reply
  9. Blake

    Yeah sorry about that, the post removed all the tags when I submitted it and wouldn’t let me edit. Here they are without the leading and trailing carats.

    OOBE
    HideWirelessSetupInOOBE true
    NetworkLocation Work
    SkipMachineOOBE true
    SkipUserOOBE true
    /OOBE

    Reply
  10. Westy

    I’m having a mixture of results. sometimes I see the “Something went wrong” screen and other times I don’t. However I always see the “Alright, you’re connected. Now we’ll check for any updates…” screen. This screen only occurs upon the very first login after the OSD Task Sequence has finished.

    The setupact.log file shows the following error among a few others:
    [CloudExperienceHostBroker.exe] Disabling default account failed [hr=0xD00000E5]

    What I’ve noticed from one of our 1607 Windows 10 clients is that the setupact.log file shows no “CloudExperienceHostBroker.exe” messages during login.

    I’m now at a stage where I’ve tried all the suggestions I’ve read online and none work, I’m now going to log an MS support call but suspect I’ll be told about the “common bug” and get fobbed off. Let’s see.

    Reply
    1. Craig Jarvis

      We’ve gone the support call route. Known issue, will be resolved in the next CB release (so not when 1703 goes CBB).

      As a side note, setting the supposedly deprecated unattend.xml file settings for SkipMachineOOBE and SkipUserOOBE to false is a usable workaround for us.

      Regards,

      CJ

      Reply
  11. Westy

    I’ve managed to fix it in my environment, and it was indeed the group policy issue described above.

    I had to go back and recreate my base WIM in a build and capture TS. I used an unattend file that only applied some basic settings: Locale/language settings, registered organisation, timezone, and all the skip OOBE settings. I think the issue was where the build and capture VM was being placed in AD when it joined the domain in the TS. It was receiving a few GPOs and one being related to the Administrators groups and I think this must have tarnished the WIM. So, I changed this to an OU in AD that had no GPOs assigned to it.

    When I come to deploy this WIM in my deploy TS I then apply the image using a different unattend.xml file that includes settings to create a custom local admin account (I didn’t want to include this when creating the base WIM like we used to in case it was causing the issue). As soon as the machine reached the login screen I could immediately see that the setupact.log file looked a lot better than before. I logged in and was greeted with the usual “Hi, we’re glad you’re here” windows 10 screens and not the others.

    So for those that see this issue please try recreating your WIM and ensure that when the reference machine joins the domain that it is placed into an OU that has no GPOs attached to it.

    Hope this can help someone.

    Reply
  12. Craig Jarvis

    This has been fixed in the July cumulative update. I can confirm that it works.

    Regards,

    CJ

    Reply
    1. Tim

      Hi Craig,

      Can you share the actual KB article for that CU as there has been a few CU updates released recently.

      Reply
        1. Tim

          Thanks. I’ll be updating our image this month sometime that should include that CU and any current patches at that time 🙂

          Reply
  13. Tim

    Also I should mention that we revolved the issue of “Just a moment” in our Workgroup deploy task sequence. It turns out the defauluser account that we used to delete in previous versions of 10 (1511 and 1607) was causing the TS to get stuck. It seems that Windows actually needs to use this account now during the OOBE phase for reasons I’m not 100% sure why. We have now removed this step and it works perfectly fine now

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *