none
MDT 2012: Force MININT and _SMSTaskSequence on C Drive

    Question

  • Hi,

    I'm deploying Windows 7 X64 using MDT 2012, I format 3 partitions at the beginning of the task sequence and I assign them specific drive letters during the state restore phase.
    I had no problem with MDT 2010 but since I'm using MDT 2012 MININT and _SMSTaskSequence folders are created on partition 2 so when I assign my drive letters deployment fails.
    I tried to force SMSTSLocalDataDrive in cs.ini but it seems that MDT doesn't care, I can see in the variables.dat that the C drive is selected but folders are still in my second partition.
    Any help?

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene


    Wednesday, April 25, 2012 10:55 AM

Answers

All replies

  • Are you performing a new computer deployment?  If so, the formatting would be done during the preinstall phase, not state restore.  And there is no way provided in the "Format and Partition Disk" step to assign drive letters, since the values assigned in Windows PE wouldn't be persisted through to the new OS anyway.

    Generally it's best to let MDT put the folders where it wants them.  In MDT 2012, we will try to put them on the volume that the OS will target, and that's often not the first volume.  If the first volume is the boot volume and the OS goes to the second volume, then having the folders on the first volume (which would be C: at that point) would be very bad - when the machine boots into the new OS, that first volume (C:) would be hidden, and that would prevent the task sequence from continuing.


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus

    Wednesday, April 25, 2012 3:14 PM
  • Thanks Michael,

    I do format during the preinstall phase, I just reassign drive letters during the state restore phase.
    My first partition is the system partition, I don't have any extra boot partition, but the folders keep copying on the second partition so when I reassign drive letters the task sequence fails.
    With MDT 2010 there was no problem, folders were on my system partition.

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene


    Wednesday, April 25, 2012 4:33 PM
  • What if I make a script to move those folder after reassigning drive letters?

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Thursday, April 26, 2012 8:19 AM
  • I don't think that's nearly as easy as it sounds.  It would be better to make sure whatever custom steps you have in the task sequence are able to deal with different drive letters.


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus

    Thursday, April 26, 2012 4:41 PM
  • The problem is the 2 folders keep being created on another partition than the system partition. I try to put this partition first and my system partition second and the task sequence still put the folders on the same partition! It's like the TS is looking for this partition to copy these folders!
    It's driving me crazy! And I don't understand why did it work with MDT 2010...
    Which script determines where to create MININT and _SMSTaskSequence?

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene


    Thursday, April 26, 2012 5:50 PM
  • We modified the logic in MDT 2012 to use the first available partition that would be able to hold an OS.  That logic is in LiteTouch.wsf.  It used to be hard-coded to use C:, but that caused failures in scenarios like the one I described (hidden boot partition).


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus

    Thursday, April 26, 2012 6:02 PM
  • So I don't understand why MDT uses the second available partition instead of using the first, but uses the first when I want it to use the second... I'm going to study litetouch.wsf a litlle bit and I'll try to understand.

    Thanks again Michael for your time.

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Thursday, April 26, 2012 9:43 PM
  • I presume it is that part of the code which determine the SMSTSLocalDataDrive:

    If oEnvironment.Item("PHASE") = "" Then
    oEnvironment.Item("SMSTSLocalDataDrive") = GetFirstPossibleSystemDrive
    oUtility.VerifyPathExists oEnvironment.Item("SMSTSLocalDataDrive") & "\MININT\SMSOSD\OSDLOGS"
    oUtility.ResetLocalRootPath
    End If

    But I still don't understand how does the script determine which partition is the first possible system drive.
    I don't have bitlocker partition, my system partition is the first one so why does MDT keep chosing the second one? And why when I change the partition order to make the second partition my system partition MDT chose the first! Is MDT playing with my nerves?

    To be more precise, my client wants 3 partitions, don't ask me why, it's like that unfortunately:
    1_C:\=System
    2_R:\=Recovery
    3_D:\=Data

    MDT always assign letter C to Recovery Partition, even if it is the second one...


    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Friday, April 27, 2012 8:03 AM
  • OK I gave up and cheated to obtain what I want.
    I format the system partition during the preinstall phase and the 2 others during the State Restore phase.
    Thanks anyway.

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Wednesday, May 2, 2012 9:56 AM
  • I've run into this same problem and I don't think the code works quite as you've explained.

    First, my scenario:

    I'm creating automatic boot partition plus two partitions (100GB C: primary partition for OS, and 100% remaining D: partition for data storage).

    I have a custom task sequence step that is unassigning the D: letter from my data partition and remounting it under a directory within the C: drive.

    All was working as desired when the D: partition was smaller than C: (on a machine with a small hard disk).  Both the MDT (MININT\SMSOSD\OSDLOGS) and TSManager (_SMSTaskSequence) folders are being created on C:.  When I tested with a larger HD where D: was larger than C:, they moved to D:.

    From my explorations I've determined that the TSManager, when its folders disappear due to the reformatting by ZTIDiskpart.wsf, searches for a new storage location and seems to choose the largest fixed drive (I haven't confirmed that it isn't the "last" fixed drive).

    MDT, when determining a new LocalRootPath in my scenario, is using the same drive as TSManager (_SMSTaskSequence).  See ZTIUtility.vbs (ver 6.0.2223.0), Class Utility, Property Get LocalRootPath (line 1736).

    I've been able to override this behaviour by explicitly defining the use of the OS disk at the end of ZTIDiskPart.wsf:

    ' Hack to make TSManager use the new OSDisk volume for its logs and state data '
    ' Add to end of ZTIDiskpart.vbs before exiting Main '
    
    If sDestinationDrive <> "" Then
        oUtility.VerifyPathExists sDestinationDrive & "\MININT\SMSOSD\OSDLOGS"
        oUtility.ResetLocalRootPath
    
        oEnvironment.Item("_SMSTSMDataPath") = sDestinationDrive & "\_SMSTaskSequence"
        oEnvironment.Item("SMSTSLocalDataDrive") = sDestinationDrive
    End If

    Thanks, Mark

    PS.  MDT is a great product and I enjoy your blog.  Many thanks.

    Thursday, May 31, 2012 2:25 PM
  • Too Bad...I don't like to tweak MDT scripts in an entreprise environment, it involves too many things to do when you upgrade/reinstall MDT...

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Friday, June 1, 2012 7:19 AM
  • I spent some time trying to figure out why this happens and I think I've got it. MDT2010 would make sure that the system partition was C: after the partitioning was done. 2012 does not and in fact creates the system partition as the last drive letter it can find available. When you create a second partition, that becomes C: and it specifies that the log folder go on C:. When you reboot, the system partition becomes C: and C: becomes D:.

    Here's the changes I made to ZTIDiskpart.wsf

    395:
    old - sBootDrive =  GetLastAvailableDriveLetter
    new - sBootDrive =  GetNextAvailableDriveLetter

    404:
    old - oUtility.RunCommandWrite oExec, "ASSIGN LETTER=" & left(  GetLastAvailableDriveLetter, 1)
    new- oUtility.RunCommandWrite oExec, "ASSIGN LETTER=" & left(  GetNextAvailableDriveLetter, 1)

    501:

    old - sNextDriveLetter = left(GetLastAvailableDriveLetter,1) & ":"
    new - sNextDriveLetter = left(GetNextAvailableDriveLetter,1) & ":"

    I also posted this as a bug on Connect so hopefully it's fixed for the next release.

    Wednesday, October 3, 2012 2:22 PM
  • I spent some time trying to figure out why this happens and I think I've got it. MDT2010 would make sure that the system partition was C: after the partitioning was done. 2012 does not and in fact creates the system partition as the last drive letter it can find available. When you create a second partition, that becomes C: and it specifies that the log folder go on C:. When you reboot, the system partition becomes C: and C: becomes D:.

    Here's the changes I made to ZTIDiskpart.wsf

    395:
    old - sBootDrive =  GetLastAvailableDriveLetter
    new - sBootDrive =  GetNextAvailableDriveLetter

    404:
    old - oUtility.RunCommandWrite oExec, "ASSIGN LETTER=" & left(  GetLastAvailableDriveLetter, 1)
    new- oUtility.RunCommandWrite oExec, "ASSIGN LETTER=" & left(  GetNextAvailableDriveLetter, 1)

    501:

    old - sNextDriveLetter = left(GetLastAvailableDriveLetter,1) & ":"
    new - sNextDriveLetter = left(GetNextAvailableDriveLetter,1) & ":"

    I also posted this as a bug on Connect so hopefully it's fixed for the next release.

    The only thing putting me off doing this is why have MS changed it to use last letter for W7 when anything before uses first?
    Wednesday, October 3, 2012 2:51 PM
  • I spent some time trying to figure out why this happens and I think I've got it. MDT2010 would make sure that the system partition was C: after the partitioning was done. 2012 does not and in fact creates the system partition as the last drive letter it can find available. When you create a second partition, that becomes C: and it specifies that the log folder go on C:. When you reboot, the system partition becomes C: and C: becomes D:.

    Here's the changes I made to ZTIDiskpart.wsf

    395:
    old - sBootDrive =  GetLastAvailableDriveLetter
    new - sBootDrive =  GetNextAvailableDriveLetter

    404:
    old - oUtility.RunCommandWrite oExec, "ASSIGN LETTER=" & left(  GetLastAvailableDriveLetter, 1)
    new- oUtility.RunCommandWrite oExec, "ASSIGN LETTER=" & left(  GetNextAvailableDriveLetter, 1)

    501:

    old - sNextDriveLetter = left(GetLastAvailableDriveLetter,1) & ":"
    new - sNextDriveLetter = left(GetNextAvailableDriveLetter,1) & ":"

    I also posted this as a bug on Connect so hopefully it's fixed for the next release.

    The only thing putting me off doing this is why have MS changed it to use last letter for W7 when anything before uses first?
    I have the same question, but we're still using MDT2010 and haven't had any issues with it making the system partition the first drive letter for 2008 R2. If there's a reason, hopefully I'll get that feedback with the bug I posted. I just can't move forward with MDT 2012 and use it in production with this issue.
    Wednesday, October 3, 2012 2:56 PM
  • That's it! I hope they'll fix this issue.

    Thank you Rich C.

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Thursday, October 4, 2012 9:11 AM
  • Well I've done some more testing and my solution doesn't work for all situations. The problem is the BDE partition. What I ended up using is similar to M Leighton's solution above. I add the following after line 610

    oUtility.VerifyPathExists left(sDestinationDrive,2) & "\MININT\SMSOSD\OSDLOGS"
    oEnvironment.Item("SMSTSLocalDataDrive") = sDestinationDrive
    oUtility.ResetLocalRootPath


    This is after ZTIDiskpart figured out where the OS will be installed and stores that in the sDestinationDrive variable. Eariler in the script, they do something similar at line 215 when they know the target partition already exists. It just looks like it's missing at the point where the figure out what the OS partition is after diskpart runs. I'll update my bug report on Connect.

    • Proposed as answer by wweebbss Tuesday, April 2, 2013 1:05 PM
    Wednesday, October 10, 2012 5:27 PM
  • Thank you Rich.

    Michael, if you still follow this thread, what do you think about it?

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Wednesday, October 10, 2012 6:37 PM
  • Unfortunately Microsoft closed the bug report I opened and said everything works fine and they're not going to address it. That's like a slap in the face. Oh well, I'll look elsewhere to see if I can find a product where the vendor is actually willing to fix it's bugs. 
    Tuesday, October 23, 2012 7:17 PM
  • oEnvironment.Item("SMSTSLocalDataDrive") = sDestinationDrive
    oUtility.ResetLocalRootPath
    Main = SUCCESS

    add this script to line 672 ,similar the issue solved,thanks.


    • Edited by whitjjx Wednesday, September 24, 2014 9:16 AM
    • Proposed as answer by John19741 Thursday, September 25, 2014 11:49 AM
    Wednesday, September 24, 2014 9:15 AM
  • oEnvironment.Item("SMSTSLocalDataDrive") = sDestinationDrive
    oUtility.ResetLocalRootPath
    Main = SUCCESS

    add this script to line 672 ,similar the issue solved,thanks.


    This works beautifully! Thank you whitjjx!

    As for Microsoft... Not cool, very un-cool..

    Thursday, September 25, 2014 11:51 AM
  • Thanks Rich for this fix.

    We also had this issue in USB Media deloyment scenario with USB stick regornized as DriveType 2 (fixed Drive). Removeable Drive (DriveType 1) did not display that problem.
    The Minint and _SMSTaskSequence folder would appear on the USB drive right after ZTIDiskpart and this would show in the BDD.log by searching for d:\minint (when the USB is detected as D).
    We are still testing but in some instance, on the first reboot into windows after mini-setup if the USB drive was not fast enough the build would simply hang without any error on screen. That was because LTIBootstrap.exe could not find the LiteTouch script. We think that this fix should help with this issue since MININT is now kept on the SYSTEM drive.

    ZTIDiskpart still does not have this fix in MDT 2013 update 1 (the second update 1 that is ;) ).


    Manuel Toussaint

    Thursday, October 1, 2015 1:50 PM
  • We have managed to fix this by adding the following entry @ line 657 within ZTIDiskpart.wsf  in the MDT scripts folder:

    oUtility.VerifyPathExists left(sDestinationDrive,3) & "\MININT\SMSOSD\OSDLOGS"
    oEnvironment.Item("SMSTSLocalDataDrive") = sDestinationDrive
    oUtility.ResetLocalRootPath

    Notice the 3 after sDestinationDrive? That's the OS partition being specified. We had to change it from partition 2 as the default UEFI format TS identifies partition 3 as the OS partition.

    Our MDT 2013 build:6.3.8443.1000

    Tuesday, June 27, 2017 1:00 PM
  • August 2017 and this is still an issue where MDT will place logs on a secondary drive for whatever reason, and causes the deployment to fail. We also try not to edit the default scripts as they are overwritten when you upgrade to a new version of MDT. (We already have a lot modified and its very hectic.) Anyone figured out a different solution.

    @Michael Niehaus - We truly appreciate you sir and all that you do. Whenever I see your name on a forum online, I get a warm fuzzy feeling inside. 

    Friday, August 18, 2017 5:50 PM
  • I've run into this same problem and I don't think the code works quite as you've explained.

    First, my scenario:

    I'm creating automatic boot partition plus two partitions (100GB C: primary partition for OS, and 100% remaining D: partition for data storage).

    I have a custom task sequence step that is unassigning the D: letter from my data partition and remounting it under a directory within the C: drive.

    All was working as desired when the D: partition was smaller than C: (on a machine with a small hard disk).  Both the MDT (MININT\SMSOSD\OSDLOGS) and TSManager (_SMSTaskSequence) folders are being created on C:.  When I tested with a larger HD where D: was larger than C:, they moved to D:.

    From my explorations I've determined that the TSManager, when its folders disappear due to the reformatting by ZTIDiskpart.wsf, searches for a new storage location and seems to choose the largest fixed drive (I haven't confirmed that it isn't the "last" fixed drive).

    MDT, when determining a new LocalRootPath in my scenario, is using the same drive as TSManager (_SMSTaskSequence).  See ZTIUtility.vbs (ver 6.0.2223.0), Class Utility, Property Get LocalRootPath (line 1736).

    I've been able to override this behaviour by explicitly defining the use of the OS disk at the end of ZTIDiskPart.wsf:

    ' Hack to make TSManager use the new OSDisk volume for its logs and state data '
    ' Add to end of ZTIDiskpart.vbs before exiting Main '
    
    If sDestinationDrive <> "" Then
        oUtility.VerifyPathExists sDestinationDrive & "\MININT\SMSOSD\OSDLOGS"
        oUtility.ResetLocalRootPath
    
        oEnvironment.Item("_SMSTSMDataPath") = sDestinationDrive & "\_SMSTaskSequence"
        oEnvironment.Item("SMSTSLocalDataDrive") = sDestinationDrive
    End If

    Thanks, Mark

    PS.  MDT is a great product and I enjoy your blog.  Many thanks.

    After days of searching and lots of changes and solutions - this is the only solution that really solved the problem !!
    True, I respond to a message from almost 8 years ago, but I owed someone else in the world who might have the same problem as me.
    Thank you!!
    Thursday, August 23, 2018 2:43 PM