locked
Windows 10 Build 1511 (10.0.10586.0) AND SCCM OSD changes OS drive assignment to X:!!! RRS feed

  • Question

  • I have a very mature OSD Task Sequence for Windows 10 Enterprise, it has a menu-based setup that can install Windows 10 Enterprise x86, x64 and LTSB x86, x64 along with selecting which Office version (and other apps) you want, etc. I have been developing it for over a year now, since Preview Build 9926. Each time a new version (Build) comes out, I import the latest WIM's as new OS'es and swap out the relevant OS Packages in my Task Sequence to suit, no fuss, no muss.

    This time, when I swapped out RTM Windows 10 10.0.10240.16384 to the new 10.0.10586.0 (Build 1511), my Task Sequence now fails after the 2 reboots (driver detection and Windows setup) with an error 00000001, file not found. It only took a second to find that Windows is now showing X:\ as the OS drive, instead of C:\, which has been rock solid and fool-proof all the way through the Windows 10 Builds! Something is up, this is 100% new behavior and completely unexpected!

    I have already confirmed my format task is running and I am creating the proper partitions. I have already confirmed during the WIM copy tasks before Windows reboots that the C: drive is the OS drive (and no other partition exists except the 500MB System Partition, same as always). Yet as soon as Windows setup is done and my Task Sequence resumes, boom, failure and pressing F8 allows me to see why, the OS is running as X:\ (and there is o C:, the drive letters have simply swapped), no idea why!

    Jack

    Tuesday, November 17, 2015 12:20 AM

Answers

