Technical review: Ricardo Cheing · September 8, 2026
Microsoft Configuration Manager version 2603 isn’t the flashy, feature-packed release some IT teams might expect — and that’s exactly the point. Released to the Early Update Ring on May 5, 2026 and made globally available on May 27, 2026, this update is squarely focused on security hardening, infrastructure stability, and closing the gaps that have historically caused upgrades to fail mid-installation. It’s also the last release before Configuration Manager moves to an annual release cadence, with version 2609 expected later in 2026.
For organizations running a large Configuration Manager current branch hierarchy, co-managing devices with Microsoft Intune, or operating a hybrid endpoint management setup, that stability focus makes 2603 one of the more consequential updates in recent memory. But “stability release” doesn’t mean “risk-free upgrade.” This guide walks through what’s changed, the prerequisites you need in place, the most common risks admins run into, and the checks worth running once the upgrade is live.
What’s New in Configuration Manager 2603
2603 (KB 37426535) isn’t a feature-heavy release — Microsoft’s focus is security, reliability, and modernizing the underlying infrastructure rather than introducing new capabilities. It also bundles several hotfixes that were previously released as standalone packages, so teams that had been applying individual hotfixes manually get a genuine quality-of-life improvement.
Prerequisite-check updates. Microsoft documents prerequisite requirements for components such as ODBC, .NET, and the Windows ADK — worth reviewing closely before you upgrade, since a failed check here is a common blocker.
Security hardening. Improved handling of the Network Access Account (NAA), tightened default settings on the Cloud Management Gateway, and changes to how Microsoft Entra tokens are validated on management points.
Co-management improvements. Refinements to the shared-workload experience between Configuration Manager and Intune.
Client and content delivery fixes. Various fixes related to software updates scans, client reliability improvements and content distribution enhancements across distribution points.
Pre-Upgrade Health Assessment
Before you even get to the prerequisite checker, it’s worth validating the health of the hierarchy itself. Most upgrade problems trace back to conditions that existed before the update was ever launched — not to 2603 specifically. A quick health assessment up front catches those issues while they’re still easy to fix.
Overall hierarchy health and site status
Site and site database health (SQL Server health, database fragmentation, log growth)
Site-to-site replication status across the hierarchy
Remote site system health (management points, distribution points, and other roles)
SQL Server, ODBC, .NET, and Windows ADK versions against the supported matrix
Recovery readiness — confirm a recent, restorable site backup exists
Client pilot strategy — which collection will validate the upgrade before broad rollout
Framing an SCCM upgrade this way also changes the conversation with customers: the real risk usually isn’t the in-console update itself, it’s the condition of the surrounding infrastructure.
The real risk usually isn’t the in-console update. It’s the condition of the surrounding infrastructure.
We run SCCM Upgrade Readiness assessments that check hierarchy health, replication status, and recovery readiness before you schedule a production upgrade — see how we approached this for a recent AWS tenant migration.
Prerequisites Before You Upgrade
Sites on a version older than 2409 must first update to an intermediate version — 2603 cannot be installed directly on anything earlier. Once you’re on a supported starting version, work through the following before you touch Updates and Servicing.
| Requirement | What to Check |
| Starting version | Your hierarchy must be on Configuration Manager 2409 or later. All sites — central administration site, primary site, and any secondary site — must be on the same version before you start. |
| Service connection point | A working service connection point at the top-level site of your hierarchy is required to retrieve the update. It can run in online or offline mode; offline sites use the service connection tool to download the package. |
| Site system roles | Confirm every site system role — management point, distribution point, and any others in use — meets the currently supported requirements before starting. |
| SQL Server | The site database must be running a supported SQL Server version. Also confirm SQL Server 2025 compatibility if you’ve recently upgraded your database tier. |
| ODBC driver | Latest ODBC driver, version 18.4.1.1 or a currently supported/validated later version for SQL Server installed on the site server. |
| .NET Framework | .NET Framework 4.8 is required on site servers, specific site systems, and the Configuration Manager console. Update and reboot before starting. |
| Windows ADK | If you use operating system deployment, verify your Windows ADK and Windows PE / boot image versions are on the supported matrix. |
| Certificates & TLS | Review certificate expiration and disable weak ciphers where TLS configuration hasn’t been revisited recently — this matters more given 2603’s security focus. |
| Management point internet access | New in 2603: management points supporting Microsoft Entra joined users or devices use Microsoft Identity Service Essentials (MISE) for token validation, which requires outbound access to the required Microsoft authentication endpoints. Confirm firewall and proxy rules allow this — particularly important in restrictive network environments. |
Prerequisite checklist
All sites in the hierarchy on 2409 or later
Service connection point online (or offline tool ready) at the top-level site
ODBC driver 18.4.1.1+ installed on all site servers
.NET Framework 4.8 confirmed on all site systems and console
Windows ADK / boot images validated for OSD
Certificates reviewed; weak ciphers disabled
Management points serving Entra-joined users/devices confirmed to have internet access to the required Microsoft authentication endpoints (MISE token validation)
Full site database backup completed
Change control approval documented and maintenance window scheduled
Common Risks During the Upgrade
Plan for a step by step release. Update a group of clients first, check that the software updates and application installation work the way they should, then expand the release to more clients instead of upgrading all the clients in your whole system at the same time.
| Risk | Severity | Why It Happens |
| Mismatched hierarchy versions | High | This happens when you try to update before the hierarchy replication has fully synced all sites to the base version. |
| Mid-install failure | High | Unresolved issues with SQL Server, ODBC, or .NET are common causes of a failed Configuration Manager upgrade. |
| Environmental issues the checker misses | Medium | A passed prerequisite check does not mean firewall, DNS or storage problems are actually fixed. |
| Confusing install vs. update media | Medium | 2603 is not a baseline. New hierarchies must first use the current baseline, then apply the in-console update. |
| Client push installation failures | Medium | Stale credentials on the Client Push Installation Account, or client-side firewall/permission issues, are the typical cause of failed client push installs. This is a separate mechanism from the Network Access Account (NAA) — the NAA changes in 2603 mainly affect content access and certain OSD/workgroup scenarios, not client push authentication. |
| Co-management workload conflicts | Low | Workloads shared between Configuration Manager and Intune may behave inconsistently after the upgrade. |
Post-Upgrade Checks
Once the update shows complete in Updates and Servicing, do not close the console. Walk away. Work through these checks inside your scheduled maintenance window.
Check Updates and Servicing for the latest 2603 hotfixes and security updates before broadly upgrading clients — additional security updates have already been released for 2603 since the initial release
Confirm the Configuration Manager console upgraded successfully (refresh or relaunch if prompted)
Review CMUpdate.log, hman.log and dmpdownloader.log for install errors
Check ConfigMgrSetup.log and sitecomp.log on each site server for role installation issues
Push the updated client upgrade to a pilot collection before broad rollout
Validate software updates scanning and application deployment on pilot clients
Re-run hardware inventory and confirm compliance settings evaluation is reporting correctly
Spot-check operating system deployment / boot image tasks if OSD is in use
Monitor helpdesk tickets for a week for unexpected client behavior
If the Upgrade Fails
Common causes of 2603 failures include: an unresolved prerequisite that blocked the install, or an environmental issue outside the checker’s scope. Here’s how to respond to each.
Prerequisite check fails before install starts
A blocking prerequisite error must be resolved before the install can continue — it can’t be forced past. Open the prerequisite check log, identify the specific site system role or dependency it’s pointing to (ODBC, .NET, ADK), fix it, and re-run the check. Warnings are handled differently and may not necessarily block the install, but review them before proceeding.
Install fails partway through
Stop and check CMUpdate.log and hman.log first — they’ll usually show which component failed. Do not re-run the update immediately; resolve the root cause, then retry.
Site is left in an inconsistent state
Site recovery isn’t simply a matter of restoring the site database — the database, SMS Provider, and site server configuration all need to come back in sync. If you suspect the site is inconsistent, follow Microsoft’s documented site recovery process rather than restoring the database in isolation. Having a recent, verified full site backup is what makes that recovery process viable, which is why that backup step isn’t optional.
Console won’t upgrade after the site update completes
Focus troubleshooting on the machine where the console is installed, not the site server. Confirm .NET Framework 4.8 is present on that machine, and reinstall or update the console if it’s still not upgrading — a partial install is a common cause.
Clients misbehave after a pilot rollout
Halt the phased deployment before it reaches the next ring. Use the pre-production client collection to isolate the pilot, stop promoting to broader collections, and troubleshoot the issue there rather than rolling pilot clients back to a prior client version. Fall back to Microsoft’s documented site recovery process only if the issue turns out to actually require site-level recovery.
FAQ
Can I install 2603 directly on an older version of Configuration Manager?
No. Your hierarchy needs to be on version 2409 or later before 2603 becomes available as an in-console update. Sites on anything older must first update to an intermediate version.
Is 2603 a feature release or a security release?
It’s a security and infrastructure-modernization release. Microsoft’s stated focus is stability, prerequisite validation, and closing gaps tied to the Secure Future Initiative, not new end-user features.
What is the Early Update Ring, and do I need to opt in?
The Early Update Ring lets organizations test a release before its global rollout. Opting in requires running Microsoft’s PowerShell opt-in script against your top-level site server. Once 2603 is generally available, it appears in Updates and Servicing without the opt-in step.
What does a failed prerequisite check usually mean?
Common causes include an outdated ODBC driver, a missing .NET Framework version, or an ADK mismatch. Review the prerequisite check log carefully rather than re-running it blindly — it will point to the specific site system role that’s failing.
Do I need to upgrade clients right after the site update?
Not immediately, but don’t wait long. Several fixes in 2603 only take effect once the client baseline is updated, so push the client upgrade to a pilot group soon after the site-level update completes, then expand.
Don’t let a stability release turn into a scramble.
Our team plans and executes SCCM upgrades with hierarchy health checks, staged rollouts, and a tested rollback plan before anyone touches production.
