By Scott Duffey | Senior Program Manager, Intune, Microsoft Endpoint Manager   This post is not about any new functionality or changes to the service, it’s about app assignment fundamentals that have been around for a while in Intune but are not always completely understood. The aim of this post is to provide you with enough technical information about how app assignments work to help you better plan and troubleshoot your app deployments. I focus most on Windows 10 apps rather than iOS/Android device apps, but many of the concepts apply across the board. Let me know if the details in this “how it works” matches your expectations/assumptions! We’re always open to your feedback and perspective.   I’m going to cover four key technical areas: App Install Context (Device vs User) App Assignment (Device Group vs User) App Assignment Type (Available, Required and Uninstall) App Assignment Groups (Included Groups vs Excluded Groups)   App Install Context (Device vs User) Some Intune apps let you choose App Install Context. This can be configured on the app itself or on the app assignment.                     Although the concept of Device/User applies broadly across different app types, there are some nuances and implementation differences worth calling out. These nuances largely exist due to differences in Configuration Service Provider (CSP). CSPs are the Windows bits of code that translate Mobile Device Management instructions into action. For example, there is an Office CSP running on Windows 10 devices that is in charge of installing Office when Intune tells it to, whereas the EnterpriseDesktopApp CSP is responsible for installing Windows MSI line-of-business apps. Each CSP is built with a different set of capabilities. When you look at two different CSP’s, you’ll see different configurations which is why you’ll see different manageability options in Intune. You can read more about Windows 10 CSPs and capabilities here.   This table summarizes the capabilities per Windows 10 app type: App type Supports User Context Supports Device Context Calls it …. In the Admin portal Can be configured …. Windows app (Win32)   Yes Yes Install behavior At the app level Microsoft Store for Business app (Offline licensed)   Yes Yes License Type At the assignment level Microsoft Store for Business app (Online licensed)   Yes No License Type N/A Windows MSI line-of-business app   Yes Yes App install context At the app level* Windows Universal line-of-business app   Yes Yes Install Context At the assignment level** Office 365 Pro Plus   No Yes N/A N/A Edge (77 and later)   No Yes N/A N/A Web Links   No Yes N/A N/A *Only “Dual-mode” MSIs can be configured for User or Device context by an IT pro. If the MSI isn’t “Dual-mode” the context is determined automatically by Intune based on the contents of the uploaded MSI file and the option to change context is greyed out. ** With Windows Universal LOB apps, you can only choose between user/device when assigning to a device group. If you assign to a user group, you must choose user context.   Here’s an example how you can use this table. If you were thinking about deploying a Windows MSI line-of-business app in your organization, you could choose an App install context of device context while creating the app. After assigning it appropriately, you could be sure that each Windows 10 user who logs on will have the app in their Windows profile and will be able to use it. Intune reporting will show that the app was installed for the device.   Now let’s talk about assigning it appropriately…   App Assignment (Device vs User Group) After creating an app, your next consideration is assigning that app. You have two choices:   Device Group Assignment   User Group Assignment   When you assign an app to a device group, every “applicable” device will start installing the app when it syncs with Intune, no matter which user is currently logged on. Since an MDM sync can occur even when there is no user logged on, a device that has an app targeted could have that app installed while it's waiting at the logon screen. If a scheduled MDM sync happens when no users are logged on the device says “Give me all the apps assigned to this device!”   When you assign an app to a user group, the app will install on all the “applicable” devices that the user logs onto from that point forward (I’ll cover applicability shortly). For user-assigned applications to begin installing though, there needs to be a user ID present in the MDM sync session. That means a Windows 10 Azure AD joined device wouldn’t start installing a user-assigned app until the user logs on. At that point, the device syncs with Intune and says “Give me all the apps assigned to this device AND this user!   So, the key thing here is to understand how and when Windows 10 actually does its MDM sync. It has a sync schedule (we document it here), and each time the sync task fires, the device asks Intune for policy as either the Device (no Azure AD user logged on) or the Device+User (Azure AD User logged on). A key callout is that any sync attempt where the device asks for policy of the Device+User, Intune checks if the user is Intune licensed. If they don’t have a license assigned, then the whole sync session fails.   App Assignment Type When you assign an app to a group of users or devices, you also choose an Assignment Type as a mandatory step. Internally, we call this “Assignment Intent”. I’ll cover three intents here: Required – The app gets automatically installed without any user interaction. This is used to “Push” an app to a set of users or devices. Available – The app gets published to the Company Portal catalog and users can optionally go and get it from there themselves. The full intent name is “Available for enrolled devices”. That’s to distinguish it from a separate intent called “Available with or without enrollment” which is for mobile platforms (iOS/Android) only. Uninstall – The app gets uninstalled from devices that have installed it previously.   A question I frequently get asked is “How does Intune handle conflicts between these assignment types?” We strongly discourage customers from overlapping assignment types – the reason being that we want app management to be as simple and predictable as possible. In fact, the app assignment UI actually blocks you from assigning the same group to conflicting assignment types: While the Intune user interface doesn’t allow you to grant the same group conflicting assignment types, it is possible that the same user or device is in 3 different groups, each with a different assignment type. Like this: The result of the above (User has Available, Required and Uninstall assignments) is actually a merge between Required and Available. The app is installed on the device without any user interaction, but the app will also be listed as an app available for installation if the user goes to the Company Portal. Group 3 (Uninstall) loses the conflict battle. We document this conflict resolution behavior here.   While we are talking about Available apps – here’s another key point: Available apps must be assigned to User groups, not device groups. The Intune assignment UI doesn’t explicitly call this out when picking your groups, but you’ll notice that if you create an Available Assignment type, there is no “make this available to all devices” option for Available apps. See the image below:   Included Groups /Excluded Groups When assigning an app, you’ll also notice a choice of "Included Groups" or "Excluded Groups" in the UI. Excluded Groups are a feature added to limit the scope. For example, if you wanted to deploy an app to “All Users in Building 121”, but not “Engineering Users”, you could either get tricky with your Azure AD group creation... or target the app to “All building 121 users”, then exclude “Engineering Users” group. For every assignment (Available, Required, Uninstall) you can have one excluded group.   In this example, the same user “Sally” is both in scope of the Include and the Exclude group. This means that Sally won’t get the app.   But, one thing you’ll want to keep in mind - You can’t mix and match user and device groups for exclusions. This means that you can’t have a group of users like “all building 121 users” included, but exclude a group of devices (like exclude “engineering laptops” group). Likewise, in reverse you can’t include a group of devices, but exclude a group of users. This experience is documented here.   Putting it all together So, thinking about the capabilities and restrictions I called out, I created this matrix that should serve as a quick reference on what you can and can’t do per app type, context and assignment group.   App type App Context Group Type Assignment Available Required Uninstall Windows app (Win32) Device Device No Yes Yes User Yes Yes Yes User Device No Yes Yes     User Yes Yes Yes     Microsoft Store for Business app (Offline licensed) Device Device No Yes Yes User No Yes Yes User Device No Yes Yes User Yes Yes Yes Microsoft Store for Business app (Online licensed) Device Device No No No User No No No User Device No Yes Yes User Yes Yes Yes Windows MSI line-of-business app Device Device No Yes Yes User Yes Yes Yes User Device No Yes Yes User Yes Yes Yes Windows Universal line-of-business app Device Device No Yes Yes User Yes Yes Yes User Device No Yes Yes User Yes Yes Yes Office 365 Pro Plus Device Device No Yes Yes User Yes Yes Yes User Device No No No User No No No Edge Device Device No Yes No User Yes Yes No User Device No No No User No No No Windows Store Device Device No No   No   User No No No User Device No Yes Yes User Yes Yes Yes Web Apps Device Device No No No User No No No User Device No Yes Yes User Yes Yes Yes   I hope this provided some useful information. If you have any questions or points of clarifications, please add them to the comments below. You can also reach me on Twitter: @Scottduf.   Blog post updates: 10/1/20: With an update to the table to clarify the Web Apps User context. Thanks for the feedback in the comments!