Block and allow apps on Samsung KNOX devices

This week a blog post about the capabilities to block apps from starting and to allow apps to install on Samsung KNOX devices. I thought it would be good to mention these capabilities, as many are only familiar with the capability to work with compliant or noncompliant apps on Android. That capability can only be used for reporting functionalities. These capabilities are specifically for Samsung KNOX devices and can truly, and literally, block apps from starting. During this post I’ll go through the high-level steps to configure a blocked app and the end-user experience for both capabilities.

Information

Let’s start with some information about what can be achieved by using the block apps from starting and the allow apps to install capabilities. When using the block apps from starting capability, a list must be created of apps that are blocked from running on the device. Apps in this list are blocked from being run, even if they were already installed when the policy was applied. This list doesn’t prevent users from installing the apps. When using the the allow apps to install capability, a list must be created of apps that users of the device are allowed to install from the Google Play store. Only the apps in this list can be installed. No other apps can be installed from the store. This list doesn’t prevent users from starting the apps.

Configuration

Now let’s have a look at the high-level steps for these configuration. However, before I’m going to look at these steps, it’s good to mention that the configurations can be achieved by using OMA-URI settings. The following OMA-URI settings are available for these configurations:

  • To create a block apps from starting list, use the following OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/PreventStartPackages
  • To create an allow apps to install list, use the following OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/AllowInstallPackages

To find the value for these OMA-URI settings, the Google Play Store can be used. The app identifier that is used within the store, is what is needed to add a value to the block or allow lists. For example, when I’m looking at the OWA for Android app, in the store, the bold section, in the following URL, represents the required value: https://play.google.com/store/apps/details?id=com.microsoft.exchange.mowa&hl=en.

Now let’s have a look at how these two come together in the configurations for Microsoft Intune hybrid and Microsoft Intune standalone.

Environment Configuration
Microsoft Intune hybrid

PreventStartPackages_MSIhThe configuration in Microsoft Intune hybrid can be performed by starting the Create Configuration Item Wizard in the Configuration Manager administration console. Make sure to select Android and Samsung KNOW (below Settings for devices managed without the Configuration Manager client) on the General page and to select Android KNOX Samsung Standard 4.0 and higher on the Supported Platforms page. Now select Configure additional settings that are not in the default setting groups on the Device Settings page and the configuration can begin by using the earlier mentioned OMA-URI settings.

Once the configuration is finished the created configuration item can be added to a configuration baseline and can be deployed to Samsung KNOX devices.

Microsoft Intune standalone

PreventStartPackages_MSIsThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Android 4.0 and later, Samsung KNOX Standard 4.0 and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added.

Once the configuration is finished the policy can be saved and can be deployed to Samsung KNOX.

Note: When the block or allow lists must contain multiple apps, one of the following four characters ; : , | can be used as a delimiter.

End-user experience

Let’s end this blog post by having a look at the end-user experience. Below, on the left, is the end-user experience when the end-user starts an app that is blocked from starting. It’s indeed correct that it doesn’t show a screenshot. Reason behind that is because it actually lacks a real end-user experience. When the end-user tries to start a blocked app, the app won’t start and the end-user won’t get any notifications. Below, on the right, is the end-user experience when the end-user tries to install an app that is not allowed to install. The end-user will receive an error message accompanied by the message “Security policy prevents installation of this application”, which is a clear end-user experience.

Block app from starting Allow app to install
The app won’t start and the end-user won’t get a notification about what’s happening. Screenshot_20170122-125800

More information

Fore more information about blocking and allowing apps on Android devices, please refer to:

Share

Predeclaring corporate-owned devices

This week something related to last week. This week will be about predeclaring corporate-owned devices. In other words, making sure that the Device Owner of the specified devices is set to Company after enrollment. It’s also a much easier solution, for a scripted solution that I created more than year ago, for automagically setting the mobile Device Owner to Company. In this blog post I’ll provide some information about this feature, I’ll show the configuration of this feature and I’ll show the administrator experience of this feature. Please note that this functionality is only available for Microsoft Intune hybrid.

Information

Predeclaring corporate-owned devices allows organizations to identify corporate-owned devices by importing the International Mobile Equipment Identity (IMEI) numbers, or, for iOS devices, by importing the serial numbers. It’s possible to upload a comma-separated values (.csv) file containing device IMEI numbers, or to manually enter device information. Imported information will make sure that the Device Owner will be set to Company for the devices that are in lists of devices. Keep in mind that this is only applicable to devices that still need to enroll. Already enrolled devices that are on the list will not change the Device Owner.

