With Microsoft Intune, there is a lot of focus on the Mobile Device Management (MDM) aspects of the product. This is logical because from a management perspective, if you manage a device using MDM, you can configure almost all settings remotely, something we as System Administrators have been doing for many years.

In many situations, just managing the Apps which you use to access your company data hosted in Office 365 is a more suitable solution, there are a couple of reasons for that.

• Many companies who want to implement measures to protect their company data, already allow access to company data via email, apps but now want to manage that. End users, even the ones provided with a device owned by the company, use the device for personal usage as well.
• Implementing a MDM solution for mobile devices, is far more complex and more intensive from a system management point of view, in many cases the MDM solution provides way more functionality than what’s really required (protect the company data)

Mobile Application Management (MAM) in some cases is a perfect way to let your end-users use their device the way they are used to, but also implement security measures which protect your company’s most valuable asset: The data.

In this article I will go into more detail of the MAM without enrollment (MAM-WE) functionality provided by Microsoft Intune/Microsoft Endpoint Manager.

Disclaimer: This post reflects the status of assigning groups to Azure AD roles as of October 10, 2020. Functionality may change, even right after this post has been published.

What is Mobile Application Management?

According to Wikipedia, the definition of Mobile Application Management is as followed:

Mobile application management (MAM) describes software and services responsible for provisioning and controlling access to internally developed and commercially available mobile apps used in business settings on both company-provided and “bring your own” smartphones and tablet computers.

Mobile application management provides granular controls at the application level that enable administrators to manage and secure app data. MAM differs from mobile device management (MDM), which focuses on controlling the entire device and requires that users enroll their device and install a service agent.

While some enterprise mobility management (EMM) suites include a MAM function, their capabilities may be limited in comparison to stand-alone MAM solutions because EMM suites require a device management profile in order to enable app management capabilities.

Translating above to my own wording I would define Mobile Application Management as a way to manage the app on a device without the need to manage the device itself.

Comparing Microsoft Endpoint Manager/Intune with other Unified Endpoint Management vendors

Microsoft Endpoint Manager/Intune is considered a leader in the Gartner Magic Quadrant for Unified Endpoint Management for 2020, see: Gartner announces the 2020 Magic Quadrant for Unified Endpoint Management, Microsoft is sharing the Leaders position together with VMware (Airwatch) and IBM (MaaS360).

Use cases for MAM

The reasons why companies want to manage either the device or the application on the device in my opinion is quite simple. Companies want to control access to their data, and therefore they need to be able to define policies or execute actions on either the devices or the application which access that data.

Policies could be related to defining what data can get in the managed application or is allowed to leave the company managed application. Whether it is allowed to save company data on non-company managed locations (like f.e. Dropbox). When the device gets lost or stolen, the company also has a way to wipe the company data.

In some cases applications even support a distinct between private and company data from within the App, in those cases you can for example copy private data hosted in a MAM managed app to another private app, while copying company data in that same app to another private app is prohibited. A good example of an app supporting this functionality is the Microsoft Outlook App. In this case we can speak more about Mobile Information Management (MIM) since the information is protected within the App.

Not every app is capable of being managed by a Mobile Application Management vendor, the app itself must have been written with the ability for it to be managed by an MAM solution. In the world of Microsoft, most Microsoft provided apps on Mobile Platforms are capable of being managed by Microsoft Intune, since the Apps have been written using the Intune SDK. Some other vendors, like Adobe for example have added this capability to their Apps as well.

Microsoft provides a list of applications which have Intune/MEM MAM capabilities included here: Microsoft Intune protected apps

App Wrapping

When an App is not supporting the ability to be managed using MAM, there is an option to wrap the app. As the name implies, you surround the app with an extra layer providing the option to apply protection to the app. This App Wrapping is mainly used when you want to manage Custom developed apps (a.k.a. Line of Business apps, or LOB), which you deploy outside of either the Apple – or Android app stores. Keep in mind that if you wrap your apps, that you need to deploy them using an app installation file using Intune as well.

• Prepare iOS apps for app protection policies with the Intune App Wrapping Tool – https://docs.microsoft.com/en-us/mem/intune/developer/app-wrapper-prepare-ios
• Prepare Android apps for app protection policies with the Intune App Wrapping Tool – https://docs.microsoft.com/en-us/mem/intune/developer/app-wrapper-prepare-android
• Add an iOS line-of-business app to Microsoft Intune – https://docs.microsoft.com/en-us/mem/intune/apps/lob-apps-ios
• Add an Android line-of-business app to Microsoft Intune – https://docs.microsoft.com/en-us/mem/intune/apps/lob-apps-android

