The Underwhelming MAM for Edge and What Else We Can Do

A while back I had written about a solution that I have been anxiously awaiting since its announcement: MAM for Edge on Windows. Let me explain the background a bit.

We used to have Windows Information Protection (WIP). Well, we still have it for enrolled devices, but it is being deprecated, and already you cannot create new policies for WIP against unmanaged devices (that is, without enrollment). It was far from a perfect solution, but it gave us a way to protect company apps and data even on devices that weren’t enrolled, similar to what we can do using MAM for iOS and Android.

Anyway, when Microsoft first announced the deprecation of the WIP service, they did not really announce a replacement for it. Instead, they said we should leverage other solutions such as Microsoft Purview Data Loss Prevention and Information Protection (i.e., Sensitivity labels). This advice was a little bit confusing since these technologies cannot really replace the functionality of WIP, which allowed us to do stuff like encrypt corporate data on devices, and issue remote wipe commands, even against unmanaged (personal) devices.

So, when the new App protection policies for Windows were announced (starting with a policy that can help us to manage the Edge browser) I was curious as to what our capabilities would be here. I expect (hope) that additional applications will eventually be added to these policies; for example, I want to wrap this protection around not only Edge but also the Outlook or OneDrive client applications, even on personally owned/unmanaged devices.

After all, we can already do this today for both iOS and Android, neither of which Operating Systems are owned by Microsoft. So surely, we will be able to do the same or better with Windows, right? But of course, even if this seems to make sense in my head, it’s just speculation. I don’t actually know what their plans are here. All I can say is, after playing with MAM for Edge I am underwhelmed, and can only hope for better in the future development of these MAM policies.

What MAM for Edge Does Today

I will introduce you to my gripes by covering the set up and configuration of the policy as it stands today–that is, what can we do with MAM for Edge (at least it exists today in preview)?

Step 1. Set up your auto-enrollment for personal devices

Before you go to configure the policy you may want to check a couple of pre-requisites off first. For example, we need to make sure that our Windows Automatic Enrollment settings are properly configured. Navigate to Devices > Enroll devices > Windows enrollment and find Automatic enrollment.

The purpose of the MAM policy is to extend access to personally owned devices without enrollment. Therefore, you need to configure both the MDM user scope and MAM user scope. You can set each scope to either All or Some, and select the group of licensed users. If you do not define the MAM user scope, then personal Windows devices will attempt to automatically enroll, just like corporate ones. In other words, they will go down the MDM path. If your goal is to leave personal devices un-enrolled, then you must set the MAM scope on this page so that auto-enrollment doesn’t happen for personally owned Windows computers. That is, you want them to go down the MAM path.

Step 2. Connector for Windows Security Center

Next you should add a connector to Intune for Windows Security Center. This will allow you to take advantage of device health checks using your App protection policies. Navigate to Tenant Administration > Connectors and tokens > Mobile Threat Defense. Click on Add and pick Windows Security Center.

Step 3. Create the App protection policy

Only now are we ready to create our MAM policy for Windows.  We deploy from the same place we do other MAM policies: Apps > App protection policies. Click Create policy and choose Windows (not Windows Information Protection).

(Please note, if you don’t see this option in your tenant yet, don’t panic. That’s because you have to sign up to get access to this preview. As you are about to see, you aren’t missing out by waiting until it is released to General Availability. Hopefully it will be better by then.)

Give your policy a name and description, and then proceed to the next page of the wizard, where we select our apps (and today there is only one app: Microsoft Edge).

I wish I may, I wish I might, have this wish I wish tonight…BRING US MORE CLIENT APPS!!!

On the next page in the wizard, you will notice that the Data Protection options aren’t quite as robust yet as they are for the equivalent iOS and Android policies.

All we can do here is put up the basic copy/paste/save boundaries, and block printing. This means that while we are browsing under our corporate identity on a personal device, we cannot print, copy or save data to personal locations.

On the next screen, you will probably recognize many of the “Health Checks” as being similar to what we have on the mobile platforms, granted, I would like to see a few more selections here ultimately. For example, I don’t see any reason why we couldn’t have Device conditions for checking stuff like code integrity, Secure Boot, and even disk encryption (BitLocker)–similar to device compliance policies.

Finally, you can assign your policy to a specified user group. Note that we cannot use filters with this policy, which is hugely disappointing. It means that if we target a user who has both corporate and personally owned Windows devices, the policy will have to apply equally to both. But in general, I would never want to apply this policy on a Company-owned workstation.

You might argue that the policy should therefore be targeted only against groups containing devices, but this is no good either, since we are trying to control the user experience on devices that Intune doesn’t even know about yet (without enrollment, remember?). Plus, it goes against Microsoft’s best practice of targeting users for most policies, and then using filters for devices (unless of course you are specifically trying to target certain policies against enrolled, kiosk style devices or similar).

