Unable to capture a new WIM

Hi Guys,

Imhaving some trouble trying to capture a new WIM.

I was able to do the first WIM and I have been using it. but now I want to do a separate image with apps installed. and then put it on a USB for Offline deployment. However its not capturing, it completes all the way successfully. But there is no new WIM just new test files o.O
What am I missing? can you only capture one wim unless its a new bundle? I did try different bundles but nothing either.

Im assuming its working as expected :-/ ?

Hi, I assume you are capturing the WIM using the OSD site dashboard.
There is no limitation in the number of WIMs that you can capture.
Does the BigFix action complete successfully? Can you show the action log?
Thanks

Correct. I’m using the dashboard.

and then it compleates and nothing :frowning:

You’ll need to watch what is happening on the endpoint to see where it is failing.

From a Bigfix view, the task is “complete” when the windows PE image is downloaded, configured to boot, and reboots the system. You don’t get visibility into the process because the sysprep & capture process involves rebooting into WinPE where there is no Bigfix client.

If the boot into WinPE fails for any reason (usually, no network or storage driver); or the system doesn’t get an IP address, can’t reach the network share, or has wrong credentials…the Bigfix client can’t see any of that.

Hi,
you should find useful logs on the target computer on the system partition in the folder Windows\Temp\DeploymentLogs. Could you please attach them?
If the computer is still in the initial OS, it’s on C: partition, if it already rebooted to WinPE (but I think it’s not your case, otherwise you should see a red window with the error reported on the target computer), the partition letter depends on the mapping of WinPE of the partitions but it should be c: or d:. In this last case, you have to hit twice the ESC key to show the background, break the script running in the dos shell with ctrl-c (“Y” to confirm) to access and copy the files.
Thanks.

I was able to find the files. there are multiple .log files. not sure which one or what I shohd be looking for.
so I see pop-up comes up saying that is getting ready to capture. and then the capturing window comes up and then it goes away an nothing happens. the system doesnt even reboot to try to go into PE

Hi, all the logs files are needed (you can compress them to a zip file if you want to attach). The first to look at is BDD.log but then other files in the same folder could be needed to have more details on the failure.
Thanks.

Last log shows like this:
Setupact.log
2019-04-26 09:38:43, Info SYSPRP ========================================================
2019-04-26 09:38:43, Info SYSPRP === Beginning of a new sysprep run ===
2019-04-26 09:38:43, Info SYSPRP ========================================================
2019-04-26 09:38:43, Info [0x0f004d] SYSPRP The time is now 2019-04-26 09:38:43
2019-04-26 09:38:43, Info [0x0f004e] SYSPRP Initialized SysPrep log at C:\Windows\system32\sysprep\Panther
2019-04-26 09:38:43, Info [0x0f0054] SYSPRP ValidatePrivileges:User has required privileges to sysprep machine
2019-04-26 09:38:43, Info [0x0f007e] SYSPRP FCreateTagFile:Tag file C:\Windows\system32\sysprep\Sysprep_succeeded.tag does not already exist, no need to delete anything
2019-04-26 09:38:43, Info [0x0f005f] SYSPRP ParseCommands:Found supported command line option 'REBOOT’
2019-04-26 09:38:43, Info [0x0f003d] SYSPRP WinMain:Displaying dialog box for user to choose sysprep mode…
2019-04-26 09:39:26, Error [0x0f0043] SYSPRP WinMain:The sysprep dialog box returned FALSE
2019-04-26 09:39:26, Info [0x0f0052] SYSPRP Shutting down SysPrep log
2019-04-26 09:39:26, Info [0x0f004d] SYSPRP The time is now 2019-04-26 09:39:26

and the other log files shows:

2019-04-19 17:35:28, Error      [0x0f0043] SYSPRP WinMain:The sysprep dialog box returned FALSE
2019-04-26 09:16:24, Error      [0x0f0043] SYSPRP WinMain:The sysprep dialog box returned FALSE
2019-04-26 09:39:26, Error      [0x0f0043] SYSPRP WinMain:The sysprep dialog box returned FALSE

the password I copy paste to make it wasnt a missed type.
Since The system is not part of the domain. I have been Authenticating to the folder manually and then running the capture. in the past when I haven’t done that. it had failed.

Hello,
it’s not clear to me, I have never seen this issue before but it seems that a dialog box has been displayed from sysprep and after less than one minute the sysprep has been stopped.
Did you see this dialog box?
Thanks.

I also tried to do the local account option, since I read in the article you suggested that can cause problems due to .APPX and that doesn’t work. its frustrating.

now: I also went into the MDT tool and modified some stuff, but I’m not sure if this its the problem since I have the original MDT bundle that I used to capture in the past and Im not using the new one I modified.

Hi,
the local account options can be applied in the case that is described in the documentation but it’s not your case.
If you are now using the original MDT Bundle, even if you have an MDT Bundle where the scripts and task sequences have been modified in your MDT Bundle list, the original one is used. Which is the MDT bundle version you are using?
Do you see the sysprep dialog box to pop up during the capture task?
Thanks.

I get the BigFix window pop up for a second saying that the system is being captured and then it goes away.
In some cases I have seen the MDT one come up but the system doesnt reboot to begin capture.

Looking at the size, the official MDT Bundle seems to be the MDT Bundle 2_0 Test. If no script or task sequence has been changed in it and you still have the same issue, I suggest to open a ticket to product support.
Thanks.

Thank you Sergio. I did. they haven’t helped much. My experienced so far has been. here is an article. good luck. I havent opened tickets in the past and I have resolved all of them with the Forum, instead of the tickets that I opened up.
It might be my lack of knowledge on the product and these people might just dont wanna deal with users like me. anywho :smiley: there is my venting of the day.