locked
DestinationLogicalDrive won't set correctly RRS feed

  • Question

  • So here's my problem - I set this parameter in CustomSettings.ini like so:

    Diskpart tells me that my system partition is C: and that the volume number is 1 so I put:

    DestinationLogicalDrive=1

    After Re-imaging, I found NO LINES in ANY log files that indicate that it read this setting - and that references to it indicate that it has been set to D: (which is Diskpart volume number 2) ... I got frusterated and decided to hardcode this settting in the .wsf script itself to what it should be (C:) and it worked like a charm...

     

    Now....why doesn't setting it in CustomSettings.ini work?

    Here is what that portion of my CustomSettings.ini looks like:

     

    DestinationDisk=0

    DestinationPartition=1

    DestinationLogicalDrive=1

     

    Additional Details: I'm performing a refresh from XP->7 x86 and I have 1 hard drive with 2 partitions C: (system) and D: (data).

     

     



    • Edited by mdt_mishap Wednesday, September 14, 2011 8:41 PM Wrong variable name in title opps
    Tuesday, August 23, 2011 11:33 PM

All replies

  • Can you elaborate please on what you're trying to accomplish?  The default value for DestinationLogicalDrive in MDT is 0, so in your case, this would already be the C: drive.  By setting this to 1, you're targeting the D: drive.

    Actually... this is the code from ZTIUtility.vbs which uses that variable:

     

      If oEnvironment.Item("DestinationLogicalDrive") = ""  Then
       oEnvironment.Item("DestinationDisk") = 0
       oEnvironment.Item("DestinationPartition") = 1
       oEnvironment.Item("DestinationLogicalDrive") = "C:"
      End If

    So, the correct syntax might be the drive letter instead of a number.  Documentation isn't clear as far as I can find.

    • Edited by David Matan Thursday, August 25, 2011 6:46 PM syntax
    Wednesday, August 24, 2011 1:29 PM
  • My CustomSettings looks like this:

     

    DestinationDisk=0

    DestinationPartition=1

     

    DiskPart -> list volume output looks like this:

    0 E:   CD DRIVE 

    1 C:   SYSTEM

    2 D:   DATA 

     

    MDT is setting it to 2, D: (Data) - which is wrong (obviously). 

    So what I did was, in customsettings.ini, specify DestinationLogicalDisk=1

    This had no effect... The only way I was able to get the refresh to image the correct partition, was to go into the MDT scripts and hardcode the values. I feel like I shouldn't have to do that...

     

    Wednesday, August 24, 2011 7:54 PM
  • I'm beginning to think that this variable cannot be set via CustomSettings.ini :-/  I've tried settting it to C: and 1 but I don't see any resemblance of this in the logs....

     

    Anyone know what is going on?

    Thursday, August 25, 2011 6:30 AM
  • I'm still drowning on this issue --  I don't know what else to do....

     

    Things I've tried to set DestinationLogicalDrive:

     

    1) CustomSettings.ini / BootStrap.ini   Value: "C:"    Result: Failed

    2) Added Custom wsf script to set oEnvironment.Item("DestinationLogicalDrive")  Value: "C:"  Result: Value changed, but was reset to D: 

    3) Added A Task in the Task sequence to set the variable Value: "C:" Result: Value changed, but was reset to D:

     

    Do I need to set it in several places or am I missing something?

    Wednesday, September 14, 2011 8:24 PM
  • Shot in the dark, but I've been having issues because of the BDE partition for Bitlocker.  MDT keeps messing up my destination partition.  Still working through the logs and code but try preventing the partition with DoNotCreateExtraPartition=YES in your cs.ini (believe it's case sensitive) in yours and let me know how it goes.
    Thursday, September 15, 2011 4:38 AM
  • We figured how to fix 2 scenarios related to this but now we have 3rd one:

    Scenario1:

    • On Computer Management - Disk Management, Drive letter ("C") is not displayed while there IS "C Drive"
    • Fix is to
      - run DiskPart:
        RESCAN [Enter]
        EXIT [Enter]
      - Reboot

    Scenario2:

    • UpperFilters value is missing on HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}
    • Fix is to add PartMgr on UpperFilters and try again

    Now the 3rd scenario that I just faced is Physical drive is totally missing when I boot up with USB LiteTouch Bootable Media:

    • When I boot up with current Windows 7 (x86) and run DiskPart, I can tell that Disk 0 is recognized properly and OS is installed on Disk 0 Partition 1
    • When I run through "REFRESH" task sequence, it runs fine (without asking Destination Disk/Partition)
    • But when I boot up with USB, diskpart faiil to read current OS partition and display DestinationDisk variable has invalid value, etc. Sure enough, DiskPart shows the USB media only as Disk 0 and the physical destination disk is totally missing.
    • This used to work fine last week but somehow it happened this week...

    I hope that Scenario 1 and 2 is helpful for some of you and someone can answer my 3rd case...

    Regards,

    Young-


    YPae
    Thursday, September 15, 2011 3:56 PM
  • Shot in the dark, but I've been having issues because of the BDE partition for Bitlocker.  MDT keeps messing up my destination partition.  Still working through the logs and code but try preventing the partition with DoNotCreateExtraPartition=YES in your cs.ini (believe it's case sensitive) in yours and let me know how it goes.
    Hi David, I did already have DoNotCreateExtraPartition=YES in my CS.ini. Thanks though.
    Thursday, September 15, 2011 6:17 PM
  • We figured how to fix 2 scenarios related to this but now we have 3rd one:

    Scenario1:

    • On Computer Management - Disk Management, Drive letter ("C") is not displayed while there IS "C Drive"
    • Fix is to
      - run DiskPart:
        RESCAN [Enter]
        EXIT [Enter]
      - Reboot

    Scenario2:

    • UpperFilters value is missing on HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}
    • Fix is to add PartMgr on UpperFilters and try again

    Now the 3rd scenario that I just faced is Physical drive is totally missing when I boot up with USB LiteTouch Bootable Media:

    • When I boot up with current Windows 7 (x86) and run DiskPart, I can tell that Disk 0 is recognized properly and OS is installed on Disk 0 Partition 1
    • When I run through "REFRESH" task sequence, it runs fine (without asking Destination Disk/Partition)
    • But when I boot up with USB, diskpart faiil to read current OS partition and display DestinationDisk variable has invalid value, etc. Sure enough, DiskPart shows the USB media only as Disk 0 and the physical destination disk is totally missing.
    • This used to work fine last week but somehow it happened this week...

    I hope that Scenario 1 and 2 is helpful for some of you and someone can answer my 3rd case...

    Regards,

    Young-


    YPae
    YPae - this sounds like SCSI drivers could be missing from your PE WIM image.  And unfortunatly, your scenarios do not match with my issue. Thanks though.
    Thursday, September 15, 2011 6:19 PM
  • I found the root cause of my 3rd case.

    Someone enabled "HDD Password (DriveLock Password)" on the BIOS.

    Even though we typed in the HDD password to get to MDT, Diskpart is failing to recognize the DriveLock-Locked HDD.

    As soon as we removed it, everything is now fine.

    Thanks,


    YPae
    Friday, September 16, 2011 12:11 AM
  • So I understand now that the MDT variables will be reset multiple times throughout the deployment process - the thing that really ticks me off is that, even if I set an MDT variable via the task sequence - the variable does not remain set throughout the process.... Is this a known issue with MDT? 

     

    My inability to set DestinationLogicalDrive is causing all kinds of weird errors ranging from re-imaging the wrong partition to creating a duel boot ... setting the variable correctly in the beginning of the deployment will get me past the Validation .. but after that all bets are off...

     

    I really need help with permanently setting this variable. Anyone? Thanks in advance!

    Monday, September 19, 2011 7:27 PM
  • There's a few variables that are configured last-write-wins.  Everytime MDT runs a Gather sequence, it'll recollect some data and overwite certain variables. I'm not certain in what other scenarios MDT uses ZTIGather, so maybe someone else can pipe on on that.

    Assuming that's your issue, make sure that you set your destionan after any Gather tasks and before the OS applies.  The variable should stay constant.  I had a similiar issue when redefining the Model on certain hardware, and this worked for me.

     

    Monday, September 19, 2011 7:44 PM
  • david, thanks so much for your reply.

    Do you know which variables are configured as "last-write-wins" and which are "first-write-wins"

    From ZTIGather.log - I can see that, in a vanilla refresh task sequence, DestinationLogicalDrive gets set in two places:

    1) PreInstall->Gather local only

    2) State Restore->Gather local only

     

    Under the assumption that DestinationLogicalDrive is a "last-write-wins" variable, if I set this variable after these tasks, I should be golden.

    However, I am still very skeptical and confused as Johan Arwidmark points out that  "Most MDT variables are first-value-wins"

    Either way, I'll give it a go and report back.

    Monday, September 19, 2011 11:55 PM
  • I was watching the 2012 Beta 1 video http://channel9.msdn.com/Events/TechEd/Australia/Tech-Ed-Australia-2011/CLI313

    at around 54:26 - the speaker indicates that  if you try to refresh existing computers with various partition configurations, MDT will sometimes choose the wrong destination. 

    I guess I'm experiencing this issue? I'm using MDT 2010 U1.

    Tuesday, September 20, 2011 12:35 AM
  • The first-writer, last-writer settings per property are defined in ZTIGather.xml. Can be changed but that may lead to unexpected results, depending on scenario and property. Any property can be set at all times using a script or the set variable action., even after the Gather has been run. So if you really want a value set, you can set it.

    In general having multiple partitions with MDT 2010 is painful, and should be avoided (except bitlocker partitions) I know that Microsoft is trying to address that in MDT 2012 by rewriting that logic.

    / Johan

     

     


    Regards / Johan Arwidmark Twitter: @jarwidmark Blog: http://www.deploymentresearch.com FB: www.facebook.com/deploymentresearch
    • Proposed as answer by YPae Thursday, September 22, 2011 3:38 PM
    Tuesday, September 20, 2011 6:10 AM
  • Hi Johan, 

    Thank you for your reply. This variable is not defined in ZTIGather.xml.  It is referenced in a handful of scripts.

    It looks like DestinationLogicalDrive is being set based on a WMI query via the function GetBootDrive in ZTIDiskUtility.vbs. This yeilds the wrong value and is probably the source of my error.

    I would like to define this variable myself but in order to do so, I need to know a little more about it (such as whether it is modifiable, first-writer, last-writer, etc..).

    I'm pretty sure it is modifiable - and that I am getting closer to solving the problem -- 

    The next test I was thinking of performing was to set this variable in 5 places,once at initialization of the TS, and then before and after the places where I noticed it gets reset (see above comment). Does this look like the right approach? 

    I agree that multiple partitions/disks are a headache, but none-the-less a real-world issue that I cannot ignore...well, I could ignore, but then people get upset. At any rate, I'm very excited to see MDT 2012 to come out of beta. 

    Tuesday, September 20, 2011 8:34 PM
  • So in the Offical Documentation, within the Troubleshooting Reference, there is a section that says:

    "MDT 2010 does not support deploying operating systems to logical drives or dynamic disks."

    The computers that are problematic do have extended and logical partitions - but the drive to which I am deploying is NOT the logical one. So I *think* this line does not apply to me.

    Either way, I did run the test I said I was going to in my working environment and found that the setting gets updated. I now need to test on the troublesome machine. 

    I'm wondering, where does the envioronment variable %destinationlogicaldrive% get set? is it always the same as the MDT Variable DestinationLogicalDrive?

     

    Friday, September 23, 2011 11:52 PM