How to Ensure that Windows Installs on C: During a System Center Configuration Manager OSD Task Sequence


UPDATE!
This issue should no longer occur and the below solutions should no longer be needed starting with ConfigMgr Current Branch 1606 and newer. Starting with ConfigMgr Current Branch 1606 and newer, the OSDPreserveDriveLetter variable has been deprecated and ConfigMgr no longer tries to decide or tries to set what the OS driver letter should be. Instead it allows Windows Setup to determine the OS drive letter. Windows Setup usually sets the OS driver letter as C:.

Because Method #3 is basically what is being used in ConfigMgr Current Branch 1606 and newer, it is strongly recommended as the method to use in any older versions of ConfigMgr. If you were using Method #3 and it started to generate errors after upgrading to ConfigMgr Current Branch 1606 or newer, it is because the registry keys that were being deleted by Method 3 no longer exist. To fix the problem in ConfigMgr Current Branch 1606 or newer, just delete the Delete Mounted Devices group from the Task Sequence and is should resolve the problem.

Method 2 has been removed from the article as it does not make much sense when compared to either Methods 1 or 3.

Symptoms

When using an OSD Task Sequence with System Center 2012 ConfigMgr SP1 or newer to deploy a Windows OS, Windows may end up installing on a drive letter other than C:.

Cause

When using the ConfigMgr 2007 Operating System Install Package or the ConfigMgr 2012 Operating System Installer, Windows is installed by the Task Sequence while in WinPE by running Windows Setup.exe. ConfigMgr 2007 and ConfigMgr 2012 RTM allowed any version of Windows Setup.exe to run within its default version of WinPE. However technically it is only supported to run Windows Setup.exe under the matching version of WinPE. In other words, it is only supported to run Windows Setup.exe in the following scenarios:

 

Windows Version WinPE Version
Windows Vista WinPE 2.x
Windows 7 WinPE 3.x
Windows 8 WinPE 4
Windows 8.1 WinPE 5

 

The supported versions for use with ConfigMgr OSD for WinPE and Windows are as follows:

 

ConfigMgr Version Default WinPE Version Additional WinPE Supported Versions Windows Supported Versions For OSD
ConfigMgr 2007 RTM WinPE 2.0   Vista
ConfigMgr 2007 SP1 WinPE 2.1   Vista
ConfigMgr 2007 SP2 WinPE 3.0 WinPE 3.1 Vista, 7
ConfigMgr 2012 RTM WinPE 3.0 WinPE 3.1 Vista, 7
ConfigMgr 2012 SP1 WinPE 4 WinPE 3.1 (CU2), WinPE 5 (CU3) Vista, 7, 8, 8.1 (CU3)
ConfigMgr 2012 R2 WinPE 5 WinPE 3.1 Vista, 7, 8, 8.1

*Note: For the purposes of this article, Windows XP is excluded from the above list since it is out of support and does not contain Install.wim in its installation source files.

From the above table, using the default version of WinPE, there are versions of ConfigMgr that could technically run certain versions of Windows Setup.exe in a version of WinPE that does not match. For example, ConfigMgr 2007 SP2 or ConfigMgr 2012 RTM could run Windows Vista Setup.exe under WinPE 3. This scenario would technically not be supported. Therefore there were Operating System Install Packages and Operating System Installers in ConfigMgr 2007 SP2 and ConfigMgr 2012 RTM that were technically running in an unsupported scenario.

However, when using the ConfigMgr Operating System Image, ConfigMgr uses wimgapi.dll to apply the WIM image instead of using Window Setup.exe. Since Windows Setup.exe is never used, the versions of Windows and WinPE do not have to match. Using the previous scenario of Windows Vista being deployed under WinPE 3, if using an Operating System Image, deployment of Windows Vista would be supported using WinPE 3.

In ConfigMgr 2012 SP1, changes were made so that ConfigMgr would be in a fully supported scenario. For example, when running through the Create Task Sequence Wizard and specifying to Build and capture a reference operating system image, at the Install Windows screen, it prompts for an Operating System Image package. Previous to ConfigMgr 2012 SP1, it would instead prompt for either an Operating System Install Package (ConfigMgr 2007) or an Operating System Installer (ConfigMgr 2012 RTM). In ConfigMgr 2012 SP1 and newer, to have the equivalent of using either an Operating System Install Package (ConfigMgr 2007) or an Operating System Installer (ConfigMgr 2012 RTM), an Operating System Package with Install.wim from the Windows installation source files can be created and used at this step.

