If you manage Windows laptops that use Always On VPN (a Windows feature that opens a tunnel to the office the moment a laptop comes online, with no user click required), the September 2026 cumulative updates are about to put a regression in front of your help desk. Microsoft has acknowledged the issue and there is no permanent fix yet. There is a workaround, and it does not take long. What I want to walk through is the order to do it in, because the difference between a clean fix and a week of tickets is whether you audit your profile list before users hit the bug. I have made this kind of mistake before, on a different patch, and I am trying not to repeat it.
The first hour: figure out whether your fleet is exposed
Microsoft’s advisory covers three Windows 11 versions, each tied to a specific patch. The two older versions share a KB, which is normal for cumulative cycles. Before you touch any settings, query your endpoint management tool for the KB list and count how many devices come back. If you have a few dozen, you can probably fix this by hand. If you have a few thousand, you want a staged rollout so you can spot any unexpected behavior before the change is everywhere.
Here is what you are looking for, in plain language. Three different Windows 11 versions are affected: 26H1 with one patch, and 25H2 and 24H2 with a second shared patch. If none of your devices are running those patches, you can stop reading and check back next month. If some of them are, the rest of this article is for you.
The reason this hour matters is that the rest of the fix is the same regardless of how many devices you have, but the rollout plan changes based on the count. A staged rollout with a canary group catches the second-order problems before they hit everyone. A fleet-wide change at 5pm on a Friday catches them the next Monday, in front of your users, with no way to roll back.
Why the client breaks, and what the workaround actually does
The VPN client on the affected builds is in a confused state when it tries to negotiate a connection. Always On VPN supports two protocols: IKEv2 (a standard VPN protocol that handles key exchange and encryption together, widely supported on enterprise firewalls) and SSTP (a Microsoft protocol that wraps VPN traffic inside HTTPS so it crosses almost any firewall without special rules). Most enterprise profiles leave the choice to the client by setting Automatic protocol selection, meaning the client tries one protocol and falls back to the other if it fails.
That fallback path is what is broken. On the affected builds, the first attempt does not cleanly give up. The client ends up retrying or reporting that the port it just tried is still in use, which is not the firewall, is not the VPN concentrator, and is not the network. It is the client churning against itself. The error message about a busy port is the symptom to watch for in your help desk feed.
The workaround is to stop the client from choosing at all. Pin the profile to a single protocol and remove the Automatic element. For most environments, IKEv2 is the right pick, because it handles roaming and NAT (network address translation, what lets multiple devices share one public IP) better than SSTP. If you have a specific reason to use SSTP, like a firewall constraint that drops IKEv2 traffic, use SSTP. The point is to pick one and stop negotiating.
How to make the profile change
The profile lives in a small XML file that the Windows VPN client reads. Open the profile in your endpoint management tool and edit two things. Set NativeProtocolType to the protocol you chose, and remove the Automatic element. Push the change through your management tool and verify it landed on a test device before you roll it fleet-wide.
The verification step is the part most teams skip. I would not. Pick one device, push the change, disconnect the network twice, reconnect, and confirm the tunnel comes up cleanly each time. If it does, you have your answer. If it does not, you have caught the problem before it hit 200 laptops. That ten minutes is the cheapest insurance you will buy this week.
The cleanup you should do while you have the hood open
Profile lists accrete. After a few years, you will find profiles for the original pilot, the post-merger cutover, the contractor network, three regional variants, and a couple of test profiles someone forgot to delete. While you are in there anyway, take the time to do the housekeeping.
- Find any profile still pointing at the old DirectAccess paths from before the Always On VPN cutover
- Look for duplicate profiles for the same target with slightly different names
- Spot profiles pointing at VPN concentrators that have been decommissioned
- Rename what is left so the names match what your team actually calls them
None of this fixes the September bug, but it makes the next one cheaper. The cleanup is the kind of work that compounds quietly, and you will be glad you did it the next time Microsoft ships a regression and you have one profile per environment instead of seven.
Document the choice and what to monitor
The boring half of the work is the half most teams skip, and it is the half that decides whether the next person on your team inherits your fix or quietly breaks it again. Write down which protocol you pinned, why you chose it, and which environments it covers. Stick it in the runbook. If you picked IKEv2 for the main corporate network because of how it handles roaming, write IKEv2 pinned 2026-09-25 in response to KB5124012 / KB5124008 regression, see Microsoft advisory. If you picked SSTP for the contractor network because the contractor firewall blocks IKEv2, write that.
Until Microsoft ships a real fix, watch three things in your monitoring. VPN connection success rates per device, especially the post-update cohort. Help desk tickets tagged VPN or remote access, looking for the busy-port pattern. Profile compliance reports, to make sure nobody flipped a profile back to Automatic without telling you. If any of those trends the wrong way, you have a feedback signal before users do. If all three stay flat, you have earned the right to wait for Microsoft’s fix without checking the help desk every morning.
Trade-offs
The honest trade-off is between resilience and simplicity. Automatic protocol selection exists for a reason: it lets a device pick the right protocol based on the network it happens to be on, which is genuinely useful when an employee travels between office, home, and a hotel. Pinning to one protocol removes that flexibility. The cost is usually small, because most environments converge on one protocol anyway, but it is not zero.
The other trade-off is between waiting for a real fix and shipping a workaround now. If you ship the pin today, your users get a working VPN this week. If you wait for Microsoft to ship a fix, your users keep hitting the regression for however long that takes. Microsoft has already shipped emergency out-of-band updates for separate Remote Desktop failures from the same patch cycle, which suggests the September testing process is not catching what it used to catch. I would not wait.
What I would tell past me
Three things, if I could go back to the morning this advisory landed.
- Audit the profile list before you change a single setting. The KB number tells you whether you are affected. The profile list tells you how much work this is.
- Pick one protocol and write down why. Automatic is broken this month and will be a footgun every month it stays on. Pick IKEv2 unless you have a reason not to, and put the reason in the runbook.
- Treat the September cumulative cycle as a multi-incident event. One emergency advisory usually means more are coming. Watch the help desk feed, not just the patch notes.
If you do those three, you will be the team that fixed this in an afternoon instead of the one that is still explaining busy-port errors to remote workers next Friday.