Configuration Manager 2012 SP2 / R2 SP1 Incorrectly Sizes Partitions During Formatting Steps

Issue:

There is an issue that may occur in the formatting steps in Configuration Manager 2012 SP2 / R2 SP1. I have a bug filed here:Link To Bug you can vote up. I will update this post when an update is released to resolve this issue.

The issue is related to the Recovery partition size. There have been some changes in the way that formatting was intended to happen in Configuration Manager 2012 SP2 / R2 SP1. Here’s how the formatting is intended to happen:

Partition Disk 0 - BIOS

System Reserved (Primary) = 350 MB
Windows (Primary) = 99% of remaining space
Windows (Recovery) = 100% of remaining space

Partition Disk 0 – UEFI

EFI = 500 MB
MSR = 128 MB
Windows Primary = 99% of remaining space
Windows (Recovery) = 100% of remaining space

In this new partition structure in SP2 / R2 SP1, here’s how the forming should happen in a Partition Disk 0 – BIOS on a 100GB hard drive:

System Reserved (Primary) = 350 MB
Windows (Primary) = 101,029.5 MB / 98.6 GB
Windows (Recovery) = 1020.5 MB / 1 GB

Here’s the issue with the formatting step in SP2 / R2 SP1:

Partition Disk 0 - BIOS

Partition Disk 0 – UEFI

If you review the Windows (Recovery) partition, you can see it’s only doing 1% of remaining space instead of 100% of the remaining space.

So here’s how the forming actually will happen in a Partition Disk 0 – BIOS on a 100GB hard drive since the Windows (Recovery) is 1% instead of 100%:

System Reserved (Primary) = 350 MB
Windows (Primary) = 101,029.5 MB / 98.6 GB
Windows (Recovery) = 10.205 MB

There will be a remaining 1010.5 MB in this scenario and since the Recovery partition is only 10 MB this obviously won’t be enough to store a recovery WIM. The issue will be similar for UEFI partitioning as well.

It seems like an easy fix would be to adjust the Windows (Recovery) to 100% remaining space this will work in the Partition Disk 0 – UEFI. However there appears to be an issue where the console will crash when you try to do this in the Partition Disk 0 – BIOS step:

Workaround:

I’ve done many variations to find the best option to work around this issue. These scenarios also have BitLocker testing in mind for the boot partition and the recovery boot WIM. Even if you manually add all the formatting steps so the Recovery partition uses 100% of the remaining free so it’s about 1GB in my scenario when enabling BitLocker it’s unable to move the recovery boot WIM to this recovery partition since it’s not the first partition.

I reviewed the default partition layout for a fresh Windows 10 install from the ISO. Setting up Configuration Manager to use a similar partition layout of the default Windows 10 setup works the best with regards to BitLocker and the recovery WIM.

Here’s how the Windows setup formats for a BIOS based machine with a 127 GB Hard Drive:

System Reserved = 500 MB
Windows = 100% remaining Space

This setup also worked well within a Configuration Manager task sequence. By setting System Reserved to 500 MB, it will allow the boot partition and the recovery environment WIM to both fit on the System Reserved partition if BitLocker is enabled on the Windows partition. BitLocker was also automatically able to move the recovery environment onto the System Reserved partition when enabling BitLocker with this formatting.

Here’s how the Partition Disk 0 – BIOS should look for this workaround:

Here’s how the Windows setup formats for a UEFI based machine with a 127 GB Hard Drive:

Recovery = 450 MB
System = 100 MB
MSR = 16 MB
Windows = 100% remaining Space

For UEFI based partitioning, I found the following to work best for allowing BitLocker to automatically move the recovery environment WIM when enabling BitLocker.

Change the last partition for the Windows (Recovery) from 1% to a fixed size of 500 MB. Then move this partition to the top of the list.

Little More Info On Recovery Environment and Bitlocker:

Here’s a little more information on the issue with the recovery environment if you don’t change the partitioning to how I recommend in the workaround.

Lets take the initial formatting scenario where Configuration Manager incorrectly sets the Recovery Partition to 1% instead of 100%

This would leave us with a disk layout like shown below:

Now lets say I go enable Bitlocker on the device. By default, the Recovery environment WIM will be stored on the Windows partition this is fine unless you enable Bitlocker. Once Bitlocker is enabled, the Recovery environment will have to be moved to a non-Bitlocker enabled partition otherwise we couldn’t boot to it for troubleshooting.

Since the System Reserved is only 350 MB it’s not large enough for the boot files and the Recovery environment. Since the Recovery partition is only 10 Mb this also won’t work. If you try to enable Bitlocker, the Bitlocker setup won’t be able to automatically move the recovery environment it would simply delete it and you couldn’t perform a Recovery environment boot.

I also tested changing the Recovery partition from 1% remaining space to 100% . What’s interesting is even though the Recovery partition is now large enough at over 1 GB, Bitlocker still didn’t see this as a valid partition to move the Recovery environment to automatically. You could manually move the Recovery environment ReAgentc.exe tool, but I recommend simply changing the partitioning to how Windows is partitioning as demonstrated in the Workaround section.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Comments

• Anonymous
  October 28, 2015
  Justin,
  Great work on this! I noticed this behavior during my troubleshooting problems with MDT 2013 U1 (re-release) integrated with CM12R2SP1CU1. Even after making these changes, I am still having a problem deploying a HyperV Gen2 (UEFI - Secure Boot turned off) VM with Windows 7 x64 SP1 Enterprise. After hours messing around with the integrated MDT 2013 U1 task sequence, i resorted to a standard TS from ConfigMgr. Still no go on this forefront even with your suggested changes.
  
  I don't Microsoft wanted ConfigMgr admins to deploy Windows 7 with UEFI in mind. Let me know if you have the same behavior. The image I used is straight from the Windows 7 SP1 Ent x64 ISO (install.wim)