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
- User group assignment
- Device group assignment
- 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
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!
You could target your regional shared devices with an autopilot profile per region and then target a dynamic group that contains that autopilot profile. This should survive a device reset and if you’re deploying at scale, be something that your OEM vendor can align from the factory
Correct, this can be a way to introduce a custom attribute, it won‘t survive replacement but a custom attribute is available with that. Actually we also can modify the group tag since some time, so we have some kind of flexibility here. But again I think some extensionAttributes like we have on the user object would be very helpful.
Good comment anyway, should be really considered during designing 👍
Hello Oliver, we are in the process of preparing intune and autopilot/white glove for 300+ devices. Until now, we wanted to deliver as much software as possible through the white glove process (device-bound software assignment). But your recommendation is aimed at user-bound. It would be nice if the White Glove process could consider the assigned user in autopilot devices and install the user-bound apps. Do you have more information or a recommendation? Or should it work like described but doesn’t apply to hybrid joined devices?
Yeah, actually this is not an easy task. I’m not saying you have to use user assignments for every situation. Currently the primary user support is expandable imho, but I’m not aware when we get enhancements here. In your case it makes sense to use device assignments for that process. I’ve updated the post a bit to shed some more light on this.
Does the restriction that only the primary user can install apps on his device also apply if you assign the app as required to another user? Or only if it’s assigned as available?
I’ve updated the post to be more clear here, thanks for the feedback,
great article! For the Uninstall… a few questions that I haven’t found answers yet.
– App must be installed by Intune in order to be uninstalled? I mean, really? if the detection job did the trick, the uninstall string wouldn’t work at all? a bit odd when you have legacy computers that you now manage that already had the application installed prior to being Intune managed, or even if the app came from SCCM/Co-Management…
– When targeting a group to uninstall, does it behave as an exclude for the required on top of the uninstall? For example, the required is targeted to all device/users, and target a group to uninstall, should that group be set to Required+exclude?
The easiest way of such an cleanup in these situations is to build a intune package with an install command which actually runs a PowerShell script which does the uninstall of the app(s). These apps may then previously installed by whatever it was (SCCM, manual, other software management tool).
Uninstall does not have higher preference as required. See the App install intents and how they are resolved here: https://docs.microsoft.com/en-us/mem/intune/apps/apps-deploy#how-conflicts-between-app-intents-are-resolved. So yes you would need to exclude from required and target the uninstall, otherwise the required will be the final result and uninstall will never happen.
Thanks for the answer.
With that said, Required wins over uninstall. but here’s another catch that is not covered in the Conflict table.
All users: required
User Group A: Excluded required
User Group A: Uninstall
Somehow, this makes users loop between Install and Uninstall…
Within the same day, Install/Uninstall will happen 2-3 times. I was able to reproduce this for multiple users.
The expected behavior would be that because of the Exclude, the Uninstall wins, but it doesn’t.
If I begin to manage uninstall scripts on the side of the current application, it will become a mess eventually 😉
interesting catch! I need to test this myself, but as you wrote, the normal behavior should be that uninstall wins. Let me do some tests and I will come back with my observations and thought about this.
I’m testing some available win32 app installs via company portal and from this installed them on a device. I’ve created groups for required uninstalls and applied them to the apps – so when a machine requires the software removing, it should in theory come off . I add the machine name, hey presto under Managed Apps against the device it appears as Resolved intent=”Required uninstall” Installation status=”Installed”….. so it knows to remove the software. However a day later, and still nothing!!! Intune and the device are talking as other software has been added/removed via require mechanism. Any thoughts? We need that Uninstall button for available apps in the company portal!
Here is a good summary what happen when:
Your problem is that you are trying to remove the software by using the device here:
User Available and Device Uninstall Intune resolves Available
User Available and User Uninstall Intune resolves to Uninstall
Your scenario would only work with user in the uninstall group, but yeah I know it would trigger the uninstall on every device form the user, which might not the actual intent…
The whole Available scenario is currently not really feature complete. Most people are using required only because of this “gaps”. I hope they are addressed soon. But right now you have these downsides…
We have enrolled shared devices with autopilot self deploying-mode. Now if a user logs in with a special application assigned which needs a license this will be installed. All good so far, but if then another user logs in, which should not have this application installed, he can also sees this application. Is there a solution for that?
Not really, only way would be that your app (which needs a license) can be installed in user context. That way only the install user would see it, as it is in his user profile. Typical installs are not user installs, they are installed per-machine (in system context). So, if your special app does not support user-context install, you are not able to hide it from the second user once it is installed.