Troubleshoot co-management: Bootstrap with modern provisioning
This article helps you understand and troubleshoot issues that you may encounter when you set up co-management by taking path 2: Bootstrap the Configuration Manager client with modern provisioning.
This scenario occurs when you have new Windows 10 devices that join Azure AD and automatically enroll to Intune, and then you install the Configuration Manager client to reach a co-management state.
Original product version: Microsoft Intune
Original KB number: 4520150
Before you start
Before you start troubleshooting, it's important to collect some basic information about the issue and make sure that you follow all required configuration steps. This helps you better understand the problem and reduce the time to find a resolution. To do this, follow this checklist of pre-troubleshooting questions:
- Which Azure AD hybrid identity option did you select?
- What is your current MDM authority?
- Did you set up enhanced HTTP?
- Did you create the cloud services in Azure?
- Did you configure the cloud management gateway (CMG)?
- Did you configure client-facing roles for CMG traffic?
- Did you install the Configuration Manager client in Intune?
Most issues occur because one or more of these steps were not completed. If you find that a step was skipped or was not completed successfully, check the details of each step, or see the following tutorial:
Troubleshooting hybrid Azure AD configuration
If you are experiencing issues that affect either Azure AD hybrid identity or Azure AD connect, refer to the following troubleshooting guides:
- Troubleshoot Azure AD Connect install issues
- Troubleshoot errors during Azure AD connect synchronization
- Troubleshoot password hash synchronization with Azure AD Connect sync
- Troubleshoot Azure Active Directory Seamless Single Sign-On
- Troubleshoot Azure Active Directory Pass-through Authentication
- Troubleshoot single sign-on issues with Active Directory Federation Services
If you are experiencing issues that affect hybrid Azure AD join for managed domains or federated domains, refer to the following troubleshooting guides:
- Troubleshooting hybrid Azure Active Directory joined devices
- Troubleshooting devices using the dsregcmd command
Frequently asked questions
Question 1: What roles do I need to configure co-management?
Here are the required permissions and roles to configure co-management.
Question 2: What log can I use to validate workloads and determine where policies and apps come from in a co-management scenario?
You can use the following log file on Windows 10 devices:
Question 3: How do I validate that my cloud service has a unique DNS name?
To do this, follow these steps:
- Sign in to the Azure portal, go to All Services > Cloud Services (Classic), and then click Add.
- In the in DNS name field, enter a name that you want to use.
- When you have a name that is available for you to use, note it without creating it in the Cloud Service pane.
- Create a CNAME record that maps your domain to <name>.cloudapp.net in both internal and external DNS servers.
Question 4: Where can I find the Configuration Manager client setup MSI?
You can find the ccmsetup.msi file in the following folder on the Configuration Manager site server:
<ConfigMgr installation directory>\bin\i386
Question 5: How do I verify the Configuration Manager client deployment from Intune to the managed Windows 10 devices?
To verify the deployment, follow these steps on the Windows 10 device:
- Open File Explorer, and go to
- Open the ADALOperationProvider.log file with CMTrace, and look for Getting AAD (User) token and Getting AAD (device) token to verify the tokens.
- In CMTrace, open the CoManagementHandler.log file, look for Device is already enrolled with MDM and Device Provisioned to verify the enrollment.
- Open Control Panel, type Configuration Manager in the search box, and then select it.
- Select the General tab, and verify the Assigned management point.
- Select the Network tab, and verify the Internet-based management point.
Configuration Manager allows only an HTTPS-enabled management point for Azure AD-joined clients
This issue occurs if you use Configuration Manager current branch version 1802 or an earlier version. In these versions, management points that you enable for CMG must be HTTPS. Starting in version 1806, the management point can be HTTP.
To fix the issue, update to Configuration Manager current branch version 1806 or a later version.
Whether PKI certificates are still a valid option instead of enhanced HTTP
PKI certificates are still a valid option for you, but they have the following requirements:
- All client communication is done over HTTPS.
- You must have advanced control of the signing infrastructure.
For more information, see Enhanced HTTP.
I can't find the Client Computer Communication tab in Site Configuration
Starting in Configuration Manager current branch version 1906, this tab is renamed to Communication Security.
The Use Configuration Manager-generated certificates for HTTP site systems option is enabled, but no certificate is received
This behavior is expected. It can take up to 30 minutes for the management point to receive and configure the new certificate from the site. You can use the following log to track, monitor, and verify this:
<ConfigMgr installation directory>\Logs\CloudMgr.log
Records for the resources and their associated information from Azure AD aren't created in the Configuration Manager database
When you onboard the Configuration Management site to Azure AD, the Azure AD user resources aren't discovered or populated into the Configuration Manager database. Usually, you receive the 0x87d00231 error in this scenario.
This issue occurs in one of the following situations:
- You didn't successfully configure the API permissions for the app registration in the Azure portal.
- Azure AD User Discovery isn't enabled or configured.
To fix the issue, follow the steps in Azure AD User Discovery to configure API permissions and Azure AD User Discovery. You can use the following logs to check details:
<ConfigMgr installation directory>\Logs\SMS_AZUREAD_DISCOVERY_AGENT.logon the site server
%WinDir%\CCM\logs\CcmMessaging.logon the client
%WinDir%\CCM\logs\LocationServices.logon the client
If the Configuration Manager site is new or recently rebuilt, you must also configure Active Directory User Discovery.
CoManagementHandler.log shows Queuing enrollment timer to fire at...
The ADALOperationProvider.log file on the Windows devices shows Getting AAD (User) token and Getting AAD (device) token. However, the device isn't enrolled, and the last line in CoManagementHandler.log is Queuing enrollment timer to fire at....
This behavior is expected in Configuration Manager current branch version 1806 and later versions. Starting in version 1806, automatic enrollment isn't immediate for all clients. This behavior helps enrollment scale better for large environments. Configuration Manager randomizes enrollment based on the number of clients. For example, if your environment has 100,000 clients, enrollment may occur over several days.
To monitor co-management, go to Monitoring > Co-Management in the Configuration Manager console.
I copied the customized client installation command from the Configuration Manager console, but the Configuration Manager client can't be installed
This issue occurs in one of the following situations:
- The installation parameters in the command don't conform to the supported values.
- The length of the command line is greater than 1,024 characters.
To fix the issue, make sure that the command meets the requirement and the command line isn't more than 1,024 characters long.
Configuration Manager agent state is unhealthy in Intune
Intune evaluates the Configuration Manager agent state based on the
ClientHealthStatus values in the following registry subkey:
The following are possible values of
- 1: Client installed
- 2: Client registered
- 7: Client healthy
- 8: Client install or upgrade error
- 16: Communication error in management point
ClientHealthStatus value is 7 (healthy), Intune considers the Configuration Manager client as healthy if the
ClientHealthLastSyncTime is not older than 30 days.
ClientHealthStatus value isn't 7 (unhealthy), Intune considers the Configuration Manager client as healthy if the
ClientHealthLastSyncTime is not older than 48 hours.
ClientHealthLastSyncTime value is updated by the Client Notification component of Configuration Manager client, and the log file is CcmNotificationAgent.log.
To troubleshoot this issue, check the CcmNotificationAgent.log file if the
ClientHealthLastSyncTime is not up to date. Here is an example:
Updating MDM_ConfigSetting.ClientHealthLastSyncTime with value 2019-04-01T21:42:51Z BgbAgent 4/2/2019 8:42:51 AM 9476 (0x2504)
ClientHealthLastSyncTime value is up-to-date, but the last check-in time of the Configuration Manager agent is 2/1/1900 in Intune, this means that the device compliance policies workload is managed by Configuration Manager. In this case, switch the compliance policies workload to Intune or Pilot Intune.
The CMG connection point shows as disconnected
The issue occurs because of a permissions issue between the remote site system where the CMG connection point role is installed and the primary site.
The remote site system collects the
TrafficData report from the CMG, then sends the data to the primary site through state messages. Here is a sample log snippet of SMS_Cloud_ProxyConnector.log:
SMS_CLOUD_PROXYCONNECTOR 6124 (0x17ec) ReportTrafficData - state message to send: ~~<ProxyTrafficStateDetails ServerName="PS1DP.CONTOSO.COM" StartTime="Date1 Time1" EndTime="Date2 Time2" MaxConcurrentRequests="2"> <EndPoints>~~ <EndPoint Name="BGB" ProxyServer="DOMAINCMG.CLOUDAPP.NET" TargetHost="ps.contoso.com" TotalRequests="2" TotalRequestsWithBearerToken="0" MaxConcurrentRequests="2" TotalRequestBytes="2594" TotalResponseBytes="716" FailedRequests="0"/>~~ </EndPoints>~~</ProxyTrafficStateDetails>~~~~
Because the remote site system is also a management point, these state messages are moved into an outbox that is accessed by MP File Dispatch Manager that sends the files to the primary site. Here is a sample log snippet of mpfdm.log:
SMS_MP_FILE_DISPATCH_MANAGER 7044 (0x1b84) ~Moving 1 *.SMX file(s) from C:\SMS\MP\OUTBOXES\statemsg.box\ to \\PS.contoso.com\SMS_PS1\inboxes\auth\statesys.box\incoming\.
SMS_MP_FILE_DISPATCH_MANAGER 6584 (0x19b8) ~Moved file C:\SMS\MP\OUTBOXES\statemsg.box\___CMUp5onztqe.SMX to \\PS.contoso.com\SMS_PS1\inboxes\auth\statesys.box\incoming\___CMUp5onztqe.SMX
When there is a permission issue, MP File Dispatch Manager can't access the inboxes on the primary site and logs the following error in mpfdm.log:
SMS_MP_FILE_DISPATCH_MANAGER 3828 (0xef4) ~**ERROR: Cannot connect to the inbox source, sleep 30 seconds and try again.
To fix the issue, add the machine account of the remote site system to the Local Administrators group on the primary site.
Clients can't locate the management point by using the CMG, and you receive error 403
When this issue occurs, the following error is logged in LocationServices.log on the client:
[CCMHTTP] ERROR INFO: StatusCode= 403 StatusText=CMGConnector_Clientcertificaterequired LocationServices
Additionally, the following error is logged in SMS_Cloud_ProxyConnector.log on the CMG connection point server:
MessageID: <ID> RequestURI: https://<FQDN>/SMS_MP/.sms_aut?SITESIGNCERT EndpointName: SMS_MP ResponseHeader: HTTP/1.1 403 CMGConnector_Clientcertificaterequired~~ ResponseBodySize: 5274 ElapsedTime: 44 ms SMS_CLOUD_PROXYCONNECTOR
If the CMG connection point server has a valid client authentication certificate, the most possible cause is failure to validate the Certificate Revocation List (CRL) for the certificate. If this is the case, you receive the 0x87d0027e error, and the following error is logged in the CAPI2 event log:
The revocation function was unable to check revocation because the revocation server was offline. 80092013
Additionally, if you enable verbose logging by setting the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\SMS_CLOUD_PROXYCONNECTOR\VerboseLogging registry value to 1, error entries that resemble the following are logged in SMS_Cloud_ProxyConnector.log:
Chain build failed cert: C019CC17EEFA681D154BA9F24F8EAE9640D54C49
Chain 0 status: RevocationStatusUnknown
Chain 1 status: OfflineRevocation
Chain build failed cert: 54E09FEA31FE83F9A8AA5389B8D08B34D42FB3CF
Chain 0 status: RevocationStatusUnknown
Chain 1 status: OfflineRevocation
Not allowed cert: 52E140B1DD16A556AB77932B63DE87955BBC4616 52E140B1DD16A556AB77932B63DE87955BBC4616
Filtered cert count with allowed root CA and has private key: 0
Filtered cert count with client auth: 0
We recommend that, instead of automatically disabling CRL checking, you first make sure that it works. However, if you can't get CRL checking to work correctly, temporarily disable CRL checking for CMG connection points. This lets a client certificate be selected without performing CRL checking, and enables communication with the management point.
For more information about troubleshooting co-management issues, see the following articles:
- Troubleshoot co-management: Auto-enroll existing Configuration Manager-managed devices into Intune
- Troubleshoot co-management workloads
For more information about Intune and Configuration Manager co-management, see the following articles:
- Overview of Windows 10 co-management
- Getting Started: Paths to co-management
- Quickstarts for co-management
- Tutorial: Enable co-management for existing Configuration Manager clients
- How to prepare internet-based devices for co-management
If you have a question or want to get involved with our online community, visit our Intune forum.
You can also submit feedback and ideas to the Intune development team through our uservoice site.
If all else fails and you want to open a support case with the Intune Support team, see How to get support for Microsoft Intune.