none
SOLVED!!! - MDT 2013/Windows 8.1 Sysprep & Capture Fails RRS feed

  • Question

  • I'm running a basic Client Task Sequence that installs the OS, installs a few applications/drivers and then should Sysprep and Capture the image.  Everything works fine until after the Sysprep.  The machine reboots but does not reboot into the PE environment.  Instead it reboots to the local disc and the machine runs the initial OOBE setup.

    My BDD.log file can be found @ 

    https://dl.dropboxusercontent.com/u/14521312/BDD.log

    I see what look like some BCDEdit errors being returned but I'm not sure what they mean.

    If anyone can help I would greatly appreciate it.  I have to get 30 machines out yesterday.

    EDIT:  REPLACED BDD.LOG


    Thursday, August 7, 2014 2:33 PM

Answers

  • Usually MDT will only reboot when an install or application sends a return code that a reboot is required. Keith Gardner enlightened me to this yesterday on how reboots are handled for installs that need a reboot. If it's rebooting there, it's definitely going to break the rest of the process. How are your drivers managed? Are you building this on a VM? 
    Thursday, August 7, 2014 3:51 PM
  • Either that or add to task sequence -

    Set Task Sequence Variable SMSTSRebootRequested value FALSE

    Add it right after driver injection.

    Thursday, August 7, 2014 6:03 PM