*Note: If manually changed, ConfigMgr 2012 SP1 and newer does not prevent an Operating System Installer from running in a version of WinPE that does not match the Windows OS that the Operating System Installer is installing. However doing so is considered unsupported.

However in ConfigMgr 2007 and ConfigMgr 2012 RTM, there was a known issue that if Install.wim was being used as an Operating System Image, the OS would end up on D: instead of C:. The reason that Install.wim ended up on D: was that Install.wim from the install source files of some Windows versions was captured from a partition with drive letter D:. For this reason in ConfigMgr 2007 and ConfigMgr 2012 RTM using Install.wim via an Operating System Image was not a supported scenario.

Because of the design change in ConfigMgr 2012 SP1 that allowed Install.wim to be used as an Operating System Image, changes were made to ConfigMgr 2012 SP1 that allowed Windows to be installed on C: instead of D: when using Install.wim. However flexibility was still left in that allowed an administrator to install Windows on a drive letter other than C:, including the drive letter that the original WIM image was captured on.

To control the behavior of what drive letter Windows ended up on, a new variable called OSDPreserveDriveLetter was introduced in ConfigMgr 2012 SP1. This variable allows an administrator to specify what drive letter Windows will end up on. However the use of OSDPreserveDriveLetter is not immediately intuitive. From the TechNet documentation:

 

Task Sequence Built-in Variables in Configuration Manager
http://technet.microsoft.com/en-us/library/hh273375.aspx

This variable determines whether or not the task sequence uses the drive letter captured in the operating system image WIM file when applying that image to a destination computer. In Configuration Manager with no service pack, the drive letter captured in the WIM file is used when applying the operating system image WIM file. In Configuration Manager SP1 (or R2), you can set the value for this variable to False to use the location that you specify for the Destination setting in the Apply Operating System task sequence step.

 

The above TechNet document can be confusing as it alludes that there is a way to specify a drive letter that the Windows partition will receive via the Destination option in the Apply Operating System Image task. However the Destination option in the Apply Operating System Image task only specifies what drive letter Windows gets installed to while in WinPE, not what drive letter the Windows partition will receive once it boots out of WinPE.

The way OSDPreserveDriveLetter actually works is if OSDPreserveDriveLetter is set to TRUE (default), when the Task Sequence reboots out of WinPE, the Windows partition will be assigned the drive letter assigned in the captured OS WIM. If OSDPreserveDriveLetter is set to FALSE, when the Task Sequence reboots out of WinPE, the Windows partition will be assigned the same drive letter that was assigned to the OS partition while in WinPE.

In most cases administrators want the new Windows OS to be assigned a drive letter of C:. However there are certain deployment scenarios where WinPE does not assign the OS partition a drive letter of C: and the OS WIM file was not captured with a drive letter of C:, causing OSDPreserveDriveLetter to be an ineffective way to specify that Windows should end up on C:. For example take the following Refresh with USMT hardlinking on a BIOS PC scenario:

  • BIOS PC has a disk with two partitions - System Reserved (boot) partition and OS partition
  • Disk is not formatted via the Format and Partition Disk task due to the USMT hardlink store that is on the local drive
  • Install.wim from Windows installation source files is being used

In the above scenario, when the PC boots from the original OS into WinPE, the System Reserved boot partition will receive a drive letter of C: and the OS partition will be assigned a drive letter of D:. Since the OS partition in WinPE has a drive letter of D: and Install.wim also has a drive letter of D:, regardless of what OSDPreserveDriveLetter is set to, Windows will end up on D:.

In general, the issue where OSDPreserveDriveLetter cannot be reliably used only happens on BIOS PCs. It does not happen on UEFI PCs (unless the UEFI PC is in BIOS compatibility mode). The reason for this is that on UEFI PCs, the partitions that preceded the OS partition (EFI, MSR, Recovery) by default are not assigned a drive letter or are assigned a drive letter that is higher than C:. For example the EFI partition is temporarily assigned a drive letter of S: so that the BCD store can be created on the partition. The end result is that the first partition to receive a drive letter is the OS partition, resulting in the OS partition receiving a drive letter of C:.