Even though App wrapping is provided as an option, my advice would be that in case that you have any of these apps that you let them integrate with the Intune SDK, so that you have true MAM functionality built-in.

• Microsoft Intune App SDK for iOS developer guide – https://docs.microsoft.com/en-us/mem/intune/developer/app-sdk-ios
• Microsoft Intune App SDK for Android developer guide – https://docs.microsoft.com/en-us/mem/intune/developer/app-sdk-android

Mobile Application Management in Intune/Microsoft Endpoint Manager

Microsoft defines MAM as the suite of Intune management features allowing you to publish, push, configure, secure, monitor and update mobile apps for your users. All this functionality is available under the Apps node within the Microsoft Endpoint Manager admin center.

Some of the capabilities defined in the definition that Microsoft defines can only be achieved when the device is enrolled in Mobile Device Management (MDM), like publish, push and update. So basically you can use Mobile Application Management from Intune in two configuration modes:

• Intune Mobile Device Management in combination with Mobile Application Management, giving you full functionality with  publish, push, configure, secure, monitor and update options
• Intune Mobile Application Management without Mobile Device Management, which Microsoft refers to as MAM without device enrollment (MAM-WE) giving you partial functionality with configure, secure and monitor options.

So basically, you can still use MAM functionality when you use MDM, allowing you to define less strict policies for your Intune Managed apps on MDM managed devices. You could for example allow copy and paste between corporate apps and other apps on MDM managed device, while you want to restrict this on MAM-WE devices.

The figure below is a snippet of an App Protection policy, as you can see you can define if the settings must apply to all types of devices (Yes/No) and if no whether the settings are applicable for either Unmanaged (MAM-WE) or Managed devices (MDM + MAM).

When using MAM-WE we can make use of App Configuration, and App Protection policies to define the behavior of the App and how data is protected. For the remainder of this article we will define setting for MAM-WE.

App Protection Policies (APP)

By using App Protection policies you define what can, and cannot be done with the corporate data. Apps having an App Protection Policy defined on them are referred to as policy-managed apps.

App Protection policies are categorized into three categories:

1. Data relocation/protection

Allows you to define Data Transfer and Encryption options. For example how and if corporate data can be transferred to other platforms like iTunes/iCloud, Android Backup services or other Apps on the device using copy/paste functionality. You can also specify if org data must be encrypted and whether the user will be able to print data.

2. Access requirements

Allows you to define PIN and other requirements. For example you can define whether a PIN is required, and if biometric functionality can be used to unlock the App. You can also define the frequency of when access requirements must be rechecked.

3. Conditional launch

Allows you to define App conditions and Device conditions. For example for App conditions you can define the maximum attempts for an PIN to be accepted and what to do after that maximum is hit (reset PIN). For Device conditions you can determine what to do with jailbroken/rooted devices  (block access).

All the possible settings in these three categories can be found in the Microsoft documentation:

• iOS app protection policy settings – https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-policy-settings-ios
• Android app protection policy settings in Microsoft Intune – https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-policy-settings-android

Finding the right combination of settings can be a challenging task though, and should be carefully tested. To help pick the right settings Microsoft created the APP data protection framework.

APP data protection framework

The APP data protection framework is organized into three distinct configuration levels, with each level building off the previous level:

• Level 1 enterprise basic data protection – Microsoft recommends this configuration as the minimum data protection configuration for an enterprise device.

• Level 2 enterprise enhanced data protection – Microsoft recommends this configuration for devices where users access sensitive or confidential information. This configuration is applicable to most mobile users accessing work or school data. Some of the controls may impact user experience.

• Level 3 enterprise high data protection – Microsoft recommends this configuration for devices run by an organization with a larger or more sophisticated security team, or for specific users or groups who are at uniquely high risk (users who handle highly sensitive data where unauthorized disclosure causes considerable material loss to the organization). An organization likely to be targeted by well-funded and sophisticated adversaries should aspire to this configuration.

So basically you can implement the App Protection Policies from the data protection framework as a starting point. You can manually create the policies using the settings documented at Microsoft Docs:

