By Andrew Armstrong 
If you’ve still got a bookmark for upgrading System Center Configuration Manager 2012 to SP1, it’s time to let that go. That upgrade path is for Server 2008 R2 era infrastructure and has no relevance to a modern estate. Configuration Manager today is “Current Branch”: a rolling, in-console update model with no service packs, and it moves fast enough that staying current is its own small project.
This is particularly worth checking right now. Version 2503 falls out of support on 30 September 2026, version 2603 (released May 2026) is the last release under the old three-times-a-year cadence, and Microsoft’s next release, 2609, is due this month as the first under the new annual schedule. If you’re on anything older than 2509, this guide covers the actual in-console upgrade process, the prerequisites that catch people out, and the failures you’re most likely to hit.
Quick Facts
- Each Current Branch version gets 18 months of support from general availability, split into a critical-updates window and a security-only tail.
- Version
2503reaches end of support on 30 September 2026. Version2509(November 2025) is the current baseline version. - Version
2603is the last release on the old cadence. From2609onward, Configuration Manager moves to one major release a year. - There is no upgrade path directly from ConfigMgr 2012 or 2012 R2. You have to be on a supported Current Branch version to use in-console updates at all.
- Windows Server 2012 and 2012 R2 are no longer supported as site system hosts. You need Server 2016, 2019, 2022 or 2025.
Which version you should actually be running
| Version | Released | Support ends | Baseline? |
2503 | 31 March 2025 | 30 September 2026 | No |
2509 | 12 November 2025 | 12 May 2027 | Yes |
2603 | 5 May 2026 | 4 November 2027 | No |
If you’re planning a fresh hierarchy, install the 2509 baseline media and update in-console from there. If you’re already on a supported version, jump straight to the latest available update rather than installing every version in sequence, in-console updates aren’t cumulative in that sense, each one takes you from your current version to the newest one offered.
Prerequisites before you touch Updates and Servicing
- SQL Server: 2017, 2019 or 2022 only. If your site database is still on SQL 2016, that’s a separate upgrade first.
- ODBC Driver for SQL Server: version 18.4 or later on the site server and any remote SQL server.
- Windows Server: 2016 or newer for every site system role. 2012/2012 R2 will fail the prerequisite check outright.
- Service connection point: must be online and syncing. Offline mode needs the service connection tool run manually first.
- Deprecated roles: remove the enrollment point, enrollment point proxy and device management point roles if they’re still present, they were retired several versions back.
- .NET Framework: 4.8 or later on all site systems.
Running the upgrade
Quick Steps
- Go to Administration > Overview > Cloud Services > Updates and Servicing and confirm the update state has moved from “Downloading” to “Ready to Install”. Check
dmpdownloader.logandhman.logif it’s stuck. - Right-click the update and choose Run Prerequisite Check. Don’t skip this, it catches most of the failures below before they turn into a half-finished install. Watch
ConfigMgrPreReq.log. - Once it passes clean, right-click again and choose Install Update Pack.
- Choose how clients get updated: validate in a pre-production collection first (recommended for anything beyond a lab), or push to all clients immediately.
- Accept the licence terms and let it run. In a CAS hierarchy, the CAS updates first, then primary sites, governed by their service windows.
- Track progress in Monitoring > Updates and Servicing Status and
CMUpdate.logon the site server. - When it finishes, the console prompts you to install the new version. Confirm it under Administration > Site Configuration > Sites, the version and build number should match what you installed.
Secondary sites don’t update automatically. You have to kick those off separately once the parent primary site is done.
Common failures and what causes them
| Failure | Cause / fix |
| SQL change tracking backlog | The database has an unprocessed change tracking queue. Let it clear before retrying, forcing the upgrade through it risks a corrupt state. |
| Pending system restart | A restart is outstanding on the site server or SQL server. Reboot and re-run the check. |
Database upgrade error 0x87d20b15 | Usually a schema mismatch from an incomplete prior update. Check CMUpdate.log for the specific step that failed and rerun. |
| Site systems not on HTTPS/Enhanced HTTP | Recent versions push harder on this. Enable Enhanced HTTP on affected roles before upgrading. |
| SQL Server Native Client / ODBC mismatch | Update the ODBC Driver for SQL Server to 18.4+ on every relevant server, not just the site server. |
| Co-management slider misaligned | If compliance workloads are pointed at Intune but the slider disagrees, fix that before upgrading, it’s flagged as a blocker on recent versions. |
Frequently asked questions
Can I upgrade straight from ConfigMgr 2012 to Current Branch?
No. There’s no supported in-place path from 2012 or 2012 R2 to Current Branch. You need to build a new Current Branch hierarchy and migrate content, collections and clients across, which is a project in its own right, not a single update.
Should I install 2603 now or wait for 2609?
If nothing in 2603’s fix list affects you specifically, it’s reasonable to sit on your current supported version and validate directly against 2609 once it’s generally available, rather than doing two upgrades close together. If you’re up against the 2503 support deadline, don’t wait, get onto 2509 or 2603 now.
What actually breaks if I stay on an unsupported version?
Nothing breaks immediately. You stop getting security fixes and Microsoft support won’t work a ticket on that version. In-console updates still work to bring you forward, so there’s no functional reason to delay beyond inertia.
How long does the in-console upgrade actually take?
The site server portion is usually 30-90 minutes depending on hardware and hierarchy size. Console and client rollout continues afterwards on its own schedule, governed by your service windows and client upgrade settings, so treat the whole thing as a multi-hour to multi-day process, not a single maintenance window.
Discover more from TechyGeeksHome
Subscribe to get the latest posts sent to your email.
