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 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

    • Ensure sure that the option Do not assign a drive letter to this partition is NOT checked for the OS volume.

    • Next to Variable: enter in:

      OSDisk

    • Click on the OK button to save the properties for the volume.

      OS Partition Properties

    • If there any volumes after the OS volume, they can be left as is.

  6. If there are multiple Format and Partition Disk tasks in the Task Sequence, repeat Steps 4-5 for each Format and Partition Disk task. *Note: MDT Task Sequences will have multiple Format and Partition Disk tasks.

  7. 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.

  8. 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

  9. Select the Apply Operating System Image task to highlight it. *Note: This task may have the custom name of Apply Operating System.

  10. 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

  11. 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

As explained in the Cause section, the problem can happen when a partition before the OS partition is assigned a drive letter before the OS partition is assigned a drive letter. This is a common scenario with Windows 7 and newer because the default configuration in Windows 7 and newer is to have a "System Reserved" partition (which is basically the boot partition) followed by the OS partition. Assigning of drive letters to these partitions is handled by WinPE when it first boots up. It normally assigns the System Reserved partition a drive letter of C: and the OS partition a drive letter of D:. After WinPE has assigned the drive letters, it processes a file called WinPEshl.ini. Any commands in the WinPEshl.ini file are then automatically ran.

When generating ConfigMgr boot images, a WinPEshl.ini file is created and inserted into the boot image that contains a command that starts the Task Sequence. This is the method that Task Sequences start when booting into WinPE. For more information on WinPEshl.ini files see the following TechNet article:

Winpeshl.ini Reference
http://technet.microsoft.com/en-us/library/hh825046.aspx

ConfigMgr has a feature where a custom WinPEshl.ini file can be specified instead of using the default WinPEshl.ini file. This allows additional commands to be run both before and after the Task Sequence executes.

This method will use a custom WinPEshl.ini file to add commands that run before the launch of the Task Sequence. The commands in the WinPEshl.ini will reassign the drive letters of the partitions so that the OS partition is guaranteed a drive letter of C:.

*Note: Reassigning of drive letters needs to be performed by WinPEshl.ini before the Task Sequence starts because attempting to reassign them during the Task Sequence with a task other than the Format and Partition Disk will cause the Task Sequence to fail.

The below method assumes a BIOS PC that has two partitions - a System Reserved (boot) partition as the first partition and an OS partition as the second partition. If the disk partitioning is different, the commands in Step 2 may need to be modified.

  1. On the site server that hosts the boot images, open Notepad.

  2. In Notepad, copy and paste the appropriate selection below for the boot image that is being used:

    x64
    [LaunchApps]
    %WINDIR%\system32\
    cmd.exe, /c echo Select Disk 0 >> %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo Select Partition 1 >> %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo Assign Letter=S >>
    %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo Select Partition 2 >>
    %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo Assign Letter=C >> %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo exit >> %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\diskpart.exe, /s %WINDIR%\temp\diskpart-drives.txt
    %SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

    x86
    [LaunchApps]
    %WINDIR%\system32\
    cmd.exe, /c echo Select Disk 0 >> %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo Select Partition 1 >> %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo Assign Letter=S >>
    %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo Select Partition 2 >>
    %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo Assign Letter=C >> %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\cmd.exe, /c echo exit >> %WINDIR%\Temp\diskpart-drives.txt
    %WINDIR%\system32\diskpart.exe, /s %WINDIR%\temp\diskpart-drives.txt
    %SYSTEMDRIVE%\sms\bin\i386\TsBootShell.exe

    Ensure not to include the x64 or x86 line.

    WinPEshl.ini Contents

  3. In NotePad, go to File --> Save:

    WinPEshl.ini Save

    • Navigate to the following path:

      <ConfigMgr_Install_Location>\OSD\bin\<arch>

      where <ConfigMgr_Install_Location> is the install directory of ConfigMgr on the site server and <arch> is the architecture of the boot image being modified (either x64 or i386).

    • Next to Save as type: switch from Text Documents (*.txt) to All Files (*.*).

    • Next to File name:, type in:

      WinPEshl.ini

    • Click on the Save button.

      WinPEshl.ini Save Properties

  4. If using both the x64 and x86 boot images, repeat steps 1 - 3 for the other boot image. Two WinPEshl.ini files will be created - one in the <ConfigMgr_Install_Location>\OSD\bin\x64 folder and another in the <ConfigMgr_Install_Location>\OSD\bin\i386 folder.

  5. In the ConfigMgr console, navigate to Software Library --> Operating Systems --> Boot Images.

    Software Library --> Operating Systems --> Boot Images

  6. In the Results pane of the ConfigMgr console, right click on the boot image that needs to be updated with the custom WinPEshl.ini file and select Update Distribution Points.

    Update Distribution Points

  7. In the Update Distribution Points Wizard click on the Next button to rebuild the boot image.

    Note: This will update the boot image on ALL distribution points in the environment.

    Update Distribution Points Wizard

  8. Once the Update Distribution Points Wizard is complete and the boot image is rebuilt, click on the Close button and allow the distribution points to be updated with the updated boot image.

    Update Distribution Point Wizard Finish
  9. Once the Distribution Points have finished updating with the updated boot image, if necessary, update any ConfigMgr media (bootable, stand-alone, etc.) that uses the boot image. For more information on how to create ConfigMgr media, please see the below link:

    How to Deploy Operating Systems by Using Media in Configuration Manager
    http://technet.microsoft.com/en-us/library/79465d90-4831-4872-96c2-2062d80f5583

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

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

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

    Edit Task Sequence

  12. 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.

  13. 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

  14. Select the Apply Operating System Image task to highlight it. *Note: This task may have the custom name of Apply Operating System.

  15. In the Apply Operating System Image task, configure the settings under Select the location where you want to apply this operating system as follows:

    • Destination:
      Specific logical drive letter

    • Drive Letter:
      C:

       Apply Operating System Image

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

*Note: Any boot images updated in the future will have the WinPEshl.ini automatically added to them. If at any point the custom WinPEshl.ini file is no longer needed or desired, either rename or remove the WinPEshl.ini files from the <ConfigMgr_Install_Location>\OSD\bin\x64 and/or <ConfigMgr_Install_Location>\OSD\bin\i386 folders and then follow Steps 5-9.

Pros

  1. Works 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.

Cons

  1. Does not work in scenarios where the disk is partitioned and formatted during the Task Sequence via the Format and Partition Disk task because the Format and Partition Disk task will just reassign the drive letters when it runs.

  2. If there are multiple disk partitioning scenarios in the environment, then one boot image cannot be used for all of the different scenarios. For example, the boot image created in the above method may not work correctly on PCs that have one partition or on UEFI PCs. For it to work successfully in these other scenarios, either the commands in Step 2 would need to be modified or the custom WinPEshl.ini file removed to address the different partitioning schemes. A different boot image and Task Sequence specific for each partitioning scheme would then need to be created. This would require multiple boot images and Task Sequences to exist in the environment, one for each partitioning scheme. Managing these boot images and Task Sequences may become cumbersome and difficult. Additionally, targeting the different Task Sequences to PCs with a particular partitioning scheme may also be challenging. Because of these reasons, this method works best when only one disk partitioning scheme exists in the environment.

  3. 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 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:
      Reg.exe delete HKLM\Temp\MountedDevices /va /f

      Delete MountedDevices From Registry Task Properties

  7. 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

  8. 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

  9. 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.
  2. Easiest to implement.

Cons

  1. 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.



Frank Rojas
Senior Support Escalation Engineer