deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-15 18:33:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Update enroll-a-windows-10-device-automatically-using-group-policy.md

Browse Source
This commit is contained in:
Denise Vangel-MSFT
2022-04-30 08:13:05 -07:00
committed by GitHub
parent 9ed2801386
commit ebf12600d5
1 changed files with 40 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy.md
View File

@ -18,7 +18,7 @@ ms.collection: highpri
- Windows 10
Starting in Windows 10, version 1709, you can use a Group Policy to trigger auto-enrollment to MDM for Active Directory (AD) domain-joined devices.
Starting in Windows 10, version 1709, you can use a Group Policy to trigger auto-enrollment to Mobile Device Management (MDM) for Active Directory (AD) domain-joined devices.
The enrollment into Intune is triggered by a group policy created on your local AD and happens without any user interaction. This means you can automatically mass-enroll a large number of domain-joined corporate devices into Microsoft Intune. The enrollment process starts in the background once you sign in to the device with your Azure AD account.
@ -42,9 +42,9 @@ The auto-enrollment relies on the presence of an MDM service and the Azure Activ
When the auto-enrollment Group Policy is enabled, a task is created in the background that initiates the MDM enrollment. The task will use the existing MDM service configuration from the Azure Active Directory information of the user. If multi-factor authentication is required, the user will get a prompt to complete the authentication. Once the enrollment is configured, the user can check the status in the Settings page.
In Windows 10, version 1709 or later, when the same policy is configured in GP and MDM, the GP policy wins (GP policy takes precedence over MDM). Since Windows 10, version 1803, a new setting allows you to change the policy conflict winner to MDM. For additional information, see [Windows 10 Group Policy vs. Intune MDM Policy who wins?](/archive/blogs/cbernier/windows-10-group-policy-vs-intune-mdm-policy-who-wins)
In Windows 10, version 1709 or later, when the same policy is configured in Group Policy and MDM, Group Policy policy takes precedence over MDM. Since Windows 10, version 1803, a new setting allows you to change precedence to MDM. For additional information, see [Windows 10 Group Policy vs. Intune MDM Policy who wins?](/archive/blogs/cbernier/windows-10-group-policy-vs-intune-mdm-policy-who-wins)
For this policy to work, you must verify that the MDM service provider allows the GP triggered MDM enrollment for domain joined devices.
For this policy to work, you must verify that the MDM service provider allows Group Policy initiated MDM enrollment for domain-joined devices.
## Verify auto-enrollment requirements and settings
@ -60,12 +60,13 @@ The following steps demonstrate required settings using the Intune service:
![Auto-enrollment activation verification.](images/auto-enrollment-activation-verification.png)
> [!IMPORTANT]
> For BYOD devices, the MAM user scope takes precedence if both MAM user scope and MDM user scope (automatic MDM enrollment) are enabled for all users (or the same groups of users). The device will use Windows Information Protection (WIP) Policies (if you configured them) rather than being MDM enrolled.
> For bring-your-own devices (BYOD devices), the Mobile Application Management (MAM) user scope takes precedence if both MAM user scope and MDM user scope (automatic MDM enrollment) are enabled for all users (or the same groups of users). The device will use Windows Information Protection (WIP) Policies (if you configured them) rather than being MDM enrolled.
>
> For corporate devices, the MDM user scope takes precedence if both scopes are enabled. The devices get MDM enrolled.
> For corporate-owned devices, the MDM user scope takes precedence if both scopes are enabled. The devices get MDM enrolled.
3. Verify that the device OS version is Windows 10, version 1709 or later.
4. Auto-enrollment into Intune via Group Policy is valid only for devices which are hybrid Azure AD joined. This means that the device must be joined into both local Active Directory and Azure Active Directory. To verify that the device is hybrid Azure AD joined, run `dsregcmd /status` from the command line.
4. Auto-enrollment into Intune via Group Policy is valid only for devices which are hybrid Azure AD joined. The device must be joined into both local Active Directory and Azure Active Directory. To verify that the device is hybrid Azure AD joined, run `dsregcmd /status` from the command line.
You can confirm that the device is properly hybrid-joined if both **AzureAdJoined** and **DomainJoined** are set to **YES**.
@ -87,7 +88,7 @@ The following steps demonstrate required settings using the Intune service:
:::image type="content" alt-text="Mobility setting MDM intune." source="images/auto-enrollment-microsoft-intune-setting.png" lightbox="images/auto-enrollment-microsoft-intune-setting.png":::
7. Verify that the *Enable Automatic MDM enrollment using default Azure AD credentials* group policy (**Local Group Policy Editor > Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is properly deployed to all devices which should be enrolled into Intune.
7. Verify that the *Enable Automatic MDM enrollment using default Azure AD credentials* group policy (**Local Group Policy Editor** > **Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **MDM**) is properly deployed to all devices which should be enrolled into Intune.
You may contact your domain administrators to verify if the group policy has been deployed successfully.
8. Verify that the device is not enrolled with the old Intune client used on the Intune Silverlight Portal (this is the Intune portal used before the Azure portal).
@ -105,35 +106,31 @@ Requirements:
- Enterprise has MDM service already configured
- Enterprise AD must be registered with Azure AD
1. Run GPEdit.msc
Click Start, then in the text box type gpedit.
1. Run `GPEdit.msc`. Choose **Start**, then in the text box type `gpedit`.
![GPEdit desktop app search result.](images/autoenrollment-gpedit.png)
2. Under **Best match**, click **Edit group policy** to launch it.
2. Under **Best match**, select **Edit group policy** to launch it.
3. In **Local Computer Policy**, click **Administrative Templates** > **Windows Components** > **MDM**.
3. In **Local Computer Policy**, select **Administrative Templates** > **Windows Components** > **MDM**.
:::image type="content" alt-text="MDM policies." source="images/autoenrollment-mdm-policies.png" lightbox="images/autoenrollment-mdm-policies.png":::
4. Double-click **Enable automatic MDM enrollment using default Azure AD credentials** (previously called **Auto MDM Enrollment with AAD Token** in Windows 10, version 1709). For ADMX files in Windows 10, version 1903 and later, select **User Credential** as the Selected Credential Type to use.
4. Double-click **Enable automatic MDM enrollment using default Azure AD credentials** (previously called **Auto MDM Enrollment with AAD Token** in Windows 10, version 1709). For ADMX files in Windows 10, version 1903 and later, select **User Credential** as the **Selected Credential Type to use**.
:::image type="content" alt-text="MDM autoenrollment policy." source="images/autoenrollment-policy.png" lightbox="images/autoenrollment-policy.png":::
5. Click **Enable**, and select **User Credential** from the dropdown **Select Credential Type to Use**, then click **OK**.
5. Select **Enable**, select **User Credential** from the dropdown **Select Credential Type to Use**, then select **OK**.
> [!NOTE]
> In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later.
>
> The default behavior for older releases is to revert to **User Credential**.
> In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later. The default behavior for older releases is to revert to **User Credential**.
> **Device Credential** is only supported for Microsoft Intune enrollment in scenarios with Co-management or Azure Virtual Desktop because the Intune subscription is user centric.
When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called " Schedule created by enrollment client for automatically enrolling in MDM from AAD."
When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called "Schedule created by enrollment client for automatically enrolling in MDM from AAD."
To see the scheduled task, launch the [Task Scheduler app](#task-scheduler-app).
If two-factor authentication is required, you will be prompted to complete the process. Here is an example screenshot.
If two-factor authentication is required, you'll be prompted to complete the process. Here is an example screenshot.
![Two-factor authentication notification.](images/autoenrollment-2-factor-auth.png)
@ -141,33 +138,33 @@ Requirements:
> You can avoid this behavior by using Conditional Access Policies in Azure AD.
Learn more by reading [What is Conditional Access?](/azure/active-directory/conditional-access/overview).
6. To verify successful enrollment to MDM , click **Start > Settings > Accounts > Access work or school**, then select your domain account.
6. To verify successful enrollment to MDM, go to **Start** > **Settings** > **Accounts** > **Access work or school**, then select your domain account.
7. Click **Info** to see the MDM enrollment information.
7. Select **Info** to see the MDM enrollment information.
![Work School Settings.](images/autoenrollment-settings-work-school.png)
If you do not see the **Info** button or the enrollment information, it is possible that the enrollment failed. Check the status in [Task Scheduler app](#task-scheduler-app).
If you do not see the **Info** button or the enrollment information, enrollment might have failed. Check the status in [Task Scheduler app](#task-scheduler-app).
### Task Scheduler app
1. Click **Start**, then in the text box type **task scheduler**.
1. Select **Start**, then in the text box type `task scheduler`.
![Task Scheduler search result.](images/autoenrollment-task-schedulerapp.png)
2. Under **Best match**, click **Task Scheduler** to launch it.
2. Under **Best match**, select **Task Scheduler** to launch it.
3. In **Task Scheduler Library**, open **Microsoft > Windows** , then click **EnterpriseMgmt**.
3. In **Task Scheduler Library**, open **Microsoft > Windows** , then select **EnterpriseMgmt**.
:::image type="content" alt-text="Auto-enrollment scheduled task." source="images/autoenrollment-scheduled-task.png" lightbox="images/autoenrollment-scheduled-task.png":::
To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. Note that **0x80180026** is a failure message (MENROLL\_E_DEVICE\_MANAGEMENT_BLOCKED). You can see the logs in the **History** tab.
To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. Note that **0x80180026** is a failure message (`MENROLL\_E_DEVICE\_MANAGEMENT_BLOCKED`). You can see the logs in the **History** tab.
If the device enrollment is blocked, your IT admin may have enabled the **Disable MDM Enrollment** policy.
If the device enrollment is blocked, your IT admin might have enabled the **Disable MDM Enrollment** policy.
> [!NOTE]
> The GPEdit console does not reflect the status of policies set by your IT admin on your device. It is only used by the user to set policies.
> The GPEdit console does not reflect the status of policies set by your IT admin on your device. GPEdit is only used by the user to set policies.
## Configure the auto-enrollment for a group of devices
@ -178,7 +175,7 @@ Requirements:
- Ensure that PCs belong to same computer group.
> [!IMPORTANT]
> If you do not see the policy, it may be because you don't have the ADMX for Windows 10, version 1803, version 1809, or version 1903 installed. To fix the issue, use the following procedures. Note that the latest MDM.admx is backwards compatible.
> If you do not see the policy, you might not have the ADMX for Windows 10, version 1803, version 1809, or version 1903 installed. To fix the issue, use the following procedures. Note that the latest MDM.admx is backwards compatible.
1. Download:
@ -219,9 +216,9 @@ Requirements:
- 21H2 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2021 Update (21H2)**
4. Rename the extracted Policy Definitions folder to **PolicyDefinitions**.
4. Rename the extracted Policy Definitions folder to `PolicyDefinitions`.
5. Copy PolicyDefinitions folder to **\\SYSVOL\contoso.com\policies\PolicyDefinitions**.
5. Copy the PolicyDefinitions folder to `\\SYSVOL\contoso.com\policies\PolicyDefinitions`.
If this folder does not exist, then be aware that you will be switching to a [central policy store](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for your entire domain.
@ -238,12 +235,14 @@ This procedure will work for any future version as well.
4. Filter using Security Groups.
## Troubleshoot auto-enrollment of devices
Investigate the log file if you have issues even after performing all the mandatory verification steps. The first log file to investigate is the event log on the target Windows 10 device.
To collect Event Viewer logs:
1. Open Event Viewer.
2. Navigate to **Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin**.
2. Navigate to **Applications and Services Logs** > **Microsoft** > **Windows** > **DeviceManagement-Enterprise-Diagnostic-Provider** > **Admin**.
> [!Tip]
> For guidance on how to collect event logs for Intune, see [Collect MDM Event Viewer Log YouTube video](https://www.youtube.com/watch?v=U_oCe2RmQEc).
@ -260,18 +259,17 @@ To collect Event Viewer logs:
To troubleshoot, check the error code that appears in the event. See [Troubleshooting Windows device enrollment problems in Microsoft Intune](/troubleshoot/mem/intune/troubleshoot-windows-enrollment-errors) for more information.
- The auto-enrollment did not trigger at all. In this case, you will not find either event ID 75 or event ID 76. To know the reason, you must understand the internal mechanisms happening on the device as described in the following section.
- The auto-enrollment did not initiate at all. In this case, you will not find either event ID 75 or event ID 76. To know the reason, you must understand the internal mechanisms happening on the device as described in the following section.
The auto-enrollment process is triggered by a task (**Microsoft > Windows > EnterpriseMgmt**) within the task-scheduler. This task appears if the *Enable automatic MDM enrollment using default Azure AD credentials* group policy (**Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is successfully deployed to the target machine as shown in the following screenshot:
The auto-enrollment process is triggered by a task (**Microsoft** > **Windows** > **EnterpriseMgmt**) within the task-scheduler. This task appears if the *Enable automatic MDM enrollment using default Azure AD credentials* group policy (**Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **MDM**) is successfully deployed to the target machine as shown in the following screenshot:
:::image type="content" alt-text="Task scheduler." source="images/auto-enrollment-task-scheduler.png" lightbox="images/auto-enrollment-task-scheduler.png":::
> [!Note]
> This task isn't visible to standard users - run Scheduled Tasks with administrative credentials to find the task.
> This task isn't visible to standard users, run Scheduled Tasks with administrative credentials to find the task.
This task runs every 5 minutes for the duration of 1 day. To confirm if the task succeeded, check the task scheduler event logs:
**Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational**.
Look for an entry where the task scheduler created by enrollment client for automatically enrolling in MDM from AAD is triggered by event ID 107.
This task runs every 5 minutes for the duration of one day. To confirm if the task succeeded, check the task scheduler event logs:
**Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational**. Look for an entry where the task scheduler created by enrollment client for automatically enrolling in MDM from AAD is triggered by event ID 107.
:::image type="content" alt-text="Event ID 107." source="images/auto-enrollment-event-id-107.png" lightbox="images/auto-enrollment-event-id-107.png":::
@ -279,14 +277,14 @@ To collect Event Viewer logs:
:::image type="content" alt-text="Event ID 102." source="images/auto-enrollment-event-id-102.png" lightbox="images/auto-enrollment-event-id-102.png":::
Note that the task scheduler log displays event ID 102 (task completed) regardless of the auto-enrollment success or failure. This means that the task scheduler log is only useful to confirm if the auto-enrollment task is triggered or not. It does not indicate the success or failure of auto-enrollment.
Note that the task scheduler log displays event ID 102 (task completed) regardless of the auto-enrollment success or failure. The task scheduler log is only useful to confirm if the auto-enrollment task is initiated or not. It does not indicate the success or failure of auto-enrollment.
If you cannot see from the log that task Schedule created by enrollment client for automatically enrolling in MDM from AAD is initiated, there is possibly issue with the group policy. Immediately run the command `gpupdate /force` in command prompt to get the GPO applied. If this still does not help, further troubleshooting on the Active Directory is required.
One frequently seen error is related to some outdated enrollment entries in the registry on the target client device (**HKLM > Software > Microsoft > Enrollments**). If a device has been enrolled (can be any MDM solution and not only Intune), some enrollment information added into the registry is seen:
If you cannot see from the log that task Schedule created by enrollment client for automatically enrolling in MDM from AAD is initiated, there might be an issue with Group Policy. Immediately run the command `gpupdate /force` in command prompt to get the Group Policy Object applied. If you still have an issue, further troubleshooting on the Active Directory is required.
One frequently seen error is related to some outdated enrollment entries in the registry on the target client device (**HKLM > Software > Microsoft > Enrollments**). If a device has been enrolled (in any MDM solution and not only Intune), some enrollment information added into the registry is seen:
:::image type="content" alt-text="Outdated enrollment entries." source="images/auto-enrollment-outdated-enrollment-entries.png" lightbox="images/auto-enrollment-outdated-enrollment-entries.png":::
By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational** event log file under event ID 7016.
By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs** > **Microsoft** > **Windows** > **Task Scheduler** > **Operational** event log file under event ID 7016.
A resolution to this issue is to remove the registry key manually. If you do not know which registry key to remove, go for the key which displays most entries as the screenshot above. All other keys will display fewer entries as shown in the following screenshot: