USB Litetouch deployment reboot loop RRS feed

  • Question

  • Hello,

    I am hoping someone may have experienced this issue and has some insight. I am using an USB 3.0 flash drive to install W10 on two HP laptop models and 1 HP desktop. All works well with the laptop models. On the desktop (HP ProDesk 600 G2 SFF) after the OS install completes and a reboot is called for by my task sequence, Litetouch starts the whole process over again. If I remove the USB drive right before the reboot, Litetouch continues but I receive an error at the end "Error 9601 - ZTITatoo state restore should be running in the Full OS. I have tried changing multiple BIOS boot settings, adding drivers to WinPE, etc.. This only appears to be an issue with this model Desktop.

    • Edited by IggyPup1224 Wednesday, April 19, 2017 7:54 PM
    Wednesday, April 19, 2017 7:53 PM


All replies

  • Unsure what the problem is.

    Can you copy the bdd.log files to a public site like onedrive and share the link.

    Keith Garner - Principal Consultant [owner] -

    Wednesday, April 19, 2017 9:54 PM
  • We are  experiencing the same issue. Everything works fine on laptops (with the exception of one Dell) and all desktops fail. We are having this issue with all HP and Dell desktops. 

    Monday, April 24, 2017 2:38 PM
  • I have been fighting this exact same issue for the past couple weeks as well.  We have a state-wide support area and due to bandwidth concerns, field support staff are given USB 3.0 drives as MDT media points for imaging in the field.  

    We are trying to provide Windows 10 (build 1703) drives to be used with UEFI deployments but run into the same problems the original poster mentioned.  It seems to work fine on certain devices (Dell tablets: Venue 11 Pro 7140 & Latitude 5175, All of our HP and Lenovo laptops, and even some Lenovo desktops) but it fails either consistently on certain makes / models or is intermittently successful on others.  Pretty much all of our HP desktops experience the issue and I would say the vast majority of our Dell desktops have the issue as well.

    Things we have done:

    -ensured UEFI mode was enabled and Legacy was disabled in the firmware.  Secure Boot is also disabled.

    -updated firmware in almost all of the models experiencing issues (this had no effect in helping the issue)

    -updated the Out-of-Box drivers (and re-optimized boot.wim) for the models having issues (no effect)

    -tested to see if there was any discernible difference between using a Fixed Data Drive or Removable Drive (there wasn't)

    -tried to run the new MBR2GPT.exe in the task sequence prior to OS being installed per Michael Niehaus's blog (did not help)

    -tested any differences between using USB 2.0 vs USB 3.0 (no difference)

    -tested a brand new task sequence using just the OEM install of Windows 10 (still had the issue)

    The only work around we have been able to use is that when it boots back into WinPE from the drive is to select the "No" option so that it reboots again and then sometimes it will boot from the internal drive correctly and complete the deployment or we have to go back to the Boot Menu and manually select the Windows Boot Manager option to get it to complete.  Neither one of these is an ideal solution because it will always give us the ZTITattoo error.

    This issue has me completely baffled because it seems like there is some sort of conflict between the firmware and the UEFI partitioning happening.  Yet it works on a large number of models we support (mostly laptops and tablets).  We have checked the BDD.logs but do not see any problems leading up to when the issue occurs.  

    I would love if someone from Microsoft could chime in on this because it is crucial for us to be able to use USB media for LiteTouch deployments in the field.

    FYI we are using MDT build 8443 and Windows 10 x64 Enterprise build 1703.

    Monday, April 24, 2017 6:28 PM
  • IggyPup1224,

    We have been fighting with this same issue using offline media. I found a workaround that has been successful for us.

    We recently found that with our tablets, we had to have the tablet in a dock and have the USB drive plugged directly in to the dock for us to image successfully using offline media. Otherwise, it would boot back in to MDT and give us the dirty environment error. What i tried today was plugging a generic USB hub into the tablet directly and plugging the USB media into the hub. This imaged successfully. 

    Taking this one step further, i tried the same thing on a couple of our desktop models. I used generic USB hubs and plugged the offline media into that and was able to image successfully. Why this issue is not present on laptops? Who knows. It seems this layer of separation between the machine and USB drive changes how it is seen. But at least for now we have a less that ideal work around.

    Let me know if this works for you as well or if you have come up with your own workaround in the mean time.  

    • Edited by Tylor386 Tuesday, May 2, 2017 2:43 PM
    Tuesday, May 2, 2017 2:41 PM
  • I also saw similar strange behavior when trying 1703 ADK with MDT 8443. When clicking "Begin" in deployment task sequence wizard, the machine immediately reboots. Then when manually booting back to the USB key, the message appears about an existing deployment.

    In our case I'm imaging HP Spectre x360 13 (2017).

    Tuesday, May 23, 2017 6:40 PM
  • All,

    I just wanted to provide an update on this.  We were able to finally engage with Microsoft Premier Support and found that this is a known bug / issue for the MDT Product Team.

    After several weeks of them looking into it, we were provided a workaround that seemed to fix the issue for us.  Microsoft had us modify the LTIApply.wsf script.  The section that needs to be tweaked is:

    If oEnvironment.Item("OSCurrentVersion") <> "" then
                    oUtility.GetMajorMinorVersion( oEnvironment.Item("OSCurrentVersion"))
                    If ((oUtility.VersionMajor = 6 and oUtility.VersionMinor >= 2) or oUtility.VersionMajor >= 10 )then
                                  TestAndFail RunBCDBootEx( sDestinationDrive & "\windows", " /s " & left(oBootDrive.Drive,2) & " /f UEFI"), 5616, "Verify BCDBootEx"
                                  TestAndFail RunBCDBootEx( sDestinationDrive & "\windows", " "), 5616,"Verify BCDBootEx"

    The modified text should look like this:

    If oEnvironment.Item("OSCurrentVersion") <> "" then
                    oUtility.GetMajorMinorVersion( oEnvironment.Item("OSCurrentVersion"))
                    If ((oUtility.VersionMajor = 6 and oUtility.VersionMinor >= 2) or oUtility.VersionMajor >= 10 )then
                                  TestAndFail RunBCDBootEx( sDestinationDrive & "\windows", " "), 5616,"Verify BCDBootEx"
                                  TestAndFail RunBCDBootEx( sDestinationDrive & "\windows", " "), 5616,"Verify BCDBootEx"

    Obviously, the If and the Else statements end up being the same and we were told that it should work as I described it or by deleting the Else statement entirely but we have only tested the code above.

    Hope this helps!

    • Proposed as answer by JiteshKumar Thursday, September 21, 2017 12:28 PM
    Monday, August 7, 2017 6:51 PM
  • Have the exact same issue. That the deployment process starts over. Boot priority doesn't matter. But if I change from Legacy to UEFI it doesn't loop anymore. So that fixed it for me.

    Thou I also have the issues that smstasksequence and minint folder is stored on the external usb disk, not the c drive. And after first logon to Windows after WinPE. The external drive is not initialized in drive management.

    Wednesday, October 11, 2017 8:46 AM
  • Have you tried to modify LTIApply.wsf script?

    Which is mentioned above. Hope,It'll work for you.

    Wednesday, October 11, 2017 10:33 AM
  • Have you tried to modify LTIApply.wsf script?

    Which is mentioned above. Hope,It'll work for you.

    Tried it, but didn't do anything.
    Thursday, October 12, 2017 7:03 AM
  • I've done the same changes in script. it's working for me.
    Thursday, October 12, 2017 9:12 AM
  • Are you deploying from USB memory stick or external usb harddrive?

    UEFI or Legacy Mode in bios?


    Thursday, October 12, 2017 9:28 AM
  • Balterz,

    Please check out my post at the end of this thread and see if it may help.

    We ran into something similar and found that the USB palm drives we were using were not seen as "Removable Disk Drives" but were seen as "SCSI Drive" which leads MDT into thinking its a possible internal drive it can put files on.

    We fixed it by adding a WMIC field to the ZTIDiskUtility.vbs script that tells the Deployment Wizard that if the drive shows up as the Media Type of our USB palm drive, it is not a candidate for imaging.  Between that modification and the one listed in this thread to LTIApply.wsf we have been able to image using our usb palm drives without any further issues.

    Hope this helps.

    Thursday, October 12, 2017 11:49 AM
  • I'm using USB Stick with fat32 partition.
    • Marked as answer by IggyPup1224 Thursday, January 11, 2018 3:36 PM
    Friday, October 13, 2017 7:09 AM
  • I made this change and it stopped my UEFI Dell 7389's from looping to the LAN. However, my Legacy Win7 images, which use the same LTIApply file are now getting stuck at Setup Is Applying System Settings. I was wondering if changing one wsf used by both UEFI and Legacy would cause an issue. Any info on this?

    I realize the issue. I was using a device for which Dell offers no Win7 drivers. Tested another Legacy pc for Win7 and it went through fine.

    • Edited by the1rickster Thursday, December 14, 2017 1:08 PM
    Thursday, December 14, 2017 12:44 PM