IntuneMAMUPN | Back-2-Basics

This post is about clarifying the role of IntuneMAMUPN in Intune MAM for iOS/iPadOS.

Context

In my last Back 2 Basics posts, we brushed up our knowledge about the various config settings that are available to us while creating an app protection policy in Intune for iOS/iPadOS.

In that post, I mentioned that you can have two unique Intune MAM policies (with different DLP settings, Access requirements, and Conditional Launch parameters) deployed to the same set of users at the same time.

You may ask, what’s the use-case of it?

Well, in terms of mobile devices, we mainly get to work with two very specific scenarios –

• MAM-WE (without enrolment, unmanaged or BYOD), and
• MAM + MDM (enrolled with Intune, mostly COD, but can also be BYOD).

This is because a user may

• use the company-provided device that is enrolled into the company MDM solution, and
• also have their work account configured in apps on their personal devices which are not enrolled.

And from an IT standpoint, you may want to have a relaxed app protection policy to be applied to the apps on a device that is enrolled into the company MDM solution (this is the MAM+MDM scenario), while a more restrictive policy to apply to the apps on a device that is unmanaged (MAM-WE scenario).

Note that this is a supported scenario.

As such, I went ahead and have two policies created (and applied them to the same user group) as shown below to cater to the use-case as explained above.

My expectation is that the

• Unmanaged Device MAM policy to come down to apps on devices that are not enrolled into MDM, when the user signs in to targeted apps with the work account on such devices.

• Managed Device MAM policy to come down to the apps on devices that are enrolled into MDM, when the user signs in to targeted apps with the work account on such devices.

The above configuration, done for the Android platform, works as intended and expected. However, for the iOS/iPadOS platform, the story is a bit different.

The above configuration of just having two separate MAM policies of different management types targeted to the same user doesn’t work as intended.

If you go and try it out yourself, you will see that user check-ins to protected apps from managed devices (Intune MDM enrolled) are actually coming in under the Unmanaged Device MAM policy and not the Managed Device MAM policy.

This is because, by default, for the iOS/iPadOS platform, Intune MAM service picks up the management type of a protected app as Managed app.

As such, when the user uses an account to sign-in to an app that is protected with multiple Intune MAM policies of different management types (Managed App or Managed Device), for Intune MAM service to understand which policy is applicable based on the device management state, additional app configuration setting is required.

And this is where the IntuneMAMUPN comes in.

What is IntuneMAMUPN?

IntuneMAMUPN is a configuration key to set the user UPN setting on supported managed apps (which means the app is either installed via the Company Portal in case of Available assignment or installed as a Required app on the device via MDM).

When set for a managed app on an MDM-enrolled device, it helps the app to identify the MDM-enrolled user account on the device, and this in turn sets the management type of the app as Managed device and not as Managed app.

Role of IntuneMAMUPN in Intune MAM for iOS/iPadOS

The configuration of the IntuneMAMUPN configuration key for managed apps on MDM-enrolled devices allows Intune MAM service to pick up the correct management type of the app, thereby allowing Intune MAM service to serve the correct MAM policy to the app (in case there are two MAM policies available with different management type).

How can we configure IntuneMAMUPN for managed apps?

The configuration of the IntuneMAMUPN configuration key can be achieved by using an App Configuration policy of Type set to Managed devices.

The only downside, this needs to be done per app.

Example: If your MAM policy is about protecting 3 apps, then you need to create 3 individual App Configuration policies of type Managed device, one for each app.

It is to be duly noted that If the app in context is not a managed app, means the app has not been installed as a Required app from Intune, or from the Company portal (in case of Available assignment) and the user has installed the app from the platform-specific app store, then the app either needs to be re-installed on the device from the Company portal or pushed as a Required app from Intune (wherein it becomes managed on the subsequent device sync).

Configuring IntuneMAMUPN in MEM Intune

In the MEM admin center, navigate to Apps > App configuration policies, click on Add and select Managed devices as the policy type.

You need to give a Name to the policy (I suggest using the format {<app name> <IntuneMAMUPN>}), select iOS/iPadOS as the platform, and select the Targeted app.

Remember this is per app configuration so you cannot bulk select apps within a single policy.

Here in the below snap, you see me creating the IntuneMAMUPN configuration for the Outlook app.

Under Configuration settings, set Configurations settings format to Use configuration designer, scroll down, and under Additional configuration, you can enter the below data.

Configuration Key	Value Type	Configuration Value
IntuneMAMUPN	String	{{UserPrincipalName}}

You may want to do additional configuration if there is a need for the same.

For the purpose of this blog post, I will continue with only the IntuneMAMUPN config and proceed to make the necessary assignment.

Once the assignment is made, the final step is to proceed with the creation of the policy.

Validate the deployment of IntuneMAMUPN

Post deploying the app configuration policy, when I synced my iPad and checked to see the deployment status, It was showing as Not Applicable.

Can you guess what went wrong?

Remember I said above that if the app in context is not a managed app, means the app has not been installed as a Required app from Intune, or from Company portal (in case of Available assignment) and the user has installed the app from the platform-specific app store, in such cases, the policy deployment status will come up as Not Applicable as in my case above.

To remediate this, I would either

• need to re-install the app on the device from the Company Portal, or
• push it as a Required app from Intune wherein it will become managed on the subsequent device sync.

Either of the above will result in the end-user getting a prompt as below.

After a click on Manage at this prompt and initiating a device sync from the Company portal, a look back at the deployment status for the IntuneMAMUPN policy for Outlook shows as below in the MEM Admin Center.

Configuration Validation

Before having the IntuneMAMUPN config deployed, having two MAM policies of different management types applied to the same user (me!), you can see that when I signed-in to Outlook from my enrolled iPad (see Compliance State as Compliant, for unenrolled device Compliance State comes as Unavailable), Intune delivered the Unmanaged Device MAM Policy.

After having the IntuneMAMUPN config deployed

You can also use the Microsoft Edge app and browse to about:intunehelp to see Intune MAM diagnostics and see about policy details applying to MAM-capable apps on the device.

Before we end this…

It is important to note that you cannot have two Microsoft 365 accounts coming from separate tenants configured on an Intune MAM-enabled application, where both the accounts have Intune MAM policies assigned from their respective tenants.

This is because the way it works is, Intune MAM creates a container to store corporate data that is shared across all Intune MAM-supported apps on a device. And each device can only have one Intune MAM container.

The only exception to this is the Work Profile scenario with Android Enterprise, since in this mode, the device is actually running two user profiles, and thus can have two Intune MAM containers configured, one running in the primary profile and the other running in the secondary profile.