Today we’re going to take a quick look at, MAM for Windows. But what is it? MAM stands for Mobile Application Protection and Windows, instead a mobile OS, so what does Microsoft mean when they say MAM for Windows? Well, it’s in essence, it’s App Protection for Windows. It applies to the Edge Browser and can provide organisations with the ability to provide their end users with secure M365 access on personally owned unmanaged devices while applying some level of data protection controls.

So we know what is it but how does it work? If all the requirements are met, once setup, the user just has to sign in to Office and they’ll be taken through the process and well apart from one slightly misleading screen where it could all come crashing down, more on that later, it’s a fairly easy process for users to follow and makes accessing M365 almost easier.

We’ll take a look at

  1. The prerequisites
  2. The users experience both in setup and use
  3. The configuration from an Intune Admins perspective
  4. What else did we see?
  5. What didn’t we see that we maybe expected?

What are the prerequisites…

If you look at the Microsoft tech announcement, it will told us that it’s Windows 11 and Microsoft Edge for Windows ver. 117 and above. With the updated learn article Data protection for Windows MAM | Microsoft Learn, this was changed to support Windows 10 running build 19046.3636 and above with KB5031445 or later.

  • Windows 10, build 19046.3636, KB5031445 or later and Windows 11, build 10.0.22621.2506, KB5031455 (22H2) or later
  • Microsoft Intune (2309 release)
  • Microsoft Edge (v117 stable branch and later for Windows 11 and v118.0.2088.71 and later for Windows 11)
  • Windows Security Center (v 1.0.2310.2002 and later) if using Device Risk scores
  • Users must be assigned a licence for Microsoft Intune and a Conditional Access P1 or P2 licence.

The Setup…

The first thing users will see when they sign in is a conditional access message saying that they’ll need to sign into the Edge Browser or access the account from a registered device. (we’ll not get into the later, you never know, I may do another post on this separately).

Here’s a quick step by step run though of what it looks like for the user

  1. Firstly they’ll sign into Office.com with their organisational account

2. User will be asked to create a work profile, they simply need to select the account and select the Sign in to Sync data and they’ll then be prompted for their password.

4. This is where it gets interesting, the user is provided with a a couple of options on this screen. We need them to register the device but not enrol and allow the organisation to manage the device. Managed devices will block MAM for Windows from working so the user has to untick Allow my organisation to manage my device and then select OK.

If they only sign into the app by selecting No, this won’t register the device and they’ll get stuck in a loop with MS Edge asking them to sign in and create a work profile. You have been warned.

5. Once signed in, the work profile will be created, a couple of customisation screens will appear, they can tailor the browser or simply just click Continue, Next and Done.

And its done. A user will now have SSO when they use the Microsoft Edge browser using the newly created Work Profile.

In Practice…

Here’s the subtle difference between the Personal and Work profiles signed in and how you can select between the two.

Trying to download files from OneDrive / SharePoint is blocked (as per our requirement) along with the ability to download the Office installer, rather unexpectedly but when you think about it logically, you can understand why.

How was it configured…

Configuration is carried out in 2 parts. You first have to great an App Protection Policy, followed by a Conditional Access Policy to enforce it.

App Protection

The App Protection Policy is created within Intune here – Apps – Microsoft Intune admin center and you’ll need the role of Intune Admin or Global Admin (GA) to create this policy. The policy is broken down into 2 areas;

  1. Data protection
  2. Health Checks (otherwise known as Conditional Launch)

Data Protection allows admins to select where the managed profile can receive data from, send and receive organisational data, whether to allow cut, copy and past and decide if users can print organisational data.

Health Checks allow admins to set criteria that must be met before a user can access M365 data via the work profile, such as Minimum OS, Minimum Edge version and id their account is disabled. It can also use the devices risk score from Microsoft Defender for Endpoint if used to secure unmanaged devices. (we’ll not cover this aspect here)

Once the App Protection Policy is configured, it would be prevalent to assign this to a test group of users before deploying this to production.

Conditional Access

The Conditional Access Policy is created within Intune or Entra ID – Conditional Access – Microsoft Intune admin center and you’ll need the role of Conditional Access Admin or Global Admin (GA) to create this policy.

This article isn’t designed to teach you how to use CA policies, if you are unfamiliar with these, improve your knowledge here – What is Conditional Access in Microsoft Entra ID? | Microsoft Learn

Below is the policy that I created, targeting O365 apps, on windows, via a browser to require app protection. My policy did not follow the Microsoft guidance to either require app protection or require a compliant device. Consider your use case carefully.

What else did we see…

An interesting one here, the Minimum OS was originally set to block older OS but regardless of the version of OS, I found that it always blocked it, even if the OS version was higher. As you can see from below, I changed this to warn so that I could continue but it’s still complaining, despite the Windows version being equal.

What didn’t see see or would like

For me, it’s around 2 aspects.

The user setup process is confusing that users have to untick the box or face having their device managed. This could be must tidier if Microsoft revised this part of the process.

The second is around the app protection policy with there being no access requirements that you get on both iOS and Android App Protection Policies. This means that admins can’t set a PIN or password requirement for users. This missing feature alone may rule out this being a viable option for some organisations.

Further Info

Here’s the official docs from Microsoft