Stuck on "Sysprep is working...Processing generalize phase Sysprep plugins..." RRS feed

  • Question

  • Windows Server 2012 R2

    MDT 2013 Update 2

    Windows 10 Pro 64-bit

    I built a new server, and I was able to install a brand new Windows 10 Pro 64-bit image on a laptop (HP EliteBook 850 G3) with no errors at all.  Although, it was missing 3 drivers (bluetooth drivers, and NXP NewFieldProximity Provider driver, which were later found by a Microsoft update).  I built my reference computer, and then progressed to capturing it by launching LiteTouch.vbs from my deploymentshare$.  It runs successfully until the "Running action: Execute Sysprep" part.  At this point, I am still able to ping the server, and browse to all folders and files in the deploymentshare$.  However, when I look in Device Manager, I don't see any network adapters (except for the MS Kernel Debug Network Adapter).  When I end the SysPrep tool from task manager, I get the following error message: "Can not find script file '\\SERVER\DeploymentShare$\Scripts\LTICleanup.wsf'."  Then I can no longer ping the server or browse the deploymentshare$  I also get the following Deployment Summary:

    FAILURE ( 6111 ): 1: Run Sysprep.exeLitetouch deployment failed, Return Code = -2147467259 0x80004005
    No networking adapters found,  The network drivers for your device are not present
    SetNamedSecurityInfo() failed.SetObjectOwner() failed.  0x80070005.
    RegQueryValueExW is unsuccessful.  0x80070002.
    Failed to run the action:  Execute Sysprep.Unknown error (Error: 000017DF; Source: Unknown)
    The execution of the group (Capture Image) has failed and the execution has been aborted.  An action failed.
    Operation aborted (Error: 80004004; Source: Windows)
    Failed to run the last action: Execute Sysprep.  Execution of task sequence failed.
    Unknown error (Error: 000017DF; Source: Unknown)Task Sequence Engine failed!  Code: enExecutionFail
    Task sequence execution failed with error code 80004005
    SetNamedSecurityInfo() failed.
    SetObjectOwner() failed.  0x80070005.
    RegQueryValueEsW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgramGetTsRegValue() is unsuccessful.  0x80070002.
    Error Task Sequence Manager failed to execute task sequence.  Code 0x80004005

    Saturday, June 18, 2016 6:07 PM

