Introduction
A short and sweet peek into the latest improvement to the enrollment of co-managed devices into Microsoft Intune.
Prior to SCCM 1906 (System Center Configuration Manager), the enrollment into Microsoft Intune required a user to sign in to the device. This has now changed and the device is able to auto-enroll into Microsoft Intune based on its Azure AD device token.
Note: This is not an A-Z guide, so I’m sadly not covering all the basics and requirements around enrollment nor co-management. Instead I’m touching base with some of the interesting parts, based on my own environment, setup and curiosity. 🙂
Hybrid Azure AD Join
There are a good bunch of prerequisites to co-management, but in this example the fun begins when my device is being hybrid Azure AD joined.
- For good measures and all, find the co-management prerequisites here: https://docs.microsoft.com/en-us/sccm/comanage/overview#prerequisites
In order for me to have my on-premises AD joined devices automatically register with Azure AD (and thus be Hybrid Azure AD joined), I’m having below and highlighted client setting configured to Yes: Automatically register new Windows 10 domain joined devices with Azure Active Directory
Note: There’s an equivalent Group Policy called “Register domain joined computers as devices” managing the exact same setting located in Computer Configuration -> Administrative Templates -> Device Registration.
This setting essentially translates into following registry key:
Which again will enable the following scheduled task in Windows 10. It’s disabled by default:
Newly Deployed Device
When digging into a newly deployed device, without actually signing in and taking an immediate look in CoManagementHandler.log, everything is as expected.
The device is not joined to AAD (Azure AD) yet and therefore not enrolled in Intune either.
Looking further into the User Device Registration Windows event log on the device, notice that the workplace join policy (the one also mentioned previously) is being enabled.
I’m not forcing anything here, so think collection updates, inventory and policy refresh in order for the custom client settings to take effect.
And the following entries in the event log shortly thereafter indicates a successful automatic device registration (Hybrid Azure AD Join). So far, so good.
AAD Device Token
What also happens in that same moment, is that ADALOperationProvider.log (the log file doesn’t exist until the device is joined to AAD) will notify you about the AAD device token. Note there’s no user token yet, because I still haven’t signed in.
Enrollment
Fast forward past more collection updates (depending how your co-management pilot collections etc. are structured), CoManagementHandler.log will now reveal when the device is being enrolled into Microsoft Intune.
Notice this is done with the AADDeviceCredentials:
Enrolling device with RegisterDeviceWithManagementUsingAADDeviceCredentials
Device Management Portal
Initially when browsing the new co-managed device in the Microsoft 365 Device Management Portal, the Enrolled by User field will be empty. This is as expected.
Coming back to the same view after signing in to the device, the Enrolled by User field is no longer empty.
ENJOY 🙂
Good learning !! Thank u for the brief.
Hi,
We configured cmg/cdp and co- (1902) The analyzer checker shows everything with green check Marks. Now we have a win10 AAD joined device (not hybrid but pure AAD joined) and enrolled in Intune. If we install the sccm client manually with the install string from the co-mgmt wizard (with ccmhostname and sitecode) the client installs but never gets initialized or contacts sccm/cmg. Its waiting for site assignment. Any guidance in this scenario?
Device-based enrollment also works in 1902 with the latest hotfix installed.
You still need to enable the “AAD\Mobility (MDM and MAM)\Intune\MDM User Scope” in Azure portal to “Some” or “All”, right?
Yeah, I mean I wouldn’t mess with the original prerequisites, as you still want the users to be able to enroll devices regardless of this new addition 🙂
How can I force auto enrollment to try again on a client? I had two clients try to auto enroll and failed due to windows 10 as a platform being blocked in intune. I fixed that but they stopped trying to enroll after the first attempt and now instead say “Auto-enrollment has been cancelled, no more pending enrollment.” in the log.
I would try to manually run the configuration baseline called: ComgmtSettingsAutoEnroll from the configmgr applet in the control panel while monitoring comangementhandler.log. If that doesn’t work, I would look into seeing if the scheduled task which is created for the purpose in: \Microsoft\Windows\EnterpriseMgmt\ is still there and if running the enrollment tasks makes a difference. If nothing turns out working, there are a way into manually resetting the enrollment process, which involves deleting the scheduled task as well as deleting some entries in registry. Let me know how you get on 🙂
Hello,
Thank you for this article!
We’re coming across an issue where we have a few machines that when joining to Azure AD (the machine was previously joined to a local AD), the machine enrolls just fine but Intune does not load onto it (users have the Enterprise Mobility + Security E3 license) and reports as “System Center Configuration Manager” as the registered MDM.
Any assistance would be greatly appreciated!