By Lee Yan | Sr. Service Engineer | Intune Support as a Feature
You’re in the process of getting your new device ready for use for an end user, and then you find that the device shows as pending for certain policies or apps in the console. You’re wondering why – what happened – it’s a clean/brand new device, it's Azure AD joined, and you’ve targeted policies and apps to the user who will use the device. This can be expected, as we explain below – it’ll make sense after we walk through how it works.
When you enroll a Windows device into Intune through Azure AD join with auto-enrollment, the workflow typically starts with a local admin user logged on. Often the user will go through settings > Accounts > Access work or school > Connect, and then the device gets enrolled into Intune. At this point in time, the device will check into the Intune service using the device certificate. The service actually doesn’t know who the logged in user is because the local admin who initiated the workflow is still logged on and the MDM agent cannot get the Azure AD user token. When this happens any user-based policies or user-targeted apps (policies and apps assigned to a user group) will not take effect, and the admin console will show the policy or app as pending for the device. If you are looking for an immediate resolution, you can do one of the following:
- On the device, log off as a local user and log back on as the Azure AD user. You can check on the device if the user is an Azure AD user by running this command from a cmd prompt: whoami /UPN. Make sure the UPN shown is the Azure AD user email address.
- Assign the policy to a device group containing the affected device. Then, from Settings > Accounts > Access work or school, click on the Connected to <aad_account> > Info > Sync to perform a device sync. While typically you want policies to apply to the user, not the device, this is a quick workaround to ensure policies such as encryption reports back compliance.
You can also check the Event logs from the client to determine if you are running into this issue. Below are the event log entries you would see if the logged on user is not an Azure AD user:
From Microsoft-Windows-User Device Registration/Admin, Event 360:
Device is AAD joined (AADJ or DJ++) : Yes
User has logged on with AAD credentials: No
From Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin, Event 212:
MDM Session: Failed to get AAD Token for sync session User Token: (Unknown Win32 Error code: 0xcaa20003) Device Token: (Incorrect function.).
Once the device checks in with the proper user credentials then the status will be updated (typically less than 30 minutes after a device sync).
Note that this does not affect Bring Your Own Device (BYOD) or co-managed devices (those with Configuration Manager and Intune).
Hope this helps explain the device experience when a local admin is logged in!
Post updated:
- 5/18/2020 - Updated with note on BYOD, and the addition of apps in the write-up, and clarification on when this scenario may occur.
