This was one of the last bugs that I worked on at Microsoft before I left the MDT Team, MDT 2012 Update 1 still has the bug. Thankfully it appears that MDT 2013 has addressed the worst part of the MDT bug (so far). Still I have regrets. :^(

The problem

Starting with early “preview” builds of System Center Configuration Manager SP1, we noticed that there was a change in the way some OS’es got deployed. The problem is that once the OS was up and running, the OS would be located on a drive other than C:. We changed MDT to work around the change in Configuration Manager. Sometime after the SCCM SP1 Beta, the default behavior of the OSDPreserveDriveLetter variable was changed, but we didn’t have time to reflect that change in the final version of MDT 2012 Update 1, so it still has the bug. Confused? Yea me too.

The OS behaviour

With Windows 7, if you deploy the Microsoft install.wim file directly from VL or DVD media, SCCM will not change the drive letter, and the OS will reflect what driver letter was used during image creation, which in the case of Windows Vista and Windows 7 is D:\. I believe that this behavior has changed back to C:\ for Windows 8, so it won’t be a problem there. Typically the Windows OOBE (Out of Box Experience) will do the right thing and change the drive letter to C:, which is the default, but SCCM will bypass that behavior.

Now, If you use a captured WIM file that was created using MDT (recommended best practice), then MDT will allow the OOBE process to correctly set the OS Drive letter in the install.wim to C:\. Great!

SCCM Behaviour

New for System Center Configuration Manager SP1, is the ability to modify the default drive letter behavior… somewhat. As described earlier, Windows Out of Box Experience (Setup), will take whatever drive letter was used during image capture, and set it correctly to C:\. SCCM overrides that behavior so it can assign whatever drive letter *it* feels should be used.  This issue has been around for a while in SCCM in one way or another (see here).

New for System Center Configuration Manager 2012 SP1 is the OSDPreserveDriveLetter variable.

OSDPreserveDriveLetter=True(default) – The Install OS step will force the OS Drive Letter to be whatever was captured in the install.wim (for Windows 7 Retail images, D:\, See above)..

OSDPreserveDriveLetter=False – The Install Step will force the drive letter to be whatever arbitrary drive letter happens to be assigned to the target partition in WinPE.

Generally, most IT departments will not deploy a retail WIM file, but a Captured WIM file. Which would have the drive letter set internally as C:, so you would use the default value of “True”. If you were using Windows 8, again, set to C:, not a problem.

The problem occurs when you have an image that was captured with the internal drive set to D:, which is what happens for Windows 7 Retail/VL (not captured/syspreped) images. The default SCCM behavior (OSDPreserveDriveLetter=True) won’t work here because it will use what is in the OS. Instead we must use (OSDPreserveDriveLetter=False).

Drive Letters in WinPE.

The problem with (OSDPreserveDriveLetter=FALSE) is that it assumes that the target partition has a drive letter that was set to what we want, in this case C:. In WinPE that is not always true. the “format and partition disk” step will blindly assign the new allocated partition the first drive letter available. And chances are pretty good that the drive letter will be something like D: (perhaps the C: drive letter was taken up by the DVD drive). So *again* we are back to getting D:\ as our OS drive.


There are two workarounds the problem.

1. Create a script to programmatically change the drive letter C: to whatever was being used as the target OS Partition.

2. The other option is to use the Wack.wsf script below to remove the Entry in the registry that is created by SCCM to force the OS to use the SCCM ideal drive letter rather than C:\.

Add this Whack.wsf script just after the “Apply Operating System Image” ( and just after the “Use Toolkit Package” ) step in the “install” group of the MDT Client Task Sequence.

I stole this script from my friend Michael Neihaus, I have not had a chance to run it myself. I thought it was a pretty clever work around for the issue.

' // ***************************************************************************
' // 
' // File:      Whack.wsf
' // 
' // Version:   1.0
' // 
' // Author:    Michael Niehaus
' // 
' // Purpose:   Remove DosDevices entries created by ConfigMgr	
' // 
' // Usage:     cscript Whack.wsf [/debug:true]
' // 
' // ***************************************************************************

Option Explicit

'//  Main Class

Class Whack

	Function Main

		Dim iRetVal
		Dim bFound
		Dim oDrive
		Dim sDir

		' Check each drive for an OS, loading the registry when found

		bFound = False
		For each oDrive in oFSO.Drives

			' Skip Windows PE
			If UCase(oDrive.DriveLetter) = "X" then
			End if

			If oFSO.FileExists(oDrive.DriveLetter & ":\Windows\system32\config\system") then
				oLogging.CreateEntry "Trying to load registry file " & oDrive.DriveLetter & ":\Windows\system32\config\system", LogTypeInfo
				iRetVal = oUtility.RunWithConsoleLogging("reg load HKLM\NewOS """ & oDrive.DriveLetter & ":\Windows\system32\config\system""")
				If iRetVal = SUCCESS then
					bFound = True
					exit for
				End if
			End If
		If not bFound then
			oLogging.CreateEntry "Unable to find the new OS registry file; MountedDevices cannot be updated.", LogTypeInfo
			Main = Failure
		End If

		' Delete the mounted devices entries

		iRetVal = oUtility.RunWithConsoleLogging("reg delete HKLM\NewOS\MountedDevices /va /f")

		' Unmount the registry file

		iRetVal = oUtility.RunWithConsoleLogging("reg unload HKLM\NewOS")

		Main = Success

	End Function

End Class


Don’t use SCCM to capture images. MDT is the recommended best practice for image creation. SCCM should then be used to deploy the captured images. Then remove the OSDPreserveDriveLetter step from the task sequence, or set it to “True” (same thing).



10 thoughts on “OSDPreserveDriveLetter

  1. “Don’t use SCCM to capture images?” What is Build and Capture for? Since when was MDT the recommended best practice for image creation?

    • That’s not to say that it’s technically impossible, I don’t recommend it.
      This is from the MDT product group, Johan, Mikael, Microsoft Consulting, etc..

      If you have already created a SCCM infrastructure with all the OS’es, applications, and patches, then keep using that system…

      However, If you are starting from scratch, then I recommend MDT Litetouch for creating the Images. It’s quicker to setup. You don’t have to dirty your production SCCM Infrastructure with a lab imaging system. It’s easier to add Applications. Litetouch can be easily automated to provide no touch image creation. Much Easier to debug issues in LTI if/when application packaging issues appear. Also fixes the D:\Windows issue when SCCM does not. :^) The overhead of SCCM is just so much greater than MDT, especially for a task like Image creation, that does not require the extra functionality of SCCM over Litetouch.

  2. Pingback: Useful deployment links - Michael Niehaus' Windows and Office deployment ramblings - Site Home - TechNet Blogs

  3. Pingback: Michael Niehaus Notes from TechEd North America | What have I learnt today?

  4. Pingback: OSD links | sccm road

  5. Thanks for the post. I’m having this exact problem when doing a Refresh with SCCM 2012 R2. The OS is getting installed on D drive, and it fails because there is not enough space. I’m trying the suggested script Whack.wsf, but it gets the following error, even when I run it manually (cscript Whack.wsf).
    Whack.wsf(69, 2) Windows Script Host: Invalid entity reference
    Please advise.

      • I didn’t realize those were the lines of the script. Line 69 is the very last one, and it’s empty! I trying, deleting that last line, but now the error shows:
        Whack.wsf(68, 11) Windows Script Host: Invalid entity reference
        Line 68 is now: End Class

  6. Did you wrap the script in a wsf wrapper or did you just copy the text from the post into a new document? THe script must have a reference to ZTIUtility.vbs or it won’t work, see the other ZTIXxxx.wsf scripts in MDT for examples.

  7. Pingback: MDT UberBug – More bugs from Johan | Keith's Consulting Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s