hi Todd I wrote about it here - https://www.niallbrady.com/2015/11/17/why-does-windows-end-up-on-x-when-deploying-windows-10-x64-1511-build-10586-with-system-center-configuration-manager/
see the highlight in yellow below which is what we've experienced... summary: however that this variable will be depreciated in SCCM version 1606 (Current Branch ) and onwards and replaced with the following new variables <https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-built-in-variables> and it’s functionality depends on whether you are using Windows 10 ADK 1511 boot images or Windows 10 ADK 1607 boot images. If you are using ADK 1511, then OSDPreserveDriveLetter=False should be ok, if using ADK 1607 there will be no need to set it. _OSDDetectedWinDir Beginning in Configuration Manager version 1602, the task sequence scans the computer’s hard drives for a previous operating system installation when Windows PE starts. The Windows folder location is stored in this variable. You can configure your task sequence to retrieve this value from the environment and use it to specify the same Windows folder location to use for the new operating system installation. _OSDDetectedWinDrive Beginning in Configuration Manager version 1602, the task sequence scans the computer’s hard drives for a previous operating system installation when Windows PE starts. The hard drive location for where the operating system is installed is stored in this variable. You can configure your task sequence to retrieve this value from the environment and use it to specify the same hard drive location to use for the new operating system. OSDPreserveDriveLetter Beginning in Configuration Manager version 1606, this task sequence variable has been deprecated. During an operating system deployment, by default, Windows Setup determines the best drive letter to use (typically C:). In previous versions, the OSDPreverveDriveLetter 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. 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. For more information, see Apply Operating System Image <https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-steps#BKMK_ApplyOperatingSystemImage> . On Thu, Dec 29, 2016 at 11:02 PM, Miller, Todd <[email protected]> wrote: > I am running Configmgr 1602 and am getting ready to update to 1610. > > > > I have a concern that the notes for 1606, but not for 1610 say > “OSDPreserveDriveLetter > task sequence variable has been deprecated. > > > > I am *using* that, and *must* use it. > > > > Michael has tweeted…. “@1E_TroyMartin <https://twitter.com/1E_TroyMartin> > And if you're using ConfigMgr 1606 or later, don't worry about > OSDPreserveDriveLetter at all :-)” > > > > What does that mean? Does it mean that in 1606 and up, it *always* > behaves as if OSDPreserveDriveLetter were set to TRUE? > > > > I need to use it because if I don’t when staff build machines and do not > remove the USB boot stick at the right time, the stick gets assigned a > letter before the fixed drive and the fixed disk ends up getting assigned > D: and the OS is installed on the D: drive – with no C: present. > > > > OSDPreserveDriveLetter forces ConfigMgr/MDT to assign the correct letter > to the OS Disk. Now it can guess wrong. Why on earth would this be > removed? > > > > I guess I will update my test environment and see exactly how screwed I am. > > > ------------------------------ > Notice: This UI Health Care e-mail (including attachments) is covered by > the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is > intended only for the use of the individual or entity to which it is > addressed, and may contain information that is privileged, confidential, > and exempt from disclosure under applicable law. If you are not the > intended recipient, any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify the sender immediately and delete or > destroy all copies of the original message and attachments thereto. Email > sent to or from UI Health Care may be retained as required by law or > regulation. Thank you. > ------------------------------ >
