Jump to content


Windows 10 Disk Partition Discrepencies

Recommended Posts

Hi all,

I hope you can help as I've been search for some clarity on this matter for the last 2 days.  Sorry for this, it's going to be a long one.....

I'm working for a company who finished migrating to Windows 10 (1703 & 1709) last year.  There are around 10k Windows 10 devices which are predominately legacy BIOS configured and now need to be converted to UEFI using the MBR2GPT tool.  The devices were built using an SCCM task sequence (SCCM 1802) with MDT 2013 Update 1 integrated.  I've just started to do some testing with the MBR2GPT tool using the guide linked below and have found the following issue(s) in this environment.  I'll highlight these issues then explain the main problem/bug I seem to have:

Guide: https://miketerrill.net/2017/09/06/windows-10-bios-to-uefi-in-place-upgrade-task-sequence-using-mbr2gpt/

- First problem is as discussed in the questions section of the above blog.  The step that re-enables the Recovery Environment is failing as the only available disk partition that can be used is Bitlocker encrypted.

- The second issue is that most of the machines in the estate have 128 GB hard disks and the recovery environment partition is being created at 12 mb in size which renders it useless.

So I took a look at what is going on in our task sequence and found the following disk partition steps for a BIOS system:

System Reserved (Primary)

350 MB fixed size. NTFS file system.


Windows (Primary)

99% of remaining space on disk. NTFS file system.


Recovery (Recovery)

1% of remaining space on disk. NTFS file system.


This was obviously the issue as after the first 2 partitions had been created, 1% of the remaining space equated to 12mb.  This problem led me to find the following blog which explains that either the SCCM or MDT task sequence template had been wrong at some stage in 2015:




Apart from the problem where I can't re-enable the RE after the BIOS to UEFI switch I also noticed that the 12 mb partition had been given a drive letter in the OS!  This appears to be normal behaviour for any Primary partitions following the MBR2GPT conversion, however, this should be a "Recovery" partition right?!


So I've spent the last 2 days building machines with different disk partition steps to try and pin down what's going on.  The first think that sticks out like a sore thumb is that when you create a standard SCCM TS the disk part steps completely contradict those in the MDT TS template.  I asked a former colleague who has a later version of MDT integration in his environment to send me the disk part config and again it's different.


It appears that the "Recovery" partition, even when created large enough to work, is not actually being created as a hidden recovery partition but instead as a "Primary" partition.  This explains 1, why I can't re-enable the RE agent, and 2, why a drive letter is being mapped to this partition after the MBR2GPT conversion.


To add to the fun, we have run Win 10 Feature Updates across almost 2500 machines and this appears to have created a useable recovery partition (a proper one with "Type" "Recovery") as part of the upgrade.  Unfortunately this then means that there are 4 partitions on the MBR disk and the MBR2GPT tool is unable to create the EFI partition if there are more than 3 MBR partitions.  My testing has led me to believe that I can safely run MBR2GPT tool to convert these machines once I've scripted a cleanup of the tiny un-useable partition.


Let me know if anyone else has had similar woes with this.


But basically my questions are this:


1) Can someone please clarify what the actual BIOS and UEFI disk partition steps should be in a Bare Metal Task Sequence?

2) Why isn't an MBR Recovery partition showing up in diskpart or disk management as a recovery partition?


Thanks in advance.  Hope it makes sense, and sorry for the essay.



Share this post

Link to post
Share on other sites

I think the following blog answers my question as to what's happening with the Recovery partition during an OSD via SCCM:


"Behind the scenes, it creates a diskpart answer file that it uses to partition and format the disk. The Recovery partition is getting set to type 7 instead of type 27 (hidden). When the Windows 10 Setup runs, it does not recognize (or use) the Recovery partition that was created by Configuration Manager"

It doesn't clarify whether this is a bug in SCCM or whether anything has been done to remedy the disk part step but I have found a solution that I've successfully tested this morning:



I now have a daunting task of trying to clean up the existing environment. Deleting any tiny Recovery partitions that were created as Primary parts, and creating proper usable 984 mb Recovery partitions.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...