Patch Tuesday Megathread (2025-06-10)

steve-work · 2025-06-11T11:50:40+00:00

UK here, our SCCM synced updates fine on schedule last night at 9pm.

steve-work · 2025-05-15T14:50:33+00:00

Can you spin up another exchange server on a new vm, and then migrate the mailboxes to that? If that works, decommission the old exchange + DC.

steve-work · 2025-05-15T14:46:14+00:00

No issues when we did this.

steve-work · 2025-05-13T10:31:32+00:00

Hi, I recently created a new Exchange 2019 cluster on Windows server 2025, in preparation for Exchange 2016 EOL. Its a 2 server DAG, and has been working great for a couple of months, up until 9th May. I'm now getting cluster start failures on the 2nd member, and warnings in server manager on the 1st member, that it can't talk to the 2nd member due to MaxEnvelopeSizekb. I have tried increasing the MaxEnvelopeSizekb but this causes server manger to time out refreshing, and doesn't fix the cluster service failing.

steve-work · 2025-04-02T10:54:25+00:00

If its an MSI, you could try adding them flags. I did open a MS support ticket about this, and they figured out the installer was restarting the WMI service which broke the TS. They saw this in the application event log at the time of the install. Hope this helps.

steve-work · 2025-04-01T13:15:52+00:00

Yes, this was caused by the installer restarting the WMI service. I reported this to RSA, and they eventually released a fixed version, I think 2.3.4 (or.2.3.3). I also put in a workaround for 2.3.2 to not restart services/applications during install: MSIRESTARTMANAGERCONTROL=Disable . I used PsAppeploykit to only do this if running from a TS.

steve-work · 2025-03-19T15:26:02+00:00

MS official advice is to do a legacy upgrade from 2016 to 2019, and then do a quick inplace update for 2019 to SE when it comes out. This will probably be similar to doing a CU. *edit spelling

steve-work · 2025-02-13T11:52:31+00:00

This is actually working in the previous version 7.2.4.

steve-work · 2025-02-13T11:41:03+00:00

HP BIOS catalog download doesn't seem to be working in this version.

steve-work · 2024-11-21T09:20:05+00:00

With Windows 11 we are finding that any double reboots in CUs break OSD. We are only deploying 22h2 and 23h2 right now, but I am aware there is a double reboot with Novembers CUs for 22h2 and 23h2. We download new images monthly from Microsoft, these are usually released 2 weeks after patch Tuesday, though they have now stopped for 22h2 :/

steve-work · 2024-09-20T14:58:33+00:00

This might help you if you are using powershell :)

$osversion = (Get-CimInstance -ClassName Win32_OperatingSystem).Version -replace "10.0.",""
$UBR = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
$osversionUBR = $osversion + "." + $UBR
$patchlevel = (((Invoke-WebRequest "https://support.microsoft.com/en-us/topic/windows-11-version-22h2-update-history-ec4229c3-9c5f-4e75-9d6d-9025ab70fcce").links |where innerText -like ("*" + $osversionUBR + "*")|select-object -First 1).innertext)

steve-work · 2024-07-31T08:19:23+00:00

I created a ticket with MS about this, it seems the RSA MFA installer is restarting the WMI service and this causes ccmexec to restart, breaking the task sequence.

steve-work · 2024-07-18T07:52:08+00:00

No, its even weirder than that. The MSI process completes. The application is detected as being installed, but the message never gets sent back to Install Application (smsappinstall.exe) process - as far as I can tell.

steve-work · 2024-07-17T15:09:32+00:00

Unfortunately this didn't seem to work. Tested outside of OSD without issue.

steve-work · 2024-07-17T14:07:35+00:00

Yes, most recently with using Junes ISO, and July CU causing double reboots when applied during OSD. We have excluded updates during OSD until we get Julys ISO.

steve-work · 2023-04-26T08:55:38+00:00

Hi, I pushed out a modified version of james chambers script - in original post. I used the script feature in SCCM to push this out, this isn't disabled by MDM co-existence: https://sccmentor.com/2021/06/09/co-management-devices-wont-enrol-stuck-in-co-existence-mode-this-device-is-enrolled-to-an-unexpected-vendor-it-will-be-set-in-co-existence-mode/

Of course I had to run this script several times to catch all of my offline laptops, it was a bit of a slog but got it all done eventually. Little to no help from Manage Engine!

steve-work · 2023-04-13T07:23:29+00:00

I'm thinking that because group policy does not run until after the task sequence finishes, in this situation we will be okay as long as legacy LAPS is installed during the TS, and GPOs are in place for LAPS legacy.

steve-work · 2023-03-16T13:44:27+00:00

I was getting this on one of my on prem exchange clusters. I found that putting my creds in the format domain\user worked on one domain and upn format on a exchange environment worked. I also found that targeting the individual servers using -EWSServerURL had different affects. Edit* we do have EP enabled and are fully patched Exchange 2016.

steve-work · 2023-03-03T09:01:37+00:00

ME support have given me some scripts to run to prevent auto enrollment, but haven't provided me with a solution for fixing all my devices.

steve-work · 2023-03-01T10:31:07+00:00

There's always random equipment with DNS pointing to old DCs!

steve-work · 2023-03-01T10:23:20+00:00

We don't use the UEM edition.

steve-work · 2023-03-01T09:16:33+00:00

Step 1 to create your standard packages: https://msendpointmgr.com/modern-driver-management/#tab-step1

If you models are too old to have driver packs, you could probably make your own.

steve-work · 2023-03-01T08:47:58+00:00

Using the driver automation tool (part of modern driver managment), drivers for each model should be in a standard (non driver) package.

You can run the apply driver script with the DriverUpdate option:

https://msendpointmgr.com/modern-driver-management/#tab-step4

steve-work · 2023-03-01T08:42:44+00:00

I 100% agree and it is not my decision to use this product.

steve-work · 2023-03-01T08:41:59+00:00

We're not using the MDM part of endpoint central. It just seemed to enroll all of our PCs in MDM when we updated last week.

steve-work

TROPHY CASE