none
MDT Offline Media for Windows 10 RRS feed

  • Question

  • I’ve hit a wall in my deployment preparation process. I’ve having issues deploying Windows 10 Pro with the USB created from MDT. I haven’t been able to find any cohesive documentation that spells out how to create the USB and how the BIOS information should be configured in order for these things to work together, as well as information as to what needs to be done during the deployment process (which item to choose at Boot menu, whether or not the USB has to be taken out and then reinserted later, etc.). Also, I'm aware that some documentations mentions 2 partitions on a USB and copying files over, but that only works for Fixed Disks. I'm trying to create a seamless process that doesn't involved sitting at the receiving PC waiting for the wizard to complete, pull out the USB, let it reboot and put the USB back in to finish the deployment. Cause right now, it's sitting in a loop after the "Installing OS" part of the task sequence unless I tell it to "continue the in-process deployment" at the Dirty Environment window, where it tells me to take out the USB, etc. Any help would be great!
    Thursday, August 17, 2017 4:55 PM

Answers

  • Ok, so the good news is that I got this working, mostly. I had to copy over two Boot files from the ADK 1511 into the Tools folder in my Deployment Share, etc. Now the problem that I'm having is the AutoLogon function has stopped working, and even after logging in manually, the task sequence does not resume.

    Britney

    • Marked as answer by BGibbs00 Wednesday, November 1, 2017 5:00 PM
    Tuesday, September 19, 2017 7:48 PM

