Hybrid-joined PCs that wouldn't auto-enroll in Intune, and the CA policy blocking our admins

If your domain-joined PCs are already hybrid-joined to Entra ID, one Group Policy setting will get them into Intune. The PC enrolls itself in the background with the signed-in user's Entra credentials, and nobody has to click anything. That's the theory. In practice we spent a long time on a handful of machines that refused to enroll, and every one of them was used by someone in IT. It turned out to be a Conditional Access policy. Below is the setup we use, how to check it, and how we tracked that problem down.

Make sure hybrid join actually works

Auto-enrollment rides on hybrid join. If the device isn't hybrid-joined, nothing else here matters. On a test PC, signed in as a normal domain user, run this.

dsregcmd /status

Under Device State you want AzureAdJoined : YES and DomainJoined : YES. Under SSO State you want AzureAdPrt : YES. If AzureAdJoined says NO, check that the computer object is in a synced OU, that the service connection point (SCP) is configured, and that the device can reach the Microsoft device registration endpoints. Also look the device up in Entra ID. It should show as "Microsoft Entra hybrid joined" with a registered date, not "Pending."

MDM user scope and licensing

In the Entra or Intune admin center, find the mobility (MDM and WIP) settings for Microsoft Intune and set the MDM user scope to All, or to Some with a group containing the people who sign in to these PCs. Leave the MAM scope alone unless you know you need it. Confirm those users have an Intune license and that your Windows enrollment restrictions allow Windows (MDM) enrollment.

The GPO itself

Create a GPO linked to the OU that holds the computers. Start with a test OU. Then set this.

Computer Configuration
  > Policies
    > Administrative Templates
      > Windows Components
        > MDM
          > Enable automatic MDM enrollment using default Azure AD credentials
              = Enabled
              Select Credential Type to Use: User Credential

"User Credential" is the standard choice here. "Device Credential" exists for specific co-management and ConfigMgr scenarios, so don't pick it just because it sounds more convenient.

When the policy applies, Windows creates a scheduled task under \Microsoft\Windows\EnterpriseMgmt that tries to enroll on a recurring schedule. The next time a licensed, in-scope user signs in, the device enrolls.

Kick it and watch

gpupdate /force
# Confirm the policy landed
gpresult /r /scope computer
# Confirm the enrollment task exists
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" | Select-Object TaskName, State

Sign out and back in as a normal user, give it a few minutes, and then check.

Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 50 |
  Where-Object { $_.Id -in 75,76 } |
  Format-Table TimeCreated, Id, Message -Wrap

What we did about it

Here are the options in the order I'd pick them.

1. Stop signing in to workstations with admin accounts. Give IT staff a normal daily account for their PC and keep privileged roles on separate accounts. The device then enrolls under the normal user, and your admin accounts keep their MFA requirement. This is the one I push for.
2. If you really have to, make a narrow exclusion. Adjust the CA policy so only the enrollment resource shown in the failed sign-in is excluded, and nothing broader. Don't exclude the admins from MFA entirely. Review the change with whoever owns your CA policies and test it with the What If tool.
3. Enroll the affected devices once with a non-admin user, then change the primary user later if you need to.

If you manage several tenants, check each one for a similar admin-MFA policy before you roll this out. I'd assume it's there until you've looked.

A few smaller ones

• Users with a non-routable UPN like @contoso.local can't authenticate to Entra properly. The UPN has to match a verified domain.
• A device that's already MDM-enrolled somewhere else (another tenant or a previous MDM) will fail until you clean that up.
• A device reimaged with the same name can have a stale Entra object. Delete the stale object and let it re-register.
• Sync cycles, the scheduled task interval and policy refresh all add delay. On a big rollout, give it a day before you start chasing ghosts.