Anyway, this is gripe #1: when this goes to GA, hopefully we will have the ability to use filters for devices here, like we can with other MAM policies for iOS and Android, meaning that we have the ability to target apps specifically on unmanaged devices (read: without enrollment).

Step 4. Create the CA policy

Now, we aren’t quite done configuring the experience yet. So far we have a policy that will apply if and only if someone is signed into their corporate profile in the Edge browser. We also need a Conditional Access policy so that access will be blocked unless they are using a corporate profile (so they cannot go around your controls simply by using another browser, or even a personal or guest Edge profile for example).

From Endpoint security > Conditional Access, create a new policy and give it a descriptive name such as “Require MAM for Edge on Windows devices.” Start by targeting your intended user group, and then make sure you are only targeting the Office 365 cloud app (this control is not supported for All cloud apps).

We need to specify two conditions: this policy only applies to Windows devices, and only to the Browser (not, sadly, desktop clients–or at least not yet).

Last, for the Access controls, choose Grant and Require app protection policy.

Save and enable this policy when done, and then we are off to the races.

Step 5. Test on an unmanaged device

Before we go further, I will note that for the preview at least, you have to use Windows 11 22H2+, and one of the Edge Insider builds; I believe these requirements will go away for GA (certainly the insider build requirement, and hopefully will be available for Windows 10 too), so not as big of a deal.

Anyway, here is the experience when we attempt to sign into the Microsoft 365 portal page from a Windows 11 device using a “personal” Edge profile (e.g., when you are signed in using a normal Microsoft Live or Outlook account).

As you can see it is going to ask us to switch to a corporate (managed) Edge profile, where our additional protections and “guard rails” can be applied.

After you sign in with your corporate identity, it will register the device with Entra and proceed to show you the Screen That Should Not Be:

This screen is not new to MAM for Edge–it comes up when signing into other applications on a newly registered device, as well. But this screen is one of my longstanding pet peeves with Microsoft because it confuses users and IT DOES NOT EVEN NEED TO EXIST. Seriously. I have the ability in my tenant to configure my auto-enrollment settings, as well as my enrollment restrictions if I want to prevent personal devices from becoming enrolled, for example. So, if I have already set these options as an administrator, WHY ON EARTH do you ask my users this question, at all?! If I want these devices enrolled, I can set that up myself. If I don’t want them enrolled (like in this example), I can accomplish that as well. So, WHY, MICROSOFT?!

Anyway, I digress. After you clear the checkbox and click OK, dismissing the Screen That Should Not Be, you will be able to click Done and then switch into your work profile where we are presented with another (as far as I can tell) optional screen.

I say optional because our only choices are Continue or Cancel, and nothing really important happens after we click Continue, we just get to go to wherever it was we were trying to browse in the first place, for example the Microsoft 365 portal home page. Now we can see that we are firmly inside our work profile, where we were trying to go all along (can’t we make this happen in fewer screens?).

However, if, from this same page, I attempt to download one of my recently accessed files, I will run into our barrier (which is by design of course):

Note that I can still work with this file while inside the managed web browser, however I am also unable to print, or copy/paste data from it:

Of course, you will notice that I was still able to take these screenshots, so we can surmise that screen capture protection is not included with the new MAM policy as of today.

I will say that at least we have good feedback when there are issues relating to the policy. That is, we have an actual log file available, which could be reviewed by an administrator to help in understanding why a certain failure occurred, e.g., was there a problem related to Conditional Access, Device Health, or something else?

Conclusions, and what else can we do?

At the end of the day, I feel rather let down by MAM for Edge, at least in its current state. Why you ask? Because this does not give us anything we did not already have with Conditional Access App restrictions or App control policies. In fact, I think I prefer the user experience of either of those two solutions over this one. However, if they add more apps to the policy, such as the Outlook client (especially the Outlook client), and the OneDrive client, then we may have a better story worth exploring.

So where does that leave us? Well, for iOS and Android, I still really like the MAM solution. App protection policies are great for targeting unmanaged, personal mobile devices (without enrollment). But I cannot say the same for Windows yet, which is shocking since, you know, Microsoft owns the Windows OS, the Office productivity apps, and even the management tool (Intune), so you’d think we would have a better story to tell here by now. But you would be wrong.

Of course, we should also acknowledge there also exists a spectrum of other options to pick from when it comes to unmanaged personal device access.

In a recent update to my popular course on Microsoft Intune, our Practice Development peer group went over all of these options in more detail. If you aren’t part of the group, you can check out the course recording and other materials here. And yes, there is yet another (more expensive) option not pictured here, which is Windows 365 (we have a course on that too).

In case you were curious, my personal favorite option for handling personally owned Windows, Linux and macOS devices remains No access. After all, it is the simplest and most secure option: we enforce simply by requiring compliant devices, while at the same time blocking personal enrollments. Then only company-owned, enrolled and fully managed workstations can access corporate apps and data. That having been said, I do hope our outlook improves in this area (pun intended), and eventually comes to parity with what we can already offer our customers on the mobile platforms.

Oh well. Until next time…