All replies

  • Actually, now I'm wondering if I should set the "microsoft-windows-pnpsysprep_neutral"  option to the value of TRUE.  That should retain my drivers during the Sysprep process.  However, since I plan on deploying this Win10 image to other devices other than EliteBook 850 G3, I'm afraid it will cause problems.  Can someone here confirm this for me?

    Saturday, June 18, 2016 8:26 PM
  • Bueller?
    Sunday, June 19, 2016 4:21 PM
  • Well, apparently it worked.  I'm not sure why the SysPrep & Capture doesn't work without this added option, but whatever.  Thanks, I guess...
    Wednesday, June 22, 2016 1:56 AM
  • The scenario above is not clear t me.

    IF you run sysprep (without disabling the pnp parts), it will *remove* many drivers on the existing system. his by design.

    So the fact that you can't access the network card during sysprep, is not surprising to me.

    What is it that you are really trying to do here?

    Keith Garner - Principal Consultant [owner] -

    Wednesday, June 22, 2016 4:38 AM
  • Hi Fernando,

    I am having the same issue on a 840 G3 where are you changing this?


    Wednesday, June 22, 2016 8:46 PM
  • Sysguy99, go into the Windows SIM by clicking on the Properties, OS Info tab of your Task Sequence and selecting Unattend.xml.  Add the option of microsoft-windows-pnpsysprep from Components under Windows Image and choose the default to place under Generalize.  Hope this helps.  Thanks, Fernando!

    • Proposed as answer by vnettles Tuesday, June 28, 2016 2:10 PM
    • Edited by vnettles Tuesday, June 28, 2016 6:27 PM
    Tuesday, June 28, 2016 2:09 PM
  • I think what he is trying to do is capture an image from a HP Laptop but during the sysprep process of the task sequence it freezes. He then has to kill the process from the task manager.

    I'm having the same issue with a HP ProBook 450 G3.

    Thursday, July 21, 2016 7:59 PM
  • thanks for reply guys,

    I ended up changing it within the local GP of the client I was capturing.  Worked like a charm!

    Thanks again guys!

    Thursday, July 21, 2016 8:04 PM
  • Hello,

    I encounter the same problems, can you tell me how you solved the problem. I have an HP elibook 850 G3.

    Thank you
    Thursday, August 4, 2016 3:55 PM
  • I had this issue with an HP ProBook 450 G3 and HP EliteBook Folio 1040 G3. (Seems most people on this thread have G3 HP hardware). No problems on an HP EliteBook Folio 9480m.

    While the sysprep task is running/hung, if you check the Computer Management utility, you'll probably notice very few devices in device manager - primarily the network or disk drivers may be missing.

    Ctrl+Shift+Escape, right click on the sysprep task, and open to the file location. In the Panther folder you will find the sysprep logs. Open setupact.txt and scroll to the bottom. The last lines will probably note that it has started the generalize pass, PnpSysprep starts to run, then a bunch of devices get uninstalled.

    Essentially, sysprep is in the Generalize stage and is removing drivers specific to your hardware, including your storage and network drivers. In most cases this is fine - the system's drivers should have already been copied to the local PE - and either generic drivers kick in until it reboots or it knows they're essential drivers and will unload them later. However, in the case of this issue, that's not happening, which kind of prevents sysprep from doing anything... The task is hung because it can't write to the disk because it uninstalled it.

    From here you have two options: try different hardware or edit your unattend.xml file.

    Try different hardware:

    I was lazy and had luck with a different model. However, most documentation for MDT will note that you should be using a Virtual Machine as your reference/capture machine. Not only does a VM make it easy and convenient to update your image in the future, but the drivers used in the VM (depending on your choice of software) probably won't get nuked in the generalize phase. Drivers specific to your hardware should be loaded into MDT/SSCM separately. Once you have done your capture from the VM you can create a separate task sequence to deploy the new image. As long as you have added the drivers to MDT/SSCM, it should automatically install all relevant drivers for the detected hardware. A quick note here since it seems most people in this thread have HP hardware: HP has been pretty good lately in releasing "driver packs" for their business models, which makes it very quick and easy to import all your necessary drivers into MDT. No need to extract drivers from a factory image or deploy an image just to install and extract the drivers; you can load drivers before the hardware ever ships!

    Edit unattend.xml:

    If for whatever reason you must run the capture on the hardware itself instead of a VM, or if you're only going to deploy your image to a single model of hardware, you can change your Unattend.xml answer file to enable "PersistAllDeviceInstalls"as described by vnettles and the OP in their posts above. Here's a detailed walkthrough in case you need it:

    1. In MDT/SSCM edit the task sequence that includes your capture, click on the "OS Info" tab, and click the "Edit Unattend.xml" button.
    2. The Windows System Image Manager window will analyze the image you've selected (it will take a while) then display the current answer file configuration.
    3. On the left side of the window, in the "Windows Image" pane you should see the name of the image you are using. If not, click the grey box to browse to and select the image file for the task you are performing (if you don't have one yet, try a generic image).
    4. The catalog for the Windows image should be available now. Expand the tree to (YourImageName)\Components\amd64_Microsoft-Windows-PnpSysprep_(YourWindowsVersion)_neutral
    5. Right-click on amd64_Microsoft-Windows-PnpSysprep_(YourWindowsVersion)_neutral and select to "Add Setting to Pass 3 generalize"
    6. In the "Answer File" pane, expand the tree to unattend\Components\3 generalize
    7. Click on amd64_Microsoft-Windows-PnpSysprep_neutral, then in the Properties pane to the right, change the value "PersistAllDeviceInstalls" to "true"
    8. Save the answer file. You will likely get a warning about several of MDT's default values not passing validation. Ignore it and save it anyways.
    9. Run your capture task again and this time sysprep should complete and move on to the "Create WIM" capture task.

    There's probably a quicker/manual way to add this info to your answer file, it's just a text file at the end of the day, but doing everything through WSIM should make sure everything is done right. A veteran to sysprep may know of a way to whitelist or specify drivers that shouldn't be touched during generalization, but setting it to PersistAllDeviceInstalls is a quick way of getting things working in the short term.

    As for the OP's concerns about the drivers still being in the image after setting "PersistAllDeviceInstalls" - It's been rare from what I've seen but, yes, if the drivers were not generalized it's possible you may have driver conflicts if you deploy the image to different hardware. I've only seen it happen twice so far but it's enough of a hassle to want to avoid it.... Have I mentioned using a VM yet? :)

    Before I ramble too much more, I'll end it here. I hope someone finds this useful.


    Wednesday, August 31, 2016 1:47 AM
  • Where in the local GP?
    Wednesday, October 26, 2016 7:24 PM
  • If anyone is still having problems with sysprep capture, please copy the bdd.log file to a public site like OneDrive and share the link here.

    Keith Garner - Principal Consultant [owner] -

    Wednesday, October 26, 2016 7:54 PM
  • I'm running into this exact issue with an HP Elite X2 1012 G1. We need to capture an image quicker than we have time to develop one on a VM so I'm trying out Rami's suggestion above. Keeping my fingers crossed. Afraid I can't share my bdd.log with the world at this point, office policy.

    Orange County District Attorney

    Friday, October 28, 2016 1:57 PM