Intune application targeting for Windows 10 Win32 apps explained

In this article we will dive into the basics of Windows 10 application assignments (Win32 apps) in Intune and the various differences depending on the situation (single user associated device, shared devices, non-primary devices). Microsoft Intune differentiates between the install intent based on the app assignment (required install, available for enrolled devices, or uninstall). Actually this is only one piece to control the behavior. We also need to assign an user group or device group for the app install intent. Lastly the fact if a user is the primary user of the device will also influence the ability to install applications. Summarized we control the install of Windows 10 Win32 applications through the following facts:

App install intent:

• Required assignment
• Available for enrolled devices assignment
• Uninstall assignment

Group assignment:

• User group assignment
• Device group assignment

Additional properties:

• Primary user of the device

If we have a look at the application assignment screen we will see the options from above except the primary user behavior as this is an implicit behavior which I will explain later in the article:

Let’s start with a required user assignment of our demo application 7-zip. I will not walk through every combination but I will show the most important ones to get the general understanding. I have chosen to “Show all toast notifications” and availability and install “As soon as possible“:

The Intune Management Extension (IME) is the small helper agent on Windows 10 responsible to install our apps (See my deep dive on IME here: Part 1, Part 2, Part3). The regular polling interval of the IME is every 60 minutes. Within the next 60 minutes the user will see the notification of the required change (Tip: for debugging or testing you can restart the service “Microsoft Intune Management Extension”, this will trigger an instant lookup for a new policy, the new install intent):

the user will be notified of the download progress:

and finally the success message if everything went successful or a failed message in case of an error:

This behavior is always the same when the end user notification is set to “Show all toast notifications“. Meaning you can use user or device based assignments and even set to required or available for enrolled devices. If you have chosen to hide the toast notifications they are simply not shown.

This is pretty straight forward and basic application distribution.

What about “available for enrolled devices”, how are they made visible to the end user?

First we need the Company Portal on the device. This can be achieved by installing it via the built in Windows 10 Microsoft Store, just search for Company Portal and install it:

If you have setup the Microsoft Store for Business (MSfB) integration with Intune you can also assign the Company Portal to your users directly via Intune as a required install. The client will reach out to the Microsoft Store and downloads the latest version and installs it on the device. This is the recommended way of distributing the Company Portal.

If you did not integrate Microsoft Store for Business with Intune or you have troubles because of connectivity to the Microsoft Store, you might have blocked network access to the Microsoft Store or Conditional Access requires a compliant device to authenticate to the Microsoft Store but the device is not flagged as compliant in time during OOBE phase, you can use the Offline version of the Company Portal. After you followed the linked guide and imported the offline version you will see the “Company Portal (Offline)” version as well:

Keep in mind that the Company Portal (Offline) version should be assigned to a device group to work properly.

As soon as you deployed the Company Portal you will see all apps which are assigned as “Available for enrolled devices” to your user groups like this:

After a click on one of the apps and choosing Install you will see the same toast messages and some progress status within the Company Portal about the install. Finally the software gets installed on the device.

Let’s summarize what we have seen so far. We can assign apps as required for install without user interaction and we can make them available via Company Portal. We have options to show or hide the additional toast messages. What I did not mentioned until now is that we also have an option to specify a time window when to make the app available and the final installation deadline.

These options should give you enough flexibility to install your necessary apps for the users and provide them an additional catalog of available apps for install on their personal needs.

For typical user devices, devices which belong to one person, this is basically all we need. We are assigning all the apps to a user as required or available and even in case the person gets a new device, all the required apps getting installed again and others are available for install. Great, this is a true user to app relationship and the device does not matter in that situation. Device based assignments do have the problem that the management system looses all assignments when a device gets replaced. This is not the case with user assignments and this normally greatly simplifies internal processes around application assignments.

What about the primary user of the device and app assignments?

If we have a closer look at the devices in Intune we will see two properties, Enrolled by and Primary User:

It might look like that these properties don’t have any impact but this is not true. The primary user of a device controls the ability to install available apps! This is quite important to know as it will have some consequences.

Let’s have a look at the typical user device, belonging to one person (Autopilot user-driven deployment). This person can install all his software on his device. As soon as a user logs in to a device where he is not primary user the Company Portal will not let him install any apps:

Actually this is a good thing as it prevents people from doing unnecessary application installs when users are using other devices in situations where they might have forgotten their own device or in case they just want to look up something quickly and only having access to a colleagues devices.

