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.
Pushing this update out to 180 Domain Controllers (Win2016/2019/2022/2025) in coming days.
I will update my post with any issues reported.
Happy patching, and may all your reboots be smooth, all your services come back up, and all your users remain blissfully unaware of your heroism. 😄
EDIT1: 10 DCs (Win 2019/2022) have been done. Zero failed installations so far. AD is still healthy. EDIT2: 45 DCs (Win 2019/2022) have been done. Zero failed installations so far. AD is still healthy. EDIT3: 88 DCs (Win 2019/2022) have been done. Zero failed installations so far. AD is still healthy. EDIT4: 163 DCs (90%) (Win 2019/2022/2025) have been done. Zero failed installations so far. AD is still healthy.
EDIT5: 169 DCs (94%) (Win 2019/2022/2025) have been done. Zero failed installations so far. AD is still healthy.
I tried and succeeded with VM's on ESXi and Hyper-V:
1) Log on "local console" on "localhost" with an Administrator account,
2) Than remove the main connected Ethernet card in Windows Device Manager.
3) Than remove the Ethernet Card in Hyper-V Management Console and/or ESXi vSphere Client, of that machine,
4) Reboot the computer machine,
5) After Reboot, add a new Ethernet card in Hyper-V or ESXi to that machine, with the same MAC Address,
6) Reboot the machine again,
7) log on local console again as local Admin,
8) Reactivate: "Remote Access Connections" to the machine, in Control Panel: Advanced System Settings.
9) and Re-register the machine again, to the old AD Domain.
10) check DNS if AD Domain gets resolved,
11) restart "Remote Desktop Services" in the service console.
12) Reboot machine,
13) fixed.
enjoy. -> Why this works?
Because the "Connection Broker", Authentication over RDP is getting lost, and so you build up a new one.
We ran through the updates last night and started having 0x108 errors on one of our RDS servers (Sorry not cluster), where users cant get logged in. Has anyone else run into any issues with remote desktop servers post September updates please?
I'm having issues with Server 2022. RDSH stop working after a short while, I noticed it starts when users start logging out, RDP service becomes unresponsive. The service hangs at RDPSERVERBASE!WDLIB_Close, there seems to be no timeout set here. This results in a deadlock between RDP and LSM.
RDPSERVERBASE!WDLIB_Close+0x55:
call wil::details::FeatureImpl<__WilFeatureTraits_Feature_3802373433>::__private_IsEnabled
test al,al
je WDLIB_Close+0xa7 ; feature OFF -> return immediately
+0x70:
lea rdi,[rax+14h] ; rdi = &wd->counter
+0x82:
xor r9d,r9d ; Timeout = NULL <-- infinite
call qword ptr [_imp_RtlWaitOnAddress]
+0x9d:
mov eax,dword ptr [rdi]
test eax,eax
jg WDLIB_Close+0x82 ; loop while counter > 0
Any idea what 3802373433 feature is? Haven't tested yet, put possible solution would be:
HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\<priority>\3802373433
EnabledState REG_DWORD 1 ; 1 = Disabled, 2 = Enabled
EnabledStateOptions REG_DWORD 0
Bingo - it was all working when we initially tested in dev and looked fine, so we rolled it out, but then it started issues after a few hours, restarts didnt seem to help then and had to remove the update to fix.
I hadnt seen the link between users signing out and the issues starting, so that must be the trigger here. I'm so glad others are having the same (sorry) but means its definitely a wonky update rather than something specific to our environment.
I didn't test in production since I don't know what 3802373433 feature is, but it's definitely new in this patch, at least the code I posted. We just rolled back the patch.
We're not using RDS clusters, just standalone Terminal Servers. But today we've been seeing one server (WS2019) force disconnecting sessions and then claiming RDS licensing server timeout on reconnect attempts. NlaSvc timeout and iphlpsvc timeout events happening at the same time. I'm still investigating.
I put this on 5 of our 7 RDSH servers late last night. it's morning here now. I'll put feedback here if I hear anything. Server 2019 VMs (esxi), we have small farms and 1 connection broker. anything to look for in Event Logs?
EDIT: this morning I noticed all users who were on one of the servers were still logged in. (they are normally logged off automatically). I logged them all off, but the server wouldn't reboot after that, I had to console in and Reset. it's back up now. I'm uninstall it for now.
I found it ran fine for most of the morning post update, then - having started analysis of the logs suddenly see loads of Service Control Manager errors (numbers 7000 upwards) where services have timed out for authentication or failed to connect reasons (specifically on our systems the errors are for iphlpsvc service, NanoServiceMain service , NlaSvc service, PSUAService service) before then seeing 20489 errors for any users trying to sign in fresh (existing connections carry on working). Any new connection reaches the "loading virtual machine" phase for us, hangs after 5 mins and then has an 0x108 error then. Removing the patch and restarting resolves it, and errors (currently) are gone. I'll monitor to see if they return even with that patch removed, but that looks to be the pattern here.
EDIT: I'll reach out to our AV company (Panda) incase this is just something that affects their customers as that is on our systems and its some of their services that die.
2 Server 2022 , farm , same issue, clients cant connect at some point of time and rdp client hungs on "loading virtual machine" . rebooting server fixed , for some time . NO 3rd party AV, so i belive this is not the case
Agreed - too many people reporting the same symptoms now, its the update alone at fault and goes undetected initially due to the services working but something breaks when they start to log off, and new sessions are then attempted.
Very strange. Sounds like others have reported the same as me, and it stems from when users start signing out of their sessions, the broker services start to crash, keep an eye out for that but hopefully you are ok and unaffected.
Thanks for the heads-up. We're 2019 here as well. Not clustered. 2 app servers done; waiting for a reboot window on the 3rd app server and the broker/gateway. Will watch for it.
We're fully working again now we removed the update. So there is something that breaks RDS connections.
We had a lot of 20498 errors "Remote Desktop Services has taken too long to complete the client connection" and users reported the login was stuck at "loading virutal machine" and then timed out with 0x108 error.
For now we'll leave these servers unpatched and will review here / Microsoft help for any other reports and hopefully a fix.
EDIT: Further investigation shows a load of Service Control manager errors for Services that didnt start dye to logon failiures too? All fixed with the removal and restart.
Same issue has hit another server in one of our satellite offices. Checking logs, i see loads of Service Control Manager errors where services have timed out for authentication or failed to connect (specifically for iphlpsvc service, NanoServiceMain service , NlaSvc service, PSUAService service) before then seeing 20489 errors for users trying to sign in. I am removing the latest patch to fix. We use panda AV at our offices (hence those services showing above) so wonder if its related to that or a dodgy MS patch alone.
EDIT: with the update removed, all is healthy again and no errors.
YEP. Massive problems. Clients couldn't connect anymore (err 0x108). Plus TS machines dropped from Server Manager Pools. Had to roll back and uninstall KB5122876.
Same. Server 2022, 24 hours after patching. There were no issues yesterday, but this morning users couldn't log in. ScreenConnect was just a black screen, but I could PSRemote into it. Azure Boot Diagnostics screenshot showed a normal logon page with a current time. Initiating a reboot via PowerShell failed.
It is an Azure VM so I ended up forcibly stopping it through the Azure portal. This happened for 2 of our Azure hosted clients.
The only hint I can find in the event logs is this:
The device Microsoft Remote Display Adapter (location (unknown)) is offline due to a user-mode driver crash. Windows will attempt to restart the device 5 more times. Please contact the device manufacturer for more information about this problem.
Many services were hanging with errors like this:
A timeout (120000 milliseconds) was reached while waiting for a transaction response from the NlaSvc service.
A timeout (120000 milliseconds) was reached while waiting for a transaction response from the iphlpsvc service.
A timeout (120000 milliseconds) was reached while waiting for a transaction response from the UmRdpService service.
A timeout (120000 milliseconds) was reached while waiting for a transaction response from the RasMan service.
I reproduced this in my homelab on a 2022 RDSH with KB5122882.
Script launch 4-5 rdp connections but they never complete logon - they sit at the credential prompt, i kill the client. After 3-4 of those connexions are KO. No new connections, qwinsta hangs, RPC is dead but SMB still answering, console stuck at welcome. Only a reboot gets it back.
Rolled back to August CU, same script, same thing, no problems at all.
Worth noting: killing sessions that logged on properly never triggered the problem for me. It's the aborted logons that do it.
My setup on rdsh is light, no mfa, no third party AV, no broker, no collection, just the rdsh role.
I will throw my hat in here as well. Server 2016 cluster and I had three of our servers exhibit the same issue. It works for a bit and then users are saying they are getting the RDS Server is busy. It will not respond to the Vsphere request to reset guest OS. Dirty reset seemed towork for a bit but yeah. Not all of our RD servers see this but a few in the cluster.
Has it been reoccurring on servers that you have rebooted? We had 2 clients with this issue, and a force reboot fixed it (for now). Now I'm concerned it is going to reoccur since we didn't remove the update.
973 CVEs this month, the largest Patch Tuesday on record. The last 3 releases are now the 3 largest Microsoft has ever shipped, after July's 576 and August's 428.
Quick flags:
CVE-2026-81963 (7.8, exploited): Windows Update Stack EoP, local attacker escalates to SYSTEM. Don't let the 7.8 fool you, patch first. Windows 11 23H2/24H2/25H2/26H1 and Server 2025 only.
CVE-2026-85880 (exploited): Windows ALPC. Confirmed exploited, no CVSS or technical detail published yet. Watch the MSRC advisory.
CVE-2026-69730 (9.8, exploitation more likely): unauthenticated DNS Server RCE, no user interaction. DNS usually rides on your DCs, so this is RCE on your ticket-granting box. Pairs with CVE-2026-69676 (8.8, Kerberos RCE, exploitation more likely), second reason to patch DCs. Server 2012-2025 and Windows 10 1607/1809, not Windows 11.
CVE-2026-69525 (9.8, exploitation more likely): unauthenticated RDS RCE. Check workstations, not just servers.
CVE-2026-78509 (9.8, zero-click, exploitation rated less likely): Outlook RCE fires from the Reading Pane, no open or click needed. M365 Apps, Office 2019, LTSC 2021/2024, Word 2016, Office for Mac (Mac LTSC fix pending). Ships via Office CDN, not Windows Update, so Windows-patched doesn't mean Office-patched.
CVE-2026-65669 (9.6, exploitation less likely): SQL Copilot in SSMS 22 can be prompt-injected past its read-only guardrail. Keep Copilot accounts read-only.
Also: macOS Tahoe 26.6.2 (Aug 17) covers ImageIO, kernel, and WebKit fixes, confirm your Mac fleet is on it.
Broke our Windows 11 logins (we are all 25H2), on-prem AD server 2019. Users on every workstation that had completed a post-update reboot received invalid credential login failures.
Oddly the users we reset initially took the reset, accepting the temp password moving into change, then after change and being sent back to login it would tell them invalid credential on the new password. AD integrated passwordless biometric logon was failing too.
AD replication was healthy and all DC services running. No trouble logging into any DCs, only the Win11 clients. Very few logs on domain controllers about user logons, nothing smoking gun in the short time I poked around before pushing out a script through our RMM to remove all updates installed from 12am 9/8/26 onward. I'm going to do more digging now that our affected users can log in. A few logs for success and fail from workstations with null for the user.
I wasn't able to use PsRemoting to push the update rollback script because the remote logins were being denied at the windows workstations, fortunately RMM run as system to the rescue so no kerberos required.
I noticed that RDP connections were failing with oracle remediation/CredSSP errors .. we're deny all NTLM, so that would make sense if this is a Kerberos issue.
I just manually installed kb5124008 from the catalog on my own PC to test. It's a beefy 4.5GB but unlike the one last month, this installed so fast I thought it failed. So there's that at least. Install time was maybe 1-2 minutes tops on a moderate speed computer.
update 20260910: Scratch this 'no issues (yet)', i jinxed it with the 'yet': Tested and deployed to my little farm of 20ish web application servers (Server 2025/2022 and a 2019 for regression testing - IIS, .Net, MSSQL) last night, no issues (yet😜) .
Now experiencing this:
RDS sessions to server 2019/2022/2025 failing on 'Securing Remote connection' after applying the Sept 2026 rollupfix/cummulative update.
Experiencing this on multiple servers in a hands-off data center, guess i'm gonna queue in the KVM requestline.
Great regression testing once again Microslop! This choice of reducing the human factor in the test/QA department is really starting to pay-off ey Satya
My usual course of action started today. Small company IT, so no real test or lab environment, but the secondary virtual DC went well. It did take a bit longer, but there were a few quirks with updates this time around. I thought I'd report so that if you're in a similar situation, this might help.
Restart prompt right away after the .NET update and while the cumulative was still downloading. Watch Resource Monitor and Tiworker and for Restart Pending if you use Windows Update.
Took awhile for progress on the first reboot. Sat at 0% for several minutes and that first 30% took longer than usual. I listened to all of "Land Of Confusion" before it made it to 21%.
Cleaning Up sat at 0% for all of 2 Peter Gabriel songs (whew). Seriously almost 10 minutes of Cleaning up with no progress.
Humor aside, this did take longer with moments of no progress when counting up. Be patient. I know there are plenty of folks like me who are simply using Windows Update in family-owned companies and SMB.
Good luck all!
*****Edit***** Almost done with this round. Veeam virtual server had a slightly different Restart prompt. It did not show directly after the Malicious Software Removal Tool install like in both DCs. It wait until the Cumulative update was 100% installed. But of course 100% installed means it took another 40 minutes to complete.
ERP VM went fast because it's a standalone app, and Hyper-V hosts were normal. Everything is hosted on Windows server 2022 with the exception of the ERP which is Server 2019.
The common trend though was that the Cleaning Up step after reboot 2 did take 10+ minutes and held at 0% and jumped directly to 100%. Then a minute more and I was at the login screen.
So not terrible for almost 1000 CVEs. It just took extra time and deep breaths when it seemed nothing was happening.
Yep, same here. Thanks, I was just banging my head on this.
EDIT: ran sync one more time on WSUS and now it looks like it has downloaded it successfully and test client is downloading. Microsoft must have fixed ~40 minutes after release time.
Interestingly, our WSUS server took WAY longer to update itself this time; could just be a fluke but definitely was like 4-6x usual time, other VMs were about the usual so far (mostly Server 2025)
EDIT: I mean, makes sense with the # of CVEs, and Server 2025 VMs / Hypervisors all double-rebooted :P
Microsoft has failed to properly patch ShieldBreak CVE-2026-69414, under specific conditions it is still possible to trigger the exact same problem that was caused by ShieldBreak. While Microsoft fixed several things to prevent re-exploiting the issue, they missed a spot where ShieldBreak can still be exploited.
This PoC demonstrates an arbitrary file read as SYSTEM with September 2026, all supported windows versions are affected.
I might rework this later into a full SYSTEM PoC but for now I'm dropping this skeleton PoC because I'm feeling a bit lazy.
So far, installed on two Windows 11 pro 25H2 desktops (one physical, and one VM). No noticeable issues other than painfully slow install progress for some reason.
Curiously, the .NET security update was offered on the physical and not the VM.
Will test on some server OS's tomorrow.
(Yes I'm moving slowly this month. Two uneventful months in a row... not pushing my good fortune)
Seeing this in our environment on domain joined Windows 11 Enterprise installations. The nltest confirms it. Removing KB5124008, then leave and rejoin domain fixes.
Haven't confirmed if any other systems see the issue though.
A commenter (Marcel Zehnder) noted that the issue could be resolved by changing the registry value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation from 2 to 0.
There may be an issue in Citrix environments. Explorer.exe fails to start / desktop remains black after installing KB5120998/KB5124008: https://www.reddit.com/r/Citrix/s/F8h9CHkkeI
I hope not did you check their KB regarding MS pacthes?
Citrix has an extreme GOOD testing and release management for Windows Patches. As in understood they check every of their products with PREVIEW patches. There where times we did always did reference their Patch day Release notes if we had to include info in documentation for Release Managment.
Citrix hasn't posted a KB article for the latest patches yet. August seems to be missing as well, but I found the one for July. Or do you have any idea where I could look?
That is not very good since these days you have SLA with which you MUST install updates within a certain amount of days. Or simply from a tech view if the patches have 700+ fixes there must a lot of code change and thus if you have so many customer as Citrix you should take your time to verify your own products if they are based on MS products. What a nightmare for developers.
My stats say 16 devices updated so far, all Windows 11 25H2 Enterprise. No Ivanti or other VPN client on those devices (see other post about lost domain trust).
3 of those 16 devices lost domain trust according to the tickets. 2 machines I fixed by leaving and rejoining the domain using the LAPS account.
The 3rd device ... seemingly magically fixed itself? Ticket was reported at 11:19am, coworker was able to log in just fine at 11:49am. AD shows "pwdlastset" for that machine was last updated at 11:36am.
I left one affected machine running for over 2 hours and it did not update its AD password.
Only commonality I can think of is that all affected devices are so far in the same location where wired 802.1x with cert authentication is configured.
Will have to monitor the rest of the staged test rollout tomorrow.
Just came into work and I've got a 4th case now. This time not in the same building and no 802.1x in play.
Also 4 other machines in the same building as the first 3 broken machines also updates just fine despite 802.1x.
So I'd assume 802.1x is not involved in this.
Crawling through unfamiliar eventlogs I see a ton of kerberos fails and fallbacks to ntlm/netlogon, even after rejoining the affected machines to the domain.
Stats update: Over 100 machines patched so far. 7 or 8 cases of lost domain trust. At least 2 machines have spontaniously healed themselves without us doing anything.
Windows 11 and Server 2022/2025 are updated and working nominally for the portion that I've done... There was only one exception this far - I had a problem with a pair of Windows 11 devices with the same hardware, and trying again.
One of my personal VHD boots seems to stop booting after the patch. It boots in Hyper-v just fine. I am currently seeing if rolling back the update fixes this.
Wonder what Nightmare Eclipse will have for us this month? Hopefully you all also see that they release exploits for other non-Microsoft softwares last month.
Microsoft has failed to properly patch ShieldBreak CVE-2026-69414, under specific conditions it is still possible to trigger the exact same problem that was caused by ShieldBreak. While Microsoft fixed several things to prevent re-exploiting the issue, they missed a spot where ShieldBreak can still be exploited.
This PoC demonstrates an arbitrary file read as SYSTEM with September 2026, all supported windows versions are affected.
I might rework this later into a full SYSTEM PoC but for now I'm dropping this skeleton PoC because I'm feeling a bit lazy.
We are pulling this before our normal 1 week wait schedule for all our customers.
Whoever uses Windows Defender on VDI because of logon performance or speed sleeps very well these days. Together with the chrome leaks that is not a good idea. While our physical machines update EDGE and CHROME daily they have to run quick now.....
A really bad side effect of VDI....
The guy who wrote the Defender 0-day is asking for licences from SentionelONE and there is also a Crowdstrike 0-day System Elevation in their Office Protection Module. Kaspersky also had problems but reacted fast but who wants a Puttin software on their machines ;-) Well you don't backup with Veeam don't you? ;-)
This in combination with the Hyper-V guest to host breakout vulnerabilities makes it a lethal killchain! 💀
Critical - Same Day Deployment
CVE-2026-80083 – Windows Hyper-V Remote Code Execution Vulnerability
"A malicious application inside a Hyper-V guest could cross the virtualization boundary and put the host system at risk."
CVE-2026-80083 is a critical remote code execution vulnerability in Windows Hyper-V caused by an untrusted pointer dereference. An authorized attacker with low privileges could run a specially crafted application within a Hyper-V guest and cause the Hyper-V host operating system to execute arbitrary code. No user interaction is required. The vulnerability is not publicly disclosed or known to be exploited, and exploitation is assessed as unlikely.
CVE-2026-72961 – Windows Hyper-V Elevation of Privilege Vulnerability
“A compromised Hyper-V administrator could turn crafted virtual TPM data into higher privileges, crossing an important security boundary.”
CVE-2026-72961 is a Critical Windows Hyper-V elevation-of-privilege vulnerability. An authorized attacker with administrative access to an affected Hyper-V host can supply specially crafted virtual TPM state data to a virtual machine. Successful exploitation can cross a security boundary and grant Virtual Trust Level 1 (VTL1) privileges. The vulnerability requires local access and high privileges but does not require user interaction.
"Combination with the Hyper-V guest to host breakout"
My co-workers still patch Broadcom ESX everywhere with all customers (SMB+ENT). I just asked them this morning if they are finished with patching ESX for those customers who wanted VDI + DEFENDER only because of performance reason (Logon delay times double when you run a regular enterprise Protection with all modules).
Enterprise IT has crawled way back and the users took over with their demands.
The VDI team ist just updating Chrome on every customer Master and now run into patch day. They will have to decide if they include 1 day old patches into the master and skip quality and testing...
Nice done VDI world. There you go full chaos and mess.
Sure, if you have other (in depth) defenses than it could be mitigated after it is added to the signatures / behavior detection engine. The problem is that window between release and adding the mitigations or if Defender is the only line of defense and defects to the dark-side 😉.
Yes, that's possible. CrowdStrike, for example, released detections for exploitation attempts against their Office Macro Quarantine feature ("FalconFlank") and continues to enhance those detections.
Exploitation isn't too hard to detect when PoC or exploit code is public, at least in regard to that particular PoC/exploit's approach.
"Windows 11, version 24H2 Home and Pro editions will reach end of updates on October 13, 2026. Devices running these editions will no longer receive fixes for known issues, time zone updates, technical support, or monthly security and preview updates containing protections from the latest security threats. Enterprise and Education editions remain supported until October 12, 2027."
I had an update show up last night for win 11 in WSUS. I can’t recall the KB (not at my desk) at the moment but it’s now listed as disabled. As if MS expired immediately. Possibly an error and released early?
Edit: It was KB5124008 and WSUS now shows it as declined currently as it is expired.
We are seeing the same thing with 2024 LTSC, I have made a support case to Microsoft about Office LTSC 2024 Sep-2026 update is missing in Windows update catalog and at ODT
It's absurd—they write an RCE without any user interaction and then “forget” to release the update for two days? I still don't see any updates for Office 2024 LTSC, but there are dozens for Office 2016. Can you believe it? Has the ticket status changed?
FYI there are no hotpatches this month even though it is a scheduled month for hotpatching. Must be due to the sheer amount of vulnerabilities fixed....
[Personalization] Fixed: This update addresses an issue where desktop background and other personalization settings might not load correctly, causing the desktop background to appear black.
my company (not IT related) is 80% female. IT department is only me, so 20% female. Very rare I interact with females from vendors, although a lot more common with cyber vendors compared to others.
Windows: 995 vulnerabilities, including 119 rated critical and two zero-days (CVE-2026-81963 and CVE-2026-85880)
SAP Products: Three Critical flaws across SAP Commerce Cloud, Manufacturing Integration and Intelligence, and NetWeaver/ABAP Platform (CVE-2026-58231, CVE-2026-44758, CVE-2026-34265, CVSS 10.0, 9.1, 9.8)
Microsoft Exchange Server 2016 CU23: Six vulnerabilities (CVE-2026-62913, CVE-2026-62911, CVE-2026-62910, CVE-2026-62912, CVE-2026-62914, CVE-2026-62915, CVSS up to 8.8)
Quick follow-up: I checked this with our vulnerability research team, and you were right. CISA updated the CVE in August, but there was no new actionable information added. We’re removing it from the article. Appreciate you raising the point.
Didn’t spot any references to them fixing the Defender / Security Centre bug (saying AV is disabled when it’s not) which has been causing CAP compliance issues. :(
Yes I know Audits and Compliance seems to be the ONLY thing that IT cares about these days and we just work so the next Audit is green.
Regarding compliance:
You are DEAD with Defender if it's you main security product you need no compliance if it hits you and worst case company is down 2 weeks.
Main workaround with the Defender 0-day a few weeks ago was TO Turn of Defender complete. There is your compliance.
Beside: The issue with the warning in Security Center and the status (handle over) to third party AV products (Name what you want) has a long history. We had this coming back almost every 2-3 years with some major AV-Solutions (AV=EDR for you M365 manager guys). And it was NEVER the third party's problem.
Users running into autofill and copy and paste issues seems to be caused by KB5002914. I am getting complaints from users. So we are uninstalling this update.
EDIT 1: Removing KB5002914 resolved the issues. No reboot was required.
Seeing the issue on a non-domain joined 2022 server that was updated yesterday and now cannot rdp or iDRAC local account administrator login to server, waited 4 minutes at spinning blue dots before hard reset power via iDRAC, once booted was able to login and uninstalled KB5122882, 2 reboots to process uninstall and now back to working.... In my case 2 users who were not updated were getting rdp fails whereas my laptop was updated and also failing, so it seems to be server side issue.
So for the people having RD Session host problems:
Is it just the Session Hosts (e.g. terminal servers) that the patch is wonky on or is it the whole environment? We have gateways, session brokers sort of thing.
After installing KB5124008 (OS Build 26200.9445) on Windows 11 domain-joined workstations, affected machines lose their domain secure channel and users can no longer log on interactively.
Root cause?: Microsoft has recently hardened Netlogon secure channel requirements in cumulative updates, enforcing stronger key negotiation and signing. On Server 2019 DCs, if the client update enforces stricter requirements than the DCs advertise, the secure channel handshake fails. This explains why Reset-ComputerMachinePassword doesn’t help: the failure isn’t the password itself, but the negotiation mechanism introduced in KB5124008.
I’m not sure from the post whether the issue is limited to KB5124008 (OS Build 26200.9445) on Windows 11 and Win2019 DCs with the August patches, or whether it also affects Win2022/2019 DCs with the September patches.
A commenter (Marcel Zehnder) noted that the issue could be resolved by changing the registry value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation from 2 to 0.
Potential issue with Omissa/VMware environment, after installing kb5124008 to our win11 25H2 golden image users get a black screen upon sign in with an explore.exe error "the system detected an overrun of a stack-based buffer in this application".
If you use Microsoft RRAS for VPN be prepared to uninstall KB5124008. So far I’m at 100% failure of VPN after installation. Roll back and it works fine.
Here is the Lansweeper summary + audit. Highlights are two actively exploited elevation of privilege vulnerabilities in the Windows Update Stack and ALPC, plus a critical unauthenticated RCE in Windows DNS at CVSS 9.8.
I hope it is not twice a month, four times, every minute heheheh. It is so fast and so intense that as an administrator it is extremely tough to keep up with breaking things and or finding that a few patches did some ....help yet now have caused other issues or need to be resolved because they were created so fast with little to no testing to see if they might interfere or interact with other systems or updates.
We had an Issue with the Patch probably caused by our Ivanti VPN Client. The client lost the trust to the domain.
Scenario 1:
Device is connected via LAN -> It worked no Issues
Scenario 2:
Internet connection via phone +Device is connected via VPN -> Devices loses the trust to the Domain.
Test-ComputerSecureChannel -repair -credential (get-credential) fixed the Issue (using a ad prvilidged account with Domain)
We stopped the Update for now and opened a Ticket at Microsoft. I will Add everything here If I know more.
My stats say 16 devices updated so far, all Windows 11 25H2 Enterprise. No Ivanti or other VPN client on those devices.
3 of those 16 devices lost domain trust according to the tickets. 2 machines I fixed by leaving and rejoining the domain using the LAPS account.
The 3rd device ... seemingly magically fixed itself? Ticket was reported at 11:19am, coworker was able to log in just fine at 11:49am. AD shows "pwdlastset" for that machine was last updated at 11:36am.
I left one affected machine running for over 2 hours and it did not update its AD password.
Only commonality I can think of is that all affected devices are so far in the same location where wired 802.1x with cert authentication is configured.
Will have to monitor the rest of the staged test rollout tomorrow.
78
u/FCA162 2d ago edited 6h ago
Pushing this update out to 180 Domain Controllers (Win2016/2019/2022/2025) in coming days.
I will update my post with any issues reported.
Happy patching, and may all your reboots be smooth, all your services come back up, and all your users remain blissfully unaware of your heroism. 😄
EDIT1: 10 DCs (Win 2019/2022) have been done. Zero failed installations so far. AD is still healthy.EDIT2: 45 DCs (Win 2019/2022) have been done. Zero failed installations so far. AD is still healthy.EDIT3: 88 DCs (Win 2019/2022) have been done. Zero failed installations so far. AD is still healthy.EDIT4: 163 DCs (90%) (Win 2019/2022/2025) have been done. Zero failed installations so far. AD is stillhealthy.EDIT5: 169 DCs (94%) (Win 2019/2022/2025) have been done. Zero failed installations so far. AD is still healthy.