About Intune Primary User

It’s a new year and I’m trying to develop a new writing habit. I’m calling it my “Friday mail sack” as a nod to a hero of mine, Ned Pyle who once ran the DSTalk blog and taught me basically everything I ever knew about Active Directory and Group Policy. If you have a question that should be answered in blog format, please shoot me an email or tweet me!

Question: Hey Scott… What is the difference between a Primary User and Enrolled by user in Intune? Are they the same?

Screenshot of Intune device blade, highlighting Primary User and Enrolled-by user

Answer: The Intune “primary user” and “enrolled by” user properties do different things. While the values usually start out the same, “Enrolled by” is immutable, “Primary” user can change during the device’s lifetime. I will tell a story to explain…

“Enrolled by” user

For a long time, Intune only had the one property, the Intune “Enrolled by” user. That property gets set during user-driven device MDM enrollment and is 100% immutable. To change it, the device would need to be re-enrolled using the UPN of some other user.

The property didn't do a whole lot… It helped you identify devices easier in the portal (for example, searching for a user in the troubleshooting page would yield results for all the devices associated with that user), it also helped for user-targeting scenarios, particularly for iOS and Android mobile devices. The enrolledby user relationship enables you to target a user group with “Scott Duffey” in it and have Intune update policy and apps for all Scott Duffey’s devices. On Azure AD Joined Windows devices, things worked (and still do work) a bit differently since the platform supports logons from multiple users. Assuming the device is Azure AD Joined, it works like this:

• No AAD user is logged on yet — If there is an MDM check-in session while the computer is sitting at Ctrl+Alt+Delete screen, Windows will only present to Intune the Device’s identity when asking for policy. This will be a device-only context MDM session. That means that only device-group targeted policies and apps will apply, no user policy. Not even if there is an enrolledby or primary user relationship.
• User A is logged on — Assuming User A is an Azure AD user and has an Intune license, the check-in session will be combined user+device context. That means that all the policy and apps assigned to the device or user (via their group memberships) will apply.
• User B is logged on — Assuming User A logged off already, User B is free to log on and is treated exactly the same way as User A in terms of which policy and apps will be delivered for them.

To summarize, Windows MDM doesn't give two hoots about who the primary user of the device is. When reaching out to Intune and asking for a policy update it will present whatever identities it has on hand and ask for the policy, be it Device Identity or Device + User Identity.

While Windows MDM happily dealt with multi-user’s, there were two key user self-service scenarios that didn’t work well if more than one AAD user was trying to use the same device:

1. Installing available apps from the Intune Company Portal, and
2. Recovering Bitlocker keys from Azure AD

Company Portal and Available apps

The Company Portal app was restricted to only allow the “enrolled by” user of the device to log in, check device compliance and trigger available app installations. This limitation turned out to be a pretty big problem, especially for EDU customer like schools, who mainly did bulk enrollment using provisioning packages created with the Setup School PC app. It was such a problem because the Intune “EnrolledbyUser” was set as null. There was no way to change the enrolledbyUser property to be the real human that would need to install available apps from the company portal. The same sort of problem was also apparent outside of EDU usage.. for example if you (the IT guy/girl) wanted to impress your boss by setting it up and enrolling it using your own credentials, you’d be stamped as the enrolledby user on it forever. Same deal if you ever tried to use a service account (A Device Enrollment Manager (DEM) account) for bulk provisioning.

Bitlocker self-service key recovery

The other thing that happens (outside of Intune) during this whole device setup process is the creation of a device object in Azure AD. A new Azure AD object gets created and set with two properties:

1. DeviceRegisteredOwner, and
2. DeviceRegisteredUser.

You wanna know which user gets set on these? You guessed it.. the user who authenticated to AAD during the setup process (either during the OOBE or later in the settings app). And guess who is allowed to self-service recover the device’s bitlocker key from Azure AD? That’s right, the DeviceRegisteredOwner.

Screenshot from myaccount.microsoft.com self-service Bitlocker key recovery

Primary User

In late 2019 to mid 2020, the Intune team (Yes, I was involved in this project too) added some features to start to address some of these challenges…

We added the new “Primary User” property to all Intune device objects and made it mutable. We tied many experiences to the Primary User, including the Company Portal and Bitlocker self-service recovery and added a new experience for admins to change the assigned Primary User from one user to another.

We connected this “Change primary user” button to the Azure AD device object too, so that changing the Intune primary user would also update the Azure AD Device Registered Owner and Device Registered User , thus unifying portal experiences and controlling bitlocker self-service recovery experiences.

There are some restrictions that had to be applied to this button. It is disabled in a few situations:

1. The button only works for Azure AD Joined (Or Hybrid AADJ) devices. On other enrollment types, the button is disabled.
2. The user chosen as primary needs to have an Intune license
3. The admin making the change needs permission. We added a permission “Managed Device/Set primary user” for this and added it to some built in roles: Helpdesk Operator, School administrator, and Endpoint Security Manager

We also made some changes to the Company Portal behavior. The company portal can be used by multiple users on the same device, however you must explicitly set it as “Shared” by removing the primary user. Once you’ve done that the user experience is something like this:

Notice the “Shared” tag in the Company Portal experience

Intune now does a pretty good job of assigning primary user when a device enrolls. Check out the table below for Who and When this gets set:

Table of Primary User assignment from Microsoft docs: https://learn.microsoft.com/en-us/mem/intune/remote-actions/find-primary-user#who-is-assigned-as-the-primary-user

Wrap up

Well that’s everything I know about the EnrolledBy User and Primary User property in Inune! I gave you some bonus content around Azure AD device /user properties and also some of the things I’ve learned about device check-in context. I hope you find it helpful!

If you have a question that should be answered in blog format, please shoot me an email or tweet me!

Official Microsoft documentation:

Find the primary user of a Microsoft Intune device.

Change the Intune Primary User - Public Preview Now Available

Learn about Intune:

Learning Microsoft Intune