Configuration

Before I’m going through the required configuration steps, it’s good to mention the format of the csv files that can be used. The lines in the csv file can contain a maximum of 4 columns with the following items in the following order: IMEI number, iOS serial number, Platform (iOS, Windows, Android), Details. Each row must contain an IMEI number, or iOS serial number, and a Platform. The Details are optional. An example would look like the following.

,F9FFFFFFFFK9,iOS,Company-owned iOS device
357777777777748,,Android,Company-owned Android device

With this information, I can go through the required configuration steps. During these steps I’ll use the example csv information. It’s good to keep in mind that it’s also possible to manually add a single IMEI number or iOS serial number. In that case the wizard will simply skip the import page, mentioned below.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > All Corporate-owned Device > Predeclared Devices;
2 On the Home tab ,click Create Predeclared Devices to open the Create Predeclared Devices wizard;
3 CPD_GeneralOn the General page, select Upload a CSV file containing IMEI or serial numbers and details, select the csv file and click Next;
4 On the Import page, click Next;
5

CDP_EntryOn the Entry page, verify the information and click Next:

Note: This page is similar to when a single IMEI number or iOS serial number, is added, using this wizard. It’s even possible, at this point, to still manually add an additional IMEI number, or iOS serial number.

6

CDP_ProfileOn the Profile page, select an iOS enrollment profile and click Next:

Note: This is an optional page that will only show when an iOS device is imported. The refresh button can be used to update the selection box for newly created iOS enrollment profiles.

7 On the Summary page, review the summary and click Next:
8 On the Completion page, review the results and click Close.

Note: After completing the wizard, the Configuration Manager administration console will not automatically refresh. This requires a manually activity.

Administrator experience

Now it’s time to look at a few interesting places in the Configuration Manager administration console. When I now navigate to Assets and Compliance > Overview > All Corporate-owned Devices > Predeclared Devices, I can see the predeclared devices, including the enrollment status of those devices. Once a device is enrolled the status will reflect in the Configuration Manager administration console, as shown below.

PD_Overview

When the predeclared devices also contained iOS devices, the iOS devices are assigned to the selected iOS enrollment profile. When I now navigate to Assets and Compliance > Overview > All Corporate-owned Devices > iOS > Enrollment Profiles, I can select the iOS enrollment profile and see the related device count, as shown below. If I want to see even more information, I can select the iOS enrollment profile and click Show Assigned Devices.

EP_Overview

When I enroll the predeclared devices, the devices will show in the Configuration Manager administration console with the Device Owner set to Company. I can easily see this information when I navigate to Assets and Compliance > Overview > Devices, as shown below.

DS_Overview

Keep in mind that the Device Owner will only be set to Company when the predeclared devices are imported before the devices are enrolled. The Device Owner will not change for already enrolled devices.

More information

For more information about predeclaring company-owned devices, please refer to this article about Predeclare devices with IMEI or iOS serial numbers.

Share

Categorizing devices

This week something completely different as the last couple of weeks. This week no conditional access and nothing specifically related to Windows 10 devices. This week it’s all about categorizing devices. Within Microsoft Intune hybrid this functionality is named Device Categories and within Microsoft Intune standalone this functionality is named Device Group Mapping. Both of these functionalities can be used to achieve the same goal. In this post I’ll provide some more information, I’ll describe the configuration in Microsoft Intune hybrid and Microsoft Intune standalone and I’ll show the end-user experience.

Information

Categorizing devices can be useful to differentiate between device categories. For example, to differentiate between devices used by users of the sales department and the users of the human resources department. When categorizing devices, the following workflow is applicable.

  1. Create collections, or device groups, for each required category;
  2. Configure collection membership rules, or device group mapping rules, that map the categories to the collections, or device groups;
  3. When end-users enroll their device, they must choose a category from the configured categories. After they choose, their device will be automatically added to the corresponding collection, or device group;.
  4. Use the collections, or device groups, when deploying policies and apps.

Configuration

Now it’s time to start with the configuration of device categories. I’ll walk through the configuration steps for Microsoft Intune hybrid and standalone and I’ll provide the configuration options.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to create custom device categories and I’ll show how to use a device category.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Device Collections;
2 On the Home tab ,click Manage Device Categories to open the Manage Device Categories dialog box;
3 ManageDC_MIHIn the Manage Device Categories dialog box, click Create to open the Create Device Categories dialog box;
4 CreateDC_MIHIn the Create Device Categories dialog box, provide an unique name and click OK to return to the Manage Device Categories dialog box;
5 Back in the Manage Device Categories dialog box, click OK.

