Cannot Sysprep and Capture Windows 10 1709 RRS feed

  • Question

  • I'm trying to grab a basic image of Windows 10 Enterprise 1709 x64 and it is not working. I am using the steps outlined here: 

    Deployment Research  and Stick to the Script

    ...and it is just not working. I am using Hyper-V on Windows 10 to build the image. I can install and configure Windows, but when it comes to Sysprep and Capture, nothing happens. Sysprep seems to work, as in it throws no errors, but the reboot does not go into Windows PE. Reboot takes me into OOBE and I am forced to repeat the entire build process. I just love having to re-learn something I've done for years every time Microsoft releases another update. 

    MDT is at version 8450 w/ADK 1709. I've even taken the steps out lined here: Disable Windows Store Apps Still, no dice. I am not sure where to look next. The log files are huge and too verbose. 

    Again, there are no errors shown during the build task sequence, it just doesn't do as it should (like most MSFT products). Thoughts?



    Friday, January 12, 2018 6:09 PM

All replies

  • How are you configuring the build and capture TS because it kinda sounds like it runs through the generalize / sysprep process but never actually pre-stages WinPE for capture. Please post your CS.ini as well as the BDD.log.


    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".

    Friday, January 12, 2018 6:12 PM
  • The log files are huge and too verbose.

     Make sure you're using CMTrace to read the log files. Its usually very good about highlighting trouble areas. Reading logs is important. Also, does a generic vanilla standard client task sequence work?
    Friday, January 12, 2018 6:51 PM
  • BDD.log


    Thanks for taking a look!

    I am using CMTrace to read the log files, but the errors are unintelligible. Googling the error codes brings me all kinds of results, none of which deal with the issues I am having. 

    I haven't tried any other task sequences. I didn't upgrade MDT from 8443 to 8450. I uninstalled/reinstalled like I usually do, then upgraded the deployment shares.


    Friday, January 12, 2018 8:45 PM
  • The first clue is this line in your bdd.log:

    <![LOG[  Console > Not enough storage is available to process this command.]LOG]!><time="11:52:06.000+000" date="01-12-2018" component="LTIApply" context="" type="1" thread="" file="LTIApply">

    That is actually an out of memory error. By default, Hyper-V VMs are configured to use dynamic memory, which causes issues like these. Go to your VMs properties and under Hardware>Memory, uncheck "Enable Dynamic Memory" and set the fixed RAM size to 4096 MB.

    Friday, January 12, 2018 10:23 PM
  • Trying again w/static memory assigned. Thanks!


    Saturday, January 13, 2018 12:04 AM
  • Memory changes didn't make any difference


    Saturday, January 13, 2018 1:28 AM
  • Sorry it's not working yet. I'm guessing you're now running into a different problem with the first problem eliminated. Can you post your bdd.log after the memory change?
    Saturday, January 13, 2018 3:01 AM
  • Could it be how I have the boot order set in the VM's firmware? It was set to: boot file/VHD, vDVD, and vNIC. I switched it to vDVD first so I can boot from the MDT PE ISO and retry an imaging session and generate fresh log files. Instead of going to BDD Welcome, it went right into creating a WIM image. An image that is now no good because OOBE setup has already been run,

    I usually use VMware Workstation for my VM work and tried Hyper-V because my copy of Workstation is from a few versions ago and figured 1709 might not work with it. Doesn't seem to work with much else. In Workstation, I set a delay in the VM's boot sequence that lets me interrupt like one would on a physical PC. I'm found no such option on Hyper-V. What would be the best boot sequence order? On all my production machines, it's SSD 1st and usually only, followed by USB key after the BIOS password has been entered.


    Saturday, January 13, 2018 6:16 PM
  • DVD is typically what I have first as that is necessary to boot into winPE and start MDT. It sounds like the subsequent run where it went into creating a WIM may have been due to starting on a dirty VM.

    If you can post your BDD.log on a fresh VM with static memory, I'd be glad to take a look and see if I have any insight on the next error being hit.

    Monday, January 15, 2018 5:15 PM
  • I'd love to share my BDD.log file, but OneDrive, like most Microsoft products, isn't currently working. It just keeps crashing in my browser (Firefox. I'm not using IE. Shouldn't have to). Once OneDrive is sorted out and I can share a 300KB file, I'll post a link. Thanks for following up.


    Tuesday, January 16, 2018 5:30 PM
  • Finally! Link:!AlaL7g1deExIguUevPcz1DhIuuQ5DQ

    The t/s just dies in the middle and never gets to the end.


    Tuesday, January 16, 2018 6:56 PM
  • Great. So the next error now is this:

    <![LOG[Litetouch deployment failed, Return Code = -2147467259  0x80004005]LOG]!><time="12:02:10.000+000" date="01-16-2018" component="LiteTouch" context="" type="3" thread="" file="LiteTouch">

    (You can find errors by searching for *type="3"* - nice and intuitive, I know.)

    Two lines below that you'll see this:

    For more information, consult the task sequencer log ...\SMSTS.LOG.

    So now, can you post your SMSTS.LOG? :)

    Tuesday, January 16, 2018 7:00 PM
  • SMSTS.log file



    Wednesday, January 17, 2018 4:30 PM
  • So this log shows an error trying to run LTISuspend.wsf in a step called "Pause Deployment". I'm guessing that you added that step yourself as it is not present by default?

    Using LTISuspend.wsf gives you a chance to customize your image manually before having capture complete and in general works fine.

    However, your call to LTISuspend.wsf has funky characters before/after it, according to the log. I see:

    cscript.exe “%SCRIPTROOT%\LTISuspend.wsf”

    in the log.

    My best guess is that you copied and pasted the step from a blog/etc and something went wrong. I've been burned similarly in the past (not with MDT, but just copying a code snippet off stackoverflow). I'd recommend deleting the step, updating your deployment share, and then trying again. If everything works, you can then add the step back with this command:

    cscript.exe %SCRIPTROOT%\LTISuspend.wsf

    Hope that gets things working.

    Wednesday, January 17, 2018 4:58 PM
  • First I would suggest taking a snapshot prior to running the sysprep and capture task sequence. That way if thing mess up all you need to do is load that snapshot.

    Second I would check to make sure the account you are using has admin access to the deploymentshare.

    Wednesday, January 17, 2018 7:16 PM
  • Thanks! How did you get to looking at smsts.log? I've removed the suspect step and will re-run now.


    Wednesday, January 17, 2018 9:22 PM
  • Hi,

    I do snapshots w/my virtualization software all of the time until my HDD is nearly full.


    Wednesday, January 17, 2018 9:23 PM
  • Thanks! How did you get to looking at smsts.log? I've removed the suspect step and will re-run now.

    First I looked in BDD.log for


    (which are errors). Once I found that, I looked around that line, and two lines below you see:

    For more information, consult the task sequencer log ...\SMSTS.LOG.

    Does that make sense?

    Wednesday, January 17, 2018 9:32 PM
  • Do you use a VM and the Legacy Network Adapter?


    • Edited by tonibert Thursday, January 18, 2018 8:58 AM
    Thursday, January 18, 2018 8:57 AM
  • I struggled for hours with this issue, only to find that changing my virtual machine used for capturing the image from UEFI to BIOS (legacy) resolved it. I deleted the old one and created a new one (VMWare Workstation 14.0) with BIOS instead of UEFI, and it now reboots into PE and captures correctly.

    It seems there is some issue with MDT not being able to stage PE properly in the UEFI firmware or change the boot order.  If you review the Windows Setup logs (setuperror.log) you can see some mention of it in there.

    Hope this helps someone.

    • Proposed as answer by tonibert Tuesday, February 13, 2018 8:12 PM
    Tuesday, February 13, 2018 12:29 AM