Group Policy Enrollment - Troubleshooting Guide!

Group Policy Enrollment – Troubleshooting Guide!

Enrolling Windows devices into Microsoft Intune using Group Policy Objects (GPO) is a powerful method for automating endpoint management. However, the process doesn’t always go smoothly—misconfigurations, policy conflicts, and system issues can prevent successful enrollment.

In this guide, we’ll walk through common challenges IT admins face when enrolling Windows devices into Intune via GPO, explore troubleshooting techniques, and provide step-by-step solutions to resolve errors. this article will help you identify the root cause and get your devices successfully enrolled in Intune.

Let’s dive in!

Group Policy Enrollment – Verification

Before starting the troubleshooting process, ensure the following prerequisites are met:

  • Auto-enrollment settings: Confirm that auto-enrollment is enabled for users enrolling their devices into Intune. If the “Some” option is selected, verify that the intended users are part of the assigned group. If “All” is selected, no additional action is needed.
Group policy enrollmnet - troubleshooting
  • MDM discovery URL: Ensure the auto-enrollment process is using the correct MDM discovery URL:
    https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
  • Licensing: The affected user must have an active Intune license assigned.
  • Enrollment restrictions: Check the device limit restrictions and platform restrictions in the Intune portal to avoid potential enrollment issues.
  • Device join status: Confirm that the device is Hybrid Azure AD Joined.
    • This can be checked either from the Entra portal. or from the device using dsregcmd /status
Group policy enrollmnet - troubleshooting
Group policy enrollmnet - troubleshooting

Group Policy Enrollment – Troubleshooting

Scenario 1: Device doesn’t exists in Entra portal

  1. Ensure that the device is properly configured for Hybrid Azure AD join. Check that the device is domain-joined and connected to the corporate network.
  2. Confirm that Entra AD Connect is installed and configured correctly. Ensure that the synchronization process is running without errors and that the device is included in the synchronization scope.

To force delta synchronization, run the following command from the device where the Entra AD connect installed

Start-ADSyncSyncCycle -PolicyType Delta

The synchronization process start with “Delta Import” task from the on-prem active directory to import any change, in our scenario we should see 1 “Adds” which is the computer object that is joined to the on-prem active directory and need to be synchronize to Entra AD, it will follow with “Delta synchronization” and end with “Export” to export the object to the Entra AD

Group policy enrollmnet - troubleshooting

Scenario 2: Device exists in Entra portal but no PRT

for the device to complete the enrollment using GPO, it must get primary refresh token “PRT”, which is issued to registered and healthy devices

To confirm if the device has the PRT, use the same command dsregcmd /status, under SSO State “AzureAdPrt”

Group policy enrollmnet - troubleshooting
  1. Check User Login Method
    • The user must log in with their domain credentials (Hybrid Azure AD Join).
    • If they are using a local account or an on-premises-only profile, PRT will not be issued.
    • To verify, run command “whoami” in CMD
    • If the user is logging in with a local account, they must sign in with their work or school account.
  2. Verify Device Registration in Entra Portal
    • Ensure the device is Hybrid Azure AD Joined.
    • make sure that the device is Registered and Activity is recent
  3. Network Connectivity: Ensure that the device has proper network connectivity to reach the Azure AD endpoints. Verify that there are no firewall or proxy settings blocking the communication. The device needs to communicate with Azure AD to obtain a PRT.
  4. Review Event Logs: Check the Event Viewer on the device for any errors related to PRT issuance. Look under the “Applications and Services Logs” > “Microsoft” > “Windows” > “User Device Registration” and also Applications and Services Logs” > “Microsoft” > “Windows” > “AAD” > Operational for relevant events
  5. A great tool that can be used to verify PRT is “DSRegTool” , it can be used to troubleshoot different scenarios, one of it is the PRT
Group policy enrollmnet - troubleshooting
  1. If all above steps didn’t help to get the PRT, next step is to try to re-register the device
    • Remove the affected device from Microsoft Entra ID to clear any existing registration issues.
    • On the impacted device, open Command Prompt as Administrator.
    • Execute the following command to unregister the device:
      • dsregcmd /leave
    • Sign out and sign back in to initiate the automatic device registration task with Entra ID
    • Allow some time for the registration to complete, then verify the status by running:
      • dsregcmd /status
    • If AzureAdPrt is still missing, manually trigger the Automatic Device Join process:
      • Open Task Scheduler (taskschd.msc).
      • Navigate to: Task Scheduler Library > Microsoft > Windows > Workplace Join
      • Run the task named “Automatic-Device-Join”.
      • Restart the device and check the PRT status again

Scenario 3: Device exists in Entra with PRT but not enrolled to Intune

If a device is successfully registered in Microsoft Entra ID and has a Primary Refresh Token (PRT) but is not enrolling into Intune, follow these troubleshooting steps

  1. Verify the Device is in the Correct OU for Group Policy Enrollment
    • Ensure the device is placed in the Organizational Unit (OU) that is linked to the GPO for MDM enrollment.
    • If the device is not in the correct OU, move it to the appropriate location and allow time for Group Policy to sync.
  2. Check Applied Group Policies from the affected device
    • Run the following command in Command Prompt (Admin) to check if the MDM enrollment policy is applied:
      • gpresult /r /scope:computer
    • Look for the MDM Enrollment GPO in the results.
    • If the policy is missing, manually force the Group Policy update
      • gpupdate /target:computer /force
    • Restart the device and check again.
  3. Ensure Correct Credential Type in GPO
    • When enabling MDM Enrollment via GPO, confirm that “User Credential” is selected as the credential type.
      • Open Group Policy Management Console (GPMC).
      • Navigate to: Computer Configuration > Policies > Administrative Templates > Windows Components > MDM
      • Check the setting “Enable automatic MDM enrollment using default Microsoft Entra credentials”.
      • Ensure “User Credential” is selected instead of “Device Credential”.
  4. Review MDM Enrollment Logs in Event Viewer
    • Open Event Viewer (eventvwr.msc) and navigate to: Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin
    • Look for Event ID 72 with the message: Auto MDM Enroll: Succeeded
    • If Event ID 72 is present, auto-enrollment was successful. If Event ID 72 is missing, enrollment failed or wasn’t triggered.
    • If enrollment failed, look for Event ID 76, which may show an error like:Auto MDM Enroll: Failed (Unknown Win32 Error code: 0x8018002b), This indicates an enrollment failure. you can check this “post” for more about device enrollmnet troubleshooting
  5. If enrollmnet is not triggered
    • Auto-enrollment is triggered by a scheduled task created by the enrollment client.
    • pen Task Scheduler (taskschd.msc).
    • nagivate to : Microsoft > Windows > EnterpriseMgmt
    • Look for the task: Schedule created by enrollment client for automatically enrolling in MDM from Microsoft Entra ID
    • This task is created when the Enable automatic MDM enrollment using default Microsoft Entra credentials Group Policy setting is successfully deployed to the target device. The task is scheduled to run every 5 minutes for one day.
    • If the task exists:
      • Open Event Viewer and check the following logs: Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational
      • Event ID 107 → Indicates the task was triggered.
      • Event ID 102 → Indicates the task was completed (even if enrollment failed).
      • if the task not triggered, check if the device is already enrolled before maybe to another MDM solution
        • Open Registry on impacted device using command Regedit as an admin and Delete all GUIDS under location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments form Users device from Registry post taking its backup

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *