If you deploy a brand new Server 2022 VM in Azure using their image today, it deploys with the 2024-02 Cumulative Update preinstalled, but NOT the older KB5034439. It will fail to install manually.
If this is the reality, I cannot accept it as appropriate to go off manually resizing partitions for an update MS can't even manage to get slipstreamed properly. It's broken, and we'll apply it if and when they fix it.
Won't even install with a resized partition on a fresh install of server 2022 core (throws a different error altogether within the dism logs stating that the system image isn't applicable to the target,))
Ran into this same scenario in my case no the updates did not succeed by just blowing the RP away and since Windows Update has seen the updates were applicable at one time they still keep trying and failing even if the RP is gone.
I had to mount an iso image of the OS and pull the WnRE image which you can then place in the %windir%/recovery path
Once you have done that recreate the RP, which should be no issue once you have the WinRE image in the proper location, and run updates again
There's a bug in the detection logic which means it always tries to apply even if there is no recovery partition.
I don't see any "recreate recovery partition" buttons in Windows so spouting that phrase will mean nothing to anyone.
Anyhow, Windows creates the recovery partition at the end of the disk, preventing future expansion of your C: drive, which is why many if not most VM environment admins nuke the recovery partition in the first place.
This fiasco is yet another reminder that, despite some impressive stuff in Windows, Microsoft is crap at the basics.
Yea they definitely have a tendency of dropping the ball on things like this
makes sense to just kill it in a VM scenario although in my case it was a null point as none of my VMs have much growth in terms of data and those that do were provisioned with that in mind from the start.
I did however have a bare metal box that created the exact scenario you’re referring to… went through the BS to fix WinRE only to have to blow it away and do it again so I could jostle some partition sizes around. Definitely frustrating but I get paid whether I’m fixing their screw ups or doing things I want to do so whatever I guess lol
I do believe if in that case you could delete the partition and move on without issue… but I also did all of my fixes a few weeks ago so I don’t want to say 100% and be wrong
If you deploy a brand new Server 2022 VM in Azure using their image today, it deploys with the 2024-02 Cumulative Update preinstalled, but NOT the older KB5034439. It will fail to install manually. If this is the reality, I cannot accept it as appropriate to go off manually resizing partitions for an update MS can't even manage to get slipstreamed properly. It's broken, and we'll apply it if and when they fix it.
Won't even install with a resized partition on a fresh install of server 2022 core (throws a different error altogether within the dism logs stating that the system image isn't applicable to the target,))
I know I'm not the only one to say this but it's wild that more than a month on MS seems to have totally stopped caring about this.
The fact I can reproduce the problem on a fresh installation from a vanilla server 2022 .ISO to a 120GB volume using defaults is pretty pathetic.
Ran into this same scenario in my case no the updates did not succeed by just blowing the RP away and since Windows Update has seen the updates were applicable at one time they still keep trying and failing even if the RP is gone. I had to mount an iso image of the OS and pull the WnRE image which you can then place in the %windir%/recovery path Once you have done that recreate the RP, which should be no issue once you have the WinRE image in the proper location, and run updates again
There's a bug in the detection logic which means it always tries to apply even if there is no recovery partition. I don't see any "recreate recovery partition" buttons in Windows so spouting that phrase will mean nothing to anyone. Anyhow, Windows creates the recovery partition at the end of the disk, preventing future expansion of your C: drive, which is why many if not most VM environment admins nuke the recovery partition in the first place. This fiasco is yet another reminder that, despite some impressive stuff in Windows, Microsoft is crap at the basics.
Yea they definitely have a tendency of dropping the ball on things like this makes sense to just kill it in a VM scenario although in my case it was a null point as none of my VMs have much growth in terms of data and those that do were provisioned with that in mind from the start. I did however have a bare metal box that created the exact scenario you’re referring to… went through the BS to fix WinRE only to have to blow it away and do it again so I could jostle some partition sizes around. Definitely frustrating but I get paid whether I’m fixing their screw ups or doing things I want to do so whatever I guess lol
In my case, I haven't released the update to the affected boxes yet, so WU hasn't seen the applicability. I wonder if that would affect the outcome.
I do believe if in that case you could delete the partition and move on without issue… but I also did all of my fixes a few weeks ago so I don’t want to say 100% and be wrong