%3CLINGO-SUB%20id%3D%22lingo-sub-1122343%22%20slang%3D%22en-US%22%3ERe%3A%20Support%20Tip%3A%20Configuration%20Policy%20Shows%20as%20Pending%20on%20Windows%20Devices%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1122343%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20device%20will%20be%20assigned%20to%20the%20first%20user%20logging%20in%2C%20with%20no%20possibility%20to%20change.%20So%20not%20really%20a%20solution%20until%20this%20is%20fixed%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fmicrosoftintune.uservoice.com%2Fforums%2F291681-ideas%2Fsuggestions%2F31356574-change-registereed-owner-for-corporate-owned-devic%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fmicrosoftintune.uservoice.com%2Fforums%2F291681-ideas%2Fsuggestions%2F31356574-change-registereed-owner-for-corporate-owned-devic%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1121378%22%20slang%3D%22en-US%22%3ESupport%20Tip%3A%20Configuration%20Policy%20Shows%20as%20Pending%20on%20Windows%20Devices%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1121378%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSTRONG%3EBy%20Lee%20Yan%20%7C%20Sr.%20Service%20Engineer%20%7C%20Intune%20Support%20as%20a%20Feature%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CDIV%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EYou%E2%80%99re%20in%20the%20process%20of%20getting%20your%20new%20device%20ready%20for%20use%20for%20an%20end%20user%2C%20and%20then%20you%20find%20that%20the%20device%20shows%20as%20pending%20for%20certain%20policies%20in%20the%20console.%20You%E2%80%99re%20wondering%20why%20%E2%80%93%20what%20happened%20%E2%80%93%20it%E2%80%99s%20a%20clean%2Fbrand%20new%20device%20and%20you%E2%80%99ve%20targeted%20policies%20to%20the%20user%20who%20will%20use%20the%20device.%20This%20is%20expected%2C%20as%20we%20explain%20below%20%E2%80%93%20it%E2%80%99ll%20make%20a%20lot%20of%20sense%20to%20you%20after%20we%20walk%20through%20how%20it%20works.%3C%2FFONT%3E%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EWhen%20you%20enroll%20a%20Windows%20device%20into%20Intune%2C%20the%20workflow%20typically%20starts%20with%20a%20local%20admin%20user%20logged%20on.%20Often%20the%20user%20will%20go%20through%20settings%20%26gt%3B%20Accounts%20%26gt%3B%20Access%20work%20or%20school%20%26gt%3B%20Connect%2C%20and%20then%20the%20device%20gets%20enrolled%20into%20Intune.%20At%20this%20point%20in%20time%2C%20the%20device%20will%20check%20into%20the%20Intune%20service%20using%20the%20device%20certificate.%20The%20service%20actually%20doesn%E2%80%99t%20know%20who%20the%20logged%20in%20user%20is%20because%20the%20local%20admin%20who%20initiated%20the%20workflow%20is%20still%20logged%20on%20and%20the%20MDM%20agent%20cannot%20get%20the%20Azure%20AD%20user%20token.%20When%20this%20happens%20any%20user-based%20policies%20or%20user-targeted%20apps%20(policies%20and%20apps%20assigned%20to%20a%20user%20group)%20will%20not%20take%20effect%2C%20and%20the%20admin%20console%20will%20show%20the%20policy%20or%20app%20as%20pending%20for%20the%20device.%20If%20you%20are%20looking%20for%20an%20immediate%20resolution%2C%20you%20can%20do%20one%20of%20the%20following%3A%3C%2FFONT%3E%3C%2FDIV%3E%0A%3COL%3E%0A%3CLI%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EOn%20the%20device%2C%20log%20off%20as%20a%20local%20user%20and%20log%20back%20on%20as%20the%20Azure%20AD%20user.%20You%20can%20check%20on%20the%20device%20if%20the%20user%20is%20an%20Azure%20AD%20user%20by%20running%20this%20command%20from%20a%20cmd%20prompt%3A%20whoami%20%2FUPN.%20Make%20sure%20the%20UPN%20shown%20is%20the%20Azure%20AD%20user%20email%20address.%3C%2FFONT%3E%3C%2FLI%3E%0A%3CLI%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EAssign%20the%20policy%20to%20a%20device%20group%20containing%20the%20affected%20device.%20From%20Settings%20%26gt%3B%20Accounts%20%26gt%3B%20Access%20work%20or%20school%2C%20click%20on%20the%20Connected%20to%20%3CAAD_ACCOUNT%3E%20%26gt%3B%20Info%20%26gt%3B%20Sync%20to%20perform%20a%20device%20sync.%20While%20typically%20you%20want%20policies%20to%20apply%20to%20the%20user%2C%20not%20the%20device%2C%20this%20is%20a%20quick%20workaround%20to%20ensure%20policies%20such%20as%20encryption%20reports%20back%20compliance.%3C%2FAAD_ACCOUNT%3E%3C%2FFONT%3E%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EYou%20can%20also%20check%20the%20Event%20logs%20from%20the%20client%20to%20determine%20if%20you%20are%20running%20into%20this.%20Below%20are%20the%20event%20log%20entries%20you%20would%20see%20if%20the%20logged%20on%20user%20is%20not%20an%20Azure%20AD%20user%3A%3C%2FFONT%3E%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EFrom%20Microsoft-Windows-User%20Device%20Registration%2FAdmin%2C%20Event%20360%3A%3CBR%20%2F%3EDevice%20is%20AAD%20joined%20(AADJ%20or%20DJ%2B%2B)%20%3A%20Yes%20%3CBR%20%2F%3EUser%20has%20logged%20on%20with%20AAD%20credentials%3A%20No%20%3C%2FFONT%3E%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EFrom%20Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider%2FAdmin%2C%20Event%20212%3A%20%3CBR%20%2F%3EMDM%20Session%3A%20Failed%20to%20get%20AAD%20Token%20for%20sync%20session%20User%20Token%3A%20(Unknown%20Win32%20Error%20code%3A%200xcaa20003)%20Device%20Token%3A%20(Incorrect%20function.).%3C%2FFONT%3E%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EOnce%20the%20device%20checks%20in%20with%20the%20proper%20user%20credentials%20then%20the%20status%20will%20be%20updated%20(typically%20less%20than%2030%20minutes%20after%20a%20device%20sync).%20%3C%2FFONT%3E%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%3CFONT%20style%3D%22background-color%3A%20%23ffffff%3B%22%3EHope%20this%20helps%20explain%20the%20device%20experience%20when%20a%20local%20admin%20is%20logged%20in!%3CBR%20%2F%3E%3C%2FFONT%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1121378%22%20slang%3D%22en-US%22%3E%3CP%3ERead%20this%20article%20for%20more%20information%20on%20when%20a%20new%20Windows%20device%20shows%20as%20pending%20for%20certain%20policies%20in%20the%20console.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1121378%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EIntune%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EMDM%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESupport%20Tip%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWindows%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E

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:
  1. 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.
  2. 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. 
