This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 0%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERP%3C/text%3E%3C/svg%3E)
The saga with trying to get Co-management continues. We just discovered that 70% of our computers didn't join Azure AD like they were supposed to with the GPO. We think we know how to fix that. Our problem is that on the test machine we are working on after we enable AAD, the device does not enroll in Intune. But if you look at the Configurations for in our case Pilot, it shows as compliant. Looking at the report shows no errors. Unfortunately the CoManagementHandler.log doesn't shine any light on it either since it reports that "Machine is already enrolled with MDM".
I don't know who decided to make these configuration policies hidden in SCCM, but its been an absolute PITA. If I knew what the configuration policy was doing I could go look at what it was doing for detection and maybe do something. As near as I can tell there is no way to unenroll in co-management either.
So far Co-Management has been a lot more trouble than its worth.
From the CoManagentHandler.log
Additional info
In the DeviceManagement-Enterprise-Diagnostics-Provider event log. Two entries show up:
DSREGCMD /status returns
Looking in Azure AD at the device it does not show a user registered to the device. The logged on user is in Azure AD and the account is synced with AD.
If you're not getting a PRT, then all bets are off as this is the main artifact of performing a hybrid AAD join (or a full AAD join) and is used for all subsequent authentication activity involving AAD including co-management (well, Intune enrollment and policy download really).
Here's a good document to help troubleshoot the HAADJ issues: https://learn.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-hybrid-join-windows-current
That's what I figured was the problem. The link you gave me shows it needs TPM, since its a VM that's probably the problem. I'll try and find a physical computer to test on.
As of 1703 (from memory) a TPM isn't specifically required anymore for HAADJ and Windows will fallback to using software for key storage. I have multiple VMs (without virtual TPMs) in my lab that are hybrid Azure AD domain joined (as well as co-managed). There are certainly many possibilities here though.
We have devices in AAD but the PRT isn't set. The ones I've looked at show up as not having a signed in user in AAD. As I dug into one of the devices there was a warning about the TPM needing a firmware update. That might be part of the problem as well. TPM is enabled but it appears Windows 10 isn't using it. If the firmware update would fix it that might solve the problem, but that could be a fair amount of work just figuring out what needs updated.
Looks like after some more research that the customer setup a large majority of their computers without using Secure Boot, TPM, Bitlocker, etc. As a result Co-Management is tripping up on the AzureAdPrt value which is set to NO.