Deploy an Intune application with user device affinity

Today I’m going to show how we can achieve user device affinity with Intune application deployment as known from ConfigMgr. When we are going to deploy applications to users, we are independent of the user’s devices. The application belongs to a user and it can be installed or it gets automatically installed on all his devices. Compare it with the actual SaaS licensing model. We enable a user to use Microsoft 365 and we are not enabling a device. The user is enabled and the user can use the software on different devices. It makes a lot of sense to deal with Win32 applications in the same way. In fact, if we want applications to be shown in the Company Portal, we already need to make them available for a user group and not a device group.

In the case of the Company Portal and available applications this works fine and non-primary users are also prevented from installing further software. Here is an example when a non-primary user tries to use the Company Portal

Well done this works as intended 👌.

Maybe a short side story here as it fits in perfectly in, the update process requires that users are clicking on newly published updates. This is a broken application lifecycle in my opinion!

Even if applications are installed by users from available assignments, an update should be installed later on in the background, this is common practice. This behavior is true for every other App store, the MS Public Store, Apple App Store, Google Play Store, except the Company Portal. This is still a real design flaw and blocker for a lot of people to use the Company Portal. Users won’t go to the Company Portal periodically to check for updates! And updates are more important than ever in a world where bad actors out there trying to hijack user devices for evil things like ransomware etc. Please Microsoft go and fix this as well and align Company Portal to the common behavior of app updating even for available assignments in the future 🙏.

Back to our topic. We have seen user device affinity with apps assigned as available. Sadly, in the required assignment scenario we miss a real user device affinity. There is a primary user and an enrollment user set during enrollment on an Intune device object:

But we are missing something like an Intune filter property “primary user” to install only for primary users. This would solve the issue with the required assignment scenario. This property is until now (August/2022) not available 🥺

Out-of-the-box there is no option to assign applications to a user and let the required assignment install on all his primary devices in Intune. Meaning if a user has required assignments and he will log on to a different device (device of the colleague) it will trigger and install all of his assigned required applications on the colleague’s device.

People using ConfigMgr (or have used ConfigMgr) are aware of the user device affinity feature in ConfigMgr. This was designed to enable application assignments to users instead of deploying the application to all user’s devices. User device affinity automatically makes sure that the application installs on all devices that are associated with that user. This is what I want to get back to with Intune.

Luckily the Intune application model was designed to have requirement rules. These rules can also be PowerShell scripts. We can specify the requirements as a PowerShell script that devices must meet before the app is installed. Perfect, then let us build some Primary User support for Intune applications.

Here is the basic idea:

Check with the application requirements PowerShell script if the current logged on user is also the primary user of the device. Based on the result the application installation is allowed or denied.

After some research I couldn’t find the primary user information on the device, but the initial enrollment user information is available 💪. This works as well but has some restrictions. That means as long as the enrollment user ist still the primary user (nobody changed the primary user in Intune) the enrollment user equals the primary user.

As a consequence, there is no support for primary user change, that would mean the device has to be rebuilt. For me it is a small downside, in my opinion an UPN change or primary user change often introduces other side effects and results anyway in a re-deployment scenario.

The script logic is now, getting the enrollment user (which is the primary user) and comparing it to the currently running explorer.exe user account. If the comparison matches the current logged on user is the enrollment user and we can install (Requirement script returns “PrimaryUser”) otherwise it is a secondary device (Requirement script returns “SecondaryUser”) and we will not let the application install. Here is an example how to check for the requirement rule result in Intune:

There are some special scenarios in which we can’t get enrollment user information. For example, on Windows 365 (Cloud PCs) and during Autopilot Pre-Provisioning (aka White Glove). Also, if the explorer.exe user account is defaultUser* or System, we are running in OOBE/Autopilot. In these cases, we still want the apps to be installed, here we simply return “PrimaryUser” to trigger the install.

Here is an example of the working requirement script and the result in Intune. On a device enrolled by my admin account:

I assigned an Intune application (Google Chrome) with the requirement rule for Primary User. The rule is defined as shown above:

The assignment is done to all my admins and users:

Which means that we expect the application Google Chrome to be installed for Obi-Wan Kenobi (Admin account) as he is the enrollment user (=primary user) and for Luke Skywalker (User account) we expect it to be blocked by the requirement rule. If we look at the install status of the application we see exactly this:

There is also another nice view (introduced not long ago) on the device under the managed apps section where you can see the Primary user and secondary users:

for Luke Skywalker we see the expected not applicable here as well:

As shown with some PowerShell script logic we can achieve user device affinity also for Intune applications. To get the script look here in my GitHub Repository:

https://github.com/okieselbach/Intune/blob/master/Detect-PrimaryUser.ps1

Hopefully this demonstrates the flexibility of requirement rules especially with the usage of PowerShell scripts and solves an issue which is hopefully built natively into the Intune service at some point in time. For the time being anyone can use the script to have some user device affinity support in Intune.

Happy application deployment to you all!