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:
- 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.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.
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:
https://blogs.technet.microsoft.com/jchalfant/configuration-manager-2012-sp2-r2-sp1-incorrectly-sizes-partitions-during-formatting-steps/
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.
Westy
Share this post
Link to post
Share on other sites