The below Resolution will present three two different methods of ensuring that Windows ends up on C: and works around scenarios where OSDPreserveDriveLetter may not work as expected. Each method has its pros and cons which are discussed. Which method is best depends on the scenario and the environment.

Resolution

Choose below from the three available methods to resolve the issue:

 

Method 1: Configure The Format And Partition Disk Task To Properly Assign Drive Letters

In this method, the Format and Partition Disk task is used to control what drive letters the partitions are assigned. Using this method will ensure that the OS partition receives a drive letter of C: while in WinPE. OSDPreserveDriveLetter will then be set to False so that after the Task Sequence reboots out of WinPE, the Windows partition ends up with the drive letter of C:

  1. In the ConfigMgr console, navigate to Software Library --> Operating Systems --> Task Sequences.
     
    Software Library --> Operating Systems --> Task Sequences
     
  2. In the Results pane of the ConfigMgr console, right click on the affected Task Sequence and choose Edit.
     

    Edit Task Sequence
     

  3. In the Task Sequence, select the Format and Partition Disk task to highlight it. In some circumstances the task may have a custom name such as Partition Disk 0 - BIOS or Partition Disk - UEFI. For MDT Task Sequences, the Format and Partition Disk tasks will have custom names such as Format and Partition Disk (UEFI), Format and Partition Disk 6.1, and Format and Partition Disk 6.0.
     
  4. In the Format and Partition Disk task, under Volume, for each volume BEFORE the OS volume:
     
    1. Highlight the volume, right click on it, and then choose Properties.
       

      Boot Partition
       

    2. Ensure the option Do not assign a drive letter to this partition is checked. *Note: Certain partition types (Recovery, EFI, MSR) will have this option greyed out and are unchecked by default. This is normal and expected.
       

      Boot Partition Properties
       

    3. Click on the OK button to save the properties for the volume.
       
    4. Repeat Steps a-c for each volume that is before the OS volume.
       
  5. In the Format and Partition Disk task, under Volume, highlight the volume where the OS will be installed. Right click on it and choose Properties.
     

    OS Partition
     

  6. In the Partition Properties window, make sure the settings are configured as follows:

    Do not assign a drive letter to this partition:
    Unchecked

    Variable:
    OSDisk
     
    OS Partition Properties

    Click on the OK button to save the properties for the volume. If there any volumes after the OS volume, they can be left as is.
     

  7. If there are multiple Format and Partition Disk tasks in the Task Sequence, repeat Steps 4-6 for each Format and Partition Disk task. *Note: MDT Task Sequences will have multiple Format and Partition Disk tasks.
     
  8. Select the task immediately before the Apply Operating System Image task to highlight it. Add a Set Task Sequence Variable task by going to the Add menu and selecting General --> Set Task Sequence Variable. *Note: The Apply Operating System Image task may have the custom name of Apply Operating System.
     

    Add Set Task Sequence Variable Task
     

    This will add a Set Task Sequence Variable task immediately before the Apply Operating System Image task.
     

  9. In the newly created Set Task Sequence Variable task, configure the settings as follows:
     
    Name:
    Set OSDPreserveDriveLetter Variable
     

    Task Sequence Variable:
    OSDPreserveDriveLetter

    Value:
    FALSE
     
    OSDPreserveDriveLetter
     

  10. Select the Apply Operating System Image task to highlight it. *Note: This task may have the custom name of Apply Operating System.
     
  11. In the Apply Operating System Image task, configure the settings under the option Select the location where you want to apply this operating system as follows:

    Destination:
    Logical drive letter stored in a variable
     
    Variable name:
    OSDisk
     
    Apply Operating System Image
     
  12. Click on the OK button to save the Task Sequence.
     

In the above method, all volumes and partitions before the OS partition are not assigned a drive letter. This causes the OS partition to receive a drive letter of C: since it is the first partition to be assigned a drive letter. The drive letter of C: is then stored as a variable, and at the Apply Operating System Image task, the variable is indirectly used to specify that Windows should receive a drive letter of C: since OSDPreserveDriveLetter is set to FALSE. When OSDPreserveDriveLetter is set to FALSE, once the Task Sequence reboots out of WinPE, the Windows partition will receive the same drive letter as the OS partition while in WinPE.

 

Pros

  1. Works in all scenarios where the disk is partitioned and formatted during the Task Sequence via the Format and Partition Disk task.