All replies

  • One thing I know is that in the BIOS, do not set the USB key as the first bootable selection. You must leave the USB in until the entire MDT process completes, even after reboot. First, just be sure USB isn't the first boot choice in the BIOS. You do a one-time boot to USB, MDT will read it again after a reboot, and then when it's all done it will boot to the HDD.
    Friday, August 18, 2017 4:42 PM
  • @the1rickster: I'm familiar with that, and that was how I had been doing this process the whole time. But what happens after it reboots, is that it is trying to start the "State Restore" phase, and gives an error that it can't be done in WinPE so it says to remove USB then restart. Once it boots back into Windows, it asks for the USB media to finish the deployment, and even then, it gives me an error or warning upon completion of the deployment. So I am trying to get this Offline Media perfect, as my Windows 7 currently is, so that it deploys flawlessly with no extra steps or weird hiccups. I'm current recreating my VM of the Reference Image as a Generation 1 in Hyper-V to see if that is causing a problem.
    • Edited by BGibbs00 Friday, August 18, 2017 5:48 PM Spelling error
    Friday, August 18, 2017 5:48 PM
  • What it sounds like is perhaps that pc is stuck in a loop. On the pc you're imaging, try this, it clears the loop in MDT:

    Press F8 (sometimes a different F key to bring up a dos box)
    type diskpart (enter)
    type list disk (enter)
    type select disk 0 (enter)
    type clean (enter)

    reboot the pc and let MDT begin from the initial start again

    • Proposed as answer by Anton Romanyuk Friday, August 25, 2017 12:09 PM
    Friday, August 18, 2017 6:27 PM
  • I can confirm the behaviour the1rickster mentioned a few days ago - sometimes MDT does not cleanup properly after a task sequence failure which in turn might lead to the aforementioned looping behavior. Running diskpart usually fixes the issue.

    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Friday, August 25, 2017 12:11 PM
  • I've done all those things because I've had other issues when there was a dirty environment, but this happens on every brand new device I've used to try and test this out on. I just don't want my staff to have to go through these extra steps just to deploy Windows 10. There should be a way around having to go through these two errors, pull out the USB, let the PC restart, and put the USB back in. We have hundreds of devices to get ready to put out to our users.

    Britney

    Friday, August 25, 2017 2:55 PM
  • Just a thought...have you allowed these new out-of-box machines to boot up to the desktop once, then attempt to image them? Perhaps the factory sysprep/unattend is interfering with the MDT process. Maybe let one boot to its factory desktop then go on to clone it through MDT.
    Friday, August 25, 2017 3:03 PM
  • Yup. I've done that also. Still, it's booting back to the USB with the "Dirty Environment" issue, etc. I can't seem to find a clear, straight answer about this USB issue.

    Britney

    Friday, August 25, 2017 9:44 PM
  • What kind of devices are we talking about? 

    Generally speaking, this kind of message would usually appear, if there are remnants of the previous installation still present (e.g. task sequence log, etc).

    Still, can you verify that in your BIOS boot configuration HDD is the first boot device? While this type of configuration requires you to press your boot menu key during the POST phase to initiate the installation, it should fix the issues you are experiencing. Doing this: e.g. boot from usb to WinPE, select task sequence which will layer down the image and initiate a reboot, will make your system boot from HDD and your installation will proceed. Do not remove your USB drive until the installation finishes.


    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Sunday, August 27, 2017 9:16 PM
  • Right now I'm trying to image Dell Latitude 5480s and Optiplex 5050s. But if the BIOS is set for UEFI, there is no way (that I am aware of) to set the HDD as the first in boot sequence. In UEFI is the Windows Boot Manager, IPv4, IPv6 and USB. Is there something I'm missing? This has been tested on devices straight out of the box from Dell and ones that have had the HDD wiped clean.

    Britney

    Sunday, August 27, 2017 9:42 PM
  • Right now I'm trying to image Dell Latitude 5480s and Optiplex 5050s. But if the BIOS is set for UEFI, there is no way (that I am aware of) to set the HDD as the first in boot sequence. In UEFI is the Windows Boot Manager, IPv4, IPv6 and USB. Is there something I'm missing? This has been tested on devices straight out of the box from Dell and ones that have had the HDD wiped clean.

    Britney


    Windows Boot Manager = HDD :)

    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Sunday, August 27, 2017 9:59 PM
  • Oh, I see. Well I'm good there then. So with that being said, it still doesn't explain the need to pull out the USB before restarting message.

    Britney

    Sunday, August 27, 2017 10:18 PM
  • I am somewhat confused by the restart message which, as I gathered, you receive at some point after the MDT Installation phase (probably in Post Install but before State Restore). Usually there are no restart messages in MDT.

    So, correct me if I am wrong, but let's walk through what is happening one more time:

    • You insert your usb drive, power on your pc, press a key to open the boot menu (because otherwise the pc would boot from HDD), select your USB drive and let the WinPE environment boot up.
    • You then go through the MDT wizard and start the installation.
    • At some point, after the image had been layered down on the hard drive, you receive a restart warning message?
    • If you follow this guidance the PC will restart and boot from HDD, go through the specialize phase, etc. If you don't you will boot back to WinPE?

    I am just trying to wrap my head around what is going wrong here.


    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Monday, August 28, 2017 6:09 AM
  • Below are the two messages, in order that I am seeing during the deployment process. The "Dirty Environment" comes after the first reboot, when it should be booting to the HDD, but instead boots back into WinPE. The second "Suspend" image is what I get if I select "No" from the previous message. This does not seem right as this is the only time I've had to deal with this. When we were deploying Windows 7 with USB media, it never happened. We could just start up the deployment and walk away to do other work. Now it's as if we have to babysit the deployment.

    Britney

    Monday, August 28, 2017 2:06 PM
  • So basically your system is booting from USB again at which point the task sequence enters the state restore phase, attempts to install an application and fails.

    When you were installing Windows 7, you were probably installing in Legacy mode, so it is a totally different scenario.

    I would like to verify following BIOS settings with you:

    • legacyrom = disable
    • secureboot = enable

    These two settings ensure, that you are running pure UEFI configuration as recommended by MS.

    Additionally, I believe (because I do not have a Dell system handy right now), that there are two sets of boot sequences, one for legacy and one for UEFI boot. Could you check?


    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Monday, August 28, 2017 2:18 PM
  • I was going to suggest something like this...Secure Boot ON. But I was unsure how to boot to USB with Secure Boot ON, unless the F12 allows a one-time boot.

    If that is the case, then enabling Secure Boot ON would prevent anything booting up except the HDD.

    Monday, August 28, 2017 2:26 PM
  • I was going to suggest something like this...Secure Boot ON. But I was unsure how to boot to USB with Secure Boot ON, unless the F12 allows a one-time boot.

    If that is the case, then enabling Secure Boot ON would prevent anything booting up except the HDD.

    In theory yes, but I haven't seen any issues with the aforementioned configuration at my customers (e.g. USB boot, secure boot = on, legacy support = off).

    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Monday, August 28, 2017 2:28 PM
  • I don't think that Secure Boot being enabled would work for us since we are an agency that uses a third-party device to encrypt our laptops. This may work for imaging our desktops. I did confirm that the Legacy ROM option was turned off, but the result is still the same. Could there be an issue with how the USB is formatted cause a problem? I used the custom ISO from my MDT deployment share and used Rufus to format the USB removable drive with the GPT partition scheme. But I've also tried it several different ways, all with the same result.

    Britney

    Monday, August 28, 2017 4:25 PM
  • I don't think so - you have confirmed that your devices boot up just fine if you remove USB drive during the first reboot, so it is bound to be boot order related. I am still trying to wrap my head around possible causes. Would it be possible to export your BIOS settings to a text file and post here / send me by mail? You can use Dell Command | Configure Wizard to capture your BIOS settings.

    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Monday, August 28, 2017 4:47 PM
  • The BIOS Configuration is a long file and I don't want to include anything uneccessary. Is there a specific set of information that you would like me to include (i.e Category Name: Boot Management, Configuration, etc.)?

    Britney

    Monday, August 28, 2017 9:27 PM
  • Tough to say, boot management / configuration is definetely something to look at first. As mentioned before, I worked extensively with Dell HW before, but I do not have a Dell handy at the moment and all BIOS config files I have here have been modified to include the necessary settings only.

    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Tuesday, August 29, 2017 5:49 AM
  • Here is the link to the BIOS Configuration for a Latitude 5480

    https://1drv.ms/u/s!Apw21RxrpqMpgixn3YReHD1hEQn3

    Here is the link to the BIOS Configuration for a OptiPlex 5050

    https://1drv.ms/u/s!Apw21RxrpqMpgi20sNnIxHmFY-RS


    Britney

    Tuesday, August 29, 2017 4:15 PM
  • Hmm... interesting. It is tough to say what is going on without having physical access to the device, so I am just going to provide a few possible steps:

    • Get the description for the items in UEFI boot order to make the whole thing more readable. This information is shown in CLI, with the following command: cctk bootorder --bootlisttype=uefi
    • Something I would definetely recommend is configuring BIOS settings in WinPE. This ensures that your devices stay compliant. I will write a blog post at some point how to accomplish this on Dell / HP systems.
    • If you do go this route, you may want to take a look at the cctk bootorder functionality and set bootorder in WinPE ensuring your devices boot from HDD.
    • Is booting via PXE an option?

    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Tuesday, August 29, 2017 4:45 PM
  • Ok, here is a link for the CLI stuff:

    https://1drv.ms/f/s!Apw21RxrpqMpgjAzvsz-RQ-ZLRr4

    Also, while the image is fine when we PXE boot with no issues, we have remote sites that need a USB in order to do the deployments because they do not have their own MDT/WDS server set up and must get their files from our main location. I'm currently looking into the BIOS Settings for WinPE, but most of what I see is in reference to using SCCM. Do you know of any literature for those of us who are using MDT?


    Britney

    Tuesday, August 29, 2017 7:09 PM
  • SCCM = MDT. Same approach. I use a PowerShell script to load HAPI drivers and then load BIOS settings from a text file / set BIOS password using cctk.

    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Tuesday, August 29, 2017 7:25 PM
  • SCCM = MDT. Same approach. I use a PowerShell script to load HAPI drivers and then load BIOS settings from a text file / set BIOS password using cctk.

    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com


    Would it be possible to create an application for the CCTK, install it during the Pre-Install phase along with injecting those HAPI drivers, so that (theoretically) after the OS installs and reboots, it boots to the HDD like it is supposed to do and continue the deployment?

    Britney

    Tuesday, August 29, 2017 9:20 PM
  • Yes, you could simply run a PowerShell script from your task sequence, no need to create an application for that.

    Here is what you would usually do:

    • Install HAPI drivers using hapi64.exe -i -k C-C-T-K -p "hapint64.exe" -q command line 
    • Set BIOS password using --setuppwd flag (otherwise you won't be able to apply certain BIOS settings)
    • Load BIOS settings using -i flag to load your text file and -valsetuppwd flag which references your password

    Granted, this is very basic as you may want to load different BIOS settings depending on your hard ware model. In my case, I am usually able to get away with using same config file for all machines. Your mileage may vary.

    I would offer you more advise but as mentioned before, in my case I am not facing any issues with the reboot behavior and without an actual test device it is somewhat hard to diagnose your issue.


    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Tuesday, August 29, 2017 11:40 PM
  • Yes, you could simply run a PowerShell script from your task sequence, no need to create an application for that.

    Here is what you would usually do:

    • Install HAPI drivers using hapi64.exe -i -k C-C-T-K -p "hapint64.exe" -q command line 
    • Set BIOS password using --setuppwd flag (otherwise you won't be able to apply certain BIOS settings)
    • Load BIOS settings using -i flag to load your text file and -valsetuppwd flag which references your password

    Granted, this is very basic as you may want to load different BIOS settings depending on your hard ware model. In my case, I am usually able to get away with using same config file for all machines. Your mileage may vary.

    I would offer you more advise but as mentioned before, in my case I am not facing any issues with the reboot behavior and without an actual test device it is somewhat hard to diagnose your issue.


    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com


    Per the files that I showed you, could you tell if the boot order was set properly in the UEFI mode so that the HDD was the first in line? Also, should I look at possibly trying to change when the USB is removed? Like do I insert the USB to get the MDT deployment started, then remove it, and after it reboots into the OS, wait for it to ask for the USB media to be put back in?

    Britney

    Wednesday, August 30, 2017 2:37 PM
  • Unfortunately I am not 100% sure. I have no way to verify till next week when I am on site with a customer who is using Dell hardware.

    However, I would still explore the option of modifying BIOS settings during WinPE phase and possibly also test if the issue still occurs with the latest Dell BIOS update. You may want to involve Dell tech support as well - my experiences with Dell support was fairly good, but your mileage may vary.

    Just a thought, could you run the cctk bootorder --bootlisttype=uefi command in WinPE?


    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Wednesday, August 30, 2017 3:35 PM
  • So i'm working on this now, but something else came to mind that I wanted to get your thoughts on. We use Hyper-V for our base images. The current image is based off of a Gen2 VM. Would that have any effect on the final deployment? I'm currently trying to find the best way to explain to upper management why we are doing UEFI-based deployments to begin with. I haven't created a Gen1 VM yet to import into MDT and do a Legacy-based boot to test this theory, but that will probably be my next move. 

    Britney

    Wednesday, August 30, 2017 10:30 PM
  • You should *never* build your reference images using Gen. 2 machines, use Gen. 1 instead. While I am not sure if this is contributing to your issue, there is an easy way to find out. Modify the Install OS step in your task sequence to install standard Windows 10 image.


    Blog - http://www.vacuumbreather.com / http://www.wcsaga.com

    Thursday, August 31, 2017 6:12 AM
  • So I'm currently rebuilding the VM on a Gen1 so I can capture it and pull it into MDT. I had done it before, but the autologon wasn't working after I rebuild the UEFI-USB. I'm also going to try using the Legacy BIOS and the NTFS USB for this as well.

    Britney

    Friday, September 1, 2017 3:27 PM
  • Just go with FAT32 (unless your image exceeds 4GB). In that case you will need to work around that, for example by using Rufus to format your USB drive.

    Cheers,
    Anton

    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, September 4, 2017 4:57 PM
  • So yeah, the custom image that I've created in MDT is exactly 13.2 GB for the .ISO file.

    Britney

    Wednesday, September 13, 2017 9:10 PM
  • The only thing that really matters is the size of install.wim :)

    Cheers,
    Anton

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

    Wednesday, September 13, 2017 9:28 PM
  • Now I've only seen an install.wim file with the extracted files from the original Windows 10 .ISO file. But I have been on an Advisory Case to get help with this too, and was just told today that this could be an issue with ADK for 1703. Was told that we might have to downgrade to ADK for 1607.

    Britney

    Wednesday, September 13, 2017 11:35 PM
  • Right, you are using a reference image. Same idea basically - you need to use NTFS file system if your WIM file exceeds 4GB which effectively makes UEFI a non-option, unless you format your USB drive as outlined above (either using Rufus or creating a separate FAT32 boot partition). The only issue I am aware of with ADK 1703 is that they originally had issues with the incorrectly signed ADK driver, which would not install on a device with enabled Secure Boot.

    Cheers,
    Anton

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

    Thursday, September 14, 2017 5:53 AM
  • Ok, so the good news is that I got this working, mostly. I had to copy over two Boot files from the ADK 1511 into the Tools folder in my Deployment Share, etc. Now the problem that I'm having is the AutoLogon function has stopped working, and even after logging in manually, the task sequence does not resume.

    Britney

    • Marked as answer by BGibbs00 Wednesday, November 1, 2017 5:00 PM
    Tuesday, September 19, 2017 7:48 PM
  • As you can't process with Fat32 Bootable USB when wim file size exceeds 4GB.  Try to splitting the MDT Media. then use Fat32 file system.

    For AutoLogon function : forced it to run by adding /f in Autologon Command.

    After modifying MDT scripts the device is not booting with the USB,Modify the LTIApply.wsf script, 

    The script change at the end of this link may help:

    https://social.technet.microsoft.com/Forums/en-US/6c2f78f5-6974-45c2-bf68-541c0ba99974/usb-litetouch-deployment-reboot-loop?forum=mdt



    • Proposed as answer by KumarJ789 Saturday, October 28, 2017 11:48 AM
    • Unproposed as answer by KumarJ789 Saturday, October 28, 2017 11:48 AM
    • Proposed as answer by KumarJ789 Saturday, October 28, 2017 11:48 AM
    Friday, September 22, 2017 3:49 AM
  • Hi, i have same issue with offline media. what boot files you have copied to tools folder and from where (exact path please)?


    Pradeepreddy G

    Monday, November 13, 2017 4:51 PM
  • These are the following files that need to be copied from the ADK 1511. (The paths below should also correspond with the location of the below files as well)

    • BCDboot
    • Bootsect

    And you'll copy them to these paths for your current version of ADK installed on your server:

    C:\windows\Programfiles(x86)\Windowskits\10\Assessment and Deployment toolkit\Deployment tools\amd64 and C:\windows\Programfiles(x86)\Windowskits\10\Assessment and Deployment toolkit\Deployment tools\x86.


    Britney

    Monday, November 13, 2017 4:58 PM