All replies

  • Thanks for your log. It seems as if you dont have any valid network adapters as the drivers are not found! Did you verify your nic drivers in your winpe image?
    • Proposed as answer by MrBrooks Thursday, August 7, 2014 2:45 PM
    Thursday, August 7, 2014 2:43 PM
  • Make sure you get yourself a decent log viewer, as heid4055 had mentioned, youre getting a networking device error.  With a log viewer like smstrace, you would've seen it in bright red

    -

    No networking adapters found, The network drivers for your device are not present

    Make sure your USB to Ethernet driver is installed on your boot image if you're deploying to a tablet. 


    • Edited by MrBrooks Thursday, August 7, 2014 2:50 PM
    Thursday, August 7, 2014 2:48 PM
  • Thanks for your log. It seems as if you dont have any valid network adapters as the drivers are not found! Did you verify your nic drivers in your winpe image?

    I think, but am not positive, that this is a red herring.  The device is a Panasonic FZ-G1 Toughbook Tablet that has not built in ethernet.  It uses the ethernet on the dock through some type of USB interface.  Those drivers are in the WinPE build.  From observation it appears that on a reboot it takes a bit of time for network connectivity to reconfigure.  All it appears to be doing, to me, when it shows the No Networking Adapters is writing an event back to the server and I don't think that's the problem but could be wrong.

    This section is where things appear to be breaking down to my untrained eye:

    Run Command: C:\windows\SYSTEM32\bcdedit.exe /export "D:\boot\bcd.save" LTIApply 8/7/2014 9:02:41 AM 0 (0x0000)
    BCD> The store export operation has failed. LTIApply 8/7/2014 9:02:42 AM 0 (0x0000)
    BCD> The system cannot find the path specified. LTIApply 8/7/2014 9:02:42 AM 0 (0x0000)
    BCDEdit returned ErrorLevel = 1 LTIApply 8/7/2014 9:02:42 AM 0 (0x0000)


    The D: does not appear to be present any longer at this point.  It is created during the Apply WinPE stage but upon reboot before the Sysprep step the D: is no longer present.


    Thursday, August 7, 2014 2:50 PM
  • Make sure you get yourself a decent log viewer, as heid4055 had mentioned, youre getting a networking device error.  With a log viewer like smstrace, you would've seen it in bright red

    -

    No networking adapters found, The network drivers for your device are not present

    Make sure your USB to Ethernet driver is installed on your boot image if you're deploying to a tablet. 


    I understand what you guys are saying but I still don't feel it's the overall issue.  I have network connectivity up to the point of running the Sysprep.  At that point all the machine should be doing is rebooting to the Boot directory created on the D:.  However the D: no longer exists because the device is rebooting after the Apply WinPE step.  I'm not sure why it's rebooting there as I do not have a reboot step in the task sequence at this point.

    I am using CMTrace and can see the networking adapter issues you point out but I do not think that's the problem.  

    Thursday, August 7, 2014 2:56 PM
  • I have updated the BDD.log file link as I realized I was referring to a different one than the one I posted.

    In this one you will actually see the Capture take place.  This is because:

    After the Device rebooted from the MDT Sysprep I manually Syspreped and Shutdown the device.  I then went into BIOS and booted from the USB to go back into my WinPE/Task Sequence Selection but instead of going there it picked up with the next steps of the Task Sequence and did the Capture?!?!

    https://dl.dropboxusercontent.com/u/14521312/BDD.log

    Capture after manual sysprep/shutdown/boot to usb starts up at 9:40.



    Thursday, August 7, 2014 3:12 PM
  • I see the new log. Again, it captures your image fine.. Upon reboot it states unable to connect to share. The network path was not found. 

    Now, after it captures your image and reboots, are you selecting your boot order correctly? I assume you are connecting via PXE? and not local media?

    Also, are you deploying Windows 7 or 8?

    Thursday, August 7, 2014 3:16 PM
  • Futher down on your log it states

    LTISysprep processed completed.

    return code -2147021886

    LTIDirty is now =FALSE

    This should be set to TRUE after it captures your image. 

    Can you format your HD and then restart your TS? I also strongly suggest you look into your WinPE nic drivers as well.....

    Thursday, August 7, 2014 3:21 PM
  • I see the new log. Again, it captures your image fine.. Upon reboot it states unable to connect to share. The network path was not found. 

    Now, after it captures your image and reboots, are you selecting your boot order correctly? I assume you are connecting via PXE? and not local media?

    Also, are you deploying Windows 7 or 8?

    It does capture it fine WITH manual intervention.  If you look at the timestamps on those logs there's a 20+ delay between when the capture should start and when it does.  This is because I had to manually run Sysprep again, shutdown and boot to USB before the next steps are logged.

    This is a Windows 8.1 Deployment.  

    See if this helps explain the process I'm going through here.  I do not think the Network Connection errors play into these parts of the task sequence when comparing the BDD logs to what is happening.

    http://i.imgur.com/EtLWRuT.png 

    This is all done booting from Local Media (USB) and not PXE.
    Thursday, August 7, 2014 3:22 PM
  • Futher down on your log it states

    LTISysprep processed completed.

    return code -2147021886

    LTIDirty is now =FALSE

    This should be set to TRUE after it captures your image. 

    Can you format your HD and then restart your TS? I also strongly suggest you look into your WinPE nic drivers as well.....

    Yes, I will re-run this installation and repost the logs.  I have a question re: the WinPE NIC drivers.  If those were the problem why would it work just fine when I reboot to USB and start WinPE which then connects to the NW with no problem.  I have included the most recent drivers available for this RealTek USB/Ethernet device into the WinPE already.

    I don't think the errors you're seeing are WinPE driver errors but instead it's the drivers not being available after running Sysprep /Generalize.  All of the errors come from steps inside the Windows 8.1 Environment and not the WinPE environment.


    Thursday, August 7, 2014 3:34 PM
  • Lets try a disk format first.. I still use the old Win98 fdisk utility :)

    Wipe all drives clean and then re-run it...

    Thursday, August 7, 2014 3:44 PM
  • Lets try a disk format first.. I still use the old Win98 fdisk utility :)

    Wipe all drives clean and then re-run it...

    I will do that but is that not already happening at this stage of the Task Sequence?

    Free Drive Letter(s): D: E: F: G: H: I: J: K: L: N: O: P: Q: R: T: U: V: W: ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    New ZTIDisk : \\MININT-DPLVH5K\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0" ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    Found Disk Index: 0   size: 128034708480 ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    Disk Index: 0   size: 128 GB ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    This is an EFI machine, therefore we will need a Boot Partition. ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    bCreateBootPartition = True ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    Configuring Disk Alignment ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    No Disk Alignment variables specified, alignment not updated. ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    About to run command: Diskpart.exe ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    Command has been started (process ID 1480) ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + RESCAN ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + LIST DISK ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + LIST VOLUME ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + REM Move Drive C: to a diffrent drive letter. ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + Select volume C: ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + Assign Letter=W: ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + SELECT DISK 0 ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + CLEAN ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + CONVERT GPT NOERR ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    Create an uEFI/GPT Boot Partition set. V: ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + CREATE PARTITION PRIMARY Size=300 ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + FORMAT QUICK FS=NTFS LABEL="Windows RE tools" ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + ASSIGN LETTER=U ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac" ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + gpt attributes=0x8000000000000001 ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + DETAIL PARTITION ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + DETAIL VOLUME ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + CREATE PARTITION EFI Size=499 ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + FORMAT QUICK FS=Fat32 LABEL="System" ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + ASSIGN LETTER=V ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + DETAIL PARTITION ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + DETAIL VOLUME ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + CREATE PARTITION MSR SIZE=128 ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + DETAIL PARTITION ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + DETAIL VOLUME ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + REM -------------- ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + REM Partition 0 ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
       Partition(0): 100 % ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    Size is Empty: Expand to remaining space. ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
       Size:  [ isEmpty = True] ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + Create Partition Primary ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    Do not mark a 2nd partition active. ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + Assign letter=C: ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
    Property OSDisk is now = C: ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + FORMAT QUICK FS=NTFS LABEL="OSDisk" ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + DETAIL VOLUME ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + DETAIL PARTITION ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + LIST PARTITION ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + LIST VOLUME ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)
      Console + EXIT ZTIDiskpart 8/7/2014 8:13:16 AM 0 (0x0000)

    Thursday, August 7, 2014 3:50 PM
  • Usually MDT will only reboot when an install or application sends a return code that a reboot is required. Keith Gardner enlightened me to this yesterday on how reboots are handled for installs that need a reboot. If it's rebooting there, it's definitely going to break the rest of the process. How are your drivers managed? Are you building this on a VM? 
    Thursday, August 7, 2014 3:51 PM
  • This is where the reboot is taking place:

    Prepare machine for Sysprep. ZTIDrivers 8/7/2014 11:17:50 AM 0 (0x0000)
    No driver actions can be taken for OS Images installed from *.wim files. ZTIDrivers 8/7/2014 11:17:50 AM 0 (0x0000)
    ZTIDrivers processing completed successfully. ZTIDrivers 8/7/2014 11:17:50 AM 0 (0x0000)
    Validating connection to \\SPHQHELPER01\Events ZTIDrivers 8/7/2014 11:17:50 AM 0 (0x0000)
    Mapping server share: \\SPHQHELPER01\Events ZTIDrivers 8/7/2014 11:17:51 AM 0 (0x0000)
    Already connected to server SPHQHELPER01 as that is where this script is running from. ZTIDrivers 8/7/2014 11:17:51 AM 0 (0x0000)
    Event 41001 sent: ZTIDrivers processing completed successfully. ZTIDrivers 8/7/2014 11:17:51 AM 0 (0x0000)
    Event 41001 sent: ZTIDrivers processing completed successfully. ZTIDrivers 8/7/2014 11:17:51 AM 0 (0x0000)
    Computer is not a member of a domain. LTISysprep 8/7/2014 11:17:52 AM 0 (0x0000)
    Property SysprepPendingFileRenameOperations is now = OnlyRebootOnce LTISysprep 8/7/2014 11:17:52 AM 0 (0x0000)
    Possible Pending File Rename Operations. LTISysprep 8/7/2014 11:17:52 AM 0 (0x0000)
    Pending File Rename Operations: \??\C:\Users\ADMINI~1\AppData\Local\Temp\nst79B0.tmp\nsProcess.dll LTISysprep 8/7/2014 11:17:52 AM 0 (0x0000)
    Property SMSTSRebootRequested is now = true LTISysprep 8/7/2014 11:17:52 AM 0 (0x0000)
    Property SMSTSRetryRequested is now = true LTISysprep 8/7/2014 11:17:52 AM 0 (0x0000)
    Initiating reboot to clear pending file rename operations. LTISysprep 8/7/2014 11:17:53 AM 0 (0x0000)

    Maybe I should try a reboot before the Imaging stage just to make sure this is cleared up?


    Thursday, August 7, 2014 4:23 PM
  • Usually MDT will only reboot when an install or application sends a return code that a reboot is required. Keith Gardner enlightened me to this yesterday on how reboots are handled for installs that need a reboot. If it's rebooting there, it's definitely going to break the rest of the process. How are your drivers managed? Are you building this on a VM? 

    To answer your questions though, drivers are managed through a single executable that calls on all needed driver and application installs to be performed as an Application Install Task.  Driver injection royally fouled these machines up as they require things to be installed in a certain order.

    I created my OS Reference in a VM and applied Windows Updates and Visual C++ redistributables.  This Task sequence uses that capture image as the OS and is being run directly on the machines to deploy.

    Thursday, August 7, 2014 4:40 PM
  • Either that or add to task sequence -

    Set Task Sequence Variable SMSTSRebootRequested value FALSE

    Add it right after driver injection.

    Thursday, August 7, 2014 6:03 PM
  • Either that or add to task sequence -

    Set Task Sequence Variable SMSTSRebootRequested value FALSE

    Add it right after driver injection.

    Adding the reboot before imaging appears to have fixed the problem.

    Thanks to everyone who helped on this.


    Thursday, August 7, 2014 6:30 PM
  • Glad you're all good now, figured it had to be something with the drivers.
    Thursday, August 7, 2014 6:47 PM