Now that I’ve created device categories, I can use them as a collection membership rule. Assuming a collection is already available, the device category can be added by performing the following steps.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Device Collections;
2 Select the required collection and on the Home tab ,click Properties to open the Properties of the collection;
3 Within the Properties of the collection, click Add Rule > Device Category Rule to open the Select Device Categories dialog box;
4

SelectDC_MIHIn the Select Device Categories dialog box, select a device category and click OK to return to the Properties of the collection;

Note: This will actually create a query collection membership rule that simply queries on the MDMDeviceCategoryID property of a device.

5 Back in the Properties of the collection, click OK.

Note: An administrator can add an additional column, named Device Category, to the devices overview (and any device collection), to get a quick overview of the used device categories for the devices.

Microsoft Intune standalone

Let’s continue with similar configuration within Microsoft Intune standalone. I’ll walk through the required steps to create a device group mapping. Assuming the required device groups are already available, the device group mapping rule can be add by performing the following steps.

1 In the Microsoft Intune administration console, navigate to ADMIN > Mobile Device Management > Device Group Mapping;
2 On the Device Group Mapping page, enable Device Group Mapping;
3 DGM_MISOn the Device Group Mapping page, with Step 2: Mapping device group mapping rules click Add to open the Add device group mapping rule dialog box;
4 AddDGM_MISIn the Add device group mapping dialog box, provide an unique name, select a device group and click Add to return to the Device Group Mapping page;
5 Back on the Device Group Mapping page, click Save.

End-user experience

After the configurations of the device categories are completed, it’s time to have a look at the end-user experience. During the enrollment of an iOS or Android device, the end-user will receive an additional message to choose a device category. Once completed that category will display in the Company Portal app and the Company Portal web app. On Windows devices the configuration can be completed after the enrollment, via the Company Portal web app.

Company Portal app Company Portal web app
IMG_0086 IMG_0087

More information

Fore more information about categorizing devices, please refer to:

Share

Conditional access for Exchange Online to the max

This week I want to show another look at conditional for Exchange Online. I want to do that by providing a scenario. That scenario will cover more than just conditional access. Mainly because conditional access simply blocks access to non-compliant devices, but what if I want to take it one step further? What if I also want to prevent potential data leakage? In that case I can’t just look at conditional access. In that case I also need to add mobile app management to the playing field. This post will address those subjects for Exchange Online.

Scenario

Now lets start with the scenario that I want to cover. Even though I know that I will use Microsoft Intune and related technologies to do the configuration, I want the scenario to describe functional requirements. The configuration should address the following requirements:

  • Email access is only allowed on managed and compliant devices;
  • Email data leakage must be prevented on managed and compliant devices;
  • Email access is available via the browser;
  • Email access is supported on iOS, Android and Windows 10.

Configuration

Now lets have a look at what I need to configure to address that scenario. The good news is that I can support this scenario with Microsoft Intune. However, the default configuration is not sufficient. I need to get creative. To address this scenario I need to make sure that email access is only available through browsers and apps that can be managed by mobile app management (MAM) policies or by Enterprise Data Protection (EDP)/ Windows Information Protection (WIP). No back doors allowed. That means that to address this scenario I need to add the following technical configurations on top of the standard conditional access and MAM (and WIP):

  • The OWA app for iOS and Android must be blocked;
  • ActiveSync apps that use basic authentication must be blocked;
  • The default browsers on iOS and Android must be blocked.

Block the OWA app

ADFS_DenyOWAThe first thing that I want to configure is a deny for the Microsoft OWA app. That specific app bypasses every form of conditional access. Luckily that doesn’t mean that there is nothing that I can do to block the app. I can use AD FS to deny specific client user agent claims for the Microsoft OWA app. 

The following example claim will deny every active claim that arrives via the AD FS proxy with a client user agent that contains MOWAHost. That should be distinctive enough to only deny the Microsoft OWA app. However, keep in mind that the Microsoft OWA app will only be blocked once it tries to verify the credentials.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “MOWAHost”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Block Exchange ActiveSync apps with basic authentication

The second thing I want to configure is a deny on every Exchange ActiveSync app with basic authentication, like the default mail app on iOS and Android. Those apps are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those apps can still leak data. The combination of the following three components allows me to only allow the Microsoft Outlook app, which is capable of working with MAM policies, on mobile devices.

1

ExchangeOnlinePolicy_EASThe first component that I need to address is the Exchange Online Policy for conditional access. I don’t want Microsoft Intune to control the access for the Exchange ActiveSync apps with basic authentication, I want Exchange Online to take care of those apps. Within Exchange Online I’ve got the ability to easily block or allow access to specific device families and models. Microsoft Outlook is available as a device family.

