Hi everyone, today we have a post by Intune Support Engineer Saurabh Sarkar. In this post Saurabh walks through the auto enrollment process for Windows devices in an Intune/Configuration Manager co-management environment. Whether you’re still thinking about enabling co-management, or you’ve already made the switch and simply want to understand better how the enrollment process works, this is one you’ll definitely want to read. If you have any questions, please post them in the comments sections at the bottom of the page.
Co-management allows you to concurrently manage Windows 10 devices by using both Configuration Manager and Microsoft Intune. It is one of the primary ways to attach an existing Configuration Manager deployment to the Microsoft 365 cloud, and when a Windows 10 device has the Configuration Manager client and is enrolled in Intune, you get the benefits of both services.
When making the move to co-management, there are two primary ways for you to set it up: auto-enrolling existing clients and bootstrapping with modern provisioning via Windows Autopilot. This post is not meant to explain the details of configuring each of these paths to co-management (you can find all of that here) but instead focuses on the process flow that happens during each step of the MDM enrollment process when an existing device auto-enrolls into Intune. Odds are you’ll never experience a problem with this, but if you do, having an understanding of the process will go a long way towards helping you troubleshoot the issue.
This example assumes the following:
- Your Configuration Manager environment is already in place and functioning correctly.
- You’re running a supported version of Configuration Manager.
- The Hybrid Azure AD Join feature is enabled.
- Auto-enrollment is enabled in the Intune tenant.
- The client computer is running Windows RS3 (build 1709) or later.
- The client computer is on-premises domain joined.
- Your account has Intune administrator credentials.
- The client computer is Hybrid Azure AD joined but not MDM enrolled. This will show in the Azure portal under Azure Active Directory -> Devices. An example is below.
The Auto Enrollment Process
1. If the Configuration Manager client is already installed, skip to Step 2. If the Configuration Manager client is not already installed, run Configuration Manager discovery and install the ConfigMgr client on the Windows computer. When complete, verify that ConfigMgr is managing the computer and that it reports its status as Healthy in the ConfigMgr console.
Verifying Client Setup
You can verify successful client installed via the following:
- Check the registry to make sure all the entries have populated. You should find entries similar to those below in the following location:
- Check ccmsetup.log to make sure the client push was successful.
- Check comanagementhandler.log which should state that all the workloads are management via SCCM and that the device is not MDM enrolled.
- Check the Configmgr client app on the device which should show Co-management as Disabled and Co-management capabilities as 1.
2. Now we will enable co-management in the Configuration Manager console. To do this we will have to provide admin credentials for our Intune tenant, thereby linking our ConfigMgr console with Intune.
We also need to specify either All or Pilot for enrollment. This determines how devices are co-managed and auto enrolled. If you select Pilot, only the Configuration Manager clients that are members of the Intune Auto Enrollment collection are automatically enrolled to Intune. If you select All, then automatic enrollment will occur for all Windows 10 computers provided they are running version 1709 or later. In this example I’ll choose Pilot.
3. Now we add the Windows 10 devices we want auto-enrolled into the Intune Auto Enrollment collection. When this happens, Configuration Manager detects that there is a new device in the collection and pushes down a configuration policy to it. Here’s how you find the ID for this configuration policy:
This policy tells the device that it now needs to enroll in Intune as per the co-management settings in the Configuration Manager console. In the client’s Comanagementhandler.log file you can see that a configuration policy (with the same policy ID as above) has landed on the device.
4. Next a scheduled task is created on the client. The task runs DeviceEnroller.exe which enrolls the device into Intune.
Note that DeviceEnroller.exe is found here on the client computer:
Enrollment Experience for a Cloud User with a Valid License
At this point, if the logged-on user is a cloud user (meaning the user was created in Azure or synced to Azure) and the user has an Intune license assigned, enrollment completes successfully.
If you go to the registry location shown below you will see that the device has been enrolled by FooUser and not the user’s UPN, thereby confirming that auto enrollment was triggered by Configuration Manager.
You can also go to Settings -> Account -> Access Work or School on the client and see that the entry for enrollment has been created with an Info option.
Running dsregcmd /status on the device will also tell us that the device is enrolled.
In the Event Viewer on the client computer you will see successful events for enrollment:
Lastly, you can check the comanagementhandler.log file and see that the enrollment was successful:
Experience for a Non-Cloud User
If the logged in user was not a cloud user, or the user did not have a valid Intune/EMS license assigned, or the logged in user is a local administrator, the enrollment attempt will fail.
In the example of a user not having a valid Intune licenser, examining the comanagementhandler.log file will reveal a message stating License of user is in bad state blocking enrollment.
NOTE For information on how to assign an Intune license to a user, see Assign licenses to users so they can enroll devices in Intune
The auto enrollment will be retried 3 times, and successive attempts will also be made each time a new user logs into the device. If the user is assigned a license, or the new logged on user has a valid Intune license, the enrollment will now succeed.
If the enrollment fails to complete after the retries, the enrollment timer will be queued and a subsequent enrollment attempt will be triggered using the AADDeviceCredentials instead. This means that the device will get enrolled into Intune as a userless device, or a without affinity, thus the device is not attributed to any specific user. You can see this inside the log, as shown below.
When it comes to auto enrollment, if the logged in user is a cloud user with an Intune license:
- The enrollment happens instantly.
- The device is associated with a specific user.
If the logged in user is a local admin or a cloud user without a license:
- The enrollment is initially retried depending on the case.
- If enrolling via the user ultimately fails, the device eventually gets enrolled as a userless device.
In both cases, a device entry will be created in the Intune portal under Devices as shown below.
If the user now opens the Configuration Manager client app on the device, they will see that co-management is now enabled:
Note that at this point an Intune administrator do remote actions such as issuing a lock/wipe/reset of the device right from the Intune portal even though all the workloads are still configured for Configuration Manager.
If you’d like to switch even more workloads from Configuration Manager to Intune, you can do that in the Configuration Manager console:
When a workload is switched, configuration policy is again pushed down to the device, updating it with the new setting. This new policy delivery can be seen in the comanagementhandler.log file, where you can see the value of co-management capabilities changing depending upon the new workload set in the console.