Sunday, 13 May 2018 08:48

Dynamically Select SSD Drive for OS Installation

Written by
Rate this item
(0 votes)


If you’ve read any of my tweets, you know that I emphasize how Microsoft Deployment Toolkit and ConfigMgr are powerful OS deployment tools which allow a high grade of customization. This blog post is another demonstration of MDT flexibility. It also shows how a PowerShell script can quickly lead to a solution.

The other day, as I was working with a customer on implementing a Windows 10, version 1803 based MDT task sequence, one of IT technicians mentioned that they had issues installing newly received HP ProDesk 600 MT G3 computers. These computers (at least the top tier configuration with Intel Core i7 and 16 GB RAM) have a somewhat unique hard drives configuration: on the inside, there are actually two disks: an HDD and an SSD. The problem: the SSD is being identified as Disk 1, which leads to two issues:

  • MDT picks the HDD as the first boot device and uses it during the "Format and Partition" step.
  • After applying the OS image, an attempt to create BCD entries will fail at the Verify BCDBootEx step with the following exit code: 15250.

I verified the issue, checked the log files, but could not find anything that would explain the problem right away. However, when looking at the attached disks I noticed that there were two Windows installations: one on the HDD (performed by the Microsoft Deployment Toolkit) and one on the SSD (HP's Windows 10 factory image). My assumption, therefore, was that the existing Windows 10 installation broke MDT function that creates a new boot entry for the new OS using BCDBoot.exe.

Running diskpart clean on the SSD in order to remove the factory image would only solve part of the problem: MDT (and Configuration Manager for that matter) would still pick the slower HDD for the OS installation. This is the expected behavior as by default each task sequence assumes that the first enumerated fixed disk should be used during the Format and Partition Disk step.

My goal now was to identify a workaround which would allow the customer to dynamically determine if the internal SSD was enumerated as the first or second boot device and adjust disk number for the Format and Partition (UEFI) task sequence step accordingly. There are actually multiple ways to achieve this:

  • Assuming that all HP ProDesk 600 MT G3 models come with the same fixed disk configuration, one could simply duplicate the "Format and Partition (UEFI)" disk step, change the disk index to 1 and test for "HP ProDesk 600 MT G3" in order to use the modified step just for this particular model. Personally, I would not go down this path as it makes a few assumptions and things typically change down the road.
  • You could modify the ZTIDiskPart script - which creates the disk partitions on the target computer by calling the Diskpart utility - as demonstrated by Keith Garner on multiple occasions by dynamically altering the OSDDiskIndex variable. 
  • Finally - and this is the solution I opted for - you could use a PowerShell script to query hard drive configuration. While this approach involves modifying your task sequences, it is MDT version agnostic and does not require reapplying your code modifications with each Microsoft Deployment Toolkit update. So I went ahead and wrote a small PowerShell script that uses Get-Disk and Get-PhysicalDisk cmdlets to query fixed disks attached to a system and pulls FriendlyName, MediaType and Number properties, merges the results together using Warren F's Join-Object function, and finally sets a variable which can be used to preselect one of "Format and Partition" steps in the task sequence.

I added the script to the MDT task sequence in the Pre-Install phase, performed the necessary modifications and - positive I'd solved my issue - ran the task sequence. To my immense satisfaction, the installation ran through. Case closed! As for why the creation of the new boot entry did not work in the first place, with everything else on my plate I haven’t had the time to investigate further.

Code Snippet:

Switch ($Model){
"HP ProDesk 600 G3 MT"{
    #Note: we need to make sure that SSD is not the first boot device, so we need to evaluate the disk number as well
    $disksorder = Get-Disk | Select-Object Number,FriendlyName
    $physicaldisks = Get-PhysicalDisk | Select-Object FriendlyName,MediaType
    $disks = Join-Object -Left $disksorder -Right $physicaldisks -LeftJoinProperty FriendlyName -RightJoinProperty FriendlyName
    Write-Host "$($myInvocation.MyCommand) - Processing retrieved physical disks."
    Write-Host "$($myInvocation.MyCommand) - " $disks

    foreach($disk in $disks)
         if($disk.MediaType -like "SSD" -and $disk.Number -gt "0") {
                Write-Host "$($myInvocation.MyCommand) - SSD drive detected and it is not the first boot device."
                $TSenv.Value("IsNVMe") = "TRUE"
                Exit 0
            if($disk.MediaType -like "SSD" -and $disk.Number -eq "0") {
                Write-Host "$($myInvocation.MyCommand) - SSD drive detected and it is the first boot device. No change required."
                Exit 0

Note: The script has only been tested on HP ProDesk 600 MT G3 but should work for other models as well provided you adjust the script to match your model(s).

How does it work:

Should you end up in the same boat, follow these steps to work around the problem:

  • Add the SSDVerifier script to your MDT deployment share and insert it into your Windows 10 task sequence before Format and Partition steps.
  • Add IsNVME property to your CustomSettings.ini.
  • Duplicate your "Format and Partition (UEFI)" step and adjust execution conditions as illustrated below:
  • Make sure that disk index on the alternative "Format and Partition (UEFI)" step is set to 1.

That's it!

Tweet me if you fancy or have any questions.

Read 457 times Last modified on Sunday, 13 May 2018 09:38
  1. Comments (1)

  2. Add yours
There are no comments posted here yet
  1. NeoBeum

I wish MS figured this out earlier - I ran in to this problem August 2015 - Windows 10 forcing itself on to my old laptop resulted in its end, forced me to buy a new device - which had Windows 10 try to install itself over the Windows 8...

I wish MS figured this out earlier - I ran in to this problem August 2015 - Windows 10 forcing itself on to my old laptop resulted in its end, forced me to buy a new device - which had Windows 10 try to install itself over the Windows 8 installation - I configured my own installation - and then I realised after the first major update that Windows would change the BCD...
Further investigation late 2016 - early 2017, I realised that the command (CMD) terminal and powershell returned different values when querying physical disks... I raised a question on the MSDN forums asking about the API for MSFT_Disks and was met with a condescending tone (probably because I'm a student) but I asked why NVMe had no enumerator, and also gave examples of when my Samsung 850 Pro returned an interface of IDE in use...
The response I received made me angry.
I also pointed out that their process to find and choose an installation path for the operating system would yield the exact problem you are talking about here.
My problem was compounded by the fact that PCIE NVME was in its infancy when I purchased my notebook for school, so I had to trouble shoot this myself.
Searching for just SSD type present is insufficient when mixed with SATA III and PCIE NVME, and querying the SCSI ports may yeild different port numbers depending on how the device tree was first walked.

Queries from the following (up until my test last year did not return matching values at times)


and in Powershell:

If I find my thread, I'll send you a link


Read More

Leave your comments

Posting comment as a guest.
0 Characters
Attachments (0 / 3)
Share Your Location

Recent Posts