Q: modifying/changing initial disk layout w/ NTLite (Server 2022)

S

stevecs

New Member
Just a question here as I just ran into this. Basically in previous versions of OS installs the installer would partition the disk as:
{EFI} ; {Rescue}; {C/Windows}
At least with 2012, 2016, 2019, and various versions between. (earlier would be the same but with no EFI just MBR)

However I just noticed that Windows 2022 server is *NOT* doing this but is instead laying out the partition as:
{EFI} ; {C/Windows} ; {Rescue}

This basically is completely brain-dead as you cannot grow the C/widows partition as it's locked if you resize the lun/disk. You have to do a bunch of operations (expand disk/lun; move rescue partition ~640 MB out; Move c/windows partition 640 MB out to make a 'gap'; copy the rescue partition into the gab before C/windows; delete the original Rescue partition; THEN resize the c/windows partition so it's at the end of the friggen lun.

I mean it's doable but it's a complete PITA and would rather fix the &$%^&%$*%^*% mistake by whomever the brainless idiot was at M$ that did this.
 
Somewhere along, MS realized you can't conveniently resize the recovery partition if it's located before the system. This is important for in-place upgrades, when the WinRE size may have increased. None of this matters for clean installs.

When the recovery partition follows the system, it's possible to increase space for WinRE by:
1. Disabling WinRE. Delete existing recovery partition.
2. Shrink the system partition if you have extra room.
3. Create larger recovery partition in expanded space. Enabling WinRE.

Now for the case of expanded volumes, you extend the system partition instead of shrinking, and then recreate the recovery partition at the volume's end.

https://woshub.com/extend-volume-blocked-by-windows-recovery-partition/

There is a logic to this strategy.
 
Actually, no, there is NO logic to that strategy and if I *ever* find the idiot who did that at M$ there would be more than just words. Basically, what you're describing is the *same* exact problem with expanding any partition when another partition follows it. So in order to solve something that happens so infrequently (rescue partition being full of which, since windows NT 3.51 days I have *never* seen that needed even in an outsourcing environment) M$ decided to move the problem to the C partition where resizing happens *DAILY* in an enterprise.

Even *IF* that was an issue, they can go back to the rescue disks they had and just not even have a rescue partition at all.

Since I'm trying to create standardized images to be used for VM's as well as physical installs to be used by several teams am trying to modify the installer to *correctly* assign disk partitions, or hell, even to not create the rescue at all (though I would like to have it on the odd case that a client machine has a problem and they did not do proper backups, also a frequent occurrence).

So this is beyond NTlite's scope/ability then to modify this behavior?

I've already called M$ (to bitch at them but from looking at their forums this has been going on since server 2022 came out (we've mainly been using 2019 so didn't notice it, but now I have to take an inventory and find a way to fix anything that may have been deployed).
 
NTLite's disk layout wizard follows a specific default model, but you're not bound to it. Define a custom layout, or just swap a few lines inside the current XML preset.
 
Thanks for that, I've actually never really used the unattended setup function in ntlite before. It appears to offer what I need.
 
You must log in or register to reply here.
Back
Top