Jan 12 2024 01:19 PM - edited Jan 12 2024 01:20 PM
Feedback from a long time patcher here:
The manner in which this particular update has been handled has been poor in my opinion. The update is only being pushed out to Windows update or Windows update for business and is not on the Microsoft catalog nor WSUS. So this update has been pushed to machines that I would call "lightly" managed or "unmanaged". Some of these impacted machines have no TPM chip nor do they have bitlocker installed so the need for this update is nil.
The communication thus far has been to instruct us to manually attempt to resize partitions which are not easy to do for anyone, and particularly not for a lot of machines. There are few tools that I can see that let us know if we're going to hit this issue other than to attempt to install and see if it fails. The PowerShell script is not something I'd have my 95 Dad want to do to his machine, let alone me wanting to do it to a bunch of machines at the office.
We're now at Friday, right before patching weekend and may I request a lot more communication and perhaps someone going back and adding in detection into the patch to at least not attempt to install on machines that have no tpm chip and do not have bitlocker installed. These machines are not at risk.
What you are asking your Microsoft patchers to do with this update is not acceptable and not attainable by your Windows 10 patching audience.
Feb 17 2024 01:06 AM
@PRSGroupITNo, she seemed to make it fairly clear that she was speaking on behalf of someone else who apparently didn't want to be clearly identified.
Feb 19 2024 11:58 AM
Feb 19 2024 12:01 PM
Feb 19 2024 12:51 PM
@Susan Bradley It's a great article. Very in-depth and detailed ,and I think you're spot-on in your criticism of Microsoft for the way they handled this update.
I've found in most cases, the problem isn't that the partition is too small for the updated WindowsRE, but that it's too small to apply the update in-place. If WindowsRE is updated outside of the recovery partition, it can be returned with space to spare. The method I described above, which may not work in every case, temporarily moves the WindowsRE files to the system (C:) drive where the update can succeed--providing C: has adequate space--then returns the files back to the hidden recovery partition.
I'm not sure if space would be a problem if we mount the recovery partition and perform an in-place, offline update to Winre.wim, but if so, the file could always be manually copied out, updated offline, and copied and back in. Microsoft supports offline updates using dism (https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-update-to-winre?view=wind...).
I can't imagine why Microsoft released the update that created this problem in the first place, but it's even more puzzling why they recommended a solution that involved a risky process of resizing a system partition and deleting the recovery partition.
Feb 19 2024 02:13 PM
Maybe they dont have another solution :)@PRSGroupIT
Feb 19 2024 03:33 PM
Feb 23 2024 03:32 PM
@PRSGroupITI got the update installed with your way and I got the Recovery Partition back to Recovery. (I even redid it by recreating it, too) but WinRE still uses the Primary OS partition. It won't seem to go back to the Recovery Partition. Do I even want it to? I got to this thread because I was still getting the error after recreating the Recovery Partition and ended up with 499MB (all Free). Is there going to be issue with future updates if it still says it's using the OS Partition? Winre.wim isn't appearing anymore which surprised me.
Feb 25 2024 02:06 AM - edited Feb 25 2024 02:47 AM
@Jagerbomber If the recovery partition is the wrong type, then windows does not accept it and it automatically creates hidden folder C:\Recovery where the recovery files are stored, when the WinRE enablement command is given. Command triger automatic file copy function. This is something I have learned the hard way. Because of this, the WinRE partition can also point to the wrong partition.
In my case, I fixed the Recovery partition type to the correct one and Windows accepted it. Microsoft's own instructions made the wrong type of partition and I followed them exactly. Because of this, the recovery partition was broken and the new location of WinRE became automaticly C:\Recovery hidden folder. In the case of an MBR disk, Microsoft's own instructions create a recovery partition whose ID is actually 7. The MBR recovery partition ID must be 27 and windows does not accept the ID number 7. The situation with a GPT disk is different and chaos occurs when the instructions for GPT and MRB disks are mixed together. GPT is needed on hard drive size is over than 2TB, because the MBR disk maximum limit is broken. This can cause a problem if the physical Windows hard disk needs to be copied to a larger than 2TB hard disk and the old hard disk is saved as MBR type.
Feb 25 2024 06:13 AM
@Arto_Montonen If the recovery partition is the "wrong type"? The partitions were created by MICROSOFT during the windows 10 install media for EVERY machine I have that refuses to apply this update. So please explain how the recovery partition can be "the wrong type", or even the wrong size for that matter.
Feb 25 2024 06:55 AM - edited Feb 25 2024 07:59 AM
The problem is in Microsoft's own manual instructions, which it guides to make changes. In the case of MRB disk, they destroy the entire Recovery partition operation on all computers. Microsoft own istructions make ID 7 partition, but Recovery partition ID is 27 in MBR disk. Windows rejects the MBR disk recovery partition if its ID number is 7. Windows rejects the MBR disk recovery partition if its ID number is 7, which is caused by Microsoft's own incorrect instructions. Microsoft tries to make the ID 27, but it fails and the ID is 7. How to change ID 7 to ID 27 can be found when you read the entire message thread. I try to tell how to fix that all **bleep** what hapen. GPT format needen over 2TB disk, because MBR Disk limits are not enough. Over limit is 2TB and then GPT is only option, if I'm right.
Feb 25 2024 09:12 AM
@Arto_MontonenI'm that fix will break windows..
Feb 25 2024 09:52 AM
:)
On many computers I have a -> error for this patch, but other updates install correctly and the computers work fine.
I believe that Microsoft, unfortunately for Windows10 -> will not fix this during a standard update, only upgrading to Windows11 is a hassle-free solution if your computer meets the technical requirements for Windows11.
Feb 25 2024 11:41 AM
I've seen your tips and I'm wondering if the end user who doesn't know what configuration they have
your computer's motherboard and does not understand what GPT or MBR is, or UEFI, should you take the steps you recommend?
Feb 25 2024 11:48 PM - edited Feb 26 2024 12:36 AM
ID 7 is not ID 27 very simple and windows does not accept ID 7 as a recovery partition if the disk type is MBR format,
C:\WINDOWS\system32>diskpart
Microsoft DiskPart version 10.0.19041.3636
Copyright (C) Microsoft Corporation.
On computer: AMON-P9
DISKPART> list disk
Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 279 GB 1024 KB
Disk 1 Online 279 GB 0 B
Disk 2 Online 279 GB 0 B
DISKPART> sel disk 0
Disk 0 is now the selected disk.
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Primary 100 MB 1024 KB
Partition 2 Primary 278 GB 101 MB
Partition 3 Recovery 783 MB 278 GB
DISKPART> sel part 3
Partition 3 is now the selected partition.
DISKPART> det part
Partition 3
Type : 27 <---- There is ID number
Hidden: No
Active: No
Offset in Bytes: 299245764608
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 2 NTFS Partition 783 MB Healthy Hidden
DISKPART> set id=27 <- This is a command that fix ID number of the MBR disk when correct disk and partition is selected. Do not do this if a GPT disk is in use, as it will not work with a GPT disk. This only works with an MBR disk.
DiskPart successfully set the partition ID.
DISKPART>exit
C:\WINDOWS\system32>reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:
Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition3\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: d66960a7-4bb6-11eb-bde1-d046185bc8ce
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0
REAGENTC.EXE: Operation Successful.
C:\WINDOWS\system32>reagentc /disable
REAGENTC.EXE: Operation Successful.
C:\WINDOWS\system32>reagentc /enable
REAGENTC.EXE: Operation Successful.
C:\WINDOWS\system32>reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:
Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition3\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: 192e780d-d480-11ee-beaa-485b395dfa49
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0
REAGENTC.EXE: Operation Successful.
C:\WINDOWS\system32>exit
Boot Configuration Data (BCD) identifier changes if a change is made to the revovery partition. I didn't even change the place. I disabled and enabled and got a new ID number.
Mar 02 2024 05:22 AM
Mar 03 2024 04:38 AM
@Susan Bradley I have a WRE of 509MB and still get this error. Plus the fixes here are beyond the scope of most users.
Mar 07 2024 11:39 AM
@Susan Bradley Hi, this tutorial helped me :): https://youtu.be/2mw6IA9Wfis
Mar 08 2024 10:51 AM
Hi PRSGroupIT - could you please reply to @Jagerbomber's message? I think Arto has tried twice but appears to be assuming that the recovery partition is not the right type. In my case, the recovery partition IS the right type (GPT = de94bba4-06d1-4d40-a16a-bfd50179d6ac) but reagentc does not use the partition when it is renabled.