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