6 Comments
Senior Member

The device will be assigned to the first user logging in, with no possibility to change. So not really a solution until this is fixed: https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/31356574-change-registereed-ow...

Occasional Visitor

I usually use DEM account with autoenroll into Intune as first user and have no problem with applying policies. As per changing primary user - since last version of Intune, I have a button for it in Device Properties, but it doesnt work (ticket already created) :)

Hi @AlenaS, thanks for the feedback! Unfortunately the UI has gone out a little early. We’re working on correcting that (removing the UI), as there are still a few more bits that need to be done before this feature is ready. Stay tuned to our What's new for an announcement on when it'll be ready! :smile:

Hi @AlphaSeb, we're excited to announce that we started rolling out a feature giving you the ability to change a device’s primary user. More info can be found here: Change the Intune Primary User – Public Preview Now Available.

Senior Member

@Intune Support Team thank you! As I'm a very close follower of your blog I have spotted this already and tried it out! It seems to work for Windows Devices, but not for iOS Devices:

I want to "Remove primary user" from a shared iOS Device:


1) I navigate to the devices properties and click "Remove Primary User"

2) I click "Save"

3) I get the confirmation that it has been saved successfully

4) As I want to navigate away, Edge says that "Your unsaved edits will be discarded"

5) I navigate back and forth to the page, and the updated value has not been saved.

 

AlphaSeb_1-1584087225142.png

Microsoft

@AlphaSeb Changing Primary user is only supported on Windows devices, not iOS. We've fixed a bug where the UI was incorrectly showing for iOS devices but as you've noted, the change does not apply. You should see this bug resolved as the UI is updated with 2003 (over the next week or so).