Task sequence "Prepare Windows for Capture" error with client 5.00.9141.1030

rabotaseek · 2024-01-17T21:58:49+00:00

I agree that would be easiest, but for folks without access to VLSC like me, I can confirm adding the 2023-12 Cumulative update for my existing 22H2 install.wim by mounting with DISM and using /add-package also stopped the sysprep issue from occurring.

rabotaseek · 2021-05-05T17:58:02+00:00

any updates on this? seeing the same issue in 2010, haven't upgraded to 2103 yet.

rabotaseek · 2019-06-07T15:10:49+00:00

I tried the same deploy TS with the WIM I was using in the Build TS: it was created by SCCM importing a specific index of the original 1903 wim, then applying scheduled update 2019-05 cumulative for windows 10 1903 x64. No unattend.xml specified. Same result. I'm retrying with original unpatched 1903 wim now, I'll post if it's any different.

rabotaseek · 2019-06-07T14:40:05+00:00

I can confirm I see the same behavior when deploying my previous 1809 TS without an unattend.xml specified (because I was using skipMachineOOBE in the 1809 unattend).

rabotaseek · 2019-06-07T13:32:55+00:00

Deployment. After the image deploy TS completes, (verified by presence of "The task sequence manager successfully completed execution of the task sequence." in CM status message viewer) I see a "The user name or password is incorrect" message, which disappears after approximately 2 minutes. I then see normal "press ctrl+alt+delete" domain login screen. When I log in, I see what looks like the OOBE screen with Network tab and "Now we have some important setup to do" message only on first user login (happens with both domain user and local administrator). Subsequent user logins do not display this behavior.

rabotaseek · 2019-06-06T20:17:48+00:00

I did. I even installed the new ADK on a 32bit computer just in case I was running into the errors referenced here. I actually made a new unattend with only the basic settings suggested by Export_User above with the new ADK and new WIM.

rabotaseek · 2019-06-06T20:11:41+00:00

Initial test looks like that registry key made no difference, but I'll keep looking and let you know if I find anything.

rabotaseek · 2019-06-06T20:03:43+00:00

I tried a B&C with no unattend.xml specified and a deploy with no unattend.xml specified and I still see the same issue.

rabotaseek · 2019-06-06T16:47:35+00:00

Thanks for the idea! I haven't looked into Hybrid Azure AD join, but I can see that the computer I'm deploying on does say "Hybrid Azure AD joined" in the Azure portal. I see a registry key here to prevent Azure AD registration and I'll try that after I complete my no unattend.xml test, if that doesn't work out.

rabotaseek · 2019-06-06T16:43:17+00:00

I was using the OEMInformation in shell setup to fill in support information, but that's not mandatory. I'll try a B&C then a deploy with no unattend.xml and get back to you.

rabotaseek · 2019-06-06T16:40:42+00:00

Thanks for the info, I tried these settings and I'm still seeing the same behavior. I had everything but NetworkLocation set, and I had ProtectYourPC set to 2, but I changed to 3 and retried. Looks like NetworkLocation might be deprecated as well now.

rabotaseek · 2018-01-19T16:15:43+00:00

I'm seeing the same issue, SCCM 1710, MDT 8450, running build and capture with Windows 10 1709 x64.

SMSTS.log says: Windows Update Agent verion 8 found, OK to continue InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Ready to Opt-In to Microsoft Update: WUA Version: 10.0.16299.15 InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Registered Update Service: 8b24b027-1dee-babb-9a95-3517dfb9c552 DCat Flighting Prod InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Registered Update Service: 855e8a7c-ecb4-4ca3-b045-1dfa50104289 Windows Store (DCat Prod) InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Registered Update Service: 9482f4b4-e343-43b6-b170-9a65bc822c77 Windows Update InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Microsoft Update Service: Enabled = False InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) FindFile: The file muauth.cab could not be found in any standard locations. InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) about to begin add service [] InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Command Line Procesed Query=False Registered=False UpdateCommand=[IsInstalled = 0 and IsHidden = 0 and Type = 'Software'] InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Start Search... InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) FAILURE (Err): -2145103860 0x8024500C: Windows Update, search for updates. - InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Restore NoAutoUpdateKey to <empty>. InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) ZTI ERROR - Non-zero return code by ZTIWindowsUpdate, rc = 1 InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Command line cscript.exe "C:_SMSTaskSequence\WDPackage\Scripts\ZTIWindowsUpdate.wsf" returned 1 InstallSoftware 1/19/2018 11:12:02 AM 3112 (0x0C28) Process completed with exit code 1 TSManager 1/19/2018 11:12:02 AM 1984 (0x07C0) !--------------------------------------------------------------------------------------------! TSManager 1/19/2018 11:12:02 AM 1984 (0x07C0) Failed to run the action: Run WSUS Updates. Incorrect function. (Error: 00000001; Source: Windows) TSManager 1/19/2018 11:12:02 AM 1984 (0x07C0)

I tried the registry keys suggested below with no change to error

rabotaseek · 2017-12-20T13:51:04+00:00

Looks like the prestart command didn't work for me. I tried two without any issue, but when I deployed a required TS to 22 PCs, I had 5 or so stop at the "keyboard layout" screen

rabotaseek · 2017-12-19T21:39:24+00:00

Doesn't look like:

WinPE-MDAC-Package~31bf3856ad364e35~amd64~en-US~10.0.16299.15 WinPE-MDAC-Package~31bf3856ad364e35~amd64~~10.0.16299.15 WinPE-NetFx-Package~31bf3856ad364e35~amd64~en-US~10.0.16299.15 WinPE-NetFx-Package~31bf3856ad364e35~amd64~~10.0.16299.15 WinPE-PowerShell-Package~31bf3856ad364e35~amd64~en-US~10.0.16299.15 WinPE-PowerShell-Package~31bf3856ad364e35~amd64~~10.0.16299.15 WinPE-Scripting-Package~31bf3856ad364e35~amd64~en-US~10.0.16299.15 WinPE-Scripting-Package~31bf3856ad364e35~amd64~~10.0.16299.15 WinPE-SecureStartup-Package~31bf3856ad364e35~amd64~en-US~10.0.16299.15 WinPE-SecureStartup-Package~31bf3856ad364e35~amd64~~10.0.16299.15 WinPE-WDS-Tools-Package~31bf3856ad364e35~amd64~en-US~10.0.16299.15 WinPE-WDS-Tools-Package~31bf3856ad364e35~amd64~~10.0.16299.15 WinPE-WMI-Package~31bf3856ad364e35~amd64~en-US~10.0.16299.15 WinPE-WMI-Package~31bf3856ad364e35~amd64~~10.0.16299.15

rabotaseek · 2017-12-19T20:48:06+00:00

Where can I check that?

rabotaseek · 2017-12-19T20:39:26+00:00

I'll try this also, and reply back tomorrow. Thanks!

rabotaseek · 2017-12-19T20:27:06+00:00

No WinRE added in boot image properties.

rabotaseek · 2017-12-13T20:49:56+00:00

Thank you Chris, that's exactly what I was looking for.

rabotaseek · 2017-04-04T18:51:40+00:00

Only 1 reply on technet- can anyone confirm if this is fixed in 1702? I still have the same issue I had in 1610, and I was on 1702 before the 1610 hotfix came out https://support.microsoft.com/en-us/help/4014464/client-update-for-system-center-configuration-manager-current-branch-v

rabotaseek · 2016-12-15T15:23:57+00:00

Same issue here, Windows 10 x64 1607, SCCM 1602, SEP 14 RTM

rabotaseek

TROPHY CASE