All replies

  • BTW, I was already a little worried when I imported the downloaded WIM (extracted from ISO) and saw "1 - Windows 10 Enterprise Technical Preview" instead of the expected "1 - Windows 10 Enterprise" they started using once RTM was available. For me, it would seem the old naming standard (Preview) may also be a sign something is wrong, perhaps mixed up code or release? It's not like the build lab to start mixing up Preview naming but it's just something else that doesn't add up...

    Jack

    Tuesday, November 17, 2015 12:28 AM
  • This is the media I downloaded BTW: "SW_DVD5_WIN_ENT_10_1511_64BIT_English_MLF_X20-82288.ISO"...

    Jack

    Tuesday, November 17, 2015 12:31 AM
  • Yeah, it's the WIM. I swapped just the OS WIM from 10.0.10586.0 back to 10 10.0.10240.16384 and everything works as expected again. Be warned, the 1511 Build is acting differently than the RTM Build, maybe just a drive letter, maybe more. I can get around it by changing any hard-coded scripts to use the OSD Drive variable but IMO this shouldn't be happening anyway, behavior I doubt is by design...

    Jack

    Tuesday, November 17, 2015 12:58 AM
  • I can confirm the same behaviour.
    Tuesday, November 17, 2015 4:21 PM
  • Thanks Roy! Not sure where to go next, Windows Team blog doesn't exactly encourage questions. I could blow an incident but getting the janitor on the phone 8 out of 10 times is frustrating, not to mention trying to get them to understand the issue...

    Jack

    Tuesday, November 17, 2015 4:48 PM
  • I've logged an incident. As its obviously a bug it should be free. BTW I was using Pro instead of Enterprise and its the same behaviour.
    Tuesday, November 17, 2015 4:53 PM
  • Would you mind updating this post when/if you have something, I would be grateful...

    Jack

    Tuesday, November 17, 2015 5:02 PM
  • Hi,

    Create the OSDPreserveDriveLetter variable in your Task Sequence just before the Apply Operating System step and assign the FALSE value.
    It will fix the problem.

    Check this : http://blogs.technet.com/b/system_center_configuration_manager_operating_system_deployment_support_blog/archive/2014/04/28/how-to-ensure-that-windows-installs-on-c-during-a-system-center-2012-configuration-manager-osd-task-sequence.aspx

    Gerald

    • Marked as answer by JFetter Tuesday, November 17, 2015 10:43 PM
    Tuesday, November 17, 2015 6:11 PM
  • Hi Gerald,

    I know about this article but the point is not whether there are options to get round (each with its own pros & cons) but the fact that Microsoft released images onto MVLS that then require changing task sequences, rather than just putting a new WIM onto a mature task sequence. This is not something we've seen before and is unexpected behaviour.

    Roy

    Tuesday, November 17, 2015 7:25 PM
  • I agree, if this were the cause (and yes, I am aware of that article as well), I would expect to find the OS on D: or E:, not X:, which seems (again, it may just be me) to be a bug...

    Jack

    Tuesday, November 17, 2015 7:29 PM
  • Unless they changed THEIR process and are actually capturing the OS as Drive X:! Ugh, I'll give the Variable a shot and hope that MS at least chimes in on the change...

    Jack

    Tuesday, November 17, 2015 7:32 PM
  • Using the OSDPreserveDriveLetter (=False) does work, I guess MS changed the way they make the WIM's internally now (using X: as the OS drive instead of C:). I can't really call this a bug, as that would explain it and frankly the variable was created specifically to address this situation. Thanks to all that contributed...

    Jack

    • Marked as answer by JFetter Tuesday, November 17, 2015 10:43 PM
    • Unmarked as answer by JFetter Tuesday, November 17, 2015 10:43 PM
    Tuesday, November 17, 2015 8:41 PM
  • Have you received an answer regarding "technical preview" in the ISO? I see the same thing when importing to MDT and am leery of using it...
    Tuesday, November 17, 2015 9:46 PM
  • They just screwed up when they named it, probably ran the development script, it's just a name (although I too cringed). So far I've tested the x86 and x64 Standard Servicing Branch (SSB) WIM's with fresh, clean OSD installs, LTSB is next...

    Jack

    Tuesday, November 17, 2015 10:42 PM
  • Yes, Michael Niehaus confirmed on twitter that it's just a naming mistake, and can be ignored.

    https://twitter.com/mniehaus/status/666732194807742464

    Wednesday, November 18, 2015 3:07 PM
  • With MDT, this only fixes it with MBR partition.  With GPT (UEFI) partitions, my OSDisk still gets assigned a letter like E:  This workaround CANNOT be the FIX.  Please get back to quality releases, and fix the mistakes in this install.wim, and re-release the build.
    Thursday, November 19, 2015 12:18 AM
  • How are you partitioning your disk? How are you formatting? Are you assigning drive letters to anything except OS partition? Is this a wipe and load (with partitioning) or upgrade existing? I ask because when I created my own W10 (and 8.1) OSD Tasks this year, I chose to always partition and format via SCCM but our Windows 7 Image was built by another team and when I upgrade one of their W7 Images, my OS Drive becomes D: during the WinPE part of the image. To get around this, I set OSDSystemDrive = D: early in the OSD so everything ends up in the right place (as I use that variable for anything that needs a drive letter, including when I partition/format!), then after reboot (and continued Windows installation), my OS drive ends up C:. The point is MS may have moved to the OS drive being X: in their WIM but that just means a tiny bit more work. I understand your frustration but 20+ years of dealing with MS products, a change like this wasn't an accident and the fact they already had a built-in way to accommodate, probably long-planned...

    Jack

    Thursday, November 19, 2015 1:11 AM
  • I will image a Surface Pro 3 tomorrow and see if my UEFI variation works or has a similar issue...

    Jack

    Thursday, November 19, 2015 1:11 AM
  • I imaged a UEFI device yesterday and it built to C: What I have noticed is there must be a fair bit of internal change in the WIM as older VMWare drivers were causing BSOD during build (although I could import them post build) and a laptop got hung up on audio drivers (again old) not getting released, neither which are big issues but they were not present with 10240.

    If the change to X: was planned, fine but they should let people know about it. My support case is getting nowhere fast "Currently I am not aware of this Issue, let me discuss internally"

    Thursday, November 19, 2015 4:40 AM
    • Proposed as answer by RoyPeacock Thursday, November 19, 2015 8:07 PM
    Thursday, November 19, 2015 8:06 PM
  • I marked this thread answered a few days ago by the OSD Variable, frankly those other "fixes" look scary to say the least. IMO the Windows Team planned this and knew this was coming, hence the OSDPreserveDriveLetter variable in SCCM to begin with, not a major issue in the end. Glad they replied but what an ugly way to handle it for some folks to have to go through...

    Jack

    Thursday, November 19, 2015 9:34 PM
  • Thank goodness I found this post before trying a deployment with the version 1511 WIM!  I have set the variable in my task sequence.

    I found it ahead of trying a deployment because I searched the build number showing because I wanted to confirm if the image name was supposed to be "Windows 10 Enterprise Technical Preview" for 1511, which it is I guess, but is clearly an error on MS's part.

    It sure would be nice if there could be an update to OS deployment this year that doesn't demand time on the forums to troubleshoot!  MDT 2013 Update 1 (true version 1: build 8290) you wasted hours of my life!

    Friday, November 27, 2015 7:04 PM
  • Does this variable also need to get set in an Client Upgrade task sequence (which I am using to go from Win 7 and 8.1 to 10)?
    Friday, November 27, 2015 7:51 PM
  • No, only when laying down the WIM directly, not when initiated by Setup.exe (Upgrade)...

    Jack

    Saturday, November 28, 2015 6:28 PM
  • I opened up a case with Microsoft the instant I saw this issue in the RTM build, but Microsoft still has yet to address the issue in build 10.0.10586.0.

    @Microsoft in the Microsoft Deployment Toolkit build #10.0.10586.0 is displayed with a title of "Windows 10 Enterprise Technical Preview". You need to address this issue and repost the media since it creates confusion to those of us using SCCM, MDT, etc...

    Monday, December 14, 2015 11:12 PM