• "Status: Download error - 0x80070643" with "2024-01 Security Update for

    From Ant@21:1/5 to All on Tue Jan 9 18:47:57 2024
    Others' (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
    "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
    64-bit W10 Pro. right now. I already rebooted once from other today's updates:

    1. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034275-cumulative-update-for-net-framework-3-5-4-8-and-4-8-1-for-windows-10-version-22h2-6c9a603c-f0a1-4b32-b7fa-a1c6337523f1
    2. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034122-os-builds-19044-3930-and-19045-3930-7656c6a4-0b06-4424-86a9-d0719f4ac252

    I read https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8
    's known issue about small WinRE partition with a https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf
    link.

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/
    --
    "Since the day we heard about you, we have not stopped praying for you and asking God to fill you with the knowledge of his will through all spiritual wisdom and understanding." --Colossians 1:9. So cold.
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Ant on Tue Jan 9 16:42:42 2024
    On 1/9/2024 1:47 PM, Ant wrote:
    Others' (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
    "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
    64-bit W10 Pro. right now. I already rebooted once from other today's updates:

    1. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034275-cumulative-update-for-net-framework-3-5-4-8-and-4-8-1-for-windows-10-version-22h2-6c9a603c-f0a1-4b32-b7fa-a1c6337523f1
    2. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034122-os-builds-19044-3930-and-19045-3930-7656c6a4-0b06-4424-86a9-d0719f4ac252

    I read https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8
    's known issue about small WinRE partition with a https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf
    link.

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/
    That's interesting. My win10 has the same issue. I read the directions on how to fix and the first step is to shrink the OS by 250M so the recovery can be larger.
    Cute idea but rather than all that command line stuff I just opened disk manager and tried to shrink it there... It won't let me, it says that it's not possible to shrink.

    Normally with a spinning disk this meant that data was stored on those last few sectors it needs to shrink.
    One would now just run some defrag program to pull the data away from the end of the disk and all is fine.
    But I have an SSD and I have a feeling this tosses a wrinkle in the works.

    So now I have no idea what to do. I'm somewhat hesitant to do those commands to shrink and reformat the new recovery. Looks simple but I'm a not adventurous.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Big Al on Tue Jan 9 16:45:21 2024
    On 1/9/2024 4:42 PM, Big Al wrote:
    On 1/9/2024 1:47 PM, Ant wrote:
    Others'
    (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
    "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
    64-bit W10 Pro. right now. I already rebooted once from other today's updates:

    1.
    https://support.microsoft.com/en-us/topic/january-9-2024-kb5034275-cumulative-update-for-net-framework-3-5-4-8-and-4-8-1-for-windows-10-version-22h2-6c9a603c-f0a1-4b32-b7fa-a1c6337523f1
    2. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034122-os-builds-19044-3930-and-19045-3930-7656c6a4-0b06-4424-86a9-d0719f4ac252

    I read
    https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8
    's known issue about small WinRE partition with a
    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf
    link.

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/
    That's interesting.  My win10 has the same issue.  I read the directions on how to fix and the first step is to shrink the OS by 250M so the recovery can be larger.
    Cute idea but rather than all that command line stuff I just opened disk manager and tried to shrink it there... It won't let me, it says that it's not possible to shrink.

    Normally with a spinning disk this meant that data was stored on those last few sectors it needs to shrink.
    One would now just run some defrag program to pull the data away from the end of the disk and all is fine.
    But I have an SSD and I have a feeling this tosses a wrinkle in the works.

    So now I have no idea what to do.  I'm somewhat hesitant to do those commands to shrink and reformat the new recovery.  Looks simple but I'm a not adventurous.
    Sometime later I'll probably image the whole system and try those commands.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ant@21:1/5 to Big Al on Tue Jan 9 21:58:18 2024
    Big Al <BigAl@invalid.com> wrote:
    On 1/9/2024 4:42 PM, Big Al wrote:
    On 1/9/2024 1:47 PM, Ant wrote:
    Others'
    (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
    "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
    64-bit W10 Pro. right now. I already rebooted once from other today's updates:

    1.
    https://support.microsoft.com/en-us/topic/january-9-2024-kb5034275-cumulative-update-for-net-framework-3-5-4-8-and-4-8-1-for-windows-10-version-22h2-6c9a603c-f0a1-4b32-b7fa-a1c6337523f1
    2. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034122-os-builds-19044-3930-and-19045-3930-7656c6a4-0b06-4424-86a9-d0719f4ac252

    I read
    https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8
    's known issue about small WinRE partition with a
    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf
    link.

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/
    That's interesting.  My win10 has the same issue.  I read the directions on how to fix and the first step is to shrink the OS by 250M so the recovery can be larger.
    Cute idea but rather than all that command line stuff I just opened disk manager and tried to shrink it there... It won't let me, it says that it's not possible to shrink.

    Normally with a spinning disk this meant that data was stored on those last few sectors it needs to shrink.
    One would now just run some defrag program to pull the data away from the end of the disk and all is fine.
    But I have an SSD and I have a feeling this tosses a wrinkle in the works.

    So now I have no idea what to do.  I'm somewhat hesitant to do those commands to shrink and reformat the new recovery.  Looks simple but I'm a not adventurous.
    Sometime later I'll probably image the whole system and try those commands.

    MS needs to do a better job with this update. It looks like pretty everyone is having this problematic update today. :(
    --
    "Since the day we heard about you, we have not stopped praying for you and asking God to fill you with the knowledge of his will through all spiritual wisdom and understanding." --Colossians 1:9. So cold.
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Big Al on Tue Jan 9 20:48:28 2024
    On 1/9/2024 4:45 PM, Big Al wrote:
    On 1/9/2024 4:42 PM, Big Al wrote:
    On 1/9/2024 1:47 PM, Ant wrote:

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/

    Then Al finds this recipe, and the fools use shorthands for the commands. DONT DO THAT.

    The users have enough trouble having to do this bloody shit by hand,
    why make it twice as hard by crypt-o-fying the command sequence ?

    Remember, the average inconvenienced customer, is doing this for the first time.
    Not the fiftieth time.

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    reagentc /info # shows recovery agent is enabled, and is using Partition 4
    # The article should show what that looks like. A picture would help.

    [Picture]

    https://i.postimg.cc/sgXwB389/diskpart-disk-summary.gif

    diskpart # Administrator Command Prompt, or Admin Powershell then type "cmd.exe" as a command
    list disk
    select disk 0
    list partition
    select partition 3 # will shrink C: now
    shrink desired=250 minimum=250 # runtime 1 second
    select partition 4
    delete partition override # "delete partition" is the command we seek to cowboy at this point
    # This solves the inability to change the origin of a partition.

    create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac # The ID is a partition type, our Recovery.
    gpt attributes =0x8000000000000001 # <=== Protected status of partition. Partitions
    # can be "marked" as "being special" [Attribute]

    format quick fs=ntfs label="Windows RE tools" # Partition 4 is NTFS, and now it has no content. Empty file system.
    # Partition is likely hidden by its ID value.
    exit

    I'm not sure the rest of the procedure is exactly valid.
    I'm having trouble believing you can reagentc /enable
    when the partition is empty. reagentc /info
    will tell you how you
    are doing.

    The above is to demonstrate what it looks like, without shorthands being used.

    I haven't tested this sequence. I'm getting tired.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Paul on Tue Jan 9 21:02:23 2024
    On 1/9/2024 8:48 PM, Paul wrote:
    On 1/9/2024 4:45 PM, Big Al wrote:
    On 1/9/2024 4:42 PM, Big Al wrote:
    On 1/9/2024 1:47 PM, Ant wrote:

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/

    Then Al finds this recipe, and the fools use shorthands for the commands. DONT DO THAT.

    The users have enough trouble having to do this bloody shit by hand,
    why make it twice as hard by crypt-o-fying the command sequence ?

    Remember, the average inconvenienced customer, is doing this for the first time.
    Not the fiftieth time.

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    reagentc /info # shows recovery agent is enabled, and is using Partition 4
    # The article should show what that looks like. A picture would help.

    [Picture]

    https://i.postimg.cc/sgXwB389/diskpart-disk-summary.gif

    diskpart # Administrator Command Prompt, or Admin Powershell then type "cmd.exe" as a command
    list disk
    select disk 0
    list partition
    select partition 3 # will shrink C: now
    shrink desired=250 minimum=250 # runtime 1 second
    select partition 4
    delete partition override # "delete partition" is the command we seek to cowboy at this point
    # This solves the inability to change the origin of a partition.

    create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac # The ID is a partition type, our Recovery.
    gpt attributes =0x8000000000000001 # <=== Protected status of partition. Partitions
    # can be "marked" as "being special" [Attribute]

    format quick fs=ntfs label="Windows RE tools" # Partition 4 is NTFS, and now it has no content. Empty file system.
    # Partition is likely hidden by its ID value.
    exit

    I'm not sure the rest of the procedure is exactly valid.
    I'm having trouble believing you can reagentc /enable
    when the partition is empty. reagentc /info
    will tell you how you
    are doing.

    The above is to demonstrate what it looks like, without shorthands being used.

    I haven't tested this sequence. I'm getting tired.

    Paul

    My Patch Tuesday came in a couple hours ago.
    I guess mine succeeded. But why are the dates
    on the files so old. My guess is, I didn't get
    new contents in my Partition 4.

    [Picture]

    https://i.postimg.cc/prMPTGLz/January2024-Patch-Tuesday.gif

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Paul on Tue Jan 9 22:41:34 2024
    On 1/9/24 09:02 PM, Paul wrote:
    On 1/9/2024 8:48 PM, Paul wrote:
    On 1/9/2024 4:45 PM, Big Al wrote:
    On 1/9/2024 4:42 PM, Big Al wrote:
    On 1/9/2024 1:47 PM, Ant wrote:

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/

    Then Al finds this recipe, and the fools use shorthands for the commands. DONT DO THAT.

    The users have enough trouble having to do this bloody shit by hand,
    why make it twice as hard by crypt-o-fying the command sequence ?

    Remember, the average inconvenienced customer, is doing this for the first time.
    Not the fiftieth time.

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    reagentc /info # shows recovery agent is enabled, and is using Partition 4
    # The article should show what that looks like. A picture would help.

    [Picture]

    https://i.postimg.cc/sgXwB389/diskpart-disk-summary.gif

    diskpart # Administrator Command Prompt, or Admin Powershell then type "cmd.exe" as a command
    list disk
    select disk 0
    list partition
    select partition 3 # will shrink C: now
    shrink desired=250 minimum=250 # runtime 1 second
    select partition 4
    delete partition override # "delete partition" is the command we seek to cowboy at this point
    # This solves the inability to change the origin of a partition.

    create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac # The ID is a partition type, our Recovery.
    gpt attributes =0x8000000000000001 # <=== Protected status of partition. Partitions
    # can be "marked" as "being special" [Attribute]

    format quick fs=ntfs label="Windows RE tools" # Partition 4 is NTFS, and now it has no content. Empty file system.
    # Partition is likely hidden by its ID value.
    exit

    I'm not sure the rest of the procedure is exactly valid.
    I'm having trouble believing you can reagentc /enable
    when the partition is empty. reagentc /info
    will tell you how you
    are doing.

    The above is to demonstrate what it looks like, without shorthands being used.

    I haven't tested this sequence. I'm getting tired.

    Paul

    My Patch Tuesday came in a couple hours ago.
    I guess mine succeeded. But why are the dates
    on the files so old. My guess is, I didn't get
    new contents in my Partition 4.

    [Picture]

    https://i.postimg.cc/prMPTGLz/January2024-Patch-Tuesday.gif

    Paul
    Your partition looks like it's 646M and mine is 641M, wonder why it's so small or why your update worked.
    Too many questions.

    bottom line? do you think these instructions are going to work? It will leave an empty partition of course. I use
    Acronis, I could replace the files after formatting. I could also dd the files out using Linux. Or do they need to be
    replaced at all?
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Big Al on Wed Jan 10 04:44:13 2024
    On 1/9/2024 10:41 PM, Big Al wrote:

    Your partition looks like it's 646M and mine is 641M, wonder why it's so small or why your update worked.
    Too many questions.

    bottom line? do you think these instructions are going to work?  It will leave an empty partition of course.  I use Acronis, I could replace the files after formatting.  I could also dd the files out using Linux.  Or do they need to be replaced at
    all?

    OK, I'm on the other computer now, and fresh carrot cake (Disk 33 Win10 x64 21H2) has been added.
    This is an "intentionally behind" installation.

    Because the machine was intentionally behind, I'm showing

    KB5001716 2023-05 Update for Windows 10 Version 21H2 Download error - 0x80070643

    So even an old update is showing that way. This means I'm slightly
    unimpressed with how things are going, and what we know.

    Whereas:

    Feature update to Windows 10, version 22H2 is showing Downloading - 56%

    It is going forward.

    OK, 22H2 is in, and '4441 is showing the error 0x80070643

    C:\$WinREAgent\Scratch\update.wim Originally showing 514MB, now shows 496,222,165 bytes (473MB)

    DISM and friends, have been grinding out a new WinRE.wim .

    And that I guess, won't fit in the partition 4.

    C:\Windows\Logs\WinREAgent\setupact.log

    2024-01-10 Info WinRE partition total space [533721088], free space [36130816], winre size [477367903], target WinRE size [496222165]
    2024-01-10 Info Free space requirement: [54525952]

    The partition just might be big enough, but it's
    violating a "free space" requirement, if some cruft
    needs to be stored near the WinRE.wim .

    Now, I can try the recipe and see what happens.

    OK, recipe works. REcovery Partition (4) now 759MB.

    *******

    winreUpdateInstaller.exe is running

    The WinRE.wim fits and all seems OK. reagentc /info is normal and functional. And the history of reagentc, you'd be surprised how many users have
    a non-functional or busted setup. That's why they can't "make a recovery stick".

    [Picture]

    https://i.postimg.cc/Z5zxB0YN/Patch-Tuesday-works-after-resize-partition4.gif

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to George on Wed Jan 10 04:44:48 2024
    On 1/10/2024 2:26 AM, George wrote:
    Paul <nospam@needed.invalid> wrote:

    On 1/9/2024 4:45 PM, Big Al wrote:
    On 1/9/2024 4:42 PM, Big Al wrote:
    On 1/9/2024 1:47 PM, Ant wrote:

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/

    Then Al finds this recipe, and the fools use shorthands for the commands. DONT DO THAT.

    Seconded. Do not, repeat Do Not, repeat DO NOT try to shortcut
    this process. There be dragons.

    The users have enough trouble having to do this bloody shit by hand,
    why make it twice as hard by crypt-o-fying the command sequence ?

    Remember, the average inconvenienced customer, is doing this for the first time.
    Not the fiftieth time.

    I suspect that MS has a FixIt tool in the works. Since this is
    night 1 of Patch Tuesday, this is probably the best we'll see for
    a while.

    [snip KB5028997 extract]

    I'm not sure the rest of the procedure is exactly valid.
    I'm having trouble believing you can reagentc /enable

    If I've figured this correctly, the /enable parameter reloads the
    stock WinRE environment, ready for patching via KB5034441.

    The above is to demonstrate what it looks like, without shorthands being used.

    And I repeat: Do not, repeat Do Not, repeat DO NOT try to
    shortcut this process.

    I haven't tested this sequence. I'm getting tired.

    I did this earlier tonight (Life, what's that?). WinRE
    partition: Old size 697 MB, new size 947 MB. After a reboot for
    the changed partition size (old precautions), KB5034441 installs
    without complaint.

    Hope this helps.


    +1

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Hall@21:1/5 to ant@zimage.comANT on Wed Jan 10 10:54:09 2024
    In message <jOycnT_9xr1ACQD4nZ2dnZfqn_SdnZ2d@earthlink.com>, Ant <ant@zimage.comANT> writes
    Others' >(https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_ >january_9th_2024/kh32u6f/) and my updated 64-bit W10 Pro. PC, I'm
    getting "Status: Download error - 0x80070643" with "2024-01 Security
    Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)"
    in 64-bit W10 Pro. right now. I already rebooted once from other
    today's updates:

    On my 32-bit Windows 10 machine, the patch seems to have downloaded OK,
    but fails to install, seemingly being stuck at 0%. After a while, it
    reports the failure and says that it will try again later. If I manually
    click the Retry button that it gives me to get it to try again
    immediately, the same thing happens.

    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.
    --
    John Hall
    "Acting is merely the art of keeping a large group of people
    from coughing."
    Sir Ralph Richardson (1902-83)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to All on Wed Jan 10 08:21:55 2024
    On 1/10/24 06:44 AM, ...w¡ñ§±¤ñ wrote:
    Paul wrote on 1/10/24 2:44 AM:

    Now, I can try the recipe and see what happens.

    OK, recipe works. REcovery Partition (4) now 759MB.


    p.s.
    KB5034957: Updating the WinRE partition on deployed devices to address security vulnerabilities in CVE-2024-20666


    <https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10>


    So now I'm totally confused.
    I'm leaning towards John Hall's idea, wait for a while and see MS fixes this on their own.

    So you're telling me that the above link that tells me to download the Safe OS Dynamic Update, and run a .ps1 power
    shell script will take care of this all for me? As well as what commands were suggested earlier (or maybe better than
    those commands). ?
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to John Hall on Wed Jan 10 08:44:22 2024
    On 1/10/2024 5:54 AM, John Hall wrote:
    In message <jOycnT_9xr1ACQD4nZ2dnZfqn_SdnZ2d@earthlink.com>, Ant <ant@zimage.comANT> writes
    Others'
    (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_
    january_9th_2024/kh32u6f/) and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in 64-bit W10 Pro. right now. I already
    rebooted once from other today's updates:

    On my 32-bit Windows 10 machine, the patch seems to have downloaded OK, but fails to install, seemingly being stuck at 0%. After a while, it reports the failure and says that it will try again later. If I manually click the Retry button that it gives
    me to get it to try again immediately, the same thing happens.

    I think I'll just wait for Microsoft to fix things rather than try anything fancy.

    Winstons link shows there is the potential for Bitlocker involvement.

    So yes, anything fancy might not be a good idea, especially the
    more protected the device is. (Surface, versus a home-built desktop)

    Hell, it could have third-party protection for all we know.

    Even if a person were to reinstall, the partition still
    might not be big enough. "Bad schemes are bad"

    One of the reasons some of the audience compromise their machines,
    is in the name of maintenance :-) My setup is almost maintainable.
    The recipe did not cause me grief. But my setup would not pass HIPPA.
    Some people have no choice but to have "complex wrecks" for computers.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Big Al on Wed Jan 10 12:24:15 2024
    On 1/10/24 08:21 AM, Big Al wrote:
    On 1/10/24 06:44 AM, ...w¡ñ§±¤ñ wrote:
    Paul wrote on 1/10/24 2:44 AM:

    Now, I can try the recipe and see what happens.

    OK, recipe works. REcovery Partition (4) now 759MB.


    p.s.
    KB5034957: Updating the WinRE partition on deployed devices to address security vulnerabilities in CVE-2024-20666


    <https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10>


    So now I'm totally confused.
    I'm leaning towards John Hall's idea, wait for a while and see MS fixes this on their own.

    So you're telling me that the above link that tells me to download the Safe OS Dynamic Update, and run a .ps1 power
    shell script will take care of this all for me?   As well as what commands were suggested earlier (or maybe better than
    those commands). ?
    Okay, my VM win 10 had a small 511M recovery and it failed the update. Great. So I did the commands in the first link, the ones you have to hand type.
    Worked fine, after I opened my eyes and noted that I had an MBR and not GPT, couldn't figure out why the commands to
    create the recovery partition didn't work. Duh!.
    Update installed just fine after the new partition was created. I'll try my live system later.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ant@21:1/5 to winstonmvp@gmail.com on Thu Jan 11 01:00:36 2024
    ...w¡ñ§±¤ñ <winstonmvp@gmail.com> wrote:
    Paul wrote on 1/10/24 6:44 AM:
    On 1/10/2024 5:54 AM, John Hall wrote:
    In message <jOycnT_9xr1ACQD4nZ2dnZfqn_SdnZ2d@earthlink.com>, Ant <ant@zimage.comANT> writes
    Others'
    (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_ >>> january_9th_2024/kh32u6f/) and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in 64-bit W10 Pro. right now. I already
    rebooted once from other today's updates:

    On my 32-bit Windows 10 machine, the patch seems to have downloaded OK, but fails to install, seemingly being stuck at 0%. After a while, it reports the failure and says that it will try again later. If I manually click the Retry button that it
    gives me to get it to try again immediately, the same thing happens.

    I think I'll just wait for Microsoft to fix things rather than try anything fancy.

    Winstons link shows there is the potential for Bitlocker involvement.

    So yes, anything fancy might not be a good idea, especially the
    more protected the device is. (Surface, versus a home-built desktop)

    Hell, it could have third-party protection for all we know.

    Even if a person were to reinstall, the partition still
    might not be big enough. "Bad schemes are bad"

    One of the reasons some of the audience compromise their machines,
    is in the name of maintenance :-) My setup is almost maintainable.
    The recipe did not cause me grief. But my setup would not pass HIPPA.
    Some people have no choice but to have "complex wrecks" for computers.

    Paul


    The manual method provided in MSFT's KB/Learn article is, well, just
    plain nasty for the consumer(in some cases even the tech savvy consumer).

    On my Win10 Pro 22H2 device the Jan. updates installed without issue and possibly(likely) WinRE had more than sufficient free space. My WinRE partition is 1 GB. Before the update is was using just shy of 630 MB of
    the 1 GB total, after the update the Win RE is using 830 MB.

    Note: Thus I did not have the need or opportunity to test the link I provided.

    I mentioned my approach to Windows RE partition creation in the past when performing a clean install. Use the Windows provided installer's Advanced options to create the 4 GPT required partitions and when doing so create
    the WinRE partition as 1 GB using a Disk Part script or manually using
    the command line UI - a script is much easier<g>.

    Likewise, on my Win11 Pro 23H2 device the Jan. update installed without issue(took about 4 minutes). The Win11 23H2 device was also previously
    clean installed as Win10 Pro and upgraded to Win11 - the same process was used during that Win10 Pro clean install which used a DiskPart script to create the 4 GPT partitions with the WinRE as a 1GB partition.

    If folks are going to reinstall, creating the WinRE as a 1 GB(or maybe
    even 2 GB, the way things are growing with WinRE now included in
    cumulative updates) might be a good idea or even the recommended norm.

    Right, but how many people will do this? 1%? Most are using the defaults. :/
    --
    "My son, if sinners entice you, do not give in to them." --Proverbs 1:10. Dang brokeness, cold, life, etc.
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Ant on Wed Jan 10 20:42:54 2024
    On 1/10/2024 8:00 PM, Ant wrote:
    ...w¡ñ§±¤ñ <winstonmvp@gmail.com> wrote:
    Paul wrote on 1/10/24 6:44 AM:
    On 1/10/2024 5:54 AM, John Hall wrote:
    In message <jOycnT_9xr1ACQD4nZ2dnZfqn_SdnZ2d@earthlink.com>, Ant <ant@zimage.comANT> writes
    Others'
    (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_ >>>>> january_9th_2024/kh32u6f/) and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in 64-bit W10 Pro. right now. I already
    rebooted once from other today's updates:

    On my 32-bit Windows 10 machine, the patch seems to have downloaded OK, but fails to install, seemingly being stuck at 0%. After a while, it reports the failure and says that it will try again later. If I manually click the Retry button that it
    gives me to get it to try again immediately, the same thing happens.

    I think I'll just wait for Microsoft to fix things rather than try anything fancy.

    Winstons link shows there is the potential for Bitlocker involvement.

    So yes, anything fancy might not be a good idea, especially the
    more protected the device is. (Surface, versus a home-built desktop)

    Hell, it could have third-party protection for all we know.

    Even if a person were to reinstall, the partition still
    might not be big enough. "Bad schemes are bad"

    One of the reasons some of the audience compromise their machines,
    is in the name of maintenance :-) My setup is almost maintainable.
    The recipe did not cause me grief. But my setup would not pass HIPPA.
    Some people have no choice but to have "complex wrecks" for computers.

    Paul


    The manual method provided in MSFT's KB/Learn article is, well, just
    plain nasty for the consumer(in some cases even the tech savvy consumer).

    On my Win10 Pro 22H2 device the Jan. updates installed without issue and
    possibly(likely) WinRE had more than sufficient free space. My WinRE
    partition is 1 GB. Before the update is was using just shy of 630 MB of
    the 1 GB total, after the update the Win RE is using 830 MB.

    Note: Thus I did not have the need or opportunity to test the link I
    provided.

    I mentioned my approach to Windows RE partition creation in the past when
    performing a clean install. Use the Windows provided installer's Advanced
    options to create the 4 GPT required partitions and when doing so create
    the WinRE partition as 1 GB using a Disk Part script or manually using
    the command line UI - a script is much easier<g>.

    Likewise, on my Win11 Pro 23H2 device the Jan. update installed without
    issue(took about 4 minutes). The Win11 23H2 device was also previously
    clean installed as Win10 Pro and upgraded to Win11 - the same process was
    used during that Win10 Pro clean install which used a DiskPart script to
    create the 4 GPT partitions with the WinRE as a 1GB partition.

    If folks are going to reinstall, creating the WinRE as a 1 GB(or maybe
    even 2 GB, the way things are growing with WinRE now included in
    cumulative updates) might be a good idea or even the recommended norm.

    Right, but how many people will do this? 1%? Most are using the defaults. :/


    I have messed with all the partitions, at one time or another, and
    some are easy, and some... are damn hard to access.

    I'm sure those programmers who have returned from their Christmas
    vacation, are raring to go on fixing the broken stuff.

    "Oh, yeah. That hole we made, before Christmas. And you
    say some of the customers fell into the hole ? I'm on it !!!
    I will make a bigger hole, capable of holding more customers !!!"

    One of the reason I make fun of those programmers, is they managed
    to make *three* Recovery partitions next to my C: . The software
    was making them after every Upgrade. It would look like this.

    --------------+-----------------+---------------+-------------+
    C: | Recovery #3 | Recovery #2 | Recovery #1 |
    --------------+-----------------+---------------+-------------+

    And then, what exactly is the user supposed to do ?

    Each upgrade, would shrink a chunk off the end of C: and
    create another Recovery. (Only one of them has the current
    valid WinRE.wim in it.)

    This is one of the benefits of GPT partitioning, you can just
    keep doing that until the cows come home. GPT can have up
    to 128 partitions.

    One of the functions of "cleanmgr.exe" should be to remove the excess ones. Once Windows.old is gone, then only one of those can be valid.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Hall@21:1/5 to john_nospam@jhall.co.uk on Thu Jan 11 09:01:33 2024
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
    Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing than
    usual before it was released.
    --
    John Hall
    "Acting is merely the art of keeping a large group of people
    from coughing."
    Sir Ralph Richardson (1902-83)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to John Hall on Thu Jan 11 07:24:31 2024
    On 1/11/2024 4:01 AM, John Hall wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings > Windows Update now tells me that I'm up to date. I wonder whether Christmas and New Year meant that this update received less testing than usual before it was released.

    That's also going to impact some backup programs.

    If you were perhaps running Incremental Forever,
    and the partition size changes.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to John Hall on Thu Jan 11 09:22:02 2024
    On 1/11/24 04:01 AM, John Hall wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings > Windows Update now tells me that I'm up to date. I
    wonder whether Christmas and New Year meant that this update received less testing than usual before it was released.
    You're right. I did the dirty work on my VM yesterday, and held off on my live system, and sure enough, it's not doing
    that update today.

    WooHoo. Thanks for the notice. One less headache.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to John Hall on Thu Jan 11 09:52:31 2024
    On 1/11/2024 3:01 AM, John Hall wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
    Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing than usual before it was released.

    Still getting the same error here today. Not fixed for me.

    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ant@21:1/5 to George on Fri Jan 12 02:51:31 2024
    George <george.ruch74@gmail.com> wrote:
    ant@zimage.comANT (Ant) wrote:

    Others' >(https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
    "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
    64-bit W10 Pro. right now. I already rebooted once from other today's updates:

    [snip]

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/

    Good news, folks. MS has released a PowerShell script to
    automate the process.

    Details, courtesy BleepingComputer: https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-script-to-update-windows-10-winre-with-bitlocker-fixes/
    (mind the wrap)

    The script: Article KB5034957 https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
    (mind he wrap)

    Has anyone tried it yet? Is it safe or buggy? :)
    --
    "My son, if sinners entice you, do not give in to them." --Proverbs 1:10. "My son, if sinners entice you, do not give in to them." --Proverbs 1:10. Dang cold winds and age.
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to sticks on Fri Jan 12 01:54:51 2024
    On 1/11/2024 10:52 AM, sticks wrote:
    On 1/11/2024 3:01 AM, John Hall wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings > Windows Update now tells me that I'm up to date. I wonder whether Christmas and New Year meant that this update received less testing than usual before it was released.

    Still getting the same error here today.  Not fixed for me.


    Is there something unique about your disk layout ?

    You would think the revision of the release, would cause
    a fresh download of it. So that it would not be using
    just the old method and running into trouble.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Slootweg@21:1/5 to John Hall on Fri Jan 12 11:31:10 2024
    John Hall <john_nospam@jhall.co.uk> wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
    Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing than usual before it was released.

    Please check that it indeed has been fixed.

    For example on my wife's Windows 10 system, Windows Update indeed says "You're up to date", but in 'Update history' ('Quality Updates' section)
    it says that KB5034441 failed to install and gives the 0x80070643 error
    code.

    So: "You're up to date", but install failure and the update is not
    re-offered (nor has any other update been offered/installed).

    And to answer Paul's question, yes this system has a 'special'
    partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
    partition which probably still contains the HP-proprietary recovery for
    Windows 8):

    From 'Disk Management':

    [Partition type descriptions translated from Dutch:]

    Partition 1: Recovery partition (400 MB)
    Partition 2: EFI system partition (260 MB)
    Partition : Windows (C:) partition (449.96 GB)
    Partition 5: Recovery partition (605 MB)
    Partition : RECOVERY (D:) partition ( 14.94 GB)

    N.B. Partitions are listed in physical order (bottom pane). Disk
    Management does not list the partition numbers for C: and D: and I don't
    see how Disk Management can show the partition numbers of these
    partitions.

    In the top pane, the order in the 'Volume' column is different than
    the physical order: Partition 1, partition 2, partition 5,
    RECOVERY (D:), Windows (C:).

    But most importantly, the question to Winston, Paul et al:

    How can we *check* that the recovery partition was indeed correctly 'fixed'/updated?

    Some posters (like John Hall) report no errors, but does that mean
    their system is OK/'fixed'/updated?

    Others (like 'sticks' and me) report errors, but does that mean their
    system is *not* OK/'fixed'/updated?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Frank Slootweg on Fri Jan 12 08:11:21 2024
    On 1/12/2024 5:31 AM, Frank Slootweg wrote:
    John Hall <john_nospam@jhall.co.uk> wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
    <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
    Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing than
    usual before it was released.

    Please check that it indeed has been fixed.

    For example on my wife's Windows 10 system, Windows Update indeed says "You're up to date", but in 'Update history' ('Quality Updates' section)
    it says that KB5034441 failed to install and gives the 0x80070643 error
    code.

    So: "You're up to date", but install failure and the update is not re-offered (nor has any other update been offered/installed).

    Checking today, mine showed 2 updates, downloaded and installed Defender
    stuff, and now opens with "Error encountered". It didn't appear to
    download a new file, or even try and reinstall. It went to the error fast.


    And to answer Paul's question, yes this system has a 'special'
    partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
    partition which probably still contains the HP-proprietary recovery for Windows 8):

    From 'Disk Management':

    [Partition type descriptions translated from Dutch:]

    Partition 1: Recovery partition (400 MB)
    Partition 2: EFI system partition (260 MB)
    Partition : Windows (C:) partition (449.96 GB)
    Partition 5: Recovery partition (605 MB)
    Partition : RECOVERY (D:) partition ( 14.94 GB)

    N.B. Partitions are listed in physical order (bottom pane). Disk Management does not list the partition numbers for C: and D: and I don't
    see how Disk Management can show the partition numbers of these
    partitions.

    In the top pane, the order in the 'Volume' column is different than
    the physical order: Partition 1, partition 2, partition 5,
    RECOVERY (D:), Windows (C:).

    I have smaller:
    System Reserved 100 MB 100% free
    Main C 465.15 GB 76% free
    Recovery 526 MB with 64% free

    I'm guessing this recovery partition is too small and that's the
    problem, so I have to run this script they have put out yesterday?



    But most importantly, the question to Winston, Paul et al:

    How can we *check* that the recovery partition was indeed correctly 'fixed'/updated?

    Some posters (like John Hall) report no errors, but does that mean
    their system is OK/'fixed'/updated?

    Others (like 'sticks' and me) report errors, but does that mean their system is *not* OK/'fixed'/updated?

    Mine's certainly not updated. My question is do I have to do something
    to get this update, or is it supposed to be fixed automatically? Kind
    of seems like a crazy way to do things if that is true. I'm sure I
    could get it done, but almost nobody else I know would be able to.

    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Hall@21:1/5 to this@ddress.is.invalid on Fri Jan 12 16:53:35 2024
    In message <unrbe1.5jo.1@ID-201911.user.individual.net>, Frank Slootweg <this@ddress.is.invalid> writes
    John Hall <john_nospam@jhall.co.uk> wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
    <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
    Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing than
    usual before it was released.

    Please check that it indeed has been fixed.

    For example on my wife's Windows 10 system, Windows Update indeed says
    "You're up to date", but in 'Update history' ('Quality Updates' section)
    it says that KB5034441 failed to install and gives the 0x80070643 error
    code.

    So: "You're up to date", but install failure and the update is not
    re-offered (nor has any other update been offered/installed).
    <snip>

    Yes, you're right. Presumably now that they know the update was faulty
    they've stopped it from trying repeatedly to install itself, and are
    still working on a fixed version which will be offered when it's ready.
    --
    John Hall
    "Acting is merely the art of keeping a large group of people
    from coughing."
    Sir Ralph Richardson (1902-83)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ant@21:1/5 to winstonmvp@gmail.com on Fri Jan 12 20:30:28 2024
    ...w¡ñ§±¤ñ <winstonmvp@gmail.com> wrote:
    Ant wrote on 1/11/24 7:51 PM:
    George <george.ruch74@gmail.com> wrote:
    ant@zimage.comANT (Ant) wrote:

    Others'
    (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
    "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
    64-bit W10 Pro. right now. I already rebooted once from other today's updates:

    [snip]

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/

    Good news, folks. MS has released a PowerShell script to
    automate the process.

    Details, courtesy BleepingComputer:
    https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-script-to-update-windows-10-winre-with-bitlocker-fixes/
    (mind the wrap)

    The script: Article KB5034957
    https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
    (mind he wrap)

    Has anyone tried it yet? Is it safe or buggy? :)

    Successful results from the Enterprise community(some of the Admins responsible for 100,000+ devices still using Win10)

    Same identical link for the Powershell script(s)I posted yesterday Jan
    10, 2024.

    Also note, in both the consumer and Enterprise community reports(earlier today) have indicated that rerunning Windows Update to install the same update are now yielding successful results.
    i.e. MSFT has updated the code for the Jan. 2024 cumulative update.
    - in this case the general understanding is they reverted to or
    modified existing code, that updated the Windoes RE envirorment(and its partition on disk) that was in use from June 2023 through Dec 2023(WinRE
    has been included in Cumulative Updates since June 2023 without issues encountered by the Jan. 2024 update)

    In both of the above successful cases, do realize that there are
    hundreds, thousands or more of different devices and not all operating
    under the same conditions as one's own device.

    I reran WU, but it still failed for this update. :( Does this fixed WU include this script?
    --
    "Blessed is the man who perseveres under trial, because when he has stood the test, he will receive the crown of life that God has promised to those who love him." --James 1:12. Only lucky 8 remember it! TGIF?
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nil@21:1/5 to George on Fri Jan 12 18:07:15 2024
    On 11 Jan 2024, George <george.ruch74@gmail.com> wrote in alt.comp.os.windows-10:

    Good news, folks. MS has released a PowerShell script to
    automate the process.

    Details, courtesy BleepingComputer: https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-sc ript-to-update-windows-10-winre-with-bitlocker-fixes/ (mind the
    wrap)

    The script: Article KB5034957 https://support.microsoft.com/en-us/topic/kb5034957-updating-the-wi nre-partition-on-deployed-devices-to-address-security-vulnerabiliti es-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10 (mind he
    wrap)

    This confuses me. If I'm reading things right, the update failed
    because the recovery partition is too small. The article says, "the
    company now also provides a dedicated PowerShell script to help you
    automate updating the WinRE partition (without having to resize it
    first) and patching the CVE-2024-20666 BitLocker vulnerability." It's
    not clear to me whether the script resizes the partition or not My
    recovery partition on this desktop is 542 MB. If that was too small
    before, is the script going to fix the basic problem?

    Ideally, what size should the Recovery Partition be? I see on two of my
    other computers, both of which took the update successfully, have
    multiple (redundant?) recovery partitions, totaling about 15 GB.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Frank Slootweg on Fri Jan 12 21:14:41 2024
    On 1/12/2024 6:31 AM, Frank Slootweg wrote:
    John Hall <john_nospam@jhall.co.uk> wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
    <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
    Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing than
    usual before it was released.

    Please check that it indeed has been fixed.

    For example on my wife's Windows 10 system, Windows Update indeed says "You're up to date", but in 'Update history' ('Quality Updates' section)
    it says that KB5034441 failed to install and gives the 0x80070643 error
    code.

    So: "You're up to date", but install failure and the update is not re-offered (nor has any other update been offered/installed).

    And to answer Paul's question, yes this system has a 'special'
    partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
    partition which probably still contains the HP-proprietary recovery for Windows 8):

    From 'Disk Management':

    [Partition type descriptions translated from Dutch:]

    Partition 1: Recovery partition (400 MB)
    Partition 2: EFI system partition (260 MB)
    Partition : Windows (C:) partition (449.96 GB)
    Partition 5: Recovery partition (605 MB)
    Partition : RECOVERY (D:) partition ( 14.94 GB)

    N.B. Partitions are listed in physical order (bottom pane). Disk
    Management does not list the partition numbers for C: and D: and I don't
    see how Disk Management can show the partition numbers of these
    partitions.

    In the top pane, the order in the 'Volume' column is different than
    the physical order: Partition 1, partition 2, partition 5,
    RECOVERY (D:), Windows (C:).

    But most importantly, the question to Winston, Paul et al:

    How can we *check* that the recovery partition was indeed correctly 'fixed'/updated?

    Some posters (like John Hall) report no errors, but does that mean
    their system is OK/'fixed'/updated?

    Others (like 'sticks' and me) report errors, but does that mean their system is *not* OK/'fixed'/updated?


    This has certainly turned into a hobby :-)

    [Picture]

    https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nil@21:1/5 to winstonmvp@gmail.com on Fri Jan 12 21:19:12 2024
    On 12 Jan 2024, =?UTF-8?B?Li4ud8Khw7HCp8KxwqTDsSA=?=
    <winstonmvp@gmail.com> wrote in alt.comp.os.windows-10:

    Nil wrote on 1/12/24 4:07 PM:
    The script: Article KB5034957
    https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
    (mind he wrap)

    This confuses me. If I'm reading things right, the update failed
    because the recovery partition is too small. The article says,
    "the company now also provides a dedicated PowerShell script to
    help you automate updating the WinRE partition (without having to
    resize it first) and patching the CVE-2024-20666 BitLocker
    vulnerability." It's not clear to me whether the script resizes
    the partition or not My recovery partition on this desktop is 542
    MB. If that was too small before, is the script going to fix the
    basic problem?

    The script in the referenced support article does not resize the
    partition. - This script only performs the installation, and only
    if you have downloaded the Safe OS update package. It doesn't
    resize any partitions. It also requires that the packages are
    actually available and have already been downloaded.
    The script does check for Bitlocker and disable and reenable WinRE
    if it's enabled.

    OK, that partly answers my question, but it skips the most important part:
    is my current Recovery large enough? Is the script smart enough to check
    if there's enough room and abort if not?


    I'll get back to you about the multiple partitions issue. It's not very important, but it would be nice to regain some of that disk space.

    Ideally, what size should the Recovery Partition be? I see on two
    of my other computers, both of which took the update
    successfully, have multiple (redundant?) recovery partitions,
    totaling about 15 GB.
    Multiple recovery partitions?
    How many?
    Please specify the sizes of each one.

    While one could have multiple Recovery partitions for Windows, one
    could also have one active Recovery partition, and/or an
    inactive(useless) or OEM 'Recovery partition'. The OEM Recovery
    partition are usually very large(GB) and is not the active
    Recovery partition being addressed/updated with the January 2024 update/patch. - The OEM Recovery partition was placed on the
    device, as-shipped, by the OEM to allow the end-user(purchaser) to
    reset the device to as-shipped condition(i.e. it has no bearing on
    the Jan. 2024 update or updating the active Windows Recovery
    partition

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Paul on Sat Jan 13 07:33:40 2024
    On 1/12/24 09:14 PM, Paul wrote:
    On 1/12/2024 6:31 AM, Frank Slootweg wrote:
    John Hall <john_nospam@jhall.co.uk> wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
    <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
    Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing than >>> usual before it was released.

    Please check that it indeed has been fixed.

    For example on my wife's Windows 10 system, Windows Update indeed says
    "You're up to date", but in 'Update history' ('Quality Updates' section)
    it says that KB5034441 failed to install and gives the 0x80070643 error
    code.

    So: "You're up to date", but install failure and the update is not
    re-offered (nor has any other update been offered/installed).

    And to answer Paul's question, yes this system has a 'special'
    partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
    partition which probably still contains the HP-proprietary recovery for
    Windows 8):

    From 'Disk Management':

    [Partition type descriptions translated from Dutch:]

    Partition 1: Recovery partition (400 MB)
    Partition 2: EFI system partition (260 MB)
    Partition : Windows (C:) partition (449.96 GB)
    Partition 5: Recovery partition (605 MB)
    Partition : RECOVERY (D:) partition ( 14.94 GB)

    N.B. Partitions are listed in physical order (bottom pane). Disk
    Management does not list the partition numbers for C: and D: and I don't
    see how Disk Management can show the partition numbers of these
    partitions.

    In the top pane, the order in the 'Volume' column is different than
    the physical order: Partition 1, partition 2, partition 5,
    RECOVERY (D:), Windows (C:).

    But most importantly, the question to Winston, Paul et al:

    How can we *check* that the recovery partition was indeed correctly
    'fixed'/updated?

    Some posters (like John Hall) report no errors, but does that mean
    their system is OK/'fixed'/updated?

    Others (like 'sticks' and me) report errors, but does that mean their
    system is *not* OK/'fixed'/updated?


    This has certainly turned into a hobby :-)

    [Picture]

    https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif

    Paul
    I just tried my system last night and I have 566M in Recovery.
    I did the manual way and when I did the shrink on the OS partition it
    failed. 96G, said it could not shrink, something about the new size
    would be less than the minimum.

    And I did verify that the Sel Part was 4 for OS and 5 for Recovery and I
    was on the right partition.

    Now I wonder if I should run the powershell script? Will it abort and
    reset properly if this error pops up there?

    You're right Paul. I've spent less time on hobbies.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Big Al on Sat Jan 13 07:35:28 2024
    On 1/13/24 07:33 AM, Big Al wrote:
    On 1/12/24 09:14 PM, Paul wrote:
    On 1/12/2024 6:31 AM, Frank Slootweg wrote:
    John Hall <john_nospam@jhall.co.uk> wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
    <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try
    anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
    Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing
    than
    usual before it was released.

       Please check that it indeed has been fixed.

       For example on my wife's Windows 10 system, Windows Update indeed
    says
    "You're up to date", but in 'Update history' ('Quality Updates' section) >>> it says that KB5034441 failed to install and gives the 0x80070643 error
    code.

       So: "You're up to date", but install failure and the update is not
    re-offered (nor has any other update been offered/installed).

       And to answer Paul's question, yes this system has a 'special'
    partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
    partition which probably still contains the HP-proprietary recovery for
    Windows 8):

     From 'Disk Management':

    [Partition type descriptions translated from Dutch:]

    Partition 1: Recovery      partition (400 MB)
    Partition 2: EFI system    partition (260 MB)
    Partition  : Windows (C:)  partition (449.96 GB)
    Partition 5: Recovery      partition (605 MB)
    Partition  : RECOVERY (D:) partition ( 14.94 GB)

       N.B. Partitions are listed in physical order (bottom pane). Disk
    Management does not list the partition numbers for C: and D: and I don't >>> see how Disk Management can show the partition numbers of these
    partitions.

       In the top pane, the order in the 'Volume' column is different than >>> the physical order: Partition 1, partition 2, partition 5,
    RECOVERY (D:), Windows (C:).

       But most importantly, the question to Winston, Paul et al:

       How can we *check* that the recovery partition was indeed correctly >>> 'fixed'/updated?

       Some posters (like John Hall) report no errors, but does that mean
    their system is OK/'fixed'/updated?

       Others (like 'sticks' and me) report errors, but does that mean their >>> system is *not* OK/'fixed'/updated?


    This has certainly turned into a hobby :-)

        [Picture]

         https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif >>
       Paul
    I just tried my system last night and I have 566M in Recovery.
    I did the manual way and when I did the shrink on the OS partition it failed.  96G, said it could not shrink, something about the new size
    would be less than the  minimum.

    And I did verify that the Sel Part was 4 for OS and 5 for Recovery and I
    was on the right partition.

    Now I wonder if I should run the powershell script?  Will it abort and
    reset properly if this error pops up there?

    You're right Paul.  I've spent less time on hobbies.
    Just saw Winston's remarks that the powershell script only fixes the
    win.re not the partition size.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Slootweg@21:1/5 to winstonmvp@gmail.com on Sat Jan 13 14:44:15 2024
    ...w¡ñ§±¤ñ <winstonmvp@gmail.com> wrote:
    Frank Slootweg wrote on 1/12/24 4:31 AM:
    And to answer Paul's question, yes this system has a 'special'
    partition layout. *Two* recovery partitions (and the HP 'RECOVERY' partition which probably still contains the HP-proprietary recovery for Windows 8):

    [...]
    From 'Disk Management':


    [Partition type descriptions translated from Dutch:]

    Partition 1: Recovery partition (400 MB)
    Partition 2: EFI system partition (260 MB)
    Partition : Windows (C:) partition (449.96 GB)
    Partition 5: Recovery partition (605 MB)
    Partition : RECOVERY (D:) partition ( 14.94 GB)

    N.B. Partitions are listed in physical order (bottom pane). Disk Management does not list the partition numbers for C: and D: and I don't see how Disk Management can show the partition numbers of these
    partitions.
    It does not, it has a drive label.
    On your device
    MSR(not shown) iw partition 3
    C: is partition 4
    D: is partition 6

    In the meantime, I have found that Macrium Reflect (Free) gives some
    more information, including partition numbers:

    - Partition 1 seems to be the real - in use - recovery partition,
    because MR says:

    1 - WINRE (None)
    Primary - NTFS
    291.4 MB
    400.0 MB

    - Partition 5 seems to be some kind of left-over recovery partition,
    because it is listed without a label (no 'WINRE'):

    5 - (None)
    Primary - NTFS
    523.4 MB
    605.0 MB

    - Partition 3 is indeed the MSR (Microsoft Reserved Partition):

    3 - (None)
    Primary - Unformatted
    120.0 MB
    120.0 MB

    In the top pane, the order in the 'Volume' column is different than
    the physical order: Partition 1, partition 2, partition 5,
    RECOVERY (D:), Windows (C:).

    You've variety of built-in tools to view partitions in an admin mode. PowerShell's command Get-Volume
    - shows about the same as Disk Management
    Diskpart provides a little more depth
    List Vol (all partitions/volumes with and without assigned drive labels)
    Sel Disk (command to select the desired disk)
    List Part (command to list and show the partitions and partition number
    on the selected disk)

    As many people probably have Macrium Reflect (Free), that's probably
    easier than using dangerous tools like 'diskpart' or use 'Get-Volume',
    which - at least by default - doesn't give the desired information
    (doesn't list partition numbers, doesn't list the MSR, lists other
    disks).

    [...]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Big Al on Sat Jan 13 11:38:19 2024
    On 1/13/2024 7:35 AM, Big Al wrote:
    On 1/13/24 07:33 AM, Big Al wrote:
    On 1/12/24 09:14 PM, Paul wrote:
    On 1/12/2024 6:31 AM, Frank Slootweg wrote:
    John Hall <john_nospam@jhall.co.uk> wrote:
    In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
    <john_nospam@jhall.co.uk> writes
    <snip>
    I think I'll just wait for Microsoft to fix things rather than try >>>>>> anything fancy.

    I'm glad I waited, as Microsoft now seem to have fixed it. Settings > >>>>> Windows Update now tells me that I'm up to date. I wonder whether
    Christmas and New Year meant that this update received less testing than >>>>> usual before it was released.

       Please check that it indeed has been fixed.

       For example on my wife's Windows 10 system, Windows Update indeed says
    "You're up to date", but in 'Update history' ('Quality Updates' section) >>>> it says that KB5034441 failed to install and gives the 0x80070643 error >>>> code.

       So: "You're up to date", but install failure and the update is not >>>> re-offered (nor has any other update been offered/installed).

       And to answer Paul's question, yes this system has a 'special'
    partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
    partition which probably still contains the HP-proprietary recovery for >>>> Windows 8):

     From 'Disk Management':

    [Partition type descriptions translated from Dutch:]

    Partition 1: Recovery      partition (400 MB)
    Partition 2: EFI system    partition (260 MB)
    Partition  : Windows (C:)  partition (449.96 GB)
    Partition 5: Recovery      partition (605 MB)
    Partition  : RECOVERY (D:) partition ( 14.94 GB)

       N.B. Partitions are listed in physical order (bottom pane). Disk
    Management does not list the partition numbers for C: and D: and I don't >>>> see how Disk Management can show the partition numbers of these
    partitions.

       In the top pane, the order in the 'Volume' column is different than >>>> the physical order: Partition 1, partition 2, partition 5,
    RECOVERY (D:), Windows (C:).

       But most importantly, the question to Winston, Paul et al:

       How can we *check* that the recovery partition was indeed correctly >>>> 'fixed'/updated?

       Some posters (like John Hall) report no errors, but does that mean >>>> their system is OK/'fixed'/updated?

       Others (like 'sticks' and me) report errors, but does that mean their >>>> system is *not* OK/'fixed'/updated?


    This has certainly turned into a hobby :-)

        [Picture]

         https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif >>>
       Paul
    I just tried my system last night and I have 566M in Recovery.
    I did the manual way and when I did the shrink on the OS partition it failed.  96G, said it could not shrink, something about the new size would be less than the  minimum.

    And I did verify that the Sel Part was 4 for OS and 5 for Recovery and I was on the right partition.

    Now I wonder if I should run the powershell script?  Will it abort and reset properly if this error pops up there?

    You're right Paul.  I've spent less time on hobbies.
    Just saw Winston's remarks that the powershell script only fixes the win.re not the partition size.

    What I use for viewing partition details, is JKDefrag.

    [Picture]

    https://i.postimg.cc/YqY9fsg0/JKDefrag-and-friends.gif

    Command Prompt - Admin

    cd /d C:\users\Bullwinkle\Downloads\JKDefrag

    jkdefrag -a 1 -d 2 C: # Visual review of the state of defragmentation. No change to disk.

    notepad jkdefrag.log # View textual information about the results. "Top 25" at bottom of file.

    jkdefrag -a 5 -d 2 C: # Push disk contents towards partition origin, makes fragmentation worse (OK)

    Do Properties on C: , Tools, use Optimize # This defragments files < 50MB
    # Optimize is crank, misbehaves in VM. Use defrag from command line, below.

    jkdefrag -a 2 -d 2 C: # This is the JKDefrag defragmentation call
    # Now the big files are shrunk. This means Windows does most of the work, JKDefrag tidies up.

    Finally, for SSD owners or VM users who are getting "slab" complaints in Optimize window:

    defrag C: # System defragmenter which is less cranky, and just gets to work.

    Those are the tools. The game is played like Space Invaders.

    I think there has been a subtle change in the Optimize defragmenter, in that
    it seems to be moving some red stuff. But I had too many frosted sugar bombs for breakfast and I can't be sure.

    The examples were done with JKDefrag 3.36 . A relatively small file, and portable software.
    I have copies of this *everywhere*. Every install gets one. Every VM gets one.

    https://www.kessels.com/JkDefrag/

    There are also procedures for cleaning up your VM.
    One component, is cleaning the NTFS file system.
    Compaction of the VM container, depends on what container you are using.
    After your compaction run on a dynamic container, the file should be smaller.

    sdelete64 -z C: # Cleaning the C partition of a VM.

    # The tool is two-pass. Please be patient. Long run time if you made C: way way too big in VM.

    https://learn.microsoft.com/en-us/sysinternals/downloads/sdelete

    Anyway, enjoy your adventure. Space invaders beware.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nil@21:1/5 to Big Al on Sat Jan 13 13:41:23 2024
    On 13 Jan 2024, Big Al <alan@invalid.com> wrote in
    alt.comp.os.windows-10:

    Just saw Winston's remarks that the powershell script only fixes
    the win.re not the partition size.

    So, this implies to me that the script will get us through the current
    error condition, but if there's a similar update in the future we may
    run into it again, due to low free space in the recovery partition.
    Would you agree?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Nil on Sat Jan 13 14:37:48 2024
    On 1/13/24 01:41 PM, Nil wrote:
    On 13 Jan 2024, Big Al <alan@invalid.com> wrote in
    alt.comp.os.windows-10:

    Just saw Winston's remarks that the powershell script only fixes
    the win.re not the partition size.

    So, this implies to me that the script will get us through the current
    error condition, but if there's a similar update in the future we may
    run into it again, due to low free space in the recovery partition.
    Would you agree?

    I would agree. I've tried to do the manual resize and it fails. It
    worked on a VM but not my live system. I dual boot Linux.
    I'm looking into doing defrag or jkdefrag as Paul has noted to get some
    space at the end. That might be why it won't shrink.

    This is (now) a low priority item.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Big Al on Sat Jan 13 17:17:24 2024
    On 1/13/2024 2:37 PM, Big Al wrote:
    On 1/13/24 01:41 PM, Nil wrote:
    On 13 Jan 2024, Big Al <alan@invalid.com> wrote in
    alt.comp.os.windows-10:

    Just saw Winston's remarks that the powershell script only fixes
    the win.re not the partition size.

    So, this implies to me that the script will get us through the current
    error condition, but if there's a similar update in the future we may
    run into it again, due to low free space in the recovery partition.
    Would you agree?

    I would agree.  I've tried to do the manual resize and it fails.  It worked on a VM but not my live system.  I dual boot Linux.
    I'm looking into doing defrag or jkdefrag as Paul has noted to get some space at the end.  That might be why it won't shrink.

    This is (now) a low priority item.Using jkdefrag I found that restore points were shoved at the end of the drive.
    I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now. I probably should have shoved it 500M, but... It's at 881M now.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Big Al on Sat Jan 13 17:25:01 2024
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and I
    was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably
    should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance
    you could post the message ID of the one that had the instructions you
    followed to get yours working? It would be much appreciated!

    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to All on Sun Jan 14 03:15:31 2024
    On 1/13/2024 2:45 PM, ...w¡ñ§±¤ñ wrote:
    Paul wrote on 1/12/24 7:14 PM:

    This has certainly turned into a hobby :-)

        [Picture]

         https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif >>
       Paul

    And will be as long as WinRE continues to grow(apparently like yours has, since it would be unlikely to have ever been initially created as a 759 MB partition)

    Lol...also unlikely for anyone's WinRE partition to be the same size as another's WinRE partition.

    You may recall, I've previously been a proponent of creating the WinRe partition for clean installs at 1 GB.
     - with my Win11 23H2(updated with Jan. 2024 updates) WinRE partition at 827 MB its winre.wim at 811 MB...2 GB could easily become my new recommendation for the WinRE partition.

    I have at least one install here that uses 1GB WinRE partitions,
    so I have done that. And likely after your feedback. It was a drive
    with two copies of Windows, and a 1GB WinRE for each.

    I just don't remember which disk drive has that feature right now.
    My disks are numbered, and the last hard drive purchased is #34,
    so it's easy to lose track :-) Most of my drives are small ones
    for scratch purposes.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to sticks on Sun Jan 14 05:45:15 2024
    On 1/13/2024 6:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance you could post
    the message ID of the one that had the instructions you followed to get yours working? 
    It would be much appreciated!

    We have not reduced the answer to this question to a "recipe".

    You could have Bitlocker encryption on the disk drive. While Bitlocker
    is not "supported" on Home, and is supported on Pro, the manage-bde
    utility may be present anyway, to give some information. Some people to
    this day, are blissfully unaware their disk is encrypted. Surprise!

    manage-bde -status

    Early in the thread, we were treated to the support.microsoft.com article.
    I tried to provide a picture of my disk drive, and show
    the commands I would use to fix my specific case. I generally
    do not use crypto, if I can possibly avoid it. (Only my VMWare
    virtual machine with the Win11 in it, is encrypted, as VMWare
    did not offer any options in the matter. Users even told VMWare how
    to do this. Crickets.)

    A typical user might have a UEFI installation on a modern computer, with
    a GPT partitioned disk. The worked example assumes these characteristics.
    I had to "avoid" using my legacy MBR Win10 installation, as it would mislead people a bit. More people could be here on OEM setups, in which case
    the possible disk layouts, crypto situations, just explodes. Thus,
    this example is a very narrow and "best-guess" at what you might find.
    OEM systems will be GPT. A lot of users in the group, might well have
    selected GPT for the flexibility it offers.

    A couple posters have already recommended waiting until Microsoft fixes this. If you're a multi-booter with *lots* of experience, I think you can handle this,
    but then, you'd be finished by now.

    The standard advice (which I use religiously when standing on a shaky platform),
    is to do a full disk backup before attempting anything like this.

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    # Administrator Command Prompt, or Admin Powershell then type "cmd.exe" as a command

    reagentc /info # shows recovery agent is enabled, and is using Partition 4
    # The article should show what that looks like. A picture would help.
    # If your reagentc is blank or messed up, *stop now*. See example further down,
    # for what one looks like.

    [Picture] This picture shows my disk setup, and makes a reference to the invisible non-partition known as MSR (reserved/junk area)
    Partition 2 can be seen from Linux gparted /dev/sda , if you really want to see the disk layout.
    The disktype.exe utility also shows it, but it's only available via a Cygwin installation.
    I do not really want to lard up this answer with a lot more utility photos. I guess even List Partition
    shows it, come to think of it.

    https://i.postimg.cc/sgXwB389/diskpart-disk-summary.gif

    reagentc /disable # Disable recovery environment agent before making changes

    diskpart.exe # Now, we're doing shrink of C: and regeneration (empty) Recovery partition 4
    list disk
    select disk 0
    list partition
    select partition 3 # will shrink C: now. This could fail, if the $USN journal is right at the end of C: .
    shrink desired=250 minimum=250 # runtime 1 second (*normally* the end of the disk doesn't have a blocker up there)
    select partition 4
    delete partition override # "delete partition" is the command we seek to cowboy at this point
    # This solves the inability to change the origin of a partition in DiskMgmt. Deleting Partition 4

    create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac # The ID is a partition type, it's our Recovery partition.
    gpt attributes =0x8000000000000001 # <=== Protected status of partition. Partitions
    # can be "marked" as "being special" [Attribute]
    # Yes, there are fourteen zeros in that constant.

    format quick fs=ntfs label="Windows RE tools" # Partition 4 is NTFS, and now it has no content. Empty file system.
    # Partition is likely hidden by its ID value. The Windows Update will fill it up.
    exit

    reagentc /enable # Even though Partition 4 is empty, we can still pretend all is well.
    reagentc /info # A sample output is provided, after this line.

    Windows Recovery Environment (Windows RE) and system reset configuration Information:

    Windows RE status: Enabled
    Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE <=== partition pointer remains as before
    Boot Configuration Data (BCD) identifier: 964e2ef1-3a60-11ed-81d3-5cf3707d2fda <=== likely inside ESP Partition 1
    Recovery image location:
    Recovery image index: 0
    Custom image location:
    Custom image index: 0

    Anyway, that was enough operations for me to fix mine. YMMV, OK?

    ... Time passes. Somehow, we encourage '4441 to install. We think
    a new WinRE.wim was installed. How to prove it ?

    To prove '4441 has installed my new WinRE, I used TestDisk version 7.
    Using this is actually too complicated to explain. Which speaks well of the interface.
    Not a problem. We have an alternative.

    [Picture]

    https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif

    The alternative, is more Diskpart. Administrator window of some sort,
    or otherwise, diskpart will elevate itself.

    diskpart.exe
    list disk
    select disk 0
    list partition
    select partition 4 # We're pointed to the 0x27 style hidden Recovery partition now.
    assign letter=K # Temporarily assigning a drive letter, to make partition visibie.
    # Permissions can *still* prevent us from doing stuff. File Manager
    # pointing to K: , is not very helpful right now.

    exit

    In the same administrator window, to prove '4441 is present, now we have
    access to the partition via the letter K. (The letter K will be removed
    on a reboot. If you want it per-session, you have to do the procedure per-session.) You should see three files with Jan 2024 datestamps or so.
    The slash a h is asking to display all files with a Hidden attribute set.

    dir /ah K:\Recovery\WindowsRE

    So that's about it... for me.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to All on Sun Jan 14 08:32:54 2024
    On 1/14/24 04:52 AM, ...w¡ñ§±¤ñ wrote:
    ...If using Win10 or Win11 and using System Restore to revisit System
    Restore in Windows, then it might be of benefit(after successfully
    installing the Jan 2024 update)to:
    a. Verify SR is still enabled
    b. Delete all SR restore points
    d. Enable SR and create a new SR restore point
    e. Restart the device
    f. Re-image the disk(System, MSR, Windows, and WinRE partitions)
    To resize my partition, I did step 'b' first to get space.
    SR was at the end of the drive.
    Then after, I performed all the others.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to sticks on Sun Jan 14 08:25:13 2024
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and
    I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and
    it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably
    should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance
    you could post the message ID of the one that had the instructions you followed to get yours working?  It would be much appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Big Al on Sun Jan 14 08:12:09 2024
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands
    and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and
    it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably
    should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any
    chance you could post the message ID of the one that had the
    instructions you followed to get yours working?  It would be much
    appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Slootweg@21:1/5 to winstonmvp@gmail.com on Sun Jan 14 14:29:48 2024
    ...w¡ñ§±¤ñ <winstonmvp@gmail.com> wrote:
    Frank Slootweg wrote on 1/13/24 7:44 AM:
    [...]
    In the meantime, I have found that Macrium Reflect (Free) gives some more information, including partition numbers:

    - Partition 1 seems to be the real - in use - recovery partition,
    because MR says:

    1 - WINRE (None)
    Primary - NTFS
    291.4 MB
    400.0 MB

    - Partition 5 seems to be some kind of left-over recovery partition,
    because it is listed without a label (no 'WINRE'):

    5 - (None)
    Primary - NTFS
    523.4 MB
    605.0 MB

    - Partition 3 is indeed the MSR (Microsoft Reserved Partition):

    3 - (None)
    Primary - Unformatted
    120.0 MB
    120.0 MB
    [...]

    Hi, Frank
    In an admin command prompt(Powershell or Command.com) enter
    reagentc /info
    The result will show WinRE's
    - the status (Recovery - Enabled or Disabled)
    - location of the active WinRE partition.


    It's unlikely that Partition 1 is the real in-use(active) WinRE partition.

    More likely, that the OEM or a post device first use and much earlier
    Windows installation version placed a WinRE before the o/s partition.
    - Up until Windows 10 version 2004, a clean install(including OEM's who
    did not follow GPT partitioning Guidelines) placed the Recovery partition
    at the beginning of the disk. Any upgrade that required a larger recovery partition then placed the new one after the Windows partition(carving
    space out of the Windows partition)
    => MSFT fixed this in Windows 10 2004 version releasing an updated
    Media Creation Tool for creating installation media(usb or iso) and also
    ISO builds available in Visual Studio subscriptionsA(fka MSDN and TechNet)
    => Devices that initially had WinRE as the first partition and as the active WinRE partition were fine up until that Recovery partition became
    too small to handle an increase in size of the WinRE partitions files(primarily winre.wim). Windows by design and consistent with GPT partitioning guidelines created a new and active WinRE partition after
    the Windows partition.

    i.e. Partition 5 would be your device's 'active, enabled, WinRE partition)...and also by design, it does not have a label.

    Correct! "reagentc /info" indeed shows the 'Windows RE location:' as ...\partition5\... And indeed on my Windows 11 system the WinRE
    partition doesn't have a label.

    Thanks for your help. All is clear now.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Paul on Sun Jan 14 08:16:12 2024
    On 1/14/2024 4:45 AM, Paul wrote:
    On 1/13/2024 6:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance you could post
    the message ID of the one that had the instructions you followed to get yours working?
    It would be much appreciated!

    We have not reduced the answer to this question to a "recipe".

    You could have Bitlocker encryption on the disk drive. While Bitlocker
    is not "supported" on Home, and is supported on Pro, the manage-bde
    utility may be present anyway, to give some information. Some people to
    this day, are blissfully unaware their disk is encrypted. Surprise!

    manage-bde -status

    Early in the thread, we were treated to the support.microsoft.com article.
    I tried to provide a picture of my disk drive, and show
    the commands I would use to fix my specific case. I generally
    do not use crypto, if I can possibly avoid it. (Only my VMWare
    virtual machine with the Win11 in it, is encrypted, as VMWare
    did not offer any options in the matter. Users even told VMWare how
    to do this. Crickets.)

    A typical user might have a UEFI installation on a modern computer, with
    a GPT partitioned disk. The worked example assumes these characteristics.
    I had to "avoid" using my legacy MBR Win10 installation, as it would mislead people a bit. More people could be here on OEM setups, in which case
    the possible disk layouts, crypto situations, just explodes. Thus,
    this example is a very narrow and "best-guess" at what you might find.
    OEM systems will be GPT. A lot of users in the group, might well have selected GPT for the flexibility it offers.

    A couple posters have already recommended waiting until Microsoft fixes this. If you're a multi-booter with *lots* of experience, I think you can handle this,
    but then, you'd be finished by now.

    The standard advice (which I use religiously when standing on a shaky platform),
    is to do a full disk backup before attempting anything like this.

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    # Administrator Command Prompt, or Admin Powershell then type "cmd.exe" as a command

    reagentc /info # shows recovery agent is enabled, and is using Partition 4
    # The article should show what that looks like. A picture would help.
    # If your reagentc is blank or messed up, *stop now*. See example further down,
    # for what one looks like.

    [Picture] This picture shows my disk setup, and makes a reference to the invisible non-partition known as MSR (reserved/junk area)
    Partition 2 can be seen from Linux gparted /dev/sda , if you really want to see the disk layout.
    The disktype.exe utility also shows it, but it's only available via a Cygwin installation.
    I do not really want to lard up this answer with a lot more utility photos. I guess even List Partition
    shows it, come to think of it.

    https://i.postimg.cc/sgXwB389/diskpart-disk-summary.gif

    reagentc /disable # Disable recovery environment agent before making changes

    diskpart.exe # Now, we're doing shrink of C: and regeneration (empty) Recovery partition 4
    list disk
    select disk 0
    list partition
    select partition 3 # will shrink C: now. This could fail, if the $USN journal is right at the end of C: .
    shrink desired=250 minimum=250 # runtime 1 second (*normally* the end of the disk doesn't have a blocker up there)
    select partition 4
    delete partition override # "delete partition" is the command we seek to cowboy at this point
    # This solves the inability to change the origin of a partition in DiskMgmt. Deleting Partition 4

    create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac # The ID is a partition type, it's our Recovery partition.
    gpt attributes =0x8000000000000001 # <=== Protected status of partition. Partitions
    # can be "marked" as "being special" [Attribute]
    # Yes, there are fourteen zeros in that constant.

    format quick fs=ntfs label="Windows RE tools" # Partition 4 is NTFS, and now it has no content. Empty file system.
    # Partition is likely hidden by its ID value. The Windows Update will fill it up.
    exit

    reagentc /enable # Even though Partition 4 is empty, we can still pretend all is well.
    reagentc /info # A sample output is provided, after this line.

    Windows Recovery Environment (Windows RE) and system reset configuration Information:

    Windows RE status: Enabled
    Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE <=== partition pointer remains as before
    Boot Configuration Data (BCD) identifier: 964e2ef1-3a60-11ed-81d3-5cf3707d2fda <=== likely inside ESP Partition 1
    Recovery image location:
    Recovery image index: 0
    Custom image location:
    Custom image index: 0

    Anyway, that was enough operations for me to fix mine. YMMV, OK?

    ... Time passes. Somehow, we encourage '4441 to install. We think
    a new WinRE.wim was installed. How to prove it ?

    To prove '4441 has installed my new WinRE, I used TestDisk version 7.
    Using this is actually too complicated to explain. Which speaks well of the interface.
    Not a problem. We have an alternative.

    [Picture]

    https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif

    The alternative, is more Diskpart. Administrator window of some sort,
    or otherwise, diskpart will elevate itself.

    diskpart.exe
    list disk
    select disk 0
    list partition
    select partition 4 # We're pointed to the 0x27 style hidden Recovery partition now.
    assign letter=K # Temporarily assigning a drive letter, to make partition visibie.
    # Permissions can *still* prevent us from doing stuff. File Manager
    # pointing to K: , is not very helpful right now.

    exit

    In the same administrator window, to prove '4441 is present, now we have access to the partition via the letter K. (The letter K will be removed
    on a reboot. If you want it per-session, you have to do the procedure per-session.) You should see three files with Jan 2024 datestamps or so.
    The slash a h is asking to display all files with a Hidden attribute set.

    dir /ah K:\Recovery\WindowsRE

    So that's about it... for me.

    Paul

    Thanks Paul. Today, I'll check Al's link and use this to try and
    resolve this problem. I'll report back if I have success.


    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to sticks on Sun Jan 14 15:34:08 2024
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands
    and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and
    it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably
    should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any
    chance you could post the message ID of the one that had the
    instructions you followed to get yours working?  It would be much
    appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note: When you get to the part of shrinking the OS by 250M, and the
    shrink fails, then just exit and reagentc /enable.
    No harm done. That was my issue. The os would not shrink, no room at
    the end. I ran Paul's jkdefrag, Mydefrag, and saw the files at the end stopping the shrink. They were the files I could move / delete etc.
    Then I could restart the process.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Big Al on Sun Jan 14 16:17:32 2024
    On 1/14/2024 2:34 PM, Big Al wrote:
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands
    and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update
    and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably
    should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any
    chance you could post the message ID of the one that had the
    instructions you followed to get yours working?  It would be much
    appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note:  When you get to the part of shrinking the OS by 250M, and the
    shrink fails, then just exit and reagentc /enable.
    No harm done.  That was my issue.  The os would not shrink, no room at
    the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at the end stopping the shrink.  They were the files I could move / delete etc.
    Then I could restart the process.

    Fortunately, I had lots of space on that drive and partition and did not
    have this problem.
    I did solve the update problem on this system using Paul's explanation
    of basically the same link Al provided. One of the commands was not
    quite the right syntax, but help provided the full correct one, and it
    worked. Don't know why that was.
    I shrank the C: partition by 1000mb and built a new WinRE partition by
    the same 1000 mb. Now the total of my RE partition is 1527MB or 1.49
    GB. After completing everything on the MS link, I ran updates again and
    it installed immediately. I then did another macrium image and deleted
    the old one. As far as I'm concerned that should be the end of it for now! Checked the wife's laptop and it has a 15G RE partition (don't know why
    it's that big) and had successfully installed the update.
    Checked my newest system that is about 2 years old and has an SSD drive,
    and it hadn't been offered it yet. Upon checking it downloaded it and
    it too failed. Checked the size of the MR partition and it too is only
    about 600MB with less than 80MB free. So, after sending this, it's down
    to that computer to do it all on that one too. At least I'm not so
    intimidated now. Now I am not a total newbie on computers, but
    certainly not a guru of any sorts, but I still can't think of any of the
    people I know who could do this. They wouldn't even try. This all
    doesn't seem acceptable to me.

    Much thanks to everyone, especially Big Al, Paul and Winston!



    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to sticks on Sun Jan 14 18:11:00 2024
    On 1/14/24 05:17 PM, sticks wrote:
    On 1/14/2024 2:34 PM, Big Al wrote:
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands >>>>>> and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update
    and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably >>>>>> should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any
    chance you could post the message ID of the one that had the
    instructions you followed to get yours working?  It would be much
    appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note:  When you get to the part of shrinking the OS by 250M, and the
    shrink fails, then just exit and reagentc /enable.
    No harm done.  That was my issue.  The os would not shrink, no room at
    the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at the
    end stopping the shrink.  They were the files I could move / delete etc.
    Then I could restart the process.

    Fortunately, I had lots of space on that drive and partition and did not
    have this problem.
    I did solve the update problem on this system using Paul's explanation
    of basically the same link Al provided.  One of the commands was not
    quite the right syntax, but help provided the full correct one, and it worked.  Don't know why that was.
    I shrank the C: partition by 1000mb and built a new WinRE partition by
    the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49
    GB.  After completing everything on the MS link, I ran updates again and
    it installed immediately.  I then did another macrium image and deleted
    the old one.  As far as I'm concerned that should be the end of it for now! Checked the wife's laptop and it has a 15G RE partition (don't know why
    it's that big) and had successfully installed the update.
    Checked my newest system that is about 2 years old and has an SSD drive,
    and it hadn't been offered it yet.  Upon checking it downloaded it and
    it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB free.  So, after sending this, it's down
    to that computer to do it all on that one too.  At least I'm not so intimidated now.  Now I am not a total newbie on computers, but
    certainly not a guru of any sorts, but I still can't think of any of the people I know who could do this.  They wouldn't even try.  This all
    doesn't seem acceptable to me.

    Much thanks to everyone, especially Big Al, Paul and Winston!



    I kinda wish I had added 1G to mine rather than 250. I may go back one
    day and up it. Now that I know how.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Big Al on Sun Jan 14 19:04:16 2024
    On 1/14/2024 6:11 PM, Big Al wrote:
    On 1/14/24 05:17 PM, sticks wrote:
    On 1/14/2024 2:34 PM, Big Al wrote:
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance you could post the message ID of the one that had the instructions you followed to get yours working?  It would be much appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note:  When you get to the part of shrinking the OS by 250M, and the shrink fails, then just exit and reagentc /enable.
    No harm done.  That was my issue.  The os would not shrink, no room at the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at the end stopping the shrink.  They were the files I could move / delete etc.
    Then I could restart the process.

    Fortunately, I had lots of space on that drive and partition and did not have this problem.
    I did solve the update problem on this system using Paul's explanation of basically the same link Al provided.  One of the commands was not quite the right syntax, but help provided the full correct one, and it worked.  Don't know why that was.
    I shrank the C: partition by 1000mb and built a new WinRE partition by the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49 GB.  After completing everything on the MS link, I ran updates again and it installed immediately.  I then
    did another macrium image and deleted the old one.  As far as I'm concerned that should be the end of it for now!
    Checked the wife's laptop and it has a 15G RE partition (don't know why it's that big) and had successfully installed the update.
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.  Now I am not a total newbie on computers, but certainly not a guru of any sorts, but I still can't think of any of the
    people I know who could do this.  They wouldn't even try.  This all doesn't seem acceptable to me.

    Much thanks to everyone, especially Big Al, Paul and Winston!



    I kinda wish I had added 1G to mine rather than 250.  I may go back one day and up it.   Now that I know how.

    Since I had one more Patch Tuesday to do, I decided to try using partition tools, rather than diskpart.

    I tried Paragon PM14 Free, and it was leaving little gaps between
    partitions. I fired up Linux gparted, and I was able to shrink C:
    by whatever I wanted, then use gparted to move the Reserved partition
    to the left. Then, resized the Reserved partition (which is a hidden type),
    and it all went fine. This means, I did not actually delete Reserved
    and make a new one. It's the same partition it was before, just resized.

    I did a reagentc /disable, did my partition stuff, then reagentc /enable afterwards. '4441 installed (because at that point, I'd plugged
    the Ethernet cable back in). The contents of Reserved look the same as
    the other Windows 10 ones.

    This is not a major savings by any means, and no simpler. But when it
    comes to shrinking and moving, since Windows is at rest while Linux
    runs, there is hardly any resistance to what you are doing. Maybe
    I didn't really need to disable reagentc, and I could have left it alone.

    This means, when '4441 installs, it would have to remove the old WinRE.wim before installing the new bigger one.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to sticks on Sun Jan 14 20:44:02 2024
    On 1/14/2024 4:17 PM, sticks wrote:
    Checked my newest system that is about 2 years old and has an SSD drive,
    and it hadn't been offered it yet.  Upon checking it downloaded it and
    it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB free.  So, after sending this, it's down
    to that computer to do it all on that one too.  At least I'm not so intimidated now.

    Well that didn't go as easily as I had hoped!
    Once again I followed the directions on the link Big Al gave. The only difference was this system is GPT and not MBR. No problem, directions
    were easy enough. All went fine until the last 2 steps, step 8,
    re-enable WinRE. It couldn't do it. Can't remember the exact wording,
    but it couldn't find the WinRE.wim file. I did find a copy of the file
    on the disk, and tried copying it into C:\windows\system32\recovery but
    that alone did not work. After a little researching, one suggestion was
    that the ReAgent.xml file was somehow corrupted or contained faulty
    information and if the .wim file was there windows would recreate the
    .xml. So I renamed it and went to check.

    reagentc /info still said it was disabled and had no location
    So, I then tried reagentc /enable and it worked.

    Says it is enabled and it created a new xml file.
    Went to windows update and the damn 5034441 is finally installed on all
    the computers here.
    Wow, I sure hope grandma can do this!


    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Paul on Sun Jan 14 22:10:09 2024
    On 1/14/24 07:04 PM, Paul wrote:
    On 1/14/2024 6:11 PM, Big Al wrote:
    On 1/14/24 05:17 PM, sticks wrote:
    On 1/14/2024 2:34 PM, Big Al wrote:
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance you could post the message ID of the one that had the instructions you followed to get yours working?  It would be much appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note:  When you get to the part of shrinking the OS by 250M, and the shrink fails, then just exit and reagentc /enable.
    No harm done.  That was my issue.  The os would not shrink, no room at the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at the end stopping the shrink.  They were the files I could move / delete etc.
    Then I could restart the process.

    Fortunately, I had lots of space on that drive and partition and did not have this problem.
    I did solve the update problem on this system using Paul's explanation of basically the same link Al provided.  One of the commands was not quite the right syntax, but help provided the full correct one, and it worked.  Don't know why that was.
    I shrank the C: partition by 1000mb and built a new WinRE partition by the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49 GB.  After completing everything on the MS link, I ran updates again and it installed immediately.  I then
    did another macrium image and deleted the old one.  As far as I'm concerned that should be the end of it for now!
    Checked the wife's laptop and it has a 15G RE partition (don't know why it's that big) and had successfully installed the update.
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.  Now I am not a total newbie on computers, but certainly not a guru of any sorts, but I still can't think of any of the
    people I know who could do this.  They wouldn't even try.  This all doesn't seem acceptable to me.

    Much thanks to everyone, especially Big Al, Paul and Winston!



    I kinda wish I had added 1G to mine rather than 250.  I may go back one day and up it.   Now that I know how.

    Since I had one more Patch Tuesday to do, I decided to try using partition tools, rather than diskpart.

    I tried Paragon PM14 Free, and it was leaving little gaps between
    partitions. I fired up Linux gparted, and I was able to shrink C:
    by whatever I wanted, then use gparted to move the Reserved partition
    to the left. Then, resized the Reserved partition (which is a hidden type), and it all went fine. This means, I did not actually delete Reserved
    and make a new one. It's the same partition it was before, just resized.

    I did a reagentc /disable, did my partition stuff, then reagentc /enable afterwards. '4441 installed (because at that point, I'd plugged
    the Ethernet cable back in). The contents of Reserved look the same as
    the other Windows 10 ones.

    What "stuff" did you do? If you resized the partition with gparted, I
    would think the job was done.

    This is not a major savings by any means, and no simpler. But when it
    comes to shrinking and moving, since Windows is at rest while Linux
    runs, there is hardly any resistance to what you are doing. Maybe
    I didn't really need to disable reagentc, and I could have left it alone.

    This means, when '4441 installs, it would have to remove the old WinRE.wim before installing the new bigger one.

    Paul

    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to sticks on Mon Jan 15 07:56:23 2024
    On 1/14/2024 9:44 PM, sticks wrote:
    On 1/14/2024 4:17 PM, sticks wrote:
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.

    Well that didn't go as easily as I had hoped!
    Once again I followed the directions on the link Big Al gave.  The only difference was this system is GPT and not MBR.  No problem, directions were easy enough.  All went fine until the last 2 steps, step 8, re-enable WinRE.  It couldn't do it. 
    Can't remember the exact wording, but it couldn't find the WinRE.wim file.  I did find a copy of the file on the disk, and tried copying it into C:\windows\system32\recovery but that alone did not work.  After a little researching, one suggestion was
    that the ReAgent.xml file was somehow corrupted or contained faulty information and if the .wim file was there windows would recreate the .xml.  So I renamed it and went to check.

    reagentc /info still said it was disabled and had no location
    So, I then tried reagentc /enable and it worked.

    Says it is enabled and it created a new xml file.
    Went to windows update and the damn 5034441 is finally installed on all the computers here.
    Wow, I sure hope grandma can do this!

    That Linux Grandma, she gets around. She can bake a
    cake while installing '4441. Fixing Windows Update is
    no harder than making a batch of shortbread cookies.

    One of the steps is to delete the Reserved partition (with Override, to make it possible).

    Creating a new partition and formatting it NTFS, of course that will erase the previous WinRE.wim . And that was one of the concerns I expressed in my first reading of the procedure, is that "reagentc /enable" after all is said and done, the partition is empty, and a routine like that should be sniffing
    for details.

    The real question, is why this was working in the first place. Why
    did "reagentc /enable" work for me ? I don't know the answer to that.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Big Al on Mon Jan 15 07:46:42 2024
    On 1/14/2024 10:10 PM, Big Al wrote:
    On 1/14/24 07:04 PM, Paul wrote:
    On 1/14/2024 6:11 PM, Big Al wrote:
    On 1/14/24 05:17 PM, sticks wrote:
    On 1/14/2024 2:34 PM, Big Al wrote:
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance you could post the message ID of the one that had the instructions you followed to get yours working?  It would be much appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note:  When you get to the part of shrinking the OS by 250M, and the shrink fails, then just exit and reagentc /enable.
    No harm done.  That was my issue.  The os would not shrink, no room at the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at the end stopping the shrink.  They were the files I could move / delete etc.
    Then I could restart the process.

    Fortunately, I had lots of space on that drive and partition and did not have this problem.
    I did solve the update problem on this system using Paul's explanation of basically the same link Al provided.  One of the commands was not quite the right syntax, but help provided the full correct one, and it worked.  Don't know why that was.
    I shrank the C: partition by 1000mb and built a new WinRE partition by the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49 GB.  After completing everything on the MS link, I ran updates again and it installed immediately.  I
    then did another macrium image and deleted the old one.  As far as I'm concerned that should be the end of it for now!
    Checked the wife's laptop and it has a 15G RE partition (don't know why it's that big) and had successfully installed the update.
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.  Now I am not a total newbie on computers, but certainly not a guru of any sorts, but I still can't think of any of the
    people I know who could do this.  They wouldn't even try.  This all doesn't seem acceptable to me.

    Much thanks to everyone, especially Big Al, Paul and Winston!



    I kinda wish I had added 1G to mine rather than 250.  I may go back one day and up it.   Now that I know how.

    Since I had one more Patch Tuesday to do, I decided to try using partition >> tools, rather than diskpart.

    I tried Paragon PM14 Free, and it was leaving little gaps between
    partitions. I fired up Linux gparted, and I was able to shrink C:
    by whatever I wanted, then use gparted to move the Reserved partition
    to the left. Then, resized the Reserved partition (which is a hidden type), >> and it all went fine. This means, I did not actually delete Reserved
    and make a new one. It's the same partition it was before, just resized.

    I did a reagentc /disable, did my partition stuff, then reagentc /enable
    afterwards. '4441 installed (because at that point, I'd plugged
    the Ethernet cable back in). The contents of Reserved look the same as
    the other Windows 10 ones.

    What "stuff" did you do?  If you resized the partition with gparted, I would think the job was done.

    I initially started work with PM14 on Windows, because I wanted to
    see if PM14 could manage to do the whole thing. Cleaning up the
    cosmetic issues on Linux was a bit easier, and I finished the process
    by doing the Reserved origin shift and resize there. I think Paragon
    did not want to resize the Reserved partition, but it allowed the
    origin to move.

    Of the two, the Linux gparted seemed to be the most capable, but
    that's a hard sell for the audience. I was mainly curious to see
    if I could do it, without have to erase the partition, create
    a new one, format it, and so on.

    I would have preferred that Paragon PM14 Free, be a bit more
    cooperative. I believe there is a later free version than 2014. They offer Move/Resize as the only functional thing on their Free version,
    which is better than the vanilla Resize in Disk Management. Some
    OPs on Paragon, require a reboot. It's not "Apple Magical" at all.
    When it is time to reboot, you will be thinking about your
    old Ghost days. But that's the price to pay, for asking it
    to work on data that is "not at rest".

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Paul on Mon Jan 15 08:44:56 2024
    On 1/15/24 07:46 AM, Paul wrote:
    On 1/14/2024 10:10 PM, Big Al wrote:
    On 1/14/24 07:04 PM, Paul wrote:
    On 1/14/2024 6:11 PM, Big Al wrote:
    On 1/14/24 05:17 PM, sticks wrote:
    On 1/14/2024 2:34 PM, Big Al wrote:
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance you could post the message ID of the one that had the instructions you followed to get yours working?  It would be much appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note:  When you get to the part of shrinking the OS by 250M, and the shrink fails, then just exit and reagentc /enable.
    No harm done.  That was my issue.  The os would not shrink, no room at the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at the end stopping the shrink.  They were the files I could move / delete etc.
    Then I could restart the process.

    Fortunately, I had lots of space on that drive and partition and did not have this problem.
    I did solve the update problem on this system using Paul's explanation of basically the same link Al provided.  One of the commands was not quite the right syntax, but help provided the full correct one, and it worked.  Don't know why that was.
    I shrank the C: partition by 1000mb and built a new WinRE partition by the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49 GB.  After completing everything on the MS link, I ran updates again and it installed immediately.  I
    then did another macrium image and deleted the old one.  As far as I'm concerned that should be the end of it for now!
    Checked the wife's laptop and it has a 15G RE partition (don't know why it's that big) and had successfully installed the update.
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than
    80MB free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.  Now I am not a total newbie on computers, but certainly not a guru of any sorts, but I still can't think of any of the
    people I know who could do this.  They wouldn't even try.  This all doesn't seem acceptable to me.

    Much thanks to everyone, especially Big Al, Paul and Winston!



    I kinda wish I had added 1G to mine rather than 250.  I may go back one day and up it.   Now that I know how.

    Since I had one more Patch Tuesday to do, I decided to try using partition >>> tools, rather than diskpart.

    I tried Paragon PM14 Free, and it was leaving little gaps between
    partitions. I fired up Linux gparted, and I was able to shrink C:
    by whatever I wanted, then use gparted to move the Reserved partition
    to the left. Then, resized the Reserved partition (which is a hidden type), >>> and it all went fine. This means, I did not actually delete Reserved
    and make a new one. It's the same partition it was before, just resized. >>>
    I did a reagentc /disable, did my partition stuff, then reagentc /enable >>> afterwards. '4441 installed (because at that point, I'd plugged
    the Ethernet cable back in). The contents of Reserved look the same as
    the other Windows 10 ones.

    What "stuff" did you do?  If you resized the partition with gparted, I would think the job was done.

    I initially started work with PM14 on Windows, because I wanted to
    see if PM14 could manage to do the whole thing. Cleaning up the
    cosmetic issues on Linux was a bit easier, and I finished the process
    by doing the Reserved origin shift and resize there. I think Paragon
    did not want to resize the Reserved partition, but it allowed the
    origin to move.

    Of the two, the Linux gparted seemed to be the most capable, but
    that's a hard sell for the audience. I was mainly curious to see
    if I could do it, without have to erase the partition, create
    a new one, format it, and so on.

    I would have preferred that Paragon PM14 Free, be a bit more
    cooperative. I believe there is a later free version than 2014. They offer Move/Resize as the only functional thing on their Free version,
    which is better than the vanilla Resize in Disk Management. Some
    OPs on Paragon, require a reboot. It's not "Apple Magical" at all.
    When it is time to reboot, you will be thinking about your
    old Ghost days. But that's the price to pay, for asking it
    to work on data that is "not at rest".

    Paul

    Did you ever try mintool partition wizard? https://www.partitionwizard.com/free-partition-manager.html
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Paul on Mon Jan 15 08:48:35 2024
    On 1/15/24 07:56 AM, Paul wrote:
    On 1/14/2024 9:44 PM, sticks wrote:
    On 1/14/2024 4:17 PM, sticks wrote:
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.

    Well that didn't go as easily as I had hoped!
    Once again I followed the directions on the link Big Al gave.  The only difference was this system is GPT and not MBR.  No problem, directions were easy enough.  All went fine until the last 2 steps, step 8, re-enable WinRE.  It couldn't do it. 
    Can't remember the exact wording, but it couldn't find the WinRE.wim file.  I did find a copy of the file on the disk, and tried copying it into C:\windows\system32\recovery but that alone did not work.  After a little researching, one suggestion was
    that the ReAgent.xml file was somehow corrupted or contained faulty information and if the .wim file was there windows would recreate the .xml.  So I renamed it and went to check.

    reagentc /info still said it was disabled and had no location
    So, I then tried reagentc /enable and it worked.

    Says it is enabled and it created a new xml file.
    Went to windows update and the damn 5034441 is finally installed on all the computers here.
    Wow, I sure hope grandma can do this!

    That Linux Grandma, she gets around. She can bake a
    cake while installing '4441. Fixing Windows Update is
    no harder than making a batch of shortbread cookies.

    One of the steps is to delete the Reserved partition (with Override, to make it possible).

    Creating a new partition and formatting it NTFS, of course that will erase the
    previous WinRE.wim . And that was one of the concerns I expressed in my first reading of the procedure, is that "reagentc /enable" after all is said and done, the partition is empty, and a routine like that should be sniffing
    for details.

    The real question, is why this was working in the first place. Why
    did "reagentc /enable" work for me ? I don't know the answer to that.

    Paul
    There's a link to a powershell script, .ps1, that is supposed to fix
    this issue by building the winre.wim outside and then moving it to
    Recovery. I haven't looked at my partition since I fixed it, wonder if
    it's empty.... hmm another day.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to All on Mon Jan 15 08:48:47 2024
    On 1/15/2024 4:03 AM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 1/14/24 3:17 PM:
    On 1/14/2024 2:34 PM, Big Al wrote:
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
    The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I probably should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any chance you could post the message ID of the one that had the instructions you followed to get yours working?  It would be much appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note:  When you get to the part of shrinking the OS by 250M, and the shrink fails, then just exit and reagentc /enable.
    No harm done.  That was my issue.  The os would not shrink, no room at the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at the end stopping the shrink.  They were the files I could move / delete etc.
    Then I could restart the process.

    Fortunately, I had lots of space on that drive and partition and did not have this problem.
    I did solve the update problem on this system using Paul's explanation of basically the same link Al provided.  One of the commands was not quite the right syntax, but help provided the full correct one, and it worked.  Don't know why that was.
    I shrank the C: partition by 1000mb and built a new WinRE partition by the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49 GB.  After completing everything on the MS link, I ran updates again and it installed immediately.  I then
    did another macrium image and deleted the old one.  As far as I'm concerned that should be the end of it for now!
    Checked the wife's laptop and it has a 15G RE partition (don't know why it's that big) and had successfully installed the update.
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.  Now I am not a total newbie on computers, but certainly not a guru of any sorts, but I still can't think of any of the
    people I know who could do this.  They wouldn't even try.  This all doesn't seem acceptable to me.

    Much thanks to everyone, especially Big Al, Paul and Winston!



    The 15 GB RE partition is unlikely the 'Active' WinRE partition.
    OEM' place a recovery partition normally at the end of the disk which is used to restore the device to as-shipped factory condition.
     - the successful update didn't use or touch that 15 GB partition.

    Open a Command prompt with admin privileges
    At the prompt, enter the following then press the return key.
     reagentc /info

    The result will show the real active WinRe partition # and the disk # on which it resides.

     ...w


    And if it said Partition 8 was the active WinRE, you could open Disk Management,
    and all the non-visible partitions use their Partition Number in the Disk Management
    table. You can click an entry at the top, and see it change slightly in the block view. That helps confirm what is what.

    I just use disktype.exe (a Cygwin executable), as a double-click. I've removed most of the boring identifiers and just kept the basics.

    .\disktype /dev/sda <=== being Cygwin, it uses foreign nomenclature, not a problem. This is disk 0.

    --- /dev/sda
    Block device, size 3.639 TiB (4000787030016 bytes)

    Partition 1: "EFI system partition" (FAT32)

    Partition 2: 16 MiB "Microsoft reserved partition" (No FS)

    Partition 3: 118.7 GiB C: "Basic data partition" (NTFS)

    Partition 4: 649 MiB Recovery (NTFS)

    Partition 5: 129.0 GiB H: "Basic data partition" (NTFS)

    Partition 6: 1.001 GiB Recovery (NTFS)

    Partition 7: 682.0 GiB S: "Basic data partition" (NTFS)

    That's how I can double check what partitions are there, is disktype.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rsutton@21:1/5 to Paul on Mon Jan 15 10:37:32 2024
    On 1/15/2024 7:56 AM, Paul wrote:
    On 1/14/2024 9:44 PM, sticks wrote:
    On 1/14/2024 4:17 PM, sticks wrote:
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.

    Well that didn't go as easily as I had hoped!
    Once again I followed the directions on the link Big Al gave.  The only difference was this system is GPT and not MBR.  No problem, directions were easy enough.  All went fine until the last 2 steps, step 8, re-enable WinRE.  It couldn't do it. 
    Can't remember the exact wording, but it couldn't find the WinRE.wim file.  I did find a copy of the file on the disk, and tried copying it into C:\windows\system32\recovery but that alone did not work.  After a little researching, one suggestion was
    that the ReAgent.xml file was somehow corrupted or contained faulty information and if the .wim file was there windows would recreate the .xml.  So I renamed it and went to check.

    reagentc /info still said it was disabled and had no location
    So, I then tried reagentc /enable and it worked.

    Says it is enabled and it created a new xml file.
    Went to windows update and the damn 5034441 is finally installed on all the computers here.
    Wow, I sure hope grandma can do this!

    That Linux Grandma, she gets around. She can bake a
    cake while installing '4441. Fixing Windows Update is
    no harder than making a batch of shortbread cookies.

    One of the steps is to delete the Reserved partition (with Override, to make it possible).

    Creating a new partition and formatting it NTFS, of course that will erase the
    previous WinRE.wim . And that was one of the concerns I expressed in my first reading of the procedure, is that "reagentc /enable" after all is said and done, the partition is empty, and a routine like that should be sniffing
    for details.

    The real question, is why this was working in the first place. Why
    did "reagentc /enable" work for me ? I don't know the answer to that.

    Paul
    Having followed up on the KB5034441 not installing, I did the steps to
    delete and re-add a larger partition and made it ntfs, etc. Now, the KB installed successfully, but the (in my case partition 4 ) is empty! I
    thought the KB would refill it during installation. Suggestions?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Big Al on Mon Jan 15 12:07:13 2024
    On 1/15/2024 8:48 AM, Big Al wrote:
    On 1/15/24 07:56 AM, Paul wrote:
    On 1/14/2024 9:44 PM, sticks wrote:
    On 1/14/2024 4:17 PM, sticks wrote:
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.

    Well that didn't go as easily as I had hoped!
    Once again I followed the directions on the link Big Al gave.  The only difference was this system is GPT and not MBR.  No problem, directions were easy enough.  All went fine until the last 2 steps, step 8, re-enable WinRE.  It couldn't do it. 
    Can't remember the exact wording, but it couldn't find the WinRE.wim file.  I did find a copy of the file on the disk, and tried copying it into C:\windows\system32\recovery but that alone did not work.  After a little researching, one suggestion was
    that the ReAgent.xml file was somehow corrupted or contained faulty information and if the .wim file was there windows would recreate the .xml.  So I renamed it and went to check.

    reagentc /info still said it was disabled and had no location
    So, I then tried reagentc /enable and it worked.

    Says it is enabled and it created a new xml file.
    Went to windows update and the damn 5034441 is finally installed on all the computers here.
    Wow, I sure hope grandma can do this!

    That Linux Grandma, she gets around. She can bake a
    cake while installing '4441. Fixing Windows Update is
    no harder than making a batch of shortbread cookies.

    One of the steps is to delete the Reserved partition (with Override, to make it possible).

    Creating a new partition and formatting it NTFS, of course that will erase the
    previous WinRE.wim . And that was one of the concerns I expressed in my first
    reading of the procedure, is that "reagentc /enable" after all is said and >> done, the partition is empty, and a routine like that should be sniffing
    for details.

    The real question, is why this was working in the first place. Why
    did "reagentc /enable" work for me ? I don't know the answer to that.

        Paul
    There's a link to a powershell script, .ps1, that is supposed to fix this issue by building the winre.wim outside and then moving it to Recovery.  I haven't looked at my partition since I fixed it, wonder if it's empty.... hmm another day.

    Remember, it's easy to get in there. As Admin

    diskpart
    list disk
    select disk 0
    list partition
    select partition 4
    assign letter=K # Temporary assignment of a letter, to a hidden partition
    exit.

    Now, in an administrator window

    dir /ah K:\Recovery\WindowsRE

    The permissions are set, to thwart normal access, so this
    should not be easy. This is why I use TestDisk 7.0 for
    taking screen shots of "success".

    The letter K: will be de-asserted on a reboot.
    Assigning a letter like this, gives limited access
    to a thing. Disk Management, for example, may not
    display the letter K: while you are successfully doing
    a dir on the thing :-)

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Hall@21:1/5 to rsutton43@comcast.net on Mon Jan 15 16:55:26 2024
    In message <uo3jfs$vm9h$1@dont-email.me>, rsutton
    <rsutton43@comcast.net> writes
    Having followed up on the KB5034441 not installing, I did the steps to
    delete and re-add a larger partition and made it ntfs, etc. Now, the KB >installed successfully, but the (in my case partition 4 ) is empty! I
    thought the KB would refill it during installation. Suggestions?

    Maybe MS have now edited the KB so that it instals somewhere else? That
    seems like a sensible thing to do if they knew that for many people it
    wouldn't fit where they were originally trying to instal it.
    --
    John Hall
    "Acting is merely the art of keeping a large group of people
    from coughing."
    Sir Ralph Richardson (1902-83)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bill Bradshaw@21:1/5 to Ant on Mon Jan 15 08:39:17 2024
    Ant wrote:
    Others' (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download
    error - 0x80070643" with "2024-01 Security Update for Windows 10
    Version 22H2 for x64-based Systems (KB5034441)" in 64-bit W10 Pro.
    right now. I already rebooted once from other today's updates:

    I am at version 10.0.19045.3930 on all my computers. Is that where I should be?
    --
    <Bill>

    Brought to you from Anchorage, Alaska

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to rsutton on Mon Jan 15 13:08:41 2024
    On 1/15/2024 10:37 AM, rsutton wrote:
    On 1/15/2024 7:56 AM, Paul wrote:
    On 1/14/2024 9:44 PM, sticks wrote:
    On 1/14/2024 4:17 PM, sticks wrote:
    Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB
    free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.

    Well that didn't go as easily as I had hoped!
    Once again I followed the directions on the link Big Al gave.  The only difference was this system is GPT and not MBR.  No problem, directions were easy enough.  All went fine until the last 2 steps, step 8, re-enable WinRE.  It couldn't do it. 
    Can't remember the exact wording, but it couldn't find the WinRE.wim file.  I did find a copy of the file on the disk, and tried copying it into C:\windows\system32\recovery but that alone did not work.  After a little researching, one suggestion was
    that the ReAgent.xml file was somehow corrupted or contained faulty information and if the .wim file was there windows would recreate the .xml.  So I renamed it and went to check.

    reagentc /info still said it was disabled and had no location
    So, I then tried reagentc /enable and it worked.

    Says it is enabled and it created a new xml file.
    Went to windows update and the damn 5034441 is finally installed on all the computers here.
    Wow, I sure hope grandma can do this!

    That Linux Grandma, she gets around. She can bake a
    cake while installing '4441. Fixing Windows Update is
    no harder than making a batch of shortbread cookies.

    One of the steps is to delete the Reserved partition (with Override, to make it possible).

    Creating a new partition and formatting it NTFS, of course that will erase the
    previous WinRE.wim . And that was one of the concerns I expressed in my first
    reading of the procedure, is that "reagentc /enable" after all is said and >> done, the partition is empty, and a routine like that should be sniffing
    for details.

    The real question, is why this was working in the first place. Why
    did "reagentc /enable" work for me ? I don't know the answer to that.

        Paul
    Having followed up on the KB5034441 not installing, I did the steps to delete and re-add a larger partition and made it ntfs, etc. Now, the KB installed successfully, but the (in my case partition 4 ) is empty! I thought the KB would refill it during
    installation.  Suggestions?

    Follow procedure for uninstallation of Patch Tuesday stuff.

    The LCU section of the file tree, contains some amount of recent patches.
    But the "C" stands for Cumulative, and a Security Update would not be there.

    *******

    There is likely more than one way to remove it.

    https://www.tenforums.com/tutorials/5472-view-windows-update-history-windows-10-a.html

    But then, I can't secure a .msu for replacement.

    KB5034441 Well, this isn't working for me...

    https://www.catalog.update.microsoft.com/Search.aspx?q=5034441

    And searches like this, prove Catalog is running, just not doing what I want.
    I see "Cumulatives" but no "Security" ones

    https://www.catalog.update.microsoft.com/Search.aspx?q=security+update+windows+10++2024-01

    If I look in the Uninstall list, 4122 (a previous security) is listed as a Cumulative
    on the Catalog site. You can't win, apparently. You can find this one. Just not stock up
    on a spare 4441. They could have pulled it I suppose.

    https://www.catalog.update.microsoft.com/Search.aspx?q=KB5034122

    *******

    To check for presence (that you got a new WinRE.wim) .

    As Admin

    diskpart
    list disk
    select disk 0
    list partition
    select partition 4 # This should be the Recovery partition you made. Recall what partition number that was.
    assign letter=K # Temporary assignment of a letter, to a hidden partition. Remove access, via a reboot.
    exit

    Now, in the administrator window

    dir /ah K:\Recovery\WindowsRE

    That should list a WinRE.wim with a Jan2024 date stamp on it.

    The permissions are set, to thwart normal access, so this
    should not be easy. This is why I use TestDisk 7.0 for
    taking screen shots of "success".

    The letter K: will be de-asserted on a reboot.

    *******

    While '4441 is running, you will notice WinREUpdateInstaller.exe running
    in Task Manager.

    That's evidence the attempt to replace winRE.wim is in motion.
    The procedure is not entirely cloaked in PendMoves or the like.
    It has a visible component, that tells you the update is in motion.

    The only reason I can remember the name of the thing, is I have a Procmon
    trace of the '4441 running. It builds a file in

    C:\Windows\Temp
    C:\$WinREAgent\Scratch\update.wim 525,---,---
    C:\$WinREAgent\Scratch\exported.wim 495,---,---

    ( C:\Windows\Logs\CBS\CBS.log
    C:\Windows\Logs\WinREAgent\setupact.log )

    That's a few breadcrumbs. I can't see it writing to Recovery itself.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Big Al on Mon Jan 15 13:16:46 2024
    On 1/15/2024 8:44 AM, Big Al wrote:

    Did you ever try mintool partition wizard? https://www.partitionwizard.com/free-partition-manager.html

    No, like backup tools, these things require a lot of careful
    test, before you trust them.

    Take gparted as a example. I fed it an Apple Mac disk drive,
    from my mac G4. "Oh yes" it said, "I grok this format".

    I tried to make some change to the disk. gparted
    absolutely destroyed it. I had a backup :-) I was
    expecting trouble. What was interesting, is the damage
    had no pattern to it. It was like a chainsaw was engaged.
    You would think with a series of similar partitions,
    the damage done on each would be similar. But it was not.

    But that's how things go with software, and why
    when offered a new item, you think about how many
    test bench items you might need.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Bill Bradshaw on Mon Jan 15 13:54:04 2024
    On 1/15/2024 12:39 PM, Bill Bradshaw wrote:
    Ant wrote:
    Others'
    (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download
    error - 0x80070643" with "2024-01 Security Update for Windows 10
    Version 22H2 for x64-based Systems (KB5034441)" in 64-bit W10 Pro.
    right now. I already rebooted once from other today's updates:

    I am at version 10.0.19045.3930 on all my computers. Is that where I should be?


    Yes. Matches the number on my odometer.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Char Jackson@21:1/5 to Paul on Mon Jan 15 13:36:07 2024
    On Mon, 15 Jan 2024 13:16:46 -0500, Paul <nospam@needed.invalid> wrote:

    On 1/15/2024 8:44 AM, Big Al wrote:

    Did you ever try mintool partition wizard?
    https://www.partitionwizard.com/free-partition-manager.html

    No, like backup tools, these things require a lot of careful
    test, before you trust them.

    I would have agreed with you on that point until about 1994. Not so much these days. The last 30 years have shown us that partitions (and partition managers) aren't the magical mysterious things that they used to be.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From WolfFan@21:1/5 to Ant on Mon Jan 15 15:11:07 2024
    On Jan 9, 2024, Ant wrote
    (in article<jOycnT_9xr1ACQD4nZ2dnZfqn_SdnZ2d@earthlink.com>):

    Others' (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_januar
    y_9th_2024/kh32u6f/)
    and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
    "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
    64-bit W10 Pro. right now. I already rebooted once from other today's updates:

    1. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034275-cumulati
    ve-update-for-net-framework-3-5-4-8-and-4-8-1-for-windows-10-version-22h2-6c9a
    603c-f0a1-4b32-b7fa-a1c6337523f1
    2. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034122-os-build
    s-19044-3930-and-19045-3930-7656c6a4-0b06-4424-86a9-d0719f4ac252

    I read https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-environme
    nt-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4f
    ee-a02a-2fdea17075a8
    's known issue about small WinRE partition with a https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-r
    esize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c82
    29763bf
    link.

    Couldn't MS do this to its users automatically without having to do it manually for
    non-technical users? :/

    Yes, they could, but where’s the fun in that?

    Ah, well... I usually back up my home Windows boxes internal boot volumes to external media twice a year, on the 1st Jan and 1st July. (A full backup, everything. Note that the data ain’t on the boot volume, it’s on assorted network thingies, and yes, there’s a separate backup process for the data.)
    I then restore the backup to a different volume. I let the backup/restore app (Macrium or Acronis, most definitately NOT anything from MS) do the
    partitions. I now have three identical boot volumes. I set the backup
    software to do incremental backups to one of the full backup volumes, the
    other is disconnected and sitting in a fire-resistant file cabinet, and
    ignore it for the next six months.

    If I encountered this problem, (which I haven’t, it appears that my
    recovery partitions are big enough, thank you Acronis, if only MS had some Tuetonic thoroughness) I would wipe the volume, repartition it, and restore from backup. Nuke and pave usually works. There’s a reason why I have backups.

    Of course, I can do this because I have backups, and spare volumes, and good software (i.e., not MS backup software. The backup paret of MS’s junk now saeems to work; the restore part, now, the restore part started out pretty
    bad and up to the last time that I tried it got worse.) Those who don’t
    have backups...

    WinBoxes at work have good backups, too.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to All on Mon Jan 15 20:03:06 2024
    On 1/15/2024 2:40 PM, ...w¡ñ§±¤ñ wrote:
    Paul wrote on 1/14/24 5:04 PM:

    This means, when '4441 installs, it would have to remove the old WinRE.wim >> before installing the new bigger one.

        Paul


    Windows keeps a log file when the 'reagentc /disable' command is done.
     The logfile's location and name
      C:\Windows\Logs\ReAgent
       ReAgent.log


    If the system is operating under design-intent, when the above command is executed, the winre.wim file is moved from the active recovery partition to the C:\WINDOWS\system32\Recovery\ folder

    [ReAgentc.exe] -----Executing command line: reagentc  /disable----- [ReAgentc.exe] ------------------------------------------------------ [ReAgentc.exe] Update enhanced config info is enabled.
    [ReAgentc.exe] WinRE is installed
    [ReAgentc.exe] winreCopyWIMBack moved WIM file from \\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\ to C:\WINDOWS\system32\Recovery\Winre.wim successfully!


    This move ensures that the fix which disables, deletes the Recovery partition, shrinks the o/s to create more space for a larger Recovery partition has the ability when reagentc /enable is executed to move the winre.wim from C: back to the Recovery
    partition.
     - i.e. if not moved, then the winre.wim file would need to be recovered from media or an ISO.

    The same logfile when reagentc /enable is run after resizing(enlarging) the Recovery partition will show the moving of winre.wim back from ...\system32\Recovery to the Recovery partition.

    But I thought that was why it was creating all those duff
    Recovery partitions. So that, on a Rollback, it could just
    point at the known-good Recovery partition.

    Although Win11 has only had one upgrade to date, that
    did not seem to create yet-another Recovery partition.
    Maybe the behavior changed at some point

    Paul


    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Char Jackson on Mon Jan 15 19:58:53 2024
    On 1/15/2024 2:36 PM, Char Jackson wrote:
    On Mon, 15 Jan 2024 13:16:46 -0500, Paul <nospam@needed.invalid> wrote:

    On 1/15/2024 8:44 AM, Big Al wrote:

    Did you ever try mintool partition wizard?
    https://www.partitionwizard.com/free-partition-manager.html

    No, like backup tools, these things require a lot of careful
    test, before you trust them.

    I would have agreed with you on that point until about 1994. Not so much these
    days. The last 30 years have shown us that partitions (and partition managers)
    aren't the magical mysterious things that they used to be.


    Lets see. Acronis Partition Manager. Few of the routines are
    particularly unique. I spot the "cluster size changer" module
    in my new purchase. Now, knowing that a function like this is
    "very risky", I'm armed with a backup. I push the button.
    The churning stops. OK, it says it is done. I start looking
    around. I'm in System32, and I see "gee, I never knew Microsoft
    put zero sized files in System32". A bit more checking, a number
    of files have zero size. If it was a pinball machine, we would
    be making the "tilt" sound effect about now.

    The thing that makes quality software, is a healthy sense of
    paranoia. It's got nothing to do with our knowledge of the topic.
    And everything to do with how thorough we can be. That's why
    so many of the steps in partition management, are "unnecessary ones".
    They are part of a defensive strategy against bad software, as
    much as anything else.

    For starters, you do CHKDSK before an operation, and CHKDSK
    after an operation (some softwares, have their own checking or
    consistency routines). You should not have changed the health
    status of a partition, by your actions. And not doing CHKDSK,
    is why technically perfect code, used to corrupt partitions.
    It was because the partition was corrupted before the
    partition manager was used, and the partition manager was
    the fall guy. Even though CHKDSK has nothing to do with
    resizing a partition, we do it anyway, as part of that
    sense of paranoia.

    Some tools, even have a "simulate" phase before the "do-it"
    phase. Some problems can be detected while simulating a change.

    The author of gparted, rewrote his code. The first version was
    finished, but it had added a lot of whizzy features. And just the
    risk level associated with this, was too much for its author.
    The code was rewritten, and only the "solid" features were
    allowed in. and that's what experience teaches you. It's
    the paranoia we learned, that made the difference.

    You learn how to write the software, while smashing one
    partition at a time.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Char Jackson@21:1/5 to Paul on Tue Jan 16 16:20:30 2024
    On Mon, 15 Jan 2024 19:58:53 -0500, Paul <nospam@needed.invalid> wrote:

    On 1/15/2024 2:36 PM, Char Jackson wrote:
    On Mon, 15 Jan 2024 13:16:46 -0500, Paul <nospam@needed.invalid> wrote:

    On 1/15/2024 8:44 AM, Big Al wrote:

    Did you ever try mintool partition wizard?
    https://www.partitionwizard.com/free-partition-manager.html

    No, like backup tools, these things require a lot of careful
    test, before you trust them.

    I would have agreed with you on that point until about 1994. Not so much these
    days. The last 30 years have shown us that partitions (and partition managers)
    aren't the magical mysterious things that they used to be.


    Lets see. Acronis Partition Manager. Few of the routines are
    particularly unique. I spot the "cluster size changer" module
    in my new purchase. Now, knowing that a function like this is
    "very risky", I'm armed with a backup. I push the button.
    The churning stops. OK, it says it is done. I start looking
    around. I'm in System32, and I see "gee, I never knew Microsoft
    put zero sized files in System32". A bit more checking, a number
    of files have zero size. If it was a pinball machine, we would
    be making the "tilt" sound effect about now.

    I used to be paranoid about working with partitions too, but 30 years and at least several hundred operations without any issues that I can remember have changed that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Char Jackson on Tue Jan 16 17:45:00 2024
    On 1/16/2024 5:20 PM, Char Jackson wrote:
    On Mon, 15 Jan 2024 19:58:53 -0500, Paul <nospam@needed.invalid> wrote:

    On 1/15/2024 2:36 PM, Char Jackson wrote:
    On Mon, 15 Jan 2024 13:16:46 -0500, Paul <nospam@needed.invalid> wrote:

    On 1/15/2024 8:44 AM, Big Al wrote:

    Did you ever try mintool partition wizard?
    https://www.partitionwizard.com/free-partition-manager.html

    No, like backup tools, these things require a lot of careful
    test, before you trust them.

    I would have agreed with you on that point until about 1994. Not so much these
    days. The last 30 years have shown us that partitions (and partition managers)
    aren't the magical mysterious things that they used to be.


    Lets see. Acronis Partition Manager. Few of the routines are
    particularly unique. I spot the "cluster size changer" module
    in my new purchase. Now, knowing that a function like this is
    "very risky", I'm armed with a backup. I push the button.
    The churning stops. OK, it says it is done. I start looking
    around. I'm in System32, and I see "gee, I never knew Microsoft
    put zero sized files in System32". A bit more checking, a number
    of files have zero size. If it was a pinball machine, we would
    be making the "tilt" sound effect about now.

    I used to be paranoid about working with partitions too, but 30 years and at least several hundred operations without any issues that I can remember have changed that.


    At the current time, one of the reasons for that, is background
    integrity checking by the OS. But because that's not documented,
    we have no way of knowing how good a job of latent faults that does.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Wed Jan 17 15:41:13 2024
    On 1/15/2024 3:03 AM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 1/14/24 3:17 PM:
    On 1/14/2024 2:34 PM, Big Al wrote:
    On 1/14/24 09:12 AM, sticks wrote:
    On 1/14/2024 7:25 AM, Big Al wrote:
    On 1/13/24 06:25 PM, sticks wrote:
    On 1/13/2024 4:17 PM, Big Al wrote:

    I deleted all of them then went back and ran those manual
    commands and I was able now to expand the partition by that 250M. >>>>>>> The rest of the commands succeeded and then I ran Windows Update >>>>>>> and it succeeded also.

    So I'm happy that my system has a larger Recovery now.  I
    probably should have shoved it 500M, but... It's at 881M now.

    I have to admit, I'm thoroughly confused now.
    I have a bunch of messages in this thread saved, but is there any
    chance you could post the message ID of the one that had the
    instructions you followed to get yours working?  It would be much >>>>>> appreciated!

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

    Thanks AL!

    Note:  When you get to the part of shrinking the OS by 250M, and the
    shrink fails, then just exit and reagentc /enable.
    No harm done.  That was my issue.  The os would not shrink, no room
    at the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at
    the end stopping the shrink.  They were the files I could move /
    delete etc.
    Then I could restart the process.

    Fortunately, I had lots of space on that drive and partition and did
    not have this problem.
    I did solve the update problem on this system using Paul's explanation
    of basically the same link Al provided.  One of the commands was not
    quite the right syntax, but help provided the full correct one, and it
    worked. Don't know why that was.
    I shrank the C: partition by 1000mb and built a new WinRE partition by
    the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49
    GB.  After completing everything on the MS link, I ran updates again
    and it installed immediately.  I then did another macrium image and
    deleted the old one.  As far as I'm concerned that should be the end
    of it for now!
    Checked the wife's laptop and it has a 15G RE partition (don't know
    why it's that big) and had successfully installed the update.
    Checked my newest system that is about 2 years old and has an SSD
    drive, and it hadn't been offered it yet.  Upon checking it downloaded
    it and it too failed.  Checked the size of the MR partition and it too
    is only about 600MB with less than 80MB free.  So, after sending this,
    it's down to that computer to do it all on that one too.  At least I'm
    not so intimidated now.  Now I am not a total newbie on computers, but
    certainly not a guru of any sorts, but I still can't think of any of
    the people I know who could do this.  They wouldn't even try.  This
    all doesn't seem acceptable to me.

    Much thanks to everyone, especially Big Al, Paul and Winston!



    The 15 GB RE partition is unlikely the 'Active' WinRE partition.
    OEM' place a recovery partition normally at the end of the disk which is
    used to restore the device to as-shipped factory condition.
     - the successful update didn't use or touch that 15 GB partition.

    Open a Command prompt with admin privileges
    At the prompt, enter the following then press the return key.
     reagentc /info

    The result will show the real active WinRe partition # and the disk # on which it resides.


    It looks like it indeed is on partition 1, which is the 15 GB partition.

    <https://www.dropbox.com/scl/fi/v9mizojxmnb0dxq79sf4h/Recovery-Partition.jpg?rlkey=75nq7il3z7ig8y77y89jfd74u&dl=0>

    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to All on Thu Jan 18 08:03:33 2024
    On 1/17/24 10:48 PM, ...w¡ñ§±¤ñ wrote:
    <snip>

    reset-to-factory-condition Recovery partition(which also includes the
    WinRE partition) at the beginning of the disk.
    - This device could also be a pre-Win10 device(originally built with Win
    7, or 8x). Many of those pre-Win10 devices were built like this by the
    OEM's.

    MBR guidelines for partitioning are shown in this MSFT article <https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions?>



    Interesting that the article says the system will grow the WinRE
    partition as needed and take from the Windows partition. Contrary to
    the 4441 update that won't grow the partition. Seems one hand isn't
    following the other at Microsoft.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Big Al on Thu Jan 18 12:55:36 2024
    On 1/18/2024 8:03 AM, Big Al wrote:
    On 1/17/24 10:48 PM, ...w¡ñ§±¤ñ wrote:
    <snip>

    reset-to-factory-condition Recovery partition(which also includes the WinRE partition) at the beginning of the disk.
    - This device could also be a pre-Win10 device(originally built with Win 7, or 8x). Many of those pre-Win10 devices were built like this by the OEM's.

    MBR guidelines for partitioning are shown in this MSFT article
    <https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions?>



    Interesting that the article says the system will grow the WinRE partition as needed and take from the Windows partition.   Contrary to the 4441 update that won't grow the partition.   Seems one hand isn't following the other at Microsoft.

    There's a subtle distinction there. The previously seen mechanism, works like this.
    I don't really think of this as "growing a partition", rather "creating
    a new partition which is a bit bigger".

    +-----+----------------------------------+----------+
    | MBR | Win10 C: | Recovery | +-----+----------------------------------+----------+

    +-----+-----------------------+ - - - - -+----------+
    | MBR | Win10 C: (shrink) | | Recovery | +-----+-----------------------+ - - - - -+----------+

    +-----+-----------------------+----------+----------+
    | MBR | Win10 C: (shrink) | Recovery | Recovery | +-----+-----------------------+----------+----------+
    ^ ^ ^ ^ No longer
    WinRE.wim needed

    Microsoft doesn't know how to do the following. They refuse to
    "dd" the partition to change the origin. Then expand it.
    It should be quite safe, since the partition has no
    drive letter typically and is not being accessed except
    by their own code. You could move the partition by
    block transfer, then do an expand to make it the desired
    1GB or whatever. (shrink C: , move Recovery left, expand Recovery)

    +-----+-------------------------------+-------------+
    | MBR | Win10 C: | Recovery1GB | +-----+-------------------------------+-------------+

    When I did that from Linux, gparted chose to move that
    partition using "dd" (to the left), rather than another method.
    After it was moved to the left, I did a resize in gparted,
    to finish the operation. I did not select move/resize and
    do both in the same operation. But I could have done it
    that way.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to Paul on Thu Jan 18 14:11:10 2024
    On 1/18/24 12:55 PM, Paul wrote:
    On 1/18/2024 8:03 AM, Big Al wrote:
    On 1/17/24 10:48 PM, ...w¡ñ§±¤ñ wrote:
    <snip>

    reset-to-factory-condition Recovery partition(which also includes the WinRE partition) at the beginning of the disk.
    - This device could also be a pre-Win10 device(originally built with Win 7, or 8x). Many of those pre-Win10 devices were built like this by the OEM's.

    MBR guidelines for partitioning are shown in this MSFT article
    <https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions?>



    Interesting that the article says the system will grow the WinRE partition as needed and take from the Windows partition.   Contrary to the 4441 update that won't grow the partition.   Seems one hand isn't following the other at Microsoft.

    There's a subtle distinction there. The previously seen mechanism, works like this.
    I don't really think of this as "growing a partition", rather "creating
    a new partition which is a bit bigger".

    +-----+----------------------------------+----------+
    | MBR | Win10 C: | Recovery | +-----+----------------------------------+----------+

    +-----+-----------------------+ - - - - -+----------+
    | MBR | Win10 C: (shrink) | | Recovery | +-----+-----------------------+ - - - - -+----------+

    +-----+-----------------------+----------+----------+
    | MBR | Win10 C: (shrink) | Recovery | Recovery | +-----+-----------------------+----------+----------+
    ^ ^ ^ ^ No longer
    WinRE.wim needed

    Microsoft doesn't know how to do the following. They refuse to
    "dd" the partition to change the origin. Then expand it.
    It should be quite safe, since the partition has no
    drive letter typically and is not being accessed except
    by their own code. You could move the partition by
    block transfer, then do an expand to make it the desired
    1GB or whatever. (shrink C: , move Recovery left, expand Recovery)

    +-----+-------------------------------+-------------+
    | MBR | Win10 C: | Recovery1GB | +-----+-------------------------------+-------------+

    When I did that from Linux, gparted chose to move that
    partition using "dd" (to the left), rather than another method.
    After it was moved to the left, I did a resize in gparted,
    to finish the operation. I did not select move/resize and
    do both in the same operation. But I could have done it
    that way.

    Paul
    Yes, I don't like doing 6 operations at once.
    I do them 1 at a time. If one fails I don't want to build upon a
    failure. Just dang common sense to me.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Big Al@21:1/5 to All on Thu Jan 18 17:34:17 2024
    On 1/18/24 04:40 PM, ...w¡ñ§±¤ñ wrote:
     - In this latest case, patching for security and updating Win10
    including its WinRE partitoin, there is insuffficient space to
    start/finish the process(install the update, shrink Winodws(C:), update
    WinRE partition files. Additionally, the part of the process that
    shrinks the Windows partition may fall because, system files(e.g. System Restore Points or other Windows protected files) reside on the end of
    the Windows partition) prevent the shrinking.

    I was going to ask till I got to the bottom of your reply.
    The above was my problem, I may have had space but C: had files at the
    end of the partition. So I was probably fighting 2 issues.

    I manually fixed them both and the update went smooth.
    --
    Linux Mint 21.2 Cinnamon
    Al

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ant@21:1/5 to All on Tue Feb 13 20:00:41 2024
    I still see this and no fix with today's automatic monthly updates. It
    still has the manual technical script instructions to fix it. :(
    --
    "[The Lord declares,] 'Rend your heart and not your garments. Return to the Lord your God, for he is gracious and compassionate, slow to anger and abounding in love, and he relents from sending calamity.'" --Joel 2:13! :) <3's Day eve & (L/C)NY (wood
    dragon).
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Ant on Tue Feb 13 15:10:03 2024
    On 2/13/2024 2:00 PM, Ant wrote:
    I still see this and no fix with today's automatic monthly updates. It
    still has the manual technical script instructions to fix it.

    I've seen you post on this several times. At this point, it's probably
    not going to fix it unless YOU try something. Have you tried following
    the instructions, making your windows partition smaller, and increasing
    the sizer of your ReAgent partition bigger?

    Winston, Paul, and others have been very helpful in assisting me fix
    this issue on several systems. In the message below, Winston details
    removing restore points because of the location they get put on the
    disk. Perhaps that might help you.

    Message ID:
    news://news.eternal-september.org:119/uq1o6i$1ra1s$1@dont-email.me


    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ant@21:1/5 to sticks on Tue Feb 13 21:28:05 2024
    sticks <wolverine01@charter.net> wrote:
    On 2/13/2024 2:00 PM, Ant wrote:
    I still see this and no fix with today's automatic monthly updates. It still has the manual technical script instructions to fix it.

    I've seen you post on this several times. At this point, it's probably
    not going to fix it unless YOU try something. Have you tried following
    the instructions, making your windows partition smaller, and increasing
    the sizer of your ReAgent partition bigger?

    Winston, Paul, and others have been very helpful in assisting me fix
    this issue on several systems. In the message below, Winston details
    removing restore points because of the location they get put on the
    disk. Perhaps that might help you.

    Message ID: news://news.eternal-september.org:119/uq1o6i$1ra1s$1@dont-email.me

    Try telling non-technical users like elders. :P
    --
    "[The Lord declares,] 'Rend your heart and not your garments. Return to the Lord your God, for he is gracious and compassionate, slow to anger and abounding in love, and he relents from sending calamity.'" --Joel 2:13! :) <3's Day eve & (L/C)NY (wood
    dragon).
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Ant on Tue Feb 13 18:00:51 2024
    On 2/13/2024 3:28 PM, Ant wrote:
    sticks <wolverine01@charter.net> wrote:
    On 2/13/2024 2:00 PM, Ant wrote:
    I still see this and no fix with today's automatic monthly updates. It
    still has the manual technical script instructions to fix it.

    I've seen you post on this several times. At this point, it's probably
    not going to fix it unless YOU try something. Have you tried following
    the instructions, making your windows partition smaller, and increasing
    the sizer of your ReAgent partition bigger?

    Winston, Paul, and others have been very helpful in assisting me fix
    this issue on several systems. In the message below, Winston details
    removing restore points because of the location they get put on the
    disk. Perhaps that might help you.

    Message ID:
    news://news.eternal-september.org:119/uq1o6i$1ra1s$1@dont-email.me

    Try telling non-technical users like elders. :P

    Did you even look at his post?

    I think these, the relative points, are something most people could do.

    ---
    - I deleted all System Restore Points
    - Disabled System Restore for the C: drive(it was not enabled for other
    drives either)
    - Used Windows Disk Cleanup in admin mode to remove everything it showed
    as removable(i.e. - all boxes were checked before running) - took about
    15 min on that 8 yr old device(Intel Atom chip and 4 GB RAM, 128 GB disk storage), and WinRE partition had sufficient free space to handle the
    Recovery partition updating).
    - Turned off Windows Update option 'Receive updates from other Microsoft products
    ---

    You just take it slowly and get it done. Same goes for the "technical
    script", as you call it. I am far from a expert on any of this stuff,
    but I am willing to try what these guys suggest. Sometimes it's over my
    head, sometimes I jump in the water and get all wet. But if you don't
    try, well......


    --
    Stand With Israel!
    NOTE: If you use Google Groups I don't see you,
    unless you're whitelisted and that's doubtful.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet
  • From Paul@21:1/5 to Ant on Wed Feb 14 02:05:56 2024
    On 2/13/2024 4:28 PM, Ant wrote:
    sticks <wolverine01@charter.net> wrote:
    On 2/13/2024 2:00 PM, Ant wrote:
    I still see this and no fix with today's automatic monthly updates. It
    still has the manual technical script instructions to fix it.

    I've seen you post on this several times. At this point, it's probably
    not going to fix it unless YOU try something. Have you tried following
    the instructions, making your windows partition smaller, and increasing
    the sizer of your ReAgent partition bigger?

    Winston, Paul, and others have been very helpful in assisting me fix
    this issue on several systems. In the message below, Winston details
    removing restore points because of the location they get put on the
    disk. Perhaps that might help you.

    Message ID:
    news://news.eternal-september.org:119/uq1o6i$1ra1s$1@dont-email.me

    Try telling non-technical users like elders. :P


    What your blocker is, may vary. This is why we can't exactly
    just slap down a single solution. In my sample C: partition
    (a Microsoft modern.ie VM from the archives), the System Volume Information
    has a file of a decent size, and this appears to prevent shrinkage.

    File 0089912 Sector 15426439
    File 0089914 Sector 133462015 <=== a Restore point was the blocker before File 0089915 Sector 66495

    I was planning on using a Macrium backup and restore method, to defragment
    the partition. You can see how the file number increments, and the sector number on the right increments, that it does a damn fine job of putting
    the files in filenum order. Only one problem. It seems to have
    the same sort of habit Microsoft would like -- putting a blocker in
    the middle of the partition. Since I never cared about this before,
    I never checked for this. All I'd noticed, is you could use Macrium to defragment a partition (restore to a slightly reduced partition size,
    causes Macrium to restore the files in order -- I call this a drag and
    drop restore, because of how you handle the restore at restoration time).

    File 0000000 Sector 6473727 $MFT
    File 0000000 Sector 831 $BITMAP
    File 0000001 Sector 125759407 $MFTMirr
    File 0000002 Sector 131903
    File 0000004 Sector 131911
    File 0000005 Sector 131919
    File 0000006 Sector 125767167 $BitMap <=== can't be moved
    File 0000007 Sector 15
    File 0000010 Sector 132175
    File 0000025 Sector 132199
    File 0000026 Sector 132207
    File 0000028 Sector 137327
    File 0000028 Sector 138927

    File 1
    Master File Table Mirror ($MftMirr)
    $STANDARD_INFORMATION (resident)
    $FILE_NAME (resident)
    $DATA (nonresident)
    logical sectors 125759400-125759407 (0x77eefa8-0x77eefaf)

    File 6
    Volume Bitmap ($BitMap)
    $STANDARD_INFORMATION (resident)
    $FILE_NAME (resident)
    $DATA (nonresident)
    logical sectors 125759488-125767167 (0x77ef000-0x77f0dff)

    But in any case, you can see I've been defeated, so it's looking like
    killing the System Protection restore points is still the better option.

    I use nfi.exe to get information on where the file is on the disk. Unfortunately, the output of nfi.exe always needs text filtering
    work to get the best value from the output. Skimming through
    four hundred thousand files in a text editor as an alternative,
    isn't exactly efficient. I get some free exercising of the gawk neurons
    while building little filters.

    Now, isn't this the activity you signed on for ? :-)
    I'm enjoying myself.

    Now, if, during the Macrium Restore, I'd shrunk the partition
    as small as possible, those little rat bastard files could
    not get in the way. So I can fix it. I'm just disappointed that
    the "order" Macrium used for restoration, is mostly so pretty,
    and only a couple items are not in a very nice place.

    [Picture]

    https://i.postimg.cc/FFT7CKTB/Macrium-Reflect-Shrink.gif

    If a partition won't shrink, yes, you can defeat it. I used
    a Macrium CD, a backup and restore of C:, to squeeze it down.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philip Herlihy@21:1/5 to All on Wed Feb 14 13:03:58 2024
    In article <QWidneGTaZz0V1b4nZ2dnZfqnPudnZ2d@earthlink.com>, Ant wrote...

    I still see this and no fix with today's automatic monthly updates. It
    still has the manual technical script instructions to fix it. :(

    The "Accepted Answer" here did work for me. It's easy enough - but it would also be quite easy to do some real damage if you don't follow the instructions really carefully.

    https://learn.microsoft.com/en-us/answers/questions/1495451/windows-update- issue-(failed-to-install)-0x8007064

    --

    Phil, London

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Ant on Wed Feb 14 10:42:44 2024
    On 2/13/2024 3:00 PM, Ant wrote:
    I still see this and no fix with today's automatic monthly updates. It
    still has the manual technical script instructions to fix it. :(


    Where is your sense of adventure.

    https://www.ctvnews.ca/polopoly_fs/1.2512395.1439379036!/httpImage/image.jpg_gen/derivatives/landscape_960/image.jpg

    He can do that, because he made a backup before doing the procedure.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Char Jackson on Wed Feb 14 11:56:51 2024
    On 2/14/2024 11:35 AM, Char Jackson wrote:
    On Wed, 14 Feb 2024 02:05:56 -0500, Paul <nospam@needed.invalid> wrote:

    If a partition won't shrink, yes, you can defeat it. I used
    a Macrium CD, a backup and restore of C:, to squeeze it down.

    I would just spend a minute or two and use a partition manager. ;-)

    I know, I know, you've got a toolbox full of tools and they get offended if you
    don't take them out and exercise them from time to time.


    Realistically though, do you have a Partition Manager For All Occasions ?

    I do, but if I were to describe it, there are individuals who
    are Orthodox and would object to the things I was describing.

    The idea of using Macrium, is "not going too far out into Edge City".

    For example, I could hook people up with Paragon PM14 Free, but
    if I did that, the support load that would create, it would never
    end. Yes, it can do stuff, but... <sigh>.

    So while there are partition managers, not all of them are
    a good idea. And someone might stub their toe on one.

    Your tool box has an angle grinder and a circular saw with no
    guard on it, because you like it that way.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Char Jackson@21:1/5 to Paul on Wed Feb 14 10:35:23 2024
    On Wed, 14 Feb 2024 02:05:56 -0500, Paul <nospam@needed.invalid> wrote:

    If a partition won't shrink, yes, you can defeat it. I used
    a Macrium CD, a backup and restore of C:, to squeeze it down.

    I would just spend a minute or two and use a partition manager. ;-)

    I know, I know, you've got a toolbox full of tools and they get offended if you don't take them out and exercise them from time to time.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John K.Eason@21:1/5 to Philip Herlihy on Wed Feb 14 19:11:00 2024
    In article <MPG.4036ca9e621eeaef989aa9@news.eternal-september.org>, PhillipHerlihy@SlashDevNull.invalid (Philip Herlihy) wrote:

    *From:* Philip Herlihy <PhillipHerlihy@SlashDevNull.invalid>
    *Date:* Wed, 14 Feb 2024 13:03:58 -0000

    In article <QWidneGTaZz0V1b4nZ2dnZfqnPudnZ2d@earthlink.com>, Ant
    wrote...

    I still see this and no fix with today's automatic monthly
    updates. It still has the manual technical script instructions to
    fix it. :(

    The "Accepted Answer" here did work for me. It's easy enough - but
    it would also be quite easy to do some real damage if you don't
    follow the instructions really carefully.

    https://learn.microsoft.com/en-us/answers/questions/1495451/windows- update-issue-(failed-to-install)-0x8007064

    I used the simple to follow method detailed by "Sumit D - VM" around half way down
    this page using Powershell and a downloaded script which worked perfectly: https://answers.microsoft.com/en-us/windows/forum/all/frustrating-update-of-kb503444
    1/d90ff626-555f-42f3-a383-c16ff44386f8?page=6 or http://tinyurl.com/ymmuf23r for a
    short link.
    --
    Regards
    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Char Jackson@21:1/5 to Paul on Wed Feb 14 17:57:09 2024
    On Wed, 14 Feb 2024 11:56:51 -0500, Paul <nospam@needed.invalid> wrote:

    On 2/14/2024 11:35 AM, Char Jackson wrote:
    On Wed, 14 Feb 2024 02:05:56 -0500, Paul <nospam@needed.invalid> wrote:

    If a partition won't shrink, yes, you can defeat it. I used
    a Macrium CD, a backup and restore of C:, to squeeze it down.

    I would just spend a minute or two and use a partition manager. ;-)

    I know, I know, you've got a toolbox full of tools and they get offended if you
    don't take them out and exercise them from time to time.


    Realistically though, do you have a Partition Manager For All Occasions ?

    So far, yes.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philip Herlihy@21:1/5 to All on Thu Feb 15 12:41:52 2024
    In article <MPG.4036ca9e621eeaef989aa9@news.eternal-september.org>, Philip Herlihy wrote...

    In article <QWidneGTaZz0V1b4nZ2dnZfqnPudnZ2d@earthlink.com>, Ant wrote...

    I still see this and no fix with today's automatic monthly updates. It still has the manual technical script instructions to fix it. :(

    The "Accepted Answer" here did work for me. It's easy enough - but it would also be quite easy to do some real damage if you don't follow the instructions
    really carefully.

    https://learn.microsoft.com/en-us/answers/questions/1495451/windows-update- issue-(failed-to-install)-0x8007064

    A more direct link:

    https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually- resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9- 24c8229763bf

    You operate on disks and partitions by Selecting them by "index" number first. Be sure to correctly identify the "OS disk index" and distinguish the "OS partition index" from the "WinRE partition index". As indicated, the Diskpart commands "list disk" and "list part" will display what's there to choose from, and I also had Disk Management running just to double-check. I did make one mistake but I got away with it.

    Overview:
    1) You disable WinRE
    2) You shrink the OS partition
    3) You delete the WinRE partition, and then re-create it.
    4) You re-enable WinRE

    Don't delete the wrong partition!!!!!

    It'll take ten minutes of concentration. Yes, it's bizarre we have to do this.

    --

    Phil, London

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)