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

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.

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.

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.

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 🤔

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.

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.

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.

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.

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.

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.!

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.

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!

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

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:

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.

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.

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