Sysprep and Capture fails.


  • Host OS: Windows 10 Enterprise 1607 x64 & VMware Workstation 14.

    Guest OS: Windows 10 Enterprise 1803 x64

    I cannot execute a sysprep and capture task sequence for MDT 2013 (latest version) because sysprep strips out the NIC driver during its process. Brilliant, BTW... Is there a way to stop sysprep from doing that? Online suggestions advise to convert the e1000 vNIC to vmxnet3. How does one do this? I can find nothing that actually says how to do so in VMware Workstation. Sure, for vSphere, or VA, but not Workstation. I did try editing the VMX file with the line:

    ethernet0.virtualDev = "e1000e"

    to read

    ethernet0.virtualDev = "vmxnet3"

    ...but this did nothing. I've tried both with VMware Tools installed and uninstalled. I did not have these problems capturing 1607. Anything else I can try? Besides switch to Hyper-V, which doesn't run on my PC.

    Thank you


    Wednesday, October 31, 2018 9:26 PM

All replies

  • Changing the NIC driver to vmxnet3 did not prevent sysprep from deleting the NIC driver.


    Thursday, November 1, 2018 1:10 PM
  • So is the issue you can run the task sequence but after the system runs sysprep and boots, it fails to connect to the deploymentshare and start the capture?

    Sysprep shouldnt strip out those drivers. I typically will inject those into the image. In your unattended file you can change the <PersistAllDeviceInstalls>false</PersistAllDeviceInstalls> to true. But I have never had this issue.

    The issue will be with your boot image. When you create your boot image you need to include your nic and storage drivers for the models you will use in capture and deploy. You may need to include the VMware drivers as well.

    You just need to create a selection profile for all your network card and storage drivers and then in the Properties > WinPE > Drivers and Patches tab select that Boot Drivers profile for Driver Injection and then recreate your boot image.

    Thursday, November 1, 2018 4:42 PM
  • What Greg said.

    I can confirm that I have not seen any issues when using the vmxnet3 Adapter. And yes, if you change your VM to use the vmxnet3 network adapter, you need drivers for the boot images. First, extract the virtual hardware drivers from the VMware Tools bundle:

    Run the following command from the command prompt:

    setup.exe /A /P C:\temp\VMware 

    (Note: If you are prompted to provide the location for the install/extraction, enter C:\temp\VMware).

    When the process is complete, click Finish.

    Then, import extracted drivers into MDT for deployment.

    Rebuild your boot images. 


    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    Monday, November 5, 2018 9:20 AM
  • I was able to perform the sysprep and capture on a new install which was airgapped. I just can't deploy it now. I get the most obscure and cryptic dism error possible. I've looked through the log files but they make no sense. An online repair of the install shows no corruption. The latest ADK is installed. That's the 1809 ADK and I'm trying to capture and deploy 1803. During the sysprep phase of the capture task sequence, the NIC driver was removed, but everything continued along without a problem.

    Why I need a custom image is because I have about 50GB of apps that need to be installed and are too large for our desktop management system to deploy. It takes about a full day to install and configure everything, so fresh attempts are very time-consuming.


    Tuesday, November 6, 2018 6:06 PM
  • I use VMs to create and capture new images as well and do not have this issue. Can you describe exactly what happens when you try to deploy the image and where exactly it fails? For example does it fail during the progress bar that shows the image being applied or does it fail during a portion of the task sequence? Typically if it fails during the task sequence it will state which task step failed.

    If it fails when applying the image it may be a formatting issue on the disk. If that is the issue make sure the disk is formatted the same as the VM captured (MBR or UEFI). 

    You can also disable all tasks in your task sequence and enable one at a time and see which one may be causing the issue.

    Wednesday, November 7, 2018 3:29 PM
  • The failure occurs during the dism /apply-image step. It fails immediately upon starting that step. I was looking at the disk partitioning step. MDT labels the OSDrive as D instead of C. I created the image in VMware Workstation with a UEFI BIOS settings. The test PC is using a UEFI BIOS setting as well. Should have went with MBR?



    Wednesday, November 7, 2018 4:45 PM
  • MBR/UEFI it doesn't matter. Any 1803 image I take won't apply. Even just a basic capture w/MS Office fails as soon as it tries to apply the image.


    Friday, November 9, 2018 10:35 PM