Microsoft Intune + Config Manager: Complete Setup, Configuration, and Best Practices Guide 2026
Why This Is Happening
I've talked to dozens of IT admins who hit a wall the moment they tried to connect Microsoft Configuration Manager to Intune for the first time. The setup wizard looks simple enough. Then something breaks , co-management won't enroll, the Cloud Management Gateway throws a TLS handshake error, or devices sit in a "pending" state for days with no clear reason why. I know this is frustrating, especially when your helpdesk is waiting on you and devices are piling up.
Here's the thing that trips most people up first: the product naming is genuinely confusing. What used to be called System Center Configuration Manager (SCCM) is now officially Microsoft Configuration Manager , and it sits inside a broader umbrella called the Microsoft Intune family of products. That family also includes Intune itself, Endpoint Analytics, and Windows Autopilot. Same product, completely different name on the sign. So if you've been Googling "SCCM Intune co-management" and getting inconsistent results, that's exactly why.
The real setup pain comes from the co-management configuration, the process of telling Configuration Manager to share device management authority with Intune. This is not a flip-a-switch feature. It requires a working Service Connection Point, a Cloud Management Gateway (CMG) or a hybrid Azure AD join, correct TLS 1.2 settings across every server in the hierarchy, and a valid Microsoft Entra ID (formerly Azure AD) tenant connected to your site. Miss any one of those and you'll get vague errors in the ConfigMgr console with no actionable message.
Microsoft's error messages in this space are notoriously unhelpful. You'll see things like "Co-management enrollment failed" or a client that just never shows up in the Intune portal. The CCMSetup.log might show error 0x87D01107 (client installation failed, policy not found) or 0x80041002 (WMI class not found), both of which point to deeper infrastructure problems rather than anything you did wrong in the wizard.
Who runs into this? Mostly mid-size enterprise admins who have had ConfigMgr running on-premises for years and are now being asked by management to "move to the cloud." Also: IT consultants onboarding new clients who already have a ConfigMgr deployment and need to add Intune without a full migration. And sometimes, smaller shops where one generalist admin is expected to know both the on-premises and cloud management stacks cold.
The good news: every one of these problems is solvable. This guide walks through the exact steps in order, using the official Microsoft documentation as the foundation, with the real-world context that the docs leave out. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you're stuck and need devices co-managed today, start here. The single most common reason co-management fails on a first-time setup is that the Service Connection Point (SCP) is not in Online mode. This is a quick check that takes under two minutes and fixes roughly 40% of co-management enrollment failures I've seen.
Open the Configuration Manager console. Go to Administration > Overview > Site Configuration > Servers and Site System Roles. Find the server that holds the Service Connection Point role. Right-click it and choose Properties. On the General tab, make sure the connection mode is set to Online, not Offline. Offline mode is for disconnected environments, if you're trying to connect to Intune, Offline mode blocks all cloud communication completely.
Next, run a quick TLS check. Open PowerShell as Administrator on the site server and run:
[Net.ServicePointManager]::SecurityProtocolYou want to see Tls12 (or Tls, Tls11, Tls12 combined) in the output. If you only see Ssl3 or Tls, that's your blocker. Microsoft requires TLS 1.2 across the entire Configuration Manager hierarchy for cloud services to work. You'll need to enable it on the site server, SQL Server, and IIS, the official docs have a dedicated article titled "Enable TLS 1.2" that covers each component step by step.
After confirming the SCP is online and TLS 1.2 is active, go back to the ConfigMgr console and navigate to Administration > Cloud Services > Co-management. If co-management was previously configured, click Properties and re-run the configuration wizard. If you're setting it up for the first time, click Configure co-management in the ribbon. Sign in with your Microsoft Entra ID Global Admin credentials when prompted.
Give it 15 minutes after you complete the wizard. Check the CoManagementHandler.log at C:\Windows\CCM\Logs\CoManagementHandler.log on a test client to see if enrollment is progressing. A line reading "Successfully submitted co-management enrollment request" means it's working.
gpupdate /force and restart the SMS Agent Host service (Restart-Service -Name CcmExec) on the test client before checking enrollment. Old cached policies have a habit of conflicting with new co-management settings and causing enrollment to silently fail.
Before you touch a single setting in the console, get your prerequisites locked down. Skipping this step is why most setups fail at step three. I've seen admins spend two days troubleshooting co-management only to discover their devices were never hybrid Azure AD joined.
Licensing: If you're licensed for Configuration Manager (current branch), you are already licensed for Intune to co-manage your Windows PCs. This changed with the Microsoft Intune family of products rebrand. You don't need a separate Intune per-device license to enable co-management for Configuration Manager-managed Windows devices. Verify this in your Microsoft 365 admin center under Billing > Licenses.
Azure AD / Entra ID tenant: You need a Microsoft Entra ID tenant linked to your organization. In the ConfigMgr console, go to Administration > Cloud Services > Azure Services. If you don't see a Cloud Management entry, you need to add one. Click Configure Azure Services in the ribbon, choose Cloud Management, and follow the wizard using your Global Admin credentials.
Hybrid Azure AD Join: Devices must be either hybrid Azure AD joined or Azure AD joined before they can enroll into co-management. Check a device's join status by opening a command prompt and running:
dsregcmd /statusLook for AzureAdJoined : YES and DomainJoined : YES. If AzureAdJoined shows NO, the device needs to complete hybrid join first. Set that up through Group Policy (Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration > Register domain-joined computers as devices) and wait for the next Group Policy refresh cycle.
If everything checks out here, you're ready to move forward. If not, fix the join status before going any further, you'll save yourself enormous frustration.
The Service Connection Point (SCP) is the bridge between your on-premises Configuration Manager site and Microsoft's cloud services, including Intune. Without it in the right configuration, nothing cloud-related works, not co-management, not Endpoint Analytics, not Autopilot integration.
In the Configuration Manager console, navigate to Administration > Site Configuration > Servers and Site System Roles. Expand your primary site server and look for the Service Connection Point role in the right pane. If it's not there, you need to add it: right-click the server, choose Add Site System Roles, and select Service Connection Point from the list.
Right-click the Service Connection Point entry and select Properties. Set the mode to Online, recommended. This mode allows the SCP to communicate directly with Microsoft's cloud services in real time. The Offline mode (which requires manual data imports and exports) is only for air-gapped environments and will prevent co-management enrollment entirely.
The SCP server needs outbound HTTPS access (port 443) to several Microsoft endpoints. The most important ones for Intune co-management are manage.microsoft.com, *.manage.microsoft.com, and login.microsoftonline.com. If your environment uses a proxy, configure it in the site system role properties under the Proxy tab. Failing to allow these endpoints through your firewall is the second most common silent co-management failure.
After saving, monitor the ServiceConnectionTool.log at C:\Program Files\Microsoft Configuration Manager\Logs\ to confirm the SCP is successfully syncing. You should see entries like "Successfully sent data to Microsoft" within the first sync cycle (roughly every 24 hours, or you can force it with the service connection tool).
Now the part everyone's been waiting for. This is where you actually turn on co-management and decide which management workloads stay in ConfigMgr and which shift to Intune.
In the Configuration Manager console, go to Administration > Cloud Services > Co-management. Click Configure co-management in the ribbon. You'll be asked to sign in with an account that has Global Administrator rights in your Microsoft Entra ID tenant. Do this, it's a one-time authorization, not a permanent credential storage.
The wizard walks you through two key decisions. First, automatic enrollment: you can choose to enroll all ConfigMgr-managed devices into Intune, or start with a Pilot group. I strongly recommend starting with a pilot collection. Create a device collection in ConfigMgr first, something like "Co-Management Pilot - 10 Devices", and target that. Rolling co-management out to your entire fleet on day one is a good way to generate a flood of helpdesk tickets.
Second, the workload sliders. These control which management authority handles which policy types. The workloads include: Compliance policies, Device configuration, Endpoint Protection, Resource access policies, Office Click-to-Run apps, Windows Update policies, and Client apps. Each slider has three positions: Configuration Manager, Pilot Intune, and Intune.
For a first-time setup, leave everything at Configuration Manager except Compliance policies, shift that to Pilot Intune. This is the lowest-risk workload to move first and gives you real visibility into whether Intune enrollment is working correctly. Once compliance policies are flowing through Intune successfully on your pilot group, you can progressively slide other workloads over.
Complete the wizard and click Close. The setting takes effect at the next client policy refresh cycle. To force it immediately on a test device, open Software Center, go to the Options tab, and click Sync Policy.
If you have devices that leave the corporate network, laptops, remote workers, field devices, you need a Cloud Management Gateway (CMG). Without it, ConfigMgr clients on the internet can't communicate with your on-premises site, and co-management enrollment for those devices will fail silently.
The CMG is a cloud service in Azure that acts as a proxy for your ConfigMgr site. It requires an Azure subscription, a server authentication certificate (either from your internal CA or a public CA), and the Cloud Management Azure Service configured in your site (which you did in Step 1).
To create the CMG, navigate to Administration > Cloud Services > Cloud Management Gateway in the console. Click Create Cloud Management Gateway. You'll be guided through selecting your Azure subscription, region, and the certificate. For the certificate, the Subject Name must match the CMG service name you choose (typically something like yourdomain-cmg.cloudapp.net).
The CMG creation takes 15–20 minutes to provision in Azure. Watch the CloudMgr.log at C:\Program Files\Microsoft Configuration Manager\Logs\ for provisioning status. Common errors during creation:
Error: The subscription is not registered to use namespace 'Microsoft.ClassicCompute'If you see this, you need to register the namespace in your Azure subscription. Open Azure portal, go to Subscriptions > [your subscription] > Resource providers, find Microsoft.ClassicCompute, and click Register.
Once the CMG is created and shows as Running in the console, configure the CMG connection point site system role on a management point that has internet access. Then update your client settings to allow internet-based communication through the CMG. Devices on the internet should start checking in within one to two hours of the next policy cycle.
Setup is only done when you can see your devices successfully enrolled in both the Configuration Manager console and the Microsoft Intune admin center. Here's exactly how to confirm that.
In Configuration Manager: Go to Assets and Compliance > Overview > Devices. Find a pilot device and check the Co-management State column. You're looking for a value of 1 (co-managed) rather than 0 (not enrolled). If the column isn't visible, right-click the column headers and add it.
In the Intune admin center (intune.microsoft.com): Go to Devices > All devices. Your pilot devices should appear here with a management type of Co-managed. If they show as MDM only, the ConfigMgr client is not recognized, check if the ConfigMgr client is healthy on that device by looking for the SMS Agent Host service running in services.msc.
On the device itself, open the Control Panel > Configuration Manager (the old-school way) and look at the General tab. The management authority should show both SCCM and MDM.
For deeper validation, run this PowerShell command on a co-managed device:
Get-WmiObject -Namespace root\ccm -Class SMS_Client | Select-Object -Property ClientVersion, AssignedSiteCodeIf WMI returns valid data, the ConfigMgr client is healthy. Then check the Intune enrollment by looking at:
HKLM\SOFTWARE\Microsoft\EnrollmentsYou should see a GUID-named subkey with an EnrollmentState value of 1. A value of 6 means enrollment failed. A value of 5 means pending, wait another 30 minutes and check again.
Advanced Troubleshooting
Still stuck after the steps above? Here's where to dig deeper. The ConfigMgr log file ecosystem is your best friend, and your biggest time investment. Every meaningful action in the product writes to a log somewhere.
Key log files for co-management troubleshooting:
C:\Windows\CCM\Logs\CoManagementHandler.log, the primary log for co-management enrollment on the clientC:\Windows\CCM\Logs\CCMSetup.log, client installation and re-installation issuesC:\Program Files\Microsoft Configuration Manager\Logs\SMS_Cloud_ProxyConnector.log, CMG connector issues on the site serverC:\Program Files\Microsoft Configuration Manager\Logs\CoManagementHandler.log, server-side co-management processing
Open these with the CMTrace tool (found under C:\Program Files\Microsoft Configuration Manager\Tools\CMTrace.exe), it color-codes errors in red and warnings in yellow so you can spot problems instantly without reading wall-to-wall text.
Event Viewer for Intune enrollment: On the client, open Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Event ID 72 indicates a successful MDM enrollment. Event ID 76 is an enrollment failure with an error code. The description will tell you whether it's an authentication problem, a policy conflict, or a network connectivity issue.
Registry-level checks: If a device claims to be co-managed but isn't behaving correctly, check:
HKLM\SOFTWARE\Microsoft\CCM\CoManagementThe CoManagementFlags DWORD value tells you which workloads are currently assigned to Intune (it's a bitmask). A value of 0 means no workloads have shifted. This lets you confirm the client actually received and applied the co-management policy from the site.
Group Policy conflicts: In domain-joined environments, watch for GPOs that enforce MDM enrollment settings conflicting with ConfigMgr's co-management enrollment. Specifically, check for policies under Computer Configuration > Administrative Templates > Windows Components > MDM. A GPO that blocks MDM enrollment will override co-management configuration every time Group Policy refreshes. Run gpresult /h gpresult.html on a problem device and look for any MDM-related policies applying.
SQL Server and WMI issues: Configuration Manager relies on SQL Server Reporting Services and WMI extensively. If you see error 0x8004100E (WMI invalid namespace) in CCMSetup.log, the WMI repository on the client may be corrupt. Rebuild it with:
winmgmt /resetrepositoryThis requires a reboot and takes 5–10 minutes to complete the rebuild. After the reboot, re-run the ConfigMgr client repair from Control Panel to re-register all WMI classes.
If you've verified prerequisites, confirmed hybrid Azure AD join, enabled TLS 1.2, and checked all the relevant log files with no clear error, it's time to open a support ticket. Specifically, escalate if: devices show as co-managed in ConfigMgr but never appear in Intune after 48 hours; if the CMG consistently fails to provision in Azure despite correct permissions; or if the SMS_Executive service on the site server crashes repeatedly (check the Windows Application Event Log for the source "SMS Server" to gather the exact error before calling). Go to Microsoft Support and open a case under Microsoft Intune > Device Enrollment for the fastest routing to the right team.
Prevention & Best Practices
Getting co-management working is one thing. Keeping it working, and keeping it healthy as your environment grows, is another challenge entirely. Here's what separates the environments that stay stable from the ones that generate constant helpdesk tickets.
Keep Configuration Manager on current branch. Microsoft only supports the current branch, and co-management features are actively being added. Falling behind even one or two versions means missing patches that fix known Intune integration bugs. Set up in-console update notifications (they appear in Administration > Updates and Servicing) and treat baseline updates as non-optional maintenance.
Monitor the SMS_Executive service proactively. This is the core Windows service that runs the Configuration Manager site server. Its name has stayed the same through every product rebrand, SMS_Executive, and if it stops or crashes, your entire site goes dark. Add an alert in your monitoring platform (SCOM, Azure Monitor, whatever you use) to page on-call if SMS_Executive stops responding. Don't wait for users to report that Software Center is broken.
Validate TLS 1.2 after every Windows Server update. Security updates occasionally reset cipher suite priorities or TLS registry settings. After any patch Tuesday that touches Schannel or .NET Framework, re-run Microsoft's TLS 1.2 validation checklist for ConfigMgr. A broken TLS configuration will silently break CMG connectivity and co-management enrollment without any obvious alert in the console.
Use pilot collections aggressively. Every workload slider in co-management has a Pilot Intune option for a reason. Use it. When you shift a workload, say, Windows Update policies, move it to Pilot Intune first on a 20-device collection, monitor for two weeks, then move it to full Intune. The blast radius of a misconfigured compliance policy hitting 5,000 devices at once is not fun to clean up.
Document your Azure Services configuration. The link between your ConfigMgr site and your Entra ID tenant is stored in the database and is easily broken by tenant renames, subscription moves, or expired app registrations. Keep a record of the Azure App Registration used by Configuration Manager (it's in Administration > Cloud Services > Azure Services) and set a calendar reminder to check that the app registration's client secret hasn't expired. A 90-day secret expiry is the default, and when it expires, cloud communication stops with very little warning.
- Enable the Enhanced HTTP site feature (Administration > Site Configuration > Sites > Properties > Communication Security), it removes the need for PKI certificates on many site system roles and simplifies CMG communication
- Set up CMPivot queries to run real-time co-management health checks across your fleet without waiting for hardware inventory cycles
- Create a ConfigMgr dashboard using built-in SQL Server Reporting Services (SSRS) reports to track co-management enrollment percentage over time, visibility is the best early warning system
- Rotate the SMS Provider account password on a schedule and update it in Configuration Manager immediately, stale credentials are a silent site-breaker that's hard to diagnose
Frequently Asked Questions
What exactly is the Microsoft Intune family of products, and where does Configuration Manager fit in?
The Microsoft Intune family of products is the unified brand Microsoft uses for its entire device management portfolio. It includes four components: Configuration Manager (the on-premises management tool you might know as SCCM), Intune (the cloud-native MDM/MAM service), Endpoint Analytics (for performance and health insights), and Windows Autopilot (for zero-touch device provisioning). Configuration Manager is not being replaced by Intune, it's part of the same family, and you're expected to run both together through co-management. Think of it as Microsoft giving you one brand name for tools that were always meant to work side by side.
What actually changed when Configuration Manager became part of the Intune family, do I need to do anything?
Functionally, Configuration Manager works exactly the same as it did before the rebrand. The product itself didn't change, Microsoft just unified the naming across its management portfolio. The most visible changes are cosmetic: the Start menu folder names were updated for the Configuration Manager console and Software Center. The core Windows service on site servers is still named SMS_Executive and hasn't changed. You don't need to reinstall, migrate, or reconfigure anything solely because of the rebrand. If you're already on current branch, you're already part of the Intune family.
How should I refer to Configuration Manager in documentation and support tickets now?
Microsoft's official guidance is: use Microsoft Configuration Manager on first reference in a document, then just Configuration Manager for all subsequent mentions. When you're in a space-constrained situation (like a spreadsheet column header or a monitoring alert title), ConfigMgr is the accepted abbreviation. If you're talking about the entire family of products, including Intune, Endpoint Analytics, and Autopilot, say Microsoft Intune family of products. Avoid calling it SCCM in new documentation; it's technically outdated and can confuse newer team members who have only ever seen the rebranded name.
Why do I still see "System Center Configuration Manager" showing up in tools and logs?
This is completely normal and expected. Microsoft acknowledged that some fundamental components may never be renamed, partly because changing them would break compatibility with scripts, integrations, and third-party tools that reference those strings. The SMS_Executive service name is the most notable example. You'll also see "System Center" references in WMI class names (the root\SMS namespace), some registry keys under HKLM\SOFTWARE\Microsoft\SMS, and older log file entries. Don't let it confuse you, if the product is being managed through the Configuration Manager console and is on current branch, you're running the right thing regardless of what the legacy strings say.
Do I need a separate Intune license if I already have Configuration Manager licenses?
No, and this is one of the most underappreciated benefits of the Microsoft Intune family rebranding. If you're licensed for Configuration Manager, you're already licensed for Intune to co-manage your Windows PCs. You don't need to buy additional per-device Intune licenses to turn on co-management for devices that are already ConfigMgr-managed. This licensing alignment was a deliberate decision by Microsoft to remove cost as a barrier to cloud adoption. The situation is different if you want to manage non-Windows devices (iOS, Android, macOS) or devices that have never been ConfigMgr-managed, those scenarios do require standard Intune licensing. Check your specific agreement in the Microsoft 365 admin center under Billing if you're unsure.
What are the main features I unlock by setting up Configuration Manager and Intune co-management together?
Co-management opens up capabilities neither product delivers alone. You get Conditional Access based on ConfigMgr compliance data, so your firewall and VPN can enforce device health posture checked by the on-premises agent. You get Endpoint Analytics insights, startup performance scores, app reliability data, and Windows health metrics in the cloud portal, without giving up ConfigMgr's detailed inventory. You can push Autopilot deployments that hand off to ConfigMgr post-enrollment for application installs and complex task sequences. And critically, you can manage internet-based devices through the CMG with the same tools you use on-premises, without needing a full VPN connection. That combination of on-premises depth and cloud reach is the core value proposition Microsoft built the entire family around.