Does Disk template change defaults, or fully automate partitioning?
- Thread starter chrcol
- Start date
The current headache with KB5034441 requiring a larger Recovery partition (700MB-1GB), highlights a big problem with Unattended disk layouts.
Back before more recent W10 releases, Recovery partition was mostly static in size and didn't expect to grow. When you assign a disk layout, you need to know the target disk's exact length, or simply allow Windows partition to extend (grow until the end of disk). The problem is <Extend> only works if there's no other partitions behind it.
<Extend> doesn't imply "extend until reaching the next assigned partition", it's "extend until the end of the disk".
For this reason, previous Windows releases ordered the disk layout:
Because you can assign a fixed size for Recovery, and extend Windows.
Due to multiple WinRE BitLocker security holes, MS is now updating the Recovery partition as part of the Monthly Update. This requires having extra room for staging the updates inside Recovery. Moving Recovery before Windows prevents the OS from resizing the Recovery partition, because it now needs a repartitioning tool to move existing data.
Today the current policy is to assign Recovery after Windows, so it's possible to shrink Windows and allow Recovery to grow:
Using this layout, you need to know the exact size for Windows partition. So how does WinPE Setup handle this situation on a blank disk? Setup extends Windows to everything after MSR, but automatically shrinks the partition, and creates Recovery in the unassigned space. But there is no shrink parameter in Unattended layouts, just <Extend>.
This was a long explanation. But what are my options?
1. Continue to use NTLite's default disk template, with Recovery placed before Windows. But you need to assign a healthy size (1GB?) to allow for growth in the patched WinRE.
2. Don't use disk layout in Unattended mode, and manually allow WinPE Setup to create a "correct" new disk layout.
- Boot WinPE, and stop at the disk layout screen.
- Enter Shift-F10 to open a CMD window.
- Run diskpart, select the correct disk (always confirm it's the right disk) and clean it.
- Return to Setup, and refresh the disk. Setup will detect it's a blank disk, and ask if you want to create a New layout.
- Accept, and Setup will continue with the rest of your Unattended setup.
Back before more recent W10 releases, Recovery partition was mostly static in size and didn't expect to grow. When you assign a disk layout, you need to know the target disk's exact length, or simply allow Windows partition to extend (grow until the end of disk). The problem is <Extend> only works if there's no other partitions behind it.
<Extend> doesn't imply "extend until reaching the next assigned partition", it's "extend until the end of the disk".
For this reason, previous Windows releases ordered the disk layout:
| System | MSR | Recovery | Windows -> end of disk |
Because you can assign a fixed size for Recovery, and extend Windows.
Due to multiple WinRE BitLocker security holes, MS is now updating the Recovery partition as part of the Monthly Update. This requires having extra room for staging the updates inside Recovery. Moving Recovery before Windows prevents the OS from resizing the Recovery partition, because it now needs a repartitioning tool to move existing data.
Today the current policy is to assign Recovery after Windows, so it's possible to shrink Windows and allow Recovery to grow:
| System | MSR | Windows <- shrink | Recovery <- grow |
Using this layout, you need to know the exact size for Windows partition. So how does WinPE Setup handle this situation on a blank disk? Setup extends Windows to everything after MSR, but automatically shrinks the partition, and creates Recovery in the unassigned space. But there is no shrink parameter in Unattended layouts, just <Extend>.
This was a long explanation. But what are my options?
1. Continue to use NTLite's default disk template, with Recovery placed before Windows. But you need to assign a healthy size (1GB?) to allow for growth in the patched WinRE.
2. Don't use disk layout in Unattended mode, and manually allow WinPE Setup to create a "correct" new disk layout.
- Boot WinPE, and stop at the disk layout screen.
- Enter Shift-F10 to open a CMD window.
- Run diskpart, select the correct disk (always confirm it's the right disk) and clean it.
Code:
> diskpart
select disk 0
clean
convert gpt [required if using UEFI boot mode]
exit
exit- Return to Setup, and refresh the disk. Setup will detect it's a blank disk, and ask if you want to create a New layout.
- Accept, and Setup will continue with the rest of your Unattended setup.
This is the problem, if I leave setup to create the layout it generates only a 500meg recovery, its a real mess. This is the bigger issue than if its before or after the OS, because even if its after, there is no one click solution offered to expand the size.
This is even before I consider what to do on my actual PC where the partition is before the windows partition.
Are you saying the CU update's modify the recovery partition and not just KB5034441?
It might explain what happened on my NUC, That was a clean install with no CU installed since the OS was installed, OS was installed with November 2023 update integrated. It had a 500M recovery partition after OS.
I left windows update to do what it wants as its a throw away install, just to see what would happen, I was expecting KB5034441 to fail and the CU to succeed, they both failed.
The powershell script Microsoft made, also failed, but then one made by a 3rd party posted on their github successfully resized the partition and KB5034441 installed.
However the OS I consider to be hosed. As the CU wont install and fails after only a few seconds. I spent hours diagnosing, and discovered DISM itself is hosed, the scanhealth flag fails with a code 2 missing file, since scanhealth has to work for restorehealth to work, I think the OS at the least likely needs a repair install, and its my only windows system to ever have a completely broken DISM, bit of a coincidence its this month of updates.
To me for a new OS install, the only viable option that you posted is the diskpart solution, but taking it further and manually creating all the partitions so I have at least 1 gig on the recovery, very cumbersome. Then hoping 1 gig or whatever size I choose is enough for future recovery expansions.
I think if disk template allows for keeping a gap at the end of the recovery before starting the main OS partition, that would potentially work whilst keeping the expand option available, however I do prefer a solution that simply bumps the default behaviour to making windows shrink the OS partition by 1 gig instead of half a gig. Fixing the problem post install, there doesnt seem any easy option available that doesnt involve 3rd party vendor tools. Usually routinely I keep space unpartition at the end of disks, for reasons of overprovisioning the SSD, this ironically might be what will save me on my main PC, but I do need to figure out on that how to manually delete the old RE and make a new one in that gap at the end. I was going to just hide the update, but if you are right and standard CU's will be needing a larger recovery it seems I wont be able to kick the can down the road.
This is even before I consider what to do on my actual PC where the partition is before the windows partition.
Are you saying the CU update's modify the recovery partition and not just KB5034441?
It might explain what happened on my NUC, That was a clean install with no CU installed since the OS was installed, OS was installed with November 2023 update integrated. It had a 500M recovery partition after OS.
I left windows update to do what it wants as its a throw away install, just to see what would happen, I was expecting KB5034441 to fail and the CU to succeed, they both failed.
The powershell script Microsoft made, also failed, but then one made by a 3rd party posted on their github successfully resized the partition and KB5034441 installed.
However the OS I consider to be hosed. As the CU wont install and fails after only a few seconds. I spent hours diagnosing, and discovered DISM itself is hosed, the scanhealth flag fails with a code 2 missing file, since scanhealth has to work for restorehealth to work, I think the OS at the least likely needs a repair install, and its my only windows system to ever have a completely broken DISM, bit of a coincidence its this month of updates.
To me for a new OS install, the only viable option that you posted is the diskpart solution, but taking it further and manually creating all the partitions so I have at least 1 gig on the recovery, very cumbersome. Then hoping 1 gig or whatever size I choose is enough for future recovery expansions.
I think if disk template allows for keeping a gap at the end of the recovery before starting the main OS partition, that would potentially work whilst keeping the expand option available, however I do prefer a solution that simply bumps the default behaviour to making windows shrink the OS partition by 1 gig instead of half a gig. Fixing the problem post install, there doesnt seem any easy option available that doesnt involve 3rd party vendor tools. Usually routinely I keep space unpartition at the end of disks, for reasons of overprovisioning the SSD, this ironically might be what will save me on my main PC, but I do need to figure out on that how to manually delete the old RE and make a new one in that gap at the end. I was going to just hide the update, but if you are right and standard CU's will be needing a larger recovery it seems I wont be able to kick the can down the road.
Last edited:
A Recovery partition is optional if you can learn to make/use a WinPE repair ISO from somewhere.
When it's most important is if you have BitLocker enabled, because WinPE has no default support for BitLocker recovery tools. You can add the optional BitLocker package from the WinPE Add-on kit, but it's a hassle.
MS started patching WinRE for W10 22H2 and W11, after the June 2023 Monthly CU (and every month after).
When a normal Recovery partition is created, Windows does a first-time provisioning by moving WinRE from the on-disk WinRE.wim image, extracting it to the Recovery partition, and copying over your current driver set. How much disk space it takes can vary.
While the normal CU is being installed, WU tries to install the current SafeOS DU update (Dynamic Updates for WinRE). If this step fails, WU marks the entire CU as having also failed.
The problem is WU is using Recovery partition for staging, instead of taking up space somewhere on the Windows volume, and copying the final results into the Recovery volume. That would probably solve most of the bloating problems. Another alternative is for MS to modify reagentc to destroy the existing volume, and rebuild it from scratch (when applying the CU).
1 GB appears to be a reasonable size that will last for W10 & 11's lifetime.
When it's most important is if you have BitLocker enabled, because WinPE has no default support for BitLocker recovery tools. You can add the optional BitLocker package from the WinPE Add-on kit, but it's a hassle.
MS started patching WinRE for W10 22H2 and W11, after the June 2023 Monthly CU (and every month after).
When a normal Recovery partition is created, Windows does a first-time provisioning by moving WinRE from the on-disk WinRE.wim image, extracting it to the Recovery partition, and copying over your current driver set. How much disk space it takes can vary.
While the normal CU is being installed, WU tries to install the current SafeOS DU update (Dynamic Updates for WinRE). If this step fails, WU marks the entire CU as having also failed.
The problem is WU is using Recovery partition for staging, instead of taking up space somewhere on the Windows volume, and copying the final results into the Recovery volume. That would probably solve most of the bloating problems. Another alternative is for MS to modify reagentc to destroy the existing volume, and rebuild it from scratch (when applying the CU).
1 GB appears to be a reasonable size that will last for W10 & 11's lifetime.
Just noticed I have two recovery partition on my desktop PC, the original one, and another after the C: drive sandwiched before the D: drive, I will speculate the second got added when I did a in place upgrade from 1809 to 21H2, so I wonder if the CU system is intelligent enough to treat this as a combined 950MB and not run out of space. I will image backup prior and see if I can get away with no changes.
On NTLite, my only concern with the wizard is its fully unattended right so it will just blindly use drive 0 for the partition layout wiping whatever is on there? Meaning to be safe whenever I use the ISO I will have to make sure only the drive I want is available to the installer.
Not good
On NTLite, my only concern with the wizard is its fully unattended right so it will just blindly use drive 0 for the partition layout wiping whatever is on there? Meaning to be safe whenever I use the ISO I will have to make sure only the drive I want is available to the installer.
Not good
Head over to TenForums/ElevenForum, and read the endless Installation threads on duplicate Recovery partitions found on disks. No, Windows can't combine them since a normal volume can't span two non-contiguous partitions. The old one is abandoned, and now stranded.
You need a 3rd-party repartition tool, to slide the Windows partition left to regain the original partition's space.
NTLite doesn't have a clue how your target system is defined. It's your responsibility to understand the drive assignments before using the template. This is no different than writing the Unattended file by hand. If you're unclear about drive numbering (which can change, based on the drive's controller priority), then don't create a layout.
You need a 3rd-party repartition tool, to slide the Windows partition left to regain the original partition's space.
NTLite doesn't have a clue how your target system is defined. It's your responsibility to understand the drive assignments before using the template. This is no different than writing the Unattended file by hand. If you're unclear about drive numbering (which can change, based on the drive's controller priority), then don't create a layout.
I think its more than a partition issue sadly.
After some hours I have found out the following.
There was no winre.wim in system32/recovery at all, there was one in c:\recovery but it was from windows 10 1809. (the original OS install).
All reagentc commands were originally a vague error code 3, after deleting one of the partitions then /info and /disable started functioning, however /enable is still constant code 3. The reagentc command to assign a path also wont ever work just spitting out that retain flag error even though the partition I made has the right id and GPT flags.
None of those threads which I already looked at fit the situation at hand.
So I tried to make a new gig partition, but because its just completely hosed and probably has been since the upgrade install to 21H2, on this system I have now wiped all recovery partitions, and hidden the KB5034441 update (as it was failing even with no active RE). The CU installed fine.
This is off topic though so back to NTLite.
On the NTLite subject I have found a process thats not too complex to make a bigger recovery partition post install, so thats not the end of the world. So because the layout is kind of an all in deal, I wont be using it, and maybe some day it can be figured out how to adjust the automated recovery partition creation size (the one made by the windows installer). Which is what my original question was on the thread. I was asking if NTLite could be made to fit my needs rather than a question of should it be my responsibility to make myself fit the existing design. Might send an email to the dev, since he didnt respond here.
After some hours I have found out the following.
There was no winre.wim in system32/recovery at all, there was one in c:\recovery but it was from windows 10 1809. (the original OS install).
All reagentc commands were originally a vague error code 3, after deleting one of the partitions then /info and /disable started functioning, however /enable is still constant code 3. The reagentc command to assign a path also wont ever work just spitting out that retain flag error even though the partition I made has the right id and GPT flags.
None of those threads which I already looked at fit the situation at hand.
So I tried to make a new gig partition, but because its just completely hosed and probably has been since the upgrade install to 21H2, on this system I have now wiped all recovery partitions, and hidden the KB5034441 update (as it was failing even with no active RE). The CU installed fine.
This is off topic though so back to NTLite.
On the NTLite subject I have found a process thats not too complex to make a bigger recovery partition post install, so thats not the end of the world. So because the layout is kind of an all in deal, I wont be using it, and maybe some day it can be figured out how to adjust the automated recovery partition creation size (the one made by the windows installer). Which is what my original question was on the thread.
I was asking if NTLite could be made to fit my needs rather than a question of should it be my responsibility to make myself fit the existing design. Might send an email to the dev, since he didnt respond here.Microsoft are suggesting 990MB on this page, not far off my 1 gig preference.
I have been looking but found no way of getting a default config with my own requirements.
1 - Must not require the use of diskpart during setup, this is excessive manual intervention.
2 - Cannot use ntlite's template system, as it might wipe something unintended.
It seems this isnt reasonably possible, but I did find another thread on here about installing windows without the recovery partition post from nuhi. Can do it just in the UI.
www.ntlite.com
I have been looking but found no way of getting a default config with my own requirements.
1 - Must not require the use of diskpart during setup, this is excessive manual intervention.
2 - Cannot use ntlite's template system, as it might wipe something unintended.
It seems this isnt reasonably possible, but I did find another thread on here about installing windows without the recovery partition post from nuhi. Can do it just in the UI.
Block Creation of Recovery Partition
i personally prefer to install in isolation on different drives and use the bios boot menu. Ditto. I go a step farther. I have two OS's I seldomly use and have a BCD backup for each set to boot to them one time only. Then a batch file for each that imports said BCD and reboots staight to the...
www.ntlite.com
I wrote a PS script which takes your unattended file, and inserts diskpart commands to run in WinPE. This follows the current MS model of moving Recovery to the end, and resizing Windows to fit the remaining space. The script will support both GPT and MBR layouts, and you can specify the Recovery's size (or take the default). And you can install to a different disk if you want.
Why does it need an unattended file? There's other ways to automate diskpart from WinPE scripting, but in order for Setup to silently begin installation we need to specify which disk/partition to install Windows on.
For users that don't use Unattended, there's a stub autounattend.xml which doesn't override any manual steps.
The script's been tested, but I haven't released it because it needs a proper write-up. DM me if you want to try it.
Why does it need an unattended file? There's other ways to automate diskpart from WinPE scripting, but in order for Setup to silently begin installation we need to specify which disk/partition to install Windows on.
For users that don't use Unattended, there's a stub autounattend.xml which doesn't override any manual steps.
The script's been tested, but I haven't released it because it needs a proper write-up. DM me if you want to try it.