Cons

  1. Does not work in scenarios where the disk is not partitioned and formatted during the Task Sequence via the Format and Partition Disk task, such as Refresh scenarios where USMT hardlinking is being used.
     
  2. May not work if a removable or external drive is connected to the PC and WinPE assigns a drive letter to the removable/external drive before assigning a drive letter to the internal hard disk partitions. This scenario is rare and usually only occurs if the internal hard drive has not been previously formatted.

 

Method 2: Use WinPEshl.ini To Reassign Drive Letters Before The Task Sequence Begins

Deprecated

 

Method 3: Force The New Windows OS To Reevaluate Drive Letters

Normally ConfigMgr determines what drive letters are assigned to each partition during the WinPE phase of the Task Sequence. However when deploying Windows outside of a ConfigMgr task sequence, Windows Setup determines the drive letters assigned to each partition. When allowing Windows to determine the drive letters, it will always assign the OS partition a drive letter of C:.

Instead of allowing ConfigMgr to determine the drive letters, the default behavior of allowing Windows to determine the drive letters can be used instead. This can be accomplished by deleting the registry entries that determine the drive letters as created by ConfigMgr.

 

Manually Add Steps To Existing Task Sequence

  1. In the ConfigMgr console, navigate to Software Library --> Operating Systems --> Task Sequences.
     

    Software Library --> Operating Systems --> Task Sequences
     

  2. In the Results pane of the ConfigMgr console, right click on the affected Task Sequence and choose Edit.
     

    Edit Task Sequence
     

  3. Select the Apply Operating System task to highlight it. Add a Run Command Line task by going to the Add menu and selecting General --> Run Command Line. This should add a Run Command Line immediately after the Apply Operating System Image task. *Note: The Apply Operating System Image task may have the custom name of Apply Operating System.

     
    Add Load Registry SYSTEM Hive Task
     

  4. In the newly created Run Command Line task, configure the settings as follows:
     
    Name:
    Load Registry SYSTEM Hive
     
    Command Line:
    reg.exe load HKLM\Temp %OSDTargetSystemDrive%\Windows\system32\config\system

     
     Load Registry SYSTEM Hive Properties
     

  5. Select the  Load Registry SYSTEM Hive task to highlight it. Add a Run Command Line task by going to the Add menu and selecting General --> Run Command Line. This should add a Run Command Line immediately after the Load Registry SYSTEM Hive task.
     
    Add Delete MountedDevices From Registry Task

     
  6. In the newly created Run Command Line task, configure the settings as follows:
     
    Name:
    Delete MountedDevices From Registry

    Command Line:
    text box enter in:
    reg.exe delete HKLM\Temp\MountedDevices /va /f

     
    Delete MountedDevices From Registry Task Properties
     

  7. While still in the Delete MountedDevices From Registry Run Command Line task, click on the Options tab and select Continue on error. This will ensure that there are no issues if the environment is ever upgraded to ConfigMgr Current Branch 1606 or newer where this is registry key value is no longer created.
     
  8. Select the Delete MountedDevices From Registry task to highlight it. Add a Run Command Line task by going to the Add menu and selecting General --> Run Command Line. This should add a Run Command Line immediately after the Delete MountedDevices From Registry task.
     
    Add Unmount Registry SYSTEM Hive Task
     
  9. In the newly created Run Command Line task, configure the settings as follows:
     
    Name:
    Unmount Registry SYSTEM Hive
     
    Command Line:
    reg.exe unload HKLM\Temp 

     
    Unmount Registry SYSTEM Hive Properties
     

  10. Click on the OK button to save the Task Sequence.
     

*Note: Although not officially supported, via this method, Install.wim could be used in ConfigMgr 2007 so that Windows ends up on C: instead of D:.

 


Copy and Paste Steps From Downloaded Task Sequence to Existing Task Sequence

