Sunday, 13 May 2018 08:48

Dynamically Select SSD Drive for OS Installation

Written by
Rate this item
(5 votes)

image

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:
    image
    image
    image
  • Make sure that disk index on the alternative "Format and Partition (UEFI)" step is set to 1.
    image

That's it!

Tweet me if you fancy or have any questions.

Read 67474 times Last modified on Sunday, 13 May 2018 09:38

Recent Posts

  • Windows 10 21H2 Built-In Apps: What to Keep
    The development of the Windows 10, version 21H2 is finished and the update will soon be available for download from…
    Written on Wednesday, 20 October 2021 11:41
  • Group Policy Changes in Windows 10 21H2
    As Windows 10, version 21H2 update development winds down, Microsoft is now preparing for the final release of the Windows…
    Written on Wednesday, 20 October 2021 07:20
  • Group Policy Changes in Windows 10 20H1 Preview
    As Windows 10 Vibranium Update (20H1) development winds down, Microsoft is now beginning the phase of checking in the final…
    Written on Tuesday, 14 January 2020 04:51
  • An alternative ESU MAK Activation Solution
    This blog post was shared with me by a colleague of mine, Daniel Dorner, a Microsoft Premier Field Engineer. It’s…
    Written on Wednesday, 04 December 2019 21:04
  • The Case of Missing UE-V Templates
    My customers often deal with unexpected Windows behavior and this case is no different. This particular one is especially interesting…
    Written on Tuesday, 03 September 2019 12:20
  • The Case of Changing Default Printer
    While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s…
    Written on Wednesday, 14 August 2019 20:36