Share via

Intune Troubleshooting: Connector for System Center Configuration Manager

  • Article

The following steps can be used to troubleshoot the Microsoft Intune Connector in System Center Configuration Manager. This is focused on troubleshooting the Connector itself rather than device specific issues although it does start from the point of view of an enrolment problem as this tends to be the first thing that an administrator tests.

The device

  1. Try to un-enrol the device and for the deletion to be replicated to get settled then re-enrolling it if this is an option (test device).
  2.  Try to enrol test devices (same OS) to isolated if it was a device issue. If you can enrol other devices of the same OS, then there is potentially a device specific issue. Ensure you’ve allowed enough time (haven’t been enrolling and un-enrolling the device constantly). Raise a support request with Microsoft Intune support.
  3.  Try enrolling a different OS device to see if there was a platform specific issue. If this works, raise a support request with Microsoft Intune support.

 

The connector

At this stage, you need to move on to the Intune Connector.  One important thing to note is that these log files generate errors in the log file and do not generate verbose status messages.  The troubleshooting process for the Connector is as follows:

  1. Check the CloudUserSync.log file (authorizes users to enrol devices in Intune). You should see it authorizing the users in the service that DirSync/Azure Active Directory Connect synchronised into Azure Active Directory. If the users cannot be found, check with DirSync/AADConnect to see if you have a sync issue. If there is no sync issue, raise a request with Microsoft Intune support.

  2. Check the dmpdownloader.log file to see if the Intune Connector's download component is able to pull messages from the service. A message like the following was the last thing in the log:

    Received 1 messages  SMS_DMP_DOWNLOADER    23/01/2015 15:38:45   5912 (0x1718)

    Received 3 messages  SMS_DMP_DOWNLOADER    23/01/2015 15:48:53   3784 (0x0EC8)

    Received 3 messages  SMS_DMP_DOWNLOADER    23/01/2015 16:49:31   2836 (0x0B14)

    Received 3 messages  SMS_DMP_DOWNLOADER    23/01/2015 17:55:15   5964 (0x174C)

  3. Check the OutgoingContentManager.log (uploads application files to Intune). You should see messages relating to upward content flow. DistMgr.log hands off content to this component when an application is targeted at the Microsoft Intune distribution point in the console. This is important for Windows Phone devices if the signed Company Portal is being used (as opposed to the Company Portal published in the Windows Phone Store).

  4. Check the dmpuploader.log file to see if the Intune Connector's upload component is able to send messages to the service. A message like the following was the last thing in the log:

    StartUpload for replication group CloudDmp last sync version 12170413 ...     SMS_DMP_UPLOADER      23/01/2015 16:55:32   6656 (0x1A00)

    Startload succeeded with transmission ID a36266f9-7663-4625-be03-71f9f89b6a43  SMS_DMP_UPLOADER      23/01/2015 16:55:33   6656 (0x1A00)

    Expecting sync data or sync end message, however message type is DRS_SyncPing  SMS_DMP_UPLOADER      23/01/2015 16:55:34   6656 (0x1A00)

    EndUpload transmission a36266f9-7663-4625-be03-71f9f89b6a43 final data version 12170518 succeeded      SMS_DMP_UPLOADER     23/01/2015 16:55:35   6656 (0x1A00)

    Found sync start for replication group CloudDmp   SMS_DMP_UPLOADER     23/01/2015 18:00:35   6656 (0x1A00)

    StartUpload for replication group CloudDmp last sync version 12170518 ...     SMS_DMP_UPLOADER      23/01/2015 18:00:35   6656 (0x1A00)

    Startload succeeded with transmission ID cee9ce04-3c6d-4f24-97fb-c66355250d31  SMS_DMP_UPLOADER      23/01/2015 18:00:36   6656 (0x1A00)

    Expecting sync data or sync end message, however message type is DRS_SyncPing  SMS_DMP_UPLOADER      23/01/2015 18:00:37   6656 (0x1A00)

    EndUpload transmission cee9ce04-3c6d-4f24-97fb-c66355250d31 final data version 12170624 succeeded      SMS_DMP_UPLOADER     23/01/2015 18:00:38   6656 (0x1A00)

 

The hierarchy

At this stage, you need to ensure that there is not a replication issue between your CAS (where the Connector is installed) and your primary sites (where device data is processed). Note that once a client is enrolled it uses the primary site configured at the time of enrolment. When the primary site in the connector is changed, this only affects new device enrolments.  If you have only one primary site and no hierarchy, you can skip steps 1 & 2 below.

  1. Begin by looking at the Monitoring à Database Replication node in the console to ensure that all sites are showing as healthy. Specifically, we need to ensure that the site data is flowing up from the primary sites to the CAS. Ensure that no replication partners (CAS+Primary, Primary+Secondary) are in maintenance mode.
  2. Run Replication Link Analyser on the CAS and each primary site that process Intune device information.  This should be run locally from the site server with local admin permissions on both the site server and the SQL Server hosting the site database (along with SysAdmin rights to SQL Server). If either this or the previous steps returned issues, raise a case System Center Configuration Manager support.
  3. Ensure the primary site can process the messages, walk through the various log files as follows:
    1. ddm.log (processes the incoming device registration and gives the initial basic information you see in the console)
    2. dataldr.log (processes the incoming hardware inventory being sent by the service via the connector)
    3. statsys.log (processes the incoming state messages sent by the service via the connector that gives information about device compliance and app deployment)
    4. mpfdm.log (at the primary site processes and routes messages from the connector to components, this is also the component that is responsible for message routing on non-hierarchy single site setup)
    5. hman.log (at the CAS (if you have one) routes messages to each device’s assigned primary site for already enrolled clients or to the site configured in the Connector for new devices)

 

File replication

Remember that Site Data flows up the hierarchy to the CAS and is owned by the primary site. The primary site owns the device records in hybrid MDM. In order for the data to be stored in the database and for DRS to replicate it, we need a primary site to process it first. To do then, the CAS (or site hosting the Intune Connector) needs to replicate the messages from the service to a primary site. Which primary site is based on the following:

  • For new devices: messages are sent to the site configured in the Intune Connector, and those devices then become assigned to that site.
  • For already registered devices: messages for that device are sent to the site to which the device is registered. 

Review the following log files as a starting point to troubleshooting file replication issues:

  1. scheduler.log on the sending site (schedules the transmission and ensure that sender scheduler currently allow communication from the CAS to the primary site)
  2. sender.log on the sending site (actually does SMB transmission)
  3. despool.log on the receiving site (this is the component responsible for "despooling" incoming messages that are then routed to ddm.log, dataldr.log, statsys.log based on the type of data)