Instead of following the above manual steps, the necessary Task Sequence steps have been exported as a stand-alone Task Sequence and provided as a download link below. These steps can be copied from the downloaded Task Sequence and added to an existing Task Sequence:

  1. Download the exported stand-alone ConfigMgr 2012 Task Sequence from the below link:
     

     ConfigMgr 2012 Task Sequence to Delete Mounted Devices

    ConfigMgr 2012 saves exported Task Sequence as ZIP files. Clicking on the above link should download the ZIP file automatically.
     

  2. Import the Task Sequence downloaded in Step 1 into ConfigMgr. This should create a new Task Sequence called Delete Mounted Devices. For information on how to import a Task Sequence see the below link:
     
    How to Manage Task Sequences in Configuration Manager
    How to Export and Import Task Sequences
    To import task sequences

    http://technet.microsoft.com/en-us/library/hh273490.aspx#BKMK_ExportImport
     

  3. In the ConfigMgr console, navigate to Software Library --> Operating Systems --> Task Sequences.
     

    Software Library --> Operating Systems --> Task Sequences
     

  4. In the Results pane of the ConfigMgr console, right click on the Delete Mounted Devices Task Sequence imported from Steps 1-2 and choose Edit.
     

    Edit Delete Mounted Devices Task Sequence
     

  5. In the Delete Mounted Devices Task Sequence, right click on the Delete Mounted Devices group from the Task Sequence and choose Copy. Do not close the Task Sequence.
     

    Copy Delete Mounted Devices Group
     

  6. In the Results pane of the ConfigMgr console, right click on the affected Task Sequence and choose Edit.
     

    Edit Task Sequence
     

  7. In the affected Task Sequence, highlight the Apply Operating System Image task and then right click and choose Paste. *Note: The Apply Operating System Image task may have the custom name of Apply Operating System.
     

    Paste Delete Mounted Devices Group
     

    This should add the Delete Mounted Devices group immediately after the Apply Operating System Image task.
     

    Delete Mounted Devices Group
     

  8. Click on the OK button in both Task Sequences to save and close them.
     

A special thanks to Michael Niehaus for providing this method.

 

Pros

  1. Works in all scenarios when an Operating System Image package is being used at the Apply Operating System Image task.
  2. Easiest to implement.

Cons

  1. There really aren't any. This is the preferred method.
  2. Does not work when using an Operating System Installers or Operating System Upgrade Packages package in the Apply Operating System Image task (deploying from Windows source files). However this is no longer the recommended method of deploying Windows or considered best practice, mainly due to the requirement of making sure that the version of WinPE matches the version of Windows that is being deployed. Instead create an Operating System Images package using Install.wim from the Windows source files (located under the Sources folder).
  3. This method is a bit of a "hack" and overrides the default behavior of ConfigMgr. **Supportability is questionable.** For this reason, if using this method, make sure to thoroughly test before implementing in a production environment. UPDATE! This method is actually now used by ConfigMgr Current Branch 1606 and newer so therefore is an officially supported method.

 

Frank Rojas
Senior Support Escalation Engineer

Delete Mounted Devices - CM12.zip


    Comments (10)

    1. Davut EREN says:

      Excellent Article. Thank you for your good document. I solved with 3.method

    2. Frank Rojas says:

      An "MDT" boot image is really a ConfigMgr boot image. There is nothing special about an MDT boot image except that the MDT Boot Image Creation Wizard makes adding optional components to WinPE easier - something that really is not even needed anymore with
      the optional components tab in the properties of the boot image introduced in ConfigMgr 2012. In other words, you don't have to do anything different - for an "MDT" boot image, the instructions are still the same.

    3. Excellent article. Thank you for sharing this useful information.

    4. yannara says:

      There is this thing, that if I enable "Do not assign a drive letter to this partition" on BDEDriver, OS will go to C: but I will have the BDE drive visible. I witnessed before, that this setting has actually the oppisite effect!

    5. Frank Rojas says:

      From my experience this option works as expected. However it sounds like you are using an MDT integrated Task Sequence. Some of the scripts that run during the MDT integrated Task Sequence, like ZTIBDE.wsf, may modify the behavior and may be causing the
      issue you are seeing.

    6. Leon Cao says:

      Thanks for your info, I am trouble with this issue several days. About method two, I am using SCCM 2012 R2 with MDT 2013 update 1, how can I create the MDT boot image with winpeshl.ini. In other words, where to put the winpishil.ini ingetrated with MDT
      to generae the MDT boot image? Thanks.

    7. Bernhard Köck says:

      Excellent article, thanks for all the work.

    8. Thanks Frank, much appreciated your article and the time devoted to provide indepth steps to be performed

    9. Sorin-Razvan Popa says:

      Excellent material, explanations included 🙂
      Many thanks and best regards,

    Skip to main content