Microsoft’s Configuration Manager version 2503 will lose support on September 30, 2026, Pacific Time — but IT administrators shouldn’t treat this as a routine upgrade to the next-in-line version. A co-management scan-source bug, documented by Microsoft and affecting environments where third-party updates are enabled, means that moving to 2509 without a specific post-release rollup could silently break Windows update delivery for many devices. The safest path is straight to 2603, which bakes in the fix.
The Concrete Details: What’s Broken and How It Was Fixed
In Configuration Manager 2503 with KB32851084 installed, and also in bare 2509, a subtle policy conflict can arise when co-management and third-party updates intersect. If an organization has enabled Configuration Manager’s third-party software update feature and has shifted the Windows Update workload to Intune or Windows Update for Business, the client may carry over a partial scan-source policy. That leftover policy can redirect update scans away from the cloud, causing devices to miss quality and feature updates they should be receiving through Intune.
Microsoft’s fix arrived in two forms:
- Configuration Manager 2603 includes the correction outright, via KB36495448.
- For organizations that must remain on 2509, the later rollup KB37864969 delivers the same fix. The April 2026 rollup for 2509, KB36949461, did not contain the scan-source correction.
That’s a critical distinction. A 2509 site that has only applied KB36949461 is still technically vulnerable, even though it’s no longer on 2503. The official support documentation, as highlighted by WindowsForum’s deep-dive analysis, explicitly ties the issue to 2503+KB32851084 and to unpatched 2509. Version 2603 avoids the problem entirely because the fix is integral from the start.
Who’s at Risk — and Who Can Breathe Easy
The bug isn’t a universal fire drill for every Configuration Manager shop. It bites only when a specific set of conditions line up:
- Co-management is enabled and actively used.
- Configuration Manager’s third-party updates feature is turned on.
- The Windows Update workload is assigned (or piloted) to Intune, meaning devices are supposed to fetch updates from Windows Update for Business.
- The site is on 2503 with KB32851084, or on 2509 without KB37864969.
If your environment doesn’t use co-management, or if you haven’t enabled third-party updates, or if you’re still delivering Windows updates through Configuration Manager’s own software update point, you’re likely in the clear. But you still need to leave 2503 before the September 2026 deadline. For everyone else, the upgrade path isn’t just a version bump — it’s a targeted remediation.
The Two Valid Upgrade Paths: Choose Your Target State
Administrators have a straightforward choice, but the completion criterion matters. Do not declare victory the moment the console says “2509.”
- Preferred: Upgrade directly to Configuration Manager 2603. The published change log for 2603 lists KB36495448, the co-management scan-source fix, so the site lands in a fully remediated state. This is the simpler, safer move for most teams.
- Alternative: Upgrade to Configuration Manager 2509 and then immediately install rollup KB37864969. Without that rollup, the scan-source issue persists. Make KB37864969 part of the same change window; don’t defer it as a separate maintenance task.
A quick decision matrix for co-managed environments:
| Current Condition | Required Target State | What to Validate |
|---|---|---|
| 2503 with KB32851084, third-party updates on, Windows Update workload in Intune | 2603, or 2509 + KB37864969 | Confirm co-managed devices receive updates via Intune/WUfB as expected |
| 2503 without the above exposure | Any supported branch (2603 or 2509+latest rollup) | Normal upgrade validation |
| 2509 with only KB36949461 | Install KB37864969 before validation | Re-test co-managed devices’ update path |
| 2603 (already upgraded) | Maintain normal servicing | Post-client-upgrade verification of update behavior |
A Step-by-Step Validation Plan Before the Deadline
Don’t wait until August 2026 to plan. A methodical, light-touch validation now will save outages later.
-
Inventory your site’s true patch level. Log into the Configuration Manager console and check the installed updates. For 2503 sites, note whether KB32851084 is present. For 2509 sites, record installed rollups. Don’t trust project plans — confirm the actual servicing state through the console’s update history.
-
Identify the devices that need a real-world test. Build a small pilot collection of co-managed devices where the Windows Update workload is assigned to Intune. These devices should have third-party updates enabled in Configuration Manager. A handful of representative endpoints is enough; you aren’t testing every machine.
-
Choose your destination before scheduling downtime. Make 2603 the default goal unless a formal change-control process explicitly demands 2509. If you choose 2509, factor in the time to apply KB37864969 within the same maintenance window.
-
Upgrade and monitor. Run the site upgrade through your normal change process. After the site is ready, roll out the updated Configuration Manager client to the pilot collection. Use your established client deployment rings.
-
Prove the fix on real devices. Don’t assume the workload assignment in the console is enough. Force a quality update scan and a feature update offer (if applicable) on a pilot device. Check that the device discovers and offers the updates through its expected path — Windows Update for Business, not a legacy WSUS source. Use Intune reporting and the Windows Update event logs on the client.
If validation fails, don’t start tweaking client-side registry keys or Group Policy as a workaround. Such manual changes obscure the root cause and won’t survive future policy refreshes. Instead, re-check the site’s servicing level and ensure the right rollup is in place.
How We Got Here: The Context Behind the Urgency
Configuration Manager’s current branch model has always come with rolling support deadlines — typically 18 months. Version 2503, released in March 2025, will reach end of support on September 30, 2026. That’s a generous timeline, but the co-management wrinkle makes it more than a routine lifecycle event.
Co-management itself has evolved from a niche migration tool to a mainstream management model. Many organizations now run hybrid environments where endpoint configuration and compliance come from Configuration Manager, while Windows updates flow from the cloud. The scan-source problem underscores how complex these hybrid states can be. A version that appears fully supported can still contain a logic flaw that emerges only when specific workloads shift.
Microsoft’s servicing documentation, as first reported in detail by WindowsForum, shows that the fix was included in 2603 and later backported to 2509 via KB37864969. However, the earlier 2509 rollup KB36949461 omitted it, leaving a gap. That’s why the September 2026 deadline isn’t just a countdown timer — it’s a signal to land on a servicing state that actually resolves known issues, not one that simply exits the unsupported version.
The lifecycle page itself lists only the end date; it doesn’t call out the co-management bug. Administrators who treat the deadline as a version-number-only checkpoint risk walking into a hidden problem. The practical target is 2603, or 2509 with KB37864969, before September 30, 2026.
Outlook: Don’t Wait Until Summer 2026
Leaving Configuration Manager 2503 is mandatory, but the upgrade is not an emergency. Use the time you have. Early adopters of 2603 will get not only the co-management fix but also continued access to both security and critical non-security updates — an important benefit, because older branches eventually receive security-only patches.
If your change control process mandates staying on an odd-numbered branch like 2509 for stability, then lock in KB37864969 as a non-negotiable part of that move. Make it a formal requirement in your upgrade checklist. By the time September 2026 arrives, every site should be on a build where the scan-source policy behaves as intended, and every co-managed device should be verifiably fetching updates from the cloud your workloads dictate.