To achieve that Microsoft Intune doesn’t control those apps, I need to make sure that the setting Block non-compliant devices on platforms supported by Microsoft Intune and the setting Block all other devices on platforms not supported by Microsoft Intune are disabled in the conditional access policy for Exchange Online.

2

EA_AccessSettingsThe second component that I need to address are the Exchange ActiveSync access settings. Within these settings I can define the default behavior of Exchange Online when a device isn’t managed by a rule or personal exemption. In this case I want to block access to all mobile devices that are not part of the rule that I will define.

To achieve that every device is blocked when it’s not managed by a rule, I need to configure the Exchange ActiveSync Access settings to Block access.

3

EA_DeviceAccessThe third component that I need to address is the Device Access Rule. With a rule like this I can define which device families and models are allowed, blocked or quarantined. In this case I want to allow access to all mobile devices that use Outlook to connect.

To achieve that all mobile devices that use Outlook are allowed, I need to create a Device Access Rule with the Outlook device family and for All models.

Note: It’s even possible to specifically select Outlook for iOS and Android as model, but at this moment that cannot be enforced.

Block default browsers on iOS and Android

The third thing that I want to configure is a deny on the default browsers on iOS (Safari) and Android (Chrome). Those browsers are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those browsers can still leak data. Luckily that doesn’t mean that there is nothing that I can do to block those browsers.

ADFS_DenySafariDefault browser iOS (Safari)
I can use AD FS to deny specific client user agent claims for the Safari browser. However, the Safari browser is tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Safari. That isn’t only applicable to iOS, but also to Android and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Safari, but doesn’t contain Windows or Android. That should be distinctive enough to deny the Safari browser on iOS devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Safari/”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Windows|Android”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

ADFS_DenyChrome

Default browser Android (Chrome)
I can also use AD FS to deny specific client user agent claims for the Chrome browser. However, the Chrome browser is also tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Chrome. That isn’t only applicable to Android, but also to iOS and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Chrome and Android, but doesn’t contain PKeyAuth or ManagedBrowser. That should be distinctive enough to deny the Chrome browser on Android devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Chrome/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Android”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “PKeyAuth|ManagedBrowser|Windows”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Result

The result is awesome, in my personal opinion. I’ve successfully tested this configurations on iOS, Android and Windows 10 devices with multiple browsers and apps. This configuration, in combination with conditional access and MAM (and WIP), provides the following results:

  • Email access is only available on managed and compliant iOS and Android devices via the Managed Browser and on managed and compliant Windows 10 devices via Internet Explorer and Microsoft Edge. These browsers can be managed via MAM and WIP to prevent data leakage. Other browsers will be blocked by conditional access, or AD FS;
  • Email access is only available on managed and compliant iOS and Android devices via the Microsoft Outlook app on managed and compliant Windows 10 devices via Outlook. These apps can be managed via MAM and WIP to prevent data leakage. Other apps will be blocked by Exchange Online;
  • Known back doors are closed. The OWA app will be blocked by AD FS.

More information

Fore more information about conditional access for Exchange Online and mobile app management, please refer to:

Share

Conditional access for browsers

This week I’ll provide an overview about the latest addition to conditional access, which is conditional access for browsers. It’s a feature that many have been waiting for and a feature that is indeed a pretty welcome addition to conditional access. This post will provide the basics about conditional for browses, the configuration of conditional access for browsers and the end-user experience with conditional access for browsers. It will also be the introduction for something much better next week.

Introduction

Conditional access allows IT organizations to manage access to corporate email, files and other resources based on customizable conditions that ensure security and compliance. The addition of conditional access for browsers addresses the backdoor that still existed for end-users connecting to the Outlook Web App (OWA) and end-users using browser access to SharePoint and OneDrive for Business. It’s now possible to restrict Outlook Web App (OWA) and browser access to SharePoint and OneDrive for Business when accessed from a browser on iOS and Android devices. Access is only allowed from the following supported browsers, on compliant devices, while unsupported browsers are simply blocked:

  • Safari (iOS);
  • Chrome (Android);
  • Managed Browser (iOS and Android).

Note: Keep in mind that this does not block access via the OWA app. More about that in my post next week.

Configuration