As soon as we convert a device to a shared device by enrolling it without a primary user (Autopilot self-deploying mode) or removing it as soon as the feature becomes available, we will get the chance to install the apps again. A shared device has no primary user:

And will show the apps again in the company portal:

Is there a way to change the primary user of a device?

Currently there is no way to do this, but it is in development (Intune features in development – 19th of February 2020). Microsoft Intune will provide a way to change the current primary user to a different one for Hybrid and Azure AD joined devices (not co-managed devices!). This way a device can easily re-purposed and given to a different user. Within Intune on the device object there will be some UI controls to change or remove the primary user in future.

Right now, it is possible to change or remove the primary user of a device by utilizing a complete reset. For Azure AD joined devices a Windows Autopilot Reset will remove the primary user and the next user who signs in after the reset will be set as the primary user.

UPDATE (Week of March 9, 2020): Change Primary User for Windows devices has been released
https://techcommunity.microsoft.com/t5/intune-customer-success/change-the-intune-primary-user-public-preview-now-available/ba-p/1221264

What about shared multi-user devices?

As soon as we support multi-user devices we need to enroll them as shared device, or remove the primary user (with the upcoming feature) to get the available apps functionality in company portal. Another option would be to use device group assignments for applications in Intune. If we have chosen user assignments as required app installs, even when I’m not the primary user of the device, the app gets installed. This could result in installations when users with required installs are switching devices!

Ideally Intune would support user assigned, required app installs for “primary users only” to prevent unnecessary installs.

A possible idea to prevent this from happening is, using some clever scripting logic within the app packages.

A device enrolled as Autopilot user-driven deployment, but used as a shared device, is still bound to the enrollment user. In that case the “available apps” are not available in the company portal. Required apps assigned to the user would be installed:

There is the option in Intune to use device group assignment for required app installs. We can assign applications to device groups as required install to prevent switching users triggering required installs. We can choose the same toast notification behavior and availability/deadlines.

If we use device assignments we have to deal with some extra situations. In case of device replacement the app assignments need to be restored for the new device. Device based assignments are also challenging as Azure AD dynamic device groups only have a limited set on attributes available for grouping devices. (see Dynamic membership rules for groups in Azure Active Directory).

This makes it difficult to automatically group all devices based on custom attributes. For example attributes representing basic things like the region like EU, US or more specific Germany, Spain, France etc. would be great. I can imagine all kind of situations where some additional attributes would be a live saver. Imagine two attributes like shared device and region. This would give us the chance to group shared devices by region or country and then assign them necessary apps for required install. Hopefully Microsoft will provide something like this in future, we have to wait and see. For now we need to find our own ways to deal with this situation. A possible way is to use Autopilot Group Tag to group your devices:

That way we can introduce some tags which can be used for grouping in dynamic AAD device groups.

What I see in addition here is custom scripting to populate the Azure AD device groups, maybe with the help of an Azure Automation PowerShell Runbook, or implementing enough logic within the apps to control the install at application level. For example an application install wrapper can check if the device is ready to install based on some properties. This could be implemented by using the App requirement rules (see my fellow Peter van der Woude’s blog for some details “Working with (custom) requirements for Win32 apps“) or logic within an install wrapper (PowerShell wrapper script for example). That way we could evaluate registry keys etc. before triggering the application install. A downside of custom attributes on the devices are a chicken and egg situation, as Intune apps don’t have any order how they are installed on the device (typically the Intune PowerShell scripts are applied early in the process but this is not guaranteed). An app requiring a specific registry key may fail as the preparation app package, writing the necessary registry keys, may not be executed as the first app in the total assignment of apps. Another downside of applications assigned to a large audience and relying on requirement rules is that we generate unnecessary load on our endpoints.

Tell me something about uninstall assignments?

Finally you can also assign apps for uninstall when they are previously installed as required or available for enrolled devices. We can’t uninstall apps which are not installed by Intune. Here we would need to create a custom Win32 app (.intunewin) containing a wrapper script to uninstall certain apps and then assign this app for install.

Conflicting app intents based on multiple assignment?

If we produce multiple assignments because of different group memberships you can follow the Microsoft article “How conflicts between app intents are resolved” to get aware of the final behavior.

As you can see on single user devices we have a well thought solution and even shared multi-user devices can be covered if we add some grouping logic. I hope this clarifies the general Intune behavior based on the different Windows 10 app assignments. Happy app deploying!