• Level 1 enterprise basic data protection – https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-framework#level-1-enterprise-basic-data-protection
• Level 2 enterprise enhanced data protection – https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-framework#level-2-enterprise-enhanced-data-protection
• Level 3 enterprise high data protection – https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-framework#level-3-enterprise-high-data-protection

APP data protection framework automation options

It’s better though to automatically have the App Protection Policies created using a script, for this you can use the following GitHub repository: https://github.com/microsoft/Intune-Config-Frameworks/tree/master/AppProtectionPolicies. Another option is to have your validated App Protection Policies exported to JSON files and have a script to import it again in another tenant, this can be achieved using the following samples: https://github.com/microsoftgraph/powershell-intune-samples/tree/master/AppConfigurationPolicy

App Configuration Policies (ACP)

By using App Configuration Policies you can determine the configuration (either default or mandatory) of the App which gets applied before the users run the app. Apps must support the ability to be configured using App Configuration Policies which is known as “managed configuration”, the configurable settings are defined by the developer of the app. For each App Configuration Policy you can define whether they must be applicable on Managed devices (MDM), which Microsoft calls “Managed Devices” or Managed Apps (MAM-WE), which Microsoft calls “Managed Apps”

For Android devices you can look up the App in the Managed Google Play store and you will see a visual mark that the app supports managed configuration. Unfortunately the Volume Program Purchase portal provided by Apple doesn’t give this information (yet), changes are though that if an App developer provides this option on Android that for iOS the options will most probably be available as well.

The settings for the app in basis can be set using so called configuration settings, where you can define a name (the key) and a value. The app developer usually supplies an XML definition file providing the keys and possible values.

Available public apps for ACP

When defining an App Configuration Policy, Microsoft provides a list of apps can choose from, below is an overview of this list (at

time of writing this article). If the application you want to configure is listed in the table below, you can perform a google search on application name + managed app which will most probably redirect you to the right page detailing the possible settings.

In my experience this list is very vague though, take Microsoft To-Do for example. It’s in the list, but when looking at the App in the Google Playstore for Work it’s not marked as “managed configuration” – Microsoft also doesn’t provide any documentation on certain applications which are in the list.

Application	iOS	Android
Adobe Acrobat Reader	Yes	Yes
Azure Information Protection	Yes	Yes
BlueJeans Video Conferencing	Yes	Yes
Board Papers	Yes	No
Box for EMM	Yes	No
Breezy for Intune	Yes	No
CellTrust SL2™ for Intune	Yes	Yes
Cisco Jabber	Yes	Yes
Citrix ShareFile for Intune	Yes	Yes
Cortana	Yes	Yes
Field Service Mobile	Yes	Yes
Hearsay Relate for Intune	Yes	Yes
iBabs For Intune	Yes	No
ISEC7 Mobile Exchange Delegate for Intune	Yes	No
Lexmark Mobile Print Intune	Yes	No
Meetio	Yes	Yes
MentorcliQ	Yes	Yes
Microsoft 365 Admin	Yes	Yes
Microsoft Bookings	Yes	Yes
Microsoft Dynamics 365	Yes	Yes
Microsoft Dynamics 365 for phones	Yes	Yes
Microsoft Dynamics 365 for tablets	No	Yes
Microsoft Edge	Yes	Yes
Microsoft Excel	Yes	Yes
Microsoft Invoicing	Yes	Yes
Microsoft Kaizala	Yes	Yes
Microsoft Launcher	No	Yes
Microsoft Office	Yes	Yes
Microsoft Office	Yes	No
Microsoft Office [HL]	No	Yes
Microsoft Office [ROW]	No	Yes
Microsoft OneDrive	Yes	Yes
Microsoft OneNote	Yes	Yes
Microsoft Outlook	Yes	Yes
Microsoft Planner	Yes	Yes
Microsoft Power Apps	Yes	No
Microsoft Power BI	Yes	Yes
Microsoft PowerPoint	Yes	Yes
Microsoft SharePoint	Yes	Yes
Microsoft StaffHub	Yes	Yes
Microsoft Stream	Yes	Yes
Microsoft Teams	Yes	Yes
Microsoft To-Do	Yes	Yes
Microsoft Visio Viewer	Yes	No
Microsoft Whiteboard	Yes	No
Microsoft Word	Yes	Yes
Nine Work for Intune	No	Yes
Notate for Intune	Yes	Yes
Now® Mobile – Intune	Yes	Yes
Power Apps	No	Yes
Power Automate	Yes	Yes
PrinterOn for Microsoft	Yes	Yes
Qlik Sense Mobile	Yes	Yes
ServiceNow® Agent – Intune	Yes	Yes
ServiceNow® Onboarding -Intune	Yes	Yes
Skype for Business	Yes	Yes
Smartcrypt For Intune	Yes	No
Speaking Email	Yes	No
Tableau Mobile for Intune	Yes	No
Vera for Intune	Yes	No
Work Folders	Yes	Yes
Yammer	Yes	Yes
Zero for Intune	Yes	Yes
Zoom for Intune	Yes	Yes

