none
MDT deploying boot files to wrong drive RRS feed

  • Question

  • We are experiencing a intermittent problem when deploying to hardware using media since upgrading to MDT 2013. Periodically when techs attempt to apply a image litetouch boots, runs through the initial steps, gets all the way past applying the image/applying unattended, then reboots. The problem is when the machine reboots instead of booting into Windows and finishing configuration we get a black screen that states "An operating system wasn't found.  Try removing drives that don't contain an operating system". After going through logs and looking further into this it appears MDT is putting the image on the correct internal drive but from some reason the actual boot folder is overwriting MDT's boot folder on our external media. Also the MININT and _SMSTaskSequence files are being put on the external media instead of C: (I'm not sure if that is normal behavioror not).

    Here is my smsts.log if it's any help. If there are any other logs I should include please let me know.

    smsts.log

    Friday, February 13, 2015 7:18 PM

Answers

  • AH!

    Configuration Manager sometimes places it's control files on the *LARGEST* fixed disk partition.

    If you are using external 1TB drives that are *LARGER* than your PC drives, that could be the issue.

    Again, I would recommend smaller Flash Drives, or you can escalate through Microsoft Support.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Monday, February 16, 2015 5:25 PM
    Moderator

All replies

  • Perhaps you sometimes use USB flash drives, and sometimes USB Hard Drives? There may be a difference (I don't recall). I would stick with USB FLash Drives.

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Monday, February 16, 2015 7:08 AM
    Moderator
  • No we always use USB hard drives. So far the only possible connection I've found is our 1 TB external drives seem to be having trouble. The ones we have that are smaller seem fine. Also even with the 1 TB drives it's not a constant. The drive may do 4-5 computers no problem, then on number 6 it just breaks. 

    The only thing we changed in our process was the upgrade to MDT2013, everything was fine while we were on 2012. I know flash drives are the preferred method for deployment, and we will make the switch if we have to. We would prefer to stick with the HDD's however because it gives us room to keep other boot utilities, tools, and perform data backups as well as image all on one drive.

    Monday, February 16, 2015 3:41 PM
  • AH!

    Configuration Manager sometimes places it's control files on the *LARGEST* fixed disk partition.

    If you are using external 1TB drives that are *LARGER* than your PC drives, that could be the issue.

    Again, I would recommend smaller Flash Drives, or you can escalate through Microsoft Support.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Monday, February 16, 2015 5:25 PM
    Moderator
  • Thanks, that's what I was afraid of. What's strange is my older 500 gig drive is still larger then most our internal drives and it always works. Even the 1TB drives seem to work about 50% of the time or better, but all it takes is the one time it doesn't work to screw everything up for us. Most of my research had said exactly what you just told me though, I was just hoping someone might have a quick fix.
    Wednesday, February 18, 2015 6:46 PM
  • We are having a similar issue with MDT 2013 Update 2 running on an HP blade BL280c G6 with Sata Drives. Primary drive is 160 GB and Data drive is 500 GB, The Image we are applying is win2012 R2 server captured from single partition.  We run litetouch, it applies the os and reboots, get no OS found, we find that it is applying the OS to the 500 GB drive (which is in the second slot).  We have tried with the SATA RAID enabled and without, makes no difference.
    Friday, February 10, 2017 5:46 PM
  • Also hitting this issue - it's quite aggravating.

    Even if you go to the trouble of digging through the MDT scripts to get it to choose the right drive to install the OS to, when TSMBootstrap.exe is called, it always chooses the largest disk to use to store its state, even if this disk is the drive you are deploying from.

    Making the source drive read-only doesn't help either. TSMBootstrap.exe will still try to use it and failure occurs.

    It would be great if we could have the source to TSMBootstrap.exe/TsManager.exe . MDT is a great tool, but it has several reasonable use cases it can't handle. Most can be worked around by digging into and editing the scripts, but if an issue is in the binaries, it's much harder.

    For now I'm living with deployment keeping state on the source deploy drive, as wrong as that is.

    Friday, June 9, 2017 9:44 PM
  • I realize this is an old topic but since it got bumped recently I thought I'd chime in. 

    We experienced the exact same issue when moving to MDT 2013 (and up to 8443 now) with using large external media drives for deployments.

    Up until recently we had given up on it but we decided to try and tackle it again since we were running out of space on our smaller flash drives and had all these 1TB palm drives laying around not being used.

    While it is accurate that MDT does seem to prefer to target the largest available drives for installing the OS on we think we may have found a way to stop it from identifying the 1TB drive as a potential "internal" drive.

    In looking through the ZTIDiskUtility.vbs script we found the section where it identifies USB connected devices and "excludes" them from being a target drive.  What was confusing us is that the palm drives we use are very clearly USB drives but for some reason not being "excluded".  We ended up running a command "wmic diskdrive get interfacetype" from command prompt while the palm drive was plugged in and found that in spite of it physically being plugged in via USB, the system saw it as a SCSI connection.  This appeared to be hardcoded in the firmware of the drive itself.  

    To get around this we ran "wmic diskdrive get mediatype" and found that it was listed as "External hard disk media".  Knowing this we went into ZTIDiskUtility.vbs, down to the "Function isOSReady" section and where it states:

    If not isempty(g_Win32_DiskDrive) then
    isOSReady = g_Win32_DiskDrive.InterfaceType <> "USB" and g_Win32_DiskDrive.InterfaceType <> "1394"

    We appended it to say this:

    If not isempty(g_Win32_DiskDrive) then
    isOSReady = g_Win32_DiskDrive.InterfaceType <> "USB" and g_Win32_DiskDrive.InterfaceType <> "1394" and g_Win32_DiskDrive.MediaType <> "External hard disk media"

    It is important to note that the code we added was specific to our model palm drive that we use (Seagate BackUp Plus Portable Drive) so other model drives may return different values.

    I must also caution that we are still testing this out but so far we have not had a deployment try to install on the palm drive itself since making this modification.  We are however still having problems during UEFI deployments where after the first reboot, certain models of hardware (particularly HP models) are booting right back into the external drive instead of picking up from the internal hard drive but that issue seems unrelated to this script change and is happening on both palm drives and flash drives and seems to be related to how the BCD store is getting updated after the OS is copied.

    Good luck!

    Tuesday, June 13, 2017 6:29 PM
  • We image our equipment using USB sticks and drives.  I normally use USB drives for testing purposes.  I recently updated all USB drives to USB 3.0 with SSD drives.  That's when I started seeing this issue.  Ian's fix with editing the ZTIDiskUtility.vbs file worked for me so far.  I've been able to image six machines without the issue returning.  Thanks.
    Monday, January 29, 2018 8:22 PM