Answered by:
Windows 10 OOBE Fails when running Sysprep after domain join.

Question
-
Has anyone been able to successfully sysprep /generalize Windows 10 (Volume license edition) after joining to a domain, and get it to boot back up with no errors?
I can install windows 10, make NO changes at all, run sysprep /generalize, and it works fine. But if i Install windows 10 and the only change is joining it to the domain, then setup fails on next reboot with the following error. i have even tried removing it from the domain and it doesn't help.
C:\Windows\Panther\setuperr.log doesn't seem to be much help. just has one error about ReAgentXMLParser (this error seems to show up even when sysprep works so i think it's unrelated).
C:\Windows\System32\Sysprep\Panther\setuperr.log doesn't seem to be much help either. Just has an error about "setupdigetclassdevs failed with error 0" (that seems to be pretty common too).
So joining the domain breaks sysprep /generalize and setup. but i can't seem to figure out why...
Oh, and one more thing to note. i have tried using my own custom unattend.xml and also running without a custom unattend.xml (by using the Sysprep GUI).
I should also mention that i am doing this on a VM. i wouldn't think that would matter since i have done that for years.
Friday, August 21, 2015 5:01 PM
Answers
-
I just figured it out FINALLY! KMS activation..... after activating with KMS then it works fine.
- Marked as answer by Jaybird283 Tuesday, November 3, 2015 9:52 PM
Tuesday, November 3, 2015 9:52 PM
All replies
-
Don't join the computer to the domain prior to sysprep. Also do not log into any other account besides Administrator while in audit mode.Friday, August 21, 2015 5:16 PM
-
I don't use audit mode. i also prefer to join the domain while i am building the image. i don't mind removing it from the domain later if needed but that doesn't seem to be a fix in this case.
Friday, August 21, 2015 5:19 PM -
I wanted to post some Errors/Warnings in the Setupact.log from Windows\Panther in case anyone knows if they are related.
2015-08-20 17:52:07, Warning SYSPRP ActionPlatform::GetValue: Error from RegQueryValueEx on value SysprepMode under key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Sysprep; dwRet = 0x2
2015-08-20 17:52:35, Error [setup.exe] ReAgentXMLParser::ParseConfigFile (xml file: \Recovery\ReAgentOld.xml) returning 0X2
2015-08-20 17:52:07, Warning SYSPRP ActionPlatform::GetValue: Error from RegQueryValueEx on value SysprepMode under key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Sysprep; dwRet = 0x2
2015-08-20 17:52:28, Warning SYSPRP Ignoring folder Deleted because could not convert to family name
2015-08-20 17:52:35, Warning TOOL SpecializeBcdStore: The /detecthal switch could not be removed because it was not found.
2015-08-20 17:52:35, Warning SYSPRP ActionPlatform::DeleteValue: Registry value DecompressOverride to be deleted does not exist under key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
2015-08-20 17:52:35, Warning SYSPRP ActionPlatform::DeleteValue: Registry value SysprepMode to be deleted does not exist under key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Sysprep
2015-08-20 17:52:35, Warning [0x0f008f] SYSPRP RunRegistryDlls:Registry key is either empty or malformed: SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\SysPrepExternal\Specialize
- Edited by Jaybird283 Friday, August 21, 2015 5:26 PM
Friday, August 21, 2015 5:20 PM -
As I know, the sysprep /generalize will clean the domain joined information.
If you would like to deploy Windows 10 with domain joined, please use the unattended file during OOBE.
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.
- Proposed as answer by Kate LiMicrosoft employee Monday, August 31, 2015 2:35 PM
- Marked as answer by MeipoXuMicrosoft contingent staff Wednesday, September 2, 2015 1:02 AM
- Unmarked as answer by Jaybird283 Wednesday, September 2, 2015 5:32 PM
Sunday, August 30, 2015 3:20 AM -
Kate, I unmarked this reply as the answer since it doesn't resolve the issue. it's helpful information but the problem still exists.Wednesday, September 2, 2015 5:34 PM
-
Is that your opinion or is that documented by Microsoft that we should not join a machine to the domain prior to sysprep? from what I have read it's ok to join the domain and the /generalize switch will remove it from the domain when you run sysprep.
Wednesday, September 2, 2015 5:37 PM -
Just tried a physical laptop in BIOS mode. same problem.
the simple act of joining the domain before running sysprep /generalize causes this issue. even straight out of the box windows 10 install.
Something odd I noticed though while doing the initial windows 10 install, is that it looks like I choose my network (or skip choosing one) during the initial OOBE then it reboots (I think it reboots) and asks me a second time. I wonder if there is a problem with the first windows setup that causes some sort of reboot or reprompt. (I wasn't actually looking but it does prompt me twice).
Wednesday, September 2, 2015 10:50 PM -
Is that your opinion or is that documented by Microsoft that we should not join a machine to the domain prior to sysprep? from what I have read it's ok to join the domain and the /generalize switch will remove it from the domain when you run sysprep.
Documentation shows that it is true that if the PC is joined to a somain, then sysprep will remove the domain membership. It is also true that sysprep may not remove all GPOs assigned to the PC. As such, these GPOs may cause a problem with the operation of sysprep, or the first boot process. One example of a GPO that isn't removed is the Strong Password policy, however I do not know of a list of what is and isn't removed by Sysprep. In my experience, it is a best practice to not join an image system to a domain as it often causes more problems than it is worth.
Since it is documented that Sysprep will remove domain membership, it is not going to save you the step of joining the PC to the domain after the image is deployed.
Regarding your posted log files, do you have anything in Panther\UnattendGC?
Thursday, September 3, 2015 3:26 PM -
Is that your opinion or is that documented by Microsoft that we should not join a machine to the domain prior to sysprep? from what I have read it's ok to join the domain and the /generalize switch will remove it from the domain when you run sysprep.
Documentation shows that it is true that if the PC is joined to a somain, then sysprep will remove the domain membership. It is also true that sysprep may not remove all GPOs assigned to the PC. As such, these GPOs may cause a problem with the operation of sysprep, or the first boot process. One example of a GPO that isn't removed is the Strong Password policy, however I do not know of a list of what is and isn't removed by Sysprep. In my experience, it is a best practice to not join an image system to a domain as it often causes more problems than it is worth.
Since it is documented that Sysprep will remove domain membership, it is not going to save you the step of joining the PC to the domain after the image is deployed.
Regarding your posted log files, do you have anything in Panther\UnattendGC?
+1 this. Just don't do it. OR - at least unjoin the domain before you sysprep the machine. One could also ask: why do you need to join the domain before sysprepping your reference image? Could this be done another way without needing to join the domain?Thursday, September 3, 2015 3:36 PM -
Thanks for taking the time to bring up those GPO points.
Here is the contents of the UnattendGC\SetupErr.log (If I could figure out how to attach files then I would upload more logs). let me know if you need any other logs.
2015-08-03 10:07:38, Error [msoobe.exe] Failed to end completed WU ZDP search [hr=0x80072EE2]
2015-08-03 10:07:38, Error [msoobe.exe] TASK: End failed running task ZDP with hr=0x80072EE2.
2015-08-03 10:41:14, Error [msoobe.exe] Failed to end completed WU ZDP search [hr=0x80072EE2]
2015-08-03 10:41:14, Error [msoobe.exe] TASK: End failed running task ZDP with hr=0x80072EE2.
2015-09-01 11:37:44, Error [msoobe.exe] Failed to set password and password hint with hr=0xD000006C
2015-09-01 11:37:44, Error [msoobe.exe] Failed to create the default account with hr=0xD000006C
2015-09-01 11:37:44, Error [msoobe.exe] TASK: End failed running task PrepareUserOOBE with hr=0xD000006C.
2015-09-01 11:37:47, Error [msoobe.exe] Failed user OOBE prep task with hr=0xD000006C
2015-09-01 11:38:28, Error [msoobe.exe] Failed to end completed WU ZDP search [hr=0x80072EE2]
2015-09-01 11:38:28, Error [msoobe.exe] TASK: End failed running task ZDP with hr=0x80072EE2.
2015-09-01 11:39:01, Error [msoobe.exe] Failed to run OOBE Host with hr=0x80004005
2015-09-01 11:39:01, Error [msoobe.exe] OOBE failed with hr=0x80004005
2015-09-01 11:39:01, Error [oobeldr.exe] OOBE UI failed with exit code [0x80004005]Thursday, September 3, 2015 5:37 PM -
Would be interested to see what the UnattendGC\setuperr.log looks like on an instance where the OS was not joined to the domain prior to sysprep, for comparison purposes.
- Edited by Tripredacus Friday, September 4, 2015 2:04 PM
Friday, September 4, 2015 2:03 PM -
Tripredacus, Here you go. This is what unattendgc\setuperr.log looks like when it works on a machine that's not joined to the domain.
2015-09-04 10:08:38, Error [msoobe.exe] Failed to end completed WU ZDP search [hr=0x80072EE2]
2015-09-04 10:08:38, Error [msoobe.exe] TASK: End failed running task ZDP with hr=0x80072EE2.
2015-09-04 14:03:51, Error [msoobe.exe] Failed to end completed WU ZDP search [hr=0x80072EE2]
2015-09-04 14:03:51, Error [msoobe.exe] TASK: End failed running task ZDP with hr=0x80072EE2.
2015-09-04 14:19:12, Error [msoobe.exe] Failed to re-set default account's password with hr=0x80070525
2015-09-04 14:19:56, Error [msoobe.exe] Failed to end completed WU ZDP search [hr=0x80072EE2]
2015-09-04 14:19:56, Error [msoobe.exe] TASK: End failed running task ZDP with hr=0x80072EE2.Friday, September 4, 2015 8:02 PM -
Ah so you can see what are maybe false negatives in the error log. Searching an error in the first one reveals you are the only person to have posted this error! At least that Google can find.Tuesday, September 8, 2015 7:12 PM
-
Would be nice if someone could install windows 10, join a domain, run sysprep /generalize, and see if it throws the error during OOBE. (it looks like its failing right before what would normally be the screen to create a user account).
Then i would know if it's something on our domain, or if it's a windows bug.
Wednesday, September 9, 2015 4:43 PM -
I have exactly same problem. After syspreped image is restored to a machine it asks for network connection and after that step it crashes and asks to restart and the magic loop begins.
I do not understand why joining a domain became a problem in win10 because win7 and win8 are perfectly OK with any sort of joined/unjoined scenarios, plus it is much more comfortable to prepare system image while it is joined to domain rather than individually joining it to domain later.
I haven't tried to syspep an pc that has not joined domain, but if someone has, please share if it works... I've had it creating a syspreped volume for five damn times and facing the same lame error at the last stage of installation....
Monday, September 14, 2015 5:23 AM -
I can confirm this happens. I deployed my Windows 10 Pro image to audit mode. Joined the domain and then sysprep /oobe /generalize /restart. It crashes after chosing to skip joining wireless network (using a notebook for test) and choose Express Settings. I get different errors. This from setuperr.log in UnattendGC:
2015-09-14 05:23:59, Error [msoobe.exe] Failed to install product key ((null)) with hr=0xC004E016 2015-09-14 05:23:59, Error [msoobe.exe] TASK: End failed running task InstallPid with hr=0xC004E016. 2015-09-14 08:24:39, Error [msoobe.exe] Failed to set password and password hint with hr=0xD000006C 2015-09-14 08:24:39, Error [msoobe.exe] Failed to create the default account with hr=0xD000006C 2015-09-14 08:24:39, Error [msoobe.exe] TASK: End failed running task PrepareUserOOBE with hr=0xD000006C. 2015-09-14 08:24:48, Error [msoobe.exe] Failed user OOBE prep task with hr=0xD000006C 2015-09-14 08:24:48, Error [msoobe.exe] Failed to run OOBE Host with hr=0x80004005 2015-09-14 08:24:48, Error [msoobe.exe] OOBE failed with hr=0x80004005 2015-09-14 08:24:48, Error [oobeldr.exe] OOBE UI failed with exit code [0x80004005]
You see a jump in the time there from 05 to 08. This is because I changed the time zone in OOBE. This is shown in UnattendGC\setupact.log:
2015-09-14 05:24:39, Info [msoobe.exe] UPDATE: running for timedate 2015-09-14 08:24:39, Info [msoobe.exe] Set time zone to [Eastern Standard Time] 2015-09-14 08:24:39, Info [msoobe.exe] UPDATE: succeeded for plugin timedate
The next page that is shown is the EULA, however the log shows that in between the Localization page and the EULA page, it tries to set up the Default account. And this fails:
2015-09-14 08:24:39, Info [msoobe.exe] Changing page to [Eula] 2015-09-14 08:24:39, Info [msoobe.exe] KILLACTIVE: wizard page for page Localization 2015-09-14 08:24:39, Info [msoobe.exe] SETACTIVE: wizard page for page Eula 2015-09-14 08:24:39, Info [msoobe.exe] Processing cache change notification for setting GLOBALIZATIONCOMMITTED. 2015-09-14 08:24:39, Info [msoobe.exe] TASK: Begin running task PrepareUserOOBE... 2015-09-14 08:24:39, Info [msoobe.exe] Creating a new default account 2015-09-14 08:24:39, Error [msoobe.exe] Failed to set password and password hint with hr=0xD000006C 2015-09-14 08:24:39, Error [msoobe.exe] Failed to create the default account with hr=0xD000006C 2015-09-14 08:24:39, Error [msoobe.exe] TASK: End failed running task PrepareUserOOBE with hr=0xD000006C. 2015-09-14 08:24:41, Info [msoobe.exe] Next button was clicked 2015-09-14 08:24:41, Info [msoobe.exe] UPDATE: running for eula
After this, I get the wireless network settings, which I choose to skip and that action is recorded in the log file. Then it shows the page for RecommandedSettings, which is the one with the Express Settings button. For ease of testing I just clicked that. Now to note, it still has not asked for a user account yet. I see this in the log:
2015-09-14 08:24:48, Info [msoobe.exe] Not creating local user because a connected user will be created in User OOBE
2015-09-14 08:24:48, Info [msoobe.exe] COMMIT: running for plugin ConnectedUser Plugin
2015-09-14 08:24:48, Info [msoobe.exe] Account creation deferred to User OOBE. Skipping ConnectedUser Commit.
2015-09-14 08:24:48, Info [msoobe.exe] COMMIT: succeeded for plugin ConnectedUser Plugin
2015-09-14 08:24:48, Info [msoobe.exe] COMMIT: running for plugin LocalUser PluginLater is the Failed User OOBE prep task error from setuperr.log. Then it completes the OOBE process as noted here:
2015-09-14 08:24:48, Info [msoobe.exe] KILLACTIVE: wizard page for page End 2015-09-14 08:24:48, Info [msoobe.exe] OOBE wizard finishing - preparing final UX before destroying wizard. 2015-09-14 08:24:48, Info [msoobe.exe] Triggering fade to black to end OOBE UI 2015-09-14 08:24:48, Info [msoobe.exe] Posting Quit message after Fade To Black Transition Complete 2015-09-14 08:24:48, Info [msoobe.exe] Main Wizard message loop finished 2015-09-14 08:24:48, Info [msoobe.exe] Finished running wizard with hr=0x00000000 2015-09-14 08:24:48, Info [msoobe.exe] Ensuring netprofm task is complete. 2015-09-14 08:24:48, Info [msoobe.exe] Wrote End-of-OOBE Timestamp to Registry 2015-09-14 08:24:48, Info [msoobe.exe] License for msoobe-FirstLogonAnim-MayBeDisabled is false 2015-09-14 08:24:48, Info [msoobe.exe] Converting aborted OOBE to E_FAIL 2015-09-14 08:24:48, Error [msoobe.exe] Failed to run OOBE Host with hr=0x80004005 2015-09-14 08:24:48, Error [msoobe.exe] OOBE failed with hr=0x80004005 2015-09-14 08:24:48, Info [msoobe.exe] Ending OOBE 2015-09-14 08:24:48, Info [msoobe.exe] ---------------------------------------------------------- 2015-09-14 08:24:48, Error [oobeldr.exe] OOBE UI failed with exit code [0x80004005]
Which is the last part of setupact.log. So the problem would actually appear to be that it can't create the Default user account and OOBE doesn't ask for a username. This would leave the OS with no accounts available as the Administrator account is disabled.
I will test again with 2 scenarios. One where I don't generalize the OS, and one where I do but create an user in Audit Mode first.
Monday, September 14, 2015 4:56 PM -
Tripredacus and TonySpark, Thank you for your replies, its good to know that i am not the only one having this issue.
Monday, September 14, 2015 5:08 PM -
Using /Generalize isn't part of the issue here. I repeated the same steps without generalizing and it still happens. Also, having a pre-existing local in the Administrator's group doesn't matter either. I did encounter 1 instance where the OS blew up after joining the domain, after the required restart but before running sysprep. This was logged in Panther\UnattendGC:
2015-09-14 06:54:07, Info [audit.exe] GetAdminAccountName: Local built-in admin account name is [Administrator] 2015-09-14 06:54:07, Error [audit.exe] EnableLocalUserAccount: Unable to enable local account [Administrator]; status = 0x8c5 2015-09-14 06:54:07, Error [audit.exe] Unable to enable local account [Administrator]; hr = 0x800708C5 2015-09-14 06:54:07, Error [audit.exe] Failed to arrange for [C:\windows\system32\oobe\audit.exe /user] to be called after logon; hr = 0x800708c5 2015-09-14 06:54:34, Info [audit.exe] Audit.exe exiting with code [0x800708c5]... 2015-09-14 06:54:34, Info [windeploy.exe] Process exited with exit code [0x800708c5] 2015-09-14 06:54:34, Error [windeploy.exe] Command [%windir%\system32\oobe\audit.exe /system] failed with exit code [0x800708c5] 2015-09-14 06:54:34, Error [windeploy.exe] Failure occured during online installation. Online installation cannot complete at this time.; hr = 0x80004005 2015-09-14 06:54:34, Info [windeploy.exe] Windeploy: Executing OnError commands
I did a compare of Administrator and DefaultAccount pre-join, post-join-pre-restart, post-join-post-restart using NET USER and there was no change. I also ran GPRESULT /r but no policies were applied to the accounts either.
Jaybird283, please note I am not "having this problem" because I don't use this process. As previously noted, it is not best practice to join an OS to the domain prior to sysprep. I am only able to do this work because it is easy to replicate. Call it... a helping hand. :)
Monday, September 14, 2015 7:21 PM -
Thanks for the detailed information. it's a huge help.
I should mention that removing it from the domain doesn't fix the issue. the result is that once a machine is joined to the domain then it's never possible to sysprep it without breaking the image (at least in my case).
Other than the fact that many of us that build images prefer to join them to the domain while building them, there are situations where you need to create an image from a machine that has been joined to the domain before. I'm sure it's resonable to understand that.
This sounds to me like a bug in the way that the OOBE phase works.
By the way, i just tried this on a 32bit Windows 10 Pro VL install and it does the same thing.
I opened up the Setup.etl and found a ton of "information" errors. (two that stand out and show up multiple times).
"The description for Event ID 5123 from source Microsoft-Windows-OOBE-Machine-DUI cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer."
"The description for Event ID 105 from source Microsoft-Windows-Services cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer."
Yeah Buddy!
Wednesday, September 16, 2015 9:39 PM -
I was having the same problem and figured out a way around it.
- remove machine from domain
- gpupdate /force /boot to remove any lingering domain group policies
- reboot
- sysprep.exe /generalize /oobe /shutdown /mode:vm (or whatever options you need)
Monday, October 12, 2015 4:15 PM -
I'm having this same issue. Nothing I have tried has worked including Jem's solution above. Anyone else have any ideas?Wednesday, October 14, 2015 1:28 PM
-
I just figured it out FINALLY! KMS activation..... after activating with KMS then it works fine.
- Marked as answer by Jaybird283 Tuesday, November 3, 2015 9:52 PM
Tuesday, November 3, 2015 9:52 PM -
Jay, can you expand on your answer?
Right now I have a VM that I've built (joined to a domain and KMS activated), that I'm looking to transfer to physical machines. I'm holding off on syspreping because it just occurred to me that this could be an issue.
Monday, November 9, 2015 4:11 AM -
Just take a snapshot and give it a try. That's why I build my images on a VM, if something breaks then you can just revert. The point I was making was that the problem went away after the machine was activated with KMS.Monday, November 9, 2015 5:51 AM
-
It would appear that the OS being activated has some bearing on the outcome of this issue, however I do not think that is the actual solution. The reason being is that the issue occurs on other editions that do not use KMS for licensing.
Tuesday, November 10, 2015 5:56 PM -
Is that your opinion or is that documented by Microsoft that we should not join a machine to the domain prior to sysprep? from what I have read it's ok to join the domain and the /generalize switch will remove it from the domain when you run sysprep.
Documentation shows that it is true that if the PC is joined to a somain, then sysprep will remove the domain membership. It is also true that sysprep may not remove all GPOs assigned to the PC. As such, these GPOs may cause a problem with the operation of sysprep, or the first boot process. One example of a GPO that isn't removed is the Strong Password policy, however I do not know of a list of what is and isn't removed by Sysprep. In my experience, it is a best practice to not join an image system to a domain as it often causes more problems than it is worth.
Since it is documented that Sysprep will remove domain membership, it is not going to save you the step of joining the PC to the domain after the image is deployed.
Regarding your posted log files, do you have anything in Panther\UnattendGC?
In my case the error in the log file was: "failed to re-set default account's password with hr=0x80070525"
For this case I found the solution, thanks for the hint by Tripredacus concerning the password policy. The reason was really that the machine was joined to a domain before image creation, and the sysprep hasn't removed the strong password policy settings. But you can do it manually when the error message shown.
- Press Shift+F10 to open a command prompt
- type secpol.msc + enter
- navigate to Account policies > Password policy
- Set "Password must meet complexity requirements" to disabled
- Set "Minimum password lenght" to 0 (I'm not sure if it's really necessary
- Reboot (restart the install)
- Edited by Horváth Balázs Wednesday, April 20, 2016 5:52 PM
- Proposed as answer by Horváth Balázs Wednesday, April 20, 2016 5:52 PM
- Unproposed as answer by Horváth Balázs Thursday, April 21, 2016 8:28 AM
- Proposed as answer by David Blancard Tuesday, December 6, 2016 7:42 PM
Wednesday, April 20, 2016 5:49 PM -
I have the same issue, and this works for me thank you for your help.Thursday, May 26, 2016 2:31 PM
-
This resolved this issue for me.
Tuesday, December 6, 2016 7:43 PM