What about Microsoft Office[HL] and Microsoft Office[ROW]

For Microsoft Office, also Microsoft Office [HL] and Microsoft Office [ROW] is listed for Android, in the official documentation nothing can be found on why these applications are here, it seems to have something to do with the version of the Office app preinstalled on some Samsung devices. The following article mentions that you should just add them all in the case of Android: Support Tip: How to enable Intune app protection policies with the Office mobile

App Configuration Policy examples

Below some examples of how an App Configuration Policy might look, In some cases, especially with Microsoft provided apps like Outlook and Edge Microsoft allows you to configure the settings using a GUI.

Creating App Protection Policies via the Microsoft 365 admin center

Besides creating an App Protection Policy via the Microsoft Endpoint Manager admin center, it’s also possible to use a Policy wizard in the Microsoft 365 Admin Center. You can find the policies under Devices -> Policies. From there you are able to create the following policy types:

• Application Management for Android
• Application Management for iOS
• Application Management for Windows 10 (WIP) for personal or company owned
• Windows 10 Device Configuration

We see that Microsoft is creating more and more templates which is a welcome thing, I personally hope that eventually you can choose a template when working from a greenfield scenario, so that you know for sure that the right settings are in place before you start migrating your data into the M365 environment.

App Configuration references:

Below some links to documentation about managed configuration you can implement using the App Configuration Policies functionality in Intune:

• Configure the Microsoft Managed Home Screen app for Android Enterprise
• Configure Microsoft Launcher
• Configure Microsoft Edge
• Configure Office
• Configure Outlook
• Configure Microsoft Teams
• Configure Adobe Acrobat
• Configure Zoom

Conditional Access

Now that we have defined our App Protection – and App Configuration policies we some challenges ahead, because if we want to enforce these policies we have to make sure that every user is using an App that we can protect and if possible manage.

With Conditional Access we can block all other apps except apps we can manage for iOS and Android, by doing so we assure that only Apps which we can manage using MAM policies are used. Microsoft explains how app-based conditional access works in the following article: How app-based Conditional Access works

Prerequisites

If we want to use Conditional Access to enforce the usage of manageable apps, we must first make sure that Legacy authentication cannot be used anymore. Please read my article on that subject for more information: Microsoft is going to disable basic/legacy authentication for Exchange Online. What does that actually mean and does that impact me?

After reading this article you will most probably come to the conclusion that you need to migrate towards an Email app supporting Modern Authentication anyway, so why not migrate to Outlook right away and properly secure the App while doing so.

For blocking Legacy Authentication and redirecting users to the Outlook App you can use the following two references:

Conditional Access: Block legacy authentication

And the other policy I recommend to implement is for situations where you have users still using the default mail application leveraging Exchange Active Sync (EAS). The idea here is that you create an Conditional Access policy which only grants access to approved client apps. By doing so, users will be notified by email that they need to transition to the Outlook App. You can also create a Block policy for EAS, but this will not notify users which might raise some questions.

Explaining how to create the EAS policy is done in the following article:  Scenario 1: Microsoft 365 apps require approved apps with app protection policies and use the procedure described in Step 2. Instead of using the Access control to require an App Protection Policy I would use the Required Approved App for now, I’ll explain why later.

Creating the Conditional Access Policy to approved Client Apps in Android and iOS

In the following slideshow I will show how to create the Conditional Access policy which requires approved client apps

Required Approved Client Apps versus Require App Protection Policy

The Microsoft documentation currently raises a lot of questions, when trying to figure out my options I decided to create a matrix comparing the options available:

• Intune Protected Apps, the Official list that Microsoft references
• Approved Client App, the list of supported Apps when using a CA policy with Grant access controls
• Require App Protection policy, the list of supported Apps when using a CA policy with Grant access controls
• Applications listed under either iOSiPadOS or Android when creating an App Protection Policy.

Based on this comparison, the only Apps with full support on all points are (note that Teams for example is missing):

• Microsoft Cortana
• Microsoft Edge
• Microsoft Excel
• Microsoft Office
• Microsoft OneDrive
• Microsoft OneNote
• Microsoft Outlook
• Microsoft Planner
• Microsoft Power BI
• Microsoft PowerPoint
• Microsoft SharePoint
• Microsoft Word

To clear up this confusion I created a GitHub item on the documentation page for the Conditional Access policy, which can be found here: Confusion about Intune Protected Apps versus Approved Client App versus Required App Protection Policy versus what’s listed in the portal – I hope Microsoft responds and clears up the confusion, If they do I will update this article.

From what I understood while discussing this confusing information with Peter Daalmans, the idea is that Microsoft want to move towards App Protection policy checks. Therefore we now see that some applications are supported under the Require App Protection Policy part, where these are not listed as Approved Client App. On the other hand having the require Approved Client App functionality available could be handy if you only have Azure AD P1 and no Enterprise Mobility + Security license (giving you MAM capabilities).

Setup experience

So now that the App Protection -, App Configuration – and Conditional Access policies have been created and assigned we can configure these managed apps on our mobile device. For both Android and iOS I created screenshots detailing the steps the users need to take in order to enroll the Application. In both scenario’s Microsoft Outlook was used.

Broker apps

When users enroll their Mobile app into Mobile Application Management, device registration into Azure AD must take place. This device registration must be performed using a so called broker app. The broker apps starts the Azure AD registration process, creating a device record in Azure AD and it verifies the identity of the app in order to verify whether the app is authorized for use by the user.

On Android this broker app is the Company Portal App, and on iOS the broker app is the Authenticator app.

Setup experience on Android

It’s advised to have the Company Portal App installed upfront to smoothen the experience for the user. Even though the setup process will ask the user to install the app if it isn’t installed. Please also be careful with the Company Portal App, because it could allow users to enroll their devices into MDM instead, please make sure that you disable personal MDM enrollment for Android at least if you don’t want this to happen.

Setup experience on iOS

It’s advised to have the Authenticator App installed upfront to smoothen the experience for the user. Even though the setup process will ask the user to install the app if it isn’t installed.

App Protection policies in action, some examples

How about managing apps on Windows and macOS?

While out of scope for this article, having MAM capabilities available for Office 365 applications on Windows or macOS devices would be very welcome. For Windows we have Windows Information Protection (WIP) available, but unfortunately implementing WIP is not as easy as implementing APP for iOS and Android devices. WIP implementation requires careful planning and has some caveats. For Office applications on macOS no MAM alike capabilities are available, and therefore the only option you have if you want to be able to manage the data is to manage the device (MDM).

Some more information about WIP, give some more insights in the challenges you are going to face:

• Limitations while using Windows Information Protection (WIP)
• Give extra Consideration before implementing WIP (Windows 10 App protection policies), by Alex Fields
• Windows Information Protection (WIP) in action, by Robert Crane
• Windows 10, MAM-WE and Office desktop apps, by Peter van der Woude
• Force Windows Information Protection with Conditional Access, by Peter Klapwijk

Wiping Company Data

In case a device using MAM capabilities gets lost or stolen, the Administrator has the option to wipe the company data of the device using the Microsoft Endpoint Manager admin center. There is also an option to perform this using the Exchange Online Admin center if you are not using MAM.

You can access the functionality to wipe the company data in the app, by opening the Microsoft Endpoint Manager admin center, selecting Apps en selecting App selective Wipe under the “Other” category

From here you have the option to either create a Wipe request – which is device based, or to execute a User-Leve Wipe, which is user based and will wipe the company data on any MAM managed app the user is using.

Did you know that when clients connect using Exchange Active Sync, the Exchange Administrator actually has the option to wipe the whole device?

Monitoring

When implementing Mobile Application Management it’s important to also monitor whether App Protection Policies and App Configuration policies are applied correctly. The Microsoft Endpoint Manager admin portal provides some monitoring capabilities which can help you to determine whether the policies have applied correctly.