Now let’s have a look at the configuration of conditional access for browsers. The configuration is the same for Microsoft Intune standalone and Microsoft Intune hybrid, as the configuration is part of the conditional access policies. It’s actually nothing more than one simple checkbox that belongs to one specific setting. That specific setting is Block non-compliant devices on the same platform as Outlook in the Exchange Online Policy and Block non-compliant devices on the same platforms as OneDrive for Business in the SharePoint Online Policy. That specific setting can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online SharePoint Online
OWAExchangeOnline OFBSharePointOnline

End-user experience

Now it’s time to look at the end-user experience, which is the most important part of this feature. Below I’ve got examples for compliant and non-compliant devices and supported and unsupported browsers. In all examples I’m trying to access https://outlook.office.com.

Android

Here is an example on an Android device using the supported Chrome browser and using the unsupported Firefox browser. The left column shows the non-compliant examples and the right column shows the compliant examples. Notice the clear message in the unsupported browser about using supported browsers for access.

Non-compliant Compliant
Screenshot_20160708-203644 Screenshot_20160710-181822
Screenshot_20160708-203757 Screenshot_20160708-204830

iOS

Here is an example on an iOS device using the supported Safari browser and using the unsupported Firefox browser. The left column shows the non-compliant examples and the right column shows the compliant examples. I haven’t been able to receive the same clear messages yet, as shown on my Android device, but the access is definitely blocked.

Non-compliant Compliant
IMG_0058 IMG_0056
IMG_0059 IMG_0057

Windows 10

I’ve also managed to successfully test conditional access for browsers on Windows 10, with Internet Explorer and Microsoft Edge, in combination with Microsoft Intune standalone and Microsoft Intune hybrid. Even in combination with Windows 10, fully managed by ConfigMgr. More about those awesome scenario’s once it’s listed as a supported platform with supported browsers.

More information

Fore more information about conditional access for browsers with Exchange Online and SharePoint Online, please refer to:

Share

Store accounts and the Microsoft Intune Company Portal app

CompanyPortalAppLogo_thumb9In this blog post I will answer a question that I get, with a lot of customers, and that’s if it’s required for end-users to have an account for the app store, of their platform, to download the Microsoft Intune Company Portal app. The app store that I mean here is can be the Google Play app store, the Apple app store,  the Windows Phone app store or the Windows app store. All these stores match with their platform and require their own store account to download apps.

Before I can answer the initial question, I first have to answer another question. That question is if it’s required to use the Microsoft Intune Company Portal app, simply because a store account is not required if the Microsoft Intune Company Portal app is not required. In this post I’ll try to answer both of these questions by providing tables for a nice overview of the requirements per platform. In general this is applicable for both Microsoft Intune standalone and Microsoft Intune integrated with ConfigMgr 2012.

Microsoft Intune Company Portal app

Now let’s start with the first question, is the Microsoft Intune Company Portal app required? In almost all the scenario’s the answer to this question will be, yes. Also, keep in mind that the advised scenario for every platform is to install the Microsoft Intune Company Portal app  and to enroll the mobile device. To be complete the following table lists the functional requirements for the Microsoft Intune Company Portal app  for every platform.

 Platform Enrollment and policies Application deployment
Android Yes Yes
iOS Yes1 Yes
Windows Phone 8.0 No Yes
Windows Phone 8.1 No Yes
Windows No Yes

1 It is possible to enroll iOS devices without using the Microsoft Intune Company Portal app. That can be achieved by either using portal.manage.microsoft.com on an iOS device, or by using the corporate device enrollment feature with Microsoft Intune standalone.

Store account

That brings me to the second question, is the store account required to get the Microsoft Intune Company Portal app? Well, this also differs per platform. To make it easy I can say that it’s required for the non-Microsoft platforms. The following table provides a quick overview per platform, including the alternatives for the Microsoft platforms.

Platform Store account required Alternative
Android Yes N/A
iOS Yes N/A
Windows Phone 8.0 No Microsoft Intune Company Portal app for Windows Phone
Windows Phone 8.1 No Microsoft Intune Company Portal app for Windows Phone 8.1
Windows No Microsoft Intune Company Portal app for Windows 8.1

Conclusion

At this moment the best method for end-users to enroll their device is to use the Microsoft Intune Company Portal app, if possible. In case the Microsoft Intune Company Portal app is not required for the enrollment, like with Microsoft platforms, it’s still advised to install the Microsoft Intune Company Portal app to better manage devices and applications.

Back to the original question, this would mean that, at this moment, a store account is always required for non-Microsoft platforms. For Microsoft platforms it depends on how the Microsoft Intune Company Portal app is deployed. Like I mentioned in my previous post, I like to use the Microsoft Intune Company Portal app for the Microsoft App store, if possible, and in that case a store account is required.

Share