winston <winstonmvp@gmail.com> wrote:

> VanguardLH wrote on 3/3/24 12:36 AM:
>
>> I did a fresh install of Windows 10. Windows chose the layout, not
>> me. I don't do upgrades from a prior version of Windows, nor was
>> there ever any multi-booting involved with OSes in different
>> partitions.
>
> Which indicates you used 2004 or earlier Win10 Media Creation Tool usb
> or dvd media, instead of the separate optional downloadable ISO(later
> using 3rd party tools to create bootable usb/dvd media).

Yep, like lots of users, I used the MCT to create the Win10 install ISO.
From my Downloads folder, looks like I used the MCT for the 1903 build.
You say the GPT guideline for partition layout was established back in
Windows 7 about 2007-2008. That is more than a decade past the 1903
build provided by MCT around May 2019.

>> Even Macrium Reflect with its use of WinPE on boot creates a .wim file
>> the boot manager uses to load WinPE and Reflect, or creates a bootable
>> CD with WinPE+Reflect, or I can create bot, so the OS partition is
>> quiescent during a restore, but Reflect using WinPE does not occupy a
>> partition on the disk with the OS partition.
>
> You really should check the date and Service Pack level of your current
> winre.wim on that first partition.
> For Win10 it should have a Service Pack Build of 3920.
>
> reagentc /info
> - will verify if the WinRe status is enabled
> - will provide the WinRE location path

Shows WinRE is enabled. Copied the WinRE path to winre.wim from that
output.

> Then look at the ‘Location’ path and create the DISM line with the
> correct disk# and partition# number shown.
> => or just copy the line below and replace the # with the correct numbers
> DISM /Get-ImageInfo
> /ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
> /index:1
> - the result will shown the Service Pack Level and date

The DISM output is:

Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Details for image :
\\?\GLOBALROOT\device\harddisk2\partition1\Recovery\WindowsRE\winre.wim

Index : 1
Name : Microsoft Windows Recovery Environment (x64)
Description : Microsoft Windows Recovery Environment (x64)
Size : 2,320,898,360 bytes <--- Only 2.16 GB in a 519 GB partition!
WIM Bootable : No If just the file size, perhaps WIM
Architecture : x64 extraction occupies much more space.
Hal : <undefined>
Version : 10.0.19041
ServicePack Build : 1
ServicePack Level : 0
Edition : WindowsPE
Installation : WindowsPE
ProductType : WinNT
ProductSuite :
System Root : WINDOWS
Directories : 3602
Files : 17513
Created : 12/7/2019 - 1:11:48 AM
Modified : 10/20/2020 - 11:48:59 PM
Languages :
en-US (Default)
The operation completed successfully.

No Service Pack info shown. Only the DISM version is listed.

Per:

https://learn.microsoft.com/en-us/windows/release-health/release-information