Monitoring can be done from the Monitoring section under Apps in the Microsoft Endpoint Manager admin portal, you can select the App protection status section for specific monitoring data related to MAM.

Monitoring App Protection Policies

For App Protection policies you have several options to monitor whether they are applied correctly. First of all you already see some nice widgets with all kinds of information like Assigned users, User status for iOS/Android, Top protected iOS/Android Apps etc..

If you click on one of the numbers in the widget you will be redirected to another screen. From there you are able to select a user and see the status of the App Protection policies. As you can see in the example below, a user-level wipe is still being performed for our test user Ferry. But you can also see that App Protection Policies have been applied to the Edge and Outlook app installed on the iPhone device.

You can also create some report data by clicking on the Report button, which will open the App Report pane, where several reporting options are available. For App protection you can use the App Report option, from here you can select platform (iOS/iPadOS or Android), the App and it’s status. This will give you an overview of all the users who are applicable to App Protection Policies. If you click on the user you will end up in the App reporting window mentioned already, providing an overview of which Apps received what policy.

Monitoring App Configuration Policies

App Configuration Policies status can only be downloaded into a CSV file, which can be further analyzed using Microsoft Excel. You can download the App Configuration report by clicking on “App configuration report”

From the Report button you also have some options to determine whether the App Configuration Policies have been delivered to the device.

Monitoring Conditional Access Policies

You should also monitor your Conditional Access policies in order to make sure that on mobile devices the only way to access the company data is by either using the web browser (for which you might have defined Conditional Access App Enforced Restriction) or by using the Approved Client Apps as detailed in this blogpost: Limit Access to Outlook Web Access, SharePoint Online and OneDrive using Conditional Access App Enforced Restrictions

From the sign-in logging you can check whether non-preferred protocols are still being used to access your Exchange Online environment for example. Make sure that no-one who has a mailbox still has the option to connect using an App which you cannot manage. See also the following articles on more information about how to detect non-preferred protocols and troubleshoot Conditional Access policies:

Conditional Access demystified, part 6: Troubleshooting Conditional Access

Microsoft is going to disable basic/legacy authentication for Exchange Online. What does that actually mean and does that impact me?

Troubleshooting on the device

In some circumstances having only the logging within the Microsoft Endpoint Manager admin center portal isn’t enough. In order to generate a logfile with more data you can type “about:intunehelp” in the Microsoft Edge browser on the device. This will open up the Intune Diagnostics page allowing you to collect Intune logfiles, which you can share from the device (f.e. by emailing them after which you can open the logfile using your favorite logfile viewer) or you can upload them to Microsoft (do not forget to also request the Reference ID in that case)

See: Use Edge for iOS and Android to access managed app logs for more information

Policy delivery

Policy delivery is not instant, that’s something you must be aware of. Depending on the user state, it can take up to 24 hours for policies to be delivered. Microsoft describes this here: Delivery timing summary Also keep in mind that retry intervals may require active app use to occur, meaning the app is launched and in use.

Keeping track of changes

Products like Microsoft Endpoint Manager, but also Operating systems like iOS and Android constantly change. If you implement Mobile Application Management you must be aware of what these changes are and determine the impact of these changes before they hit your users.

One example: With the release of iOS 14, Microsoft dropped support for iOS 12 – basically this means that you should determine who is still using iOS 12 within your organization and transition them to a supported OS again if you want your protection and configuration to keep working

Microsoft communicates these changes using the Message Center, my advice would be to integrate the message center into a Planner board and do proper follow up, see: Are you already synchronizing your Message Center messages to Planner? Here is why you should

Keeping an eye on the Microsoft 365 roadmap, and the Intune UserVoice is advised as well. The roadmap explains what’s in development and UserVoice gives you an idea of what Microsoft is considering on taking into development (the ideas with the most votes)

There are further plenty of resources if you have the proper Google search skills, there are plenty of good bloggers blogging about Microsoft Endpoint Manager and forums with information on this subject available.

And if you really cannot find a solution you can always create a support call with Microsoft, see: How to get support for Microsoft Intune

Conclusion

Mobile Application Management without enrollment within Intune has come a long way, I’ve worked with the functionality for some years now and can say that it has really evolved in a mature solution, capable of handling most scenario’s I face in implementing MAM in a Modern Workplace environment.

I hope this article gave you a good idea of its capabilities. If you made it to the conclusion, congratulations – it was a long read.