Hello r/sysadmin, I'm u/AutoModerator, and welcome to this month's Patch Megathread!

This is the (mostly) safe location to talk about the latest patches, updates, and releases. We put this thread into place to help gather all the information about this month's updates: What is fixed, what broke, what got released and should have been caught in QA, etc. We do this both to keep clutter out of the subreddit, and provide you, the dear reader, a singular resource to read.

For those of you who wish to review prior Megathreads, you can do so here.

While this thread is timed to coincide with Microsoft's Patch Tuesday, feel free to discuss any patches, updates, and releases, regardless of the company or product. NOTE: This thread is usually posted before the release of Microsoft's updates, which are scheduled to come out at 5:00PM UTC.

Remember the rules of safe patching:

• Deploy to a test/dev environment before prod.

• Deploy to a pilot/test group before the whole org.

• Have a plan to roll back if something doesn't work.

• Test, test, and test!

https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d

The fix outlined in the above article no longer works. I used to have a series of scripts that made the registry changes and ran the verification checks. Those scripts no longer work; however, previously fixed machines still report as fixed. Today, I decided to run the steps as listed (and to not use my scripts). For instance, Step 1b still returns "False".

In addition, the machines in question...

• Have at least the 2024-10 Cumulative Update (newer than is required).

• Are Secure Boot enabled.

• Are rebooted twice before proceeding to the next step. (AvailableUpdates key resets to 0, which is expected.)

I posted something similar over in MS Tech Community a couple weeks ago but haven't gotten a response.

Hi all,

Anyone else seeing this potentially be turned on in their environment?

Long story short, I had a tech reach out to me a week or so ago, about a Lenovo that would not take Windows 10. Kept saying the boot media was/imaging stick (traditional imaging, OSD) was not working. Had him rebuild his stick. Try again. Reset BIOS defaults (we image 100s of a machines a week, and it's generally 'your stick is bad' sort of thing; this tech is not dumb). I pulled out the same model he was using (a Lenovo P52s), tried Windows 10, worked fine.

Next day, went to re-image the same Lenovo box. It wouldn't boot with my stick. I frowned. My mind started pondering.

Re-imaged another box with Windows 10. Let it sit for awhile. Try again; USB stick didn't work.

Shit.

So, long story short, I update our OSD process with the 'latest monthly patch' each month, so that gets installed as an LSU/update during the TS. What I was seeing is the 'enforcement' phase of KB5025885... "turn on". Which... wasn't great.

Follow Gary's instructions here, I whipped up a new media with refreshed files, after 'fully and intentionally enabling it' on a laptop.

KB5025885 – Updating your USB Boot Media – Leveraging OSD Module – GARYTOWN ConfigMgr Blog

Copied the files over, and voila, works fine now, on the 'broken' devices.

So:

1. I have heard no one else mention this.

2. I may be insane.

3. I may have done something wrong, but I 100% did not INTENTIONALLY enable the remediation steps yet, especially during OSD and 'randomly'.

4. I saw this KB5036534: Latest Windows hardening guidance and key dates - Microsoft Support: Which specifically says:

October 2024 or later

• Secure Boot bypass protections KB5025885 | Phase 3 Mandatory Enforcement phase. The revocations (Code Integrity Boot policy and Secure Boot disallow list) will be programmatically enforced after installing updates for Windows to all affected systems with no option to be disabled.

Is anyone else seeing their fully patched October 2024 devices turn these settings on, and can no longer be imaged with their 'non remediated' sticks?

I'm not talking about the *FIRST* patch, but rather the *second* phase, the steps that Gary's blog post outlines; modifying the files on the boot media itself, not *just* patching the boot.wim.

I feel like I'm taking crazy pills, so just needed to post this.

I've gone ahead with Microsoft's recommendations for KB5025885 and have implemented these Secure Boot revocations on a few physical servers. Before doing this I verified I could get recovery partitions and bootable USBs to still work after changing the trusted SB certificates. This worked like Microsoft said it would.

However, time came to actually reinstall Windows Server on a couple machines that have these revocations applied and it is going horribly. The install USBs work after updating the boot files on the USBs, but the Windows install the USB creates fails Secure Boot... it is still signed with their revoked 2011 certificate. What is the point of updating installation media if the Windows install it creates isn't updated and won't boot with Secure Boot enabled?

I've tried placing Secure Boot in Audit mode, where the system will boot, but Microsoft's steps to update the boot EFI files fail. This process hasn't failed on any other systems I've done it on, not sure why it's failing here, but maybe it has to do with Audit mode being enabled.

Anyway, I'm in a pickle with this. Things seemed like they were fine and Microsoft's instructions (while needlessly complicated over 1 year in) worked. But it seems there is a huge hole left in their documentation, which they implied wasn't there. If you know how to get a bootable fresh install after applying KB5025885, please let me know!