the 19041 build was within the Win 10 2004 level (c. 2020-05-27 to
2021-12-14 since DISM doesn't report the sub-build number). Unlike you
say, Microsoft hasn't pushed a new version of WinRE to my Recovery
partition in about 3 years.

> If the Service Pack Number is not 3920, then your WinRE is outdated and
> possibly also Macrium's WinPE tools.

Macrium Reflect does not touch the WinRE partition. Its boot.wim file
does not occupy any partition. The most it touches is to add its
boot.wim to the OS (C:) partition, and update the BCD to add its
boot.wim to the boot menu on Windows startup. That's why, in case of
disk failure, I also save their image to a bootable rescue CD.

> => Macrium's WinPE depends on the the source the user chooses for the
> base WIM - multiple options - WinRE(the current on the device) or one
> from Msft's WADK version 10 or 5 or 4.
> - 4 supports 8.0 and earlier, 5 supports up to 8.1
> - 10 supports Win10 but uses Win10 2004
> i.e. best to update the devices recovery partition with a successful
> install of 5034441, then use updated and latest Win10 22H2-WinRE 3920 ti
> build your Macrium PE media

Reflect is configured to use the following when creatings its WIM file:

Windows RE 10 version 2004 (64-bit)

Remember that Reflect is *not* touching the Recovery (WinRE) partition.
It creates a boot.wim file to add to the Windows startup boot menu, or
burns to a rescue CD, or writes an image to a USB drive, or creates an
ISO file.

>> Guess Microsoft doesn't obey those recommendations for all fresh
>> installs.
>
> See above, they fixed it along time ago.

The partition layout I got was from MCT 2004. Since Windows 10 got
installed, I've not had to use MCT again to see what it now uses. Looks
like Microsoft didn't obey those GPT partition layout rules until after
some MCT that creates a later ISO of Windows 10.

> No, one would not use the old partition location or if deleted it's
> unallocated space. WinRE belongs after C:

Perhaps at some point in time when the ISO image created by MCT was
modified to use the recommended layout. They "fixed" it after the MCT I
used to get an ISO to install Windows 10. That doesn't alter that NOW
the partition layout is not what their instructions expect.

If I delete the current WinRE (Recovery) partition, and to prevent any
screwup on anything expecting the same disk and partition numbering
(disks are indexed starting at 0, partitions are indexed starting at 1),
I would have to create a dummy or placeholder partition in the
unallocated space created by deleting the old WinRE partition. That's
why moving down the partitions risks a problem with disk/partition
numbering getting used by anything. Delete the current WinRE partition
at the beginning of the partition layout, create a dummy partition
there, reduce the size at the end of the Windows partitions, and use
unallocated space after the Windows partition to create a new Recovery
partition, and then get WinRE installed in there.

Since the new WinRE partition would be partition 4 instead of the old
partition 1, you sure that anything that calls the WinRE partition won't
get confused because its physical numbering has changed?

>> By the way, in those GPT intents you mention, just where is unallocated
>> space supposed to exist to use for SSD overprovisioning? Where those
>> intents supposed to have unallocated space at the start of the disk?
>
> If not adopting overprovisioning already included and already
> built-in by the SSD manufacture and choosing the DIY route, it by
> design must be to the furthest right partition on the SSD(i.e. the
> last, and yes after WinRE(after C:) *and* after any GPT data
> partitions.

That's where the unallocated space now resides: last partition.

Randomized writes are not overprovisioning. Those are to alleviate
write amplication. Overprovisioning (OP) means allocating some
unallocated space on the same SSD drive.

https://www.minitool.com/partition-disk/ssd-over-provisioning.html
https://www.techtarget.com/searchstorage/definition/overprovisioning-SSD-overprovisioning

All the vendor OP tools to is facilitate managing the unallocated space
on the disk. The SSD makers simply leave some unallocated space on
their SSD disks which is a percentage of the disks' usable capacity, so
that's probably what you think is built-in OP. That the unallocated
space is invisible, so it doesn't show up File Explorer, is expected:
there is no partition there to contain a file system to mount as a
drive. You can, though, see it in diskmgmt.msc, or any 3rd-party
partition manager. You cannot change the inherent or vendor-configured
OP space on the disk. You can only add more unallocated space to
increase the effective size of the OP areas on the disk. The disk will
not report the inherent or vendor OP space to the host OS to prevent
users from accidentially deleting the "buried" OP space.

Consumer disks are usually configured to use 6 to 10% of total capacity
to the inherent or vendor OP space. You can't change this using
end-user tools. However, admins usually add another 10%, for a total of
about 20%, on workstations to lengthen longevity of the SSD.

If you want to rely on the consumer-level OP defaults, go ahead. I want
more OP space which means having unallocated space (besides the
unallocated space the disk will not report to the OS). I can certainly
consume a meager 250 MB from the end of the partition layout where is
the unallocated space for a new WinRE partition, but then that
partition's number would change from 1 to 4. Seems safer I move the OS
partition down into unallocated space, move the other partitions (EFI
and Reserved) down, too, which leaves unallocated space behind the 1st
partition (Recovery), and then enlarge the 1st partition into the newly
created unallocated space after the 1st partition. That way, I get a
larger WinRE (Recovery) partition, but is physical layout number does
not change.

However, since Microsoft had *not* updated the image in my WinRE
partition for over 2 years, why bother with this crap now?

> If I were you and had a WinRE as the first GPT partition, I would have
> wiped that drive to bare metal way back when 21H1 was released[May 2021]
> - 21H1, 21H2, 22H2 have the same core o/s files and setup the
> partitioning properly!

Why? I've never needed the WinRE (Recovery) partition, anyway. I go
through all the effort of wiping the disk, lay down a fresh install of
Windows, redo all the config and tweaks I've done to my old Windows
install, reinstall all the apps, an restore my user data back to the new
C: partition -- all just to get the WinRE partition as the last one
before the unallocated space at the end. Never used the WinRE
partition, Microsoft hasn't updated it as you claim, so I do a ton of
work, risk my setup, for no benefit at all.

> I've given you sufficient information, whether you take it or not, is
> your choice. Take it or complain to someone else about losing a scant
> amount of space that you'll unlikely ever need or use on your device.
> - especially since shrinking C to enlarge and create WinRE after the C
> partition has been in place, known and the norm for over 3 yrs.

That's not the severe problem. Losing 250 MB of 190 GB of unallocated
space is a non-issue. It's Microsoft instructions that would move the
WinRE partition from being 1st to being 4th (last before unallocated
space). I still remember there are programs, including Windows, that
rely on the physical numbering of disks and partitions to find them.
Walking down the 2nd to 4th partitions into the trailing unallocated
space, and enlarging the WinRE partition still positioned where it was
(partition #1), seems more safe than jumbling the partitions around each
other.

My point is that Microsoft's instructions can be dangerous, especially
if you don't have the partition layout they assume, but which the old
ISO install images didn't obey regarding "proper" GPT partition layout.
Even when the partition layout is as expect AFTER some version of the
ISO image created by MCT, all the work to increase the WinRE partition
can still fail. Read online to see how many users following Microsoft's
instructions only to run "reagentc /enable" to have it fail, and now
they don't have a usable WinRE partition at all. A huge change to
accomodate got tiny amout of code delta to fix a Bitlocker
vulnerability, even for users not using Bitlocker.

And, no, I don't see the WinRE has been updated in over 2 years despite
you say it gets updated often. Maybe all those delta updates of WinRE
is more typical on Pro or server editions of Windows.