Require BitLocker drive encryption via Windows 10 MDM

This blog post uses the BitLocker configuration service provider (CSP) to manage drive encryption on Windows 10 devices. This CSP was added in Windows 10, version 1703, which is currently available as Insider Preview build.

This blog post will be about requiring BitLocker drive encryption on Windows 10 devices. Until Windows 10, version 1703, this was not possible. It was only possible to create a compliance policy that would block access to Windows 10 devices without BitLocker enabled. Windows 10, version 1703, introduces the BitLocker CSP, which enables the administrator to manage BitLocker settings via Windows 10 MDM. In this post I’ll briefly go through the available settings in the BitLocker CSP and I’ll show how to require BitLocker drive encryption via Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the end-user experience.

Configuration

I’ll split the configuration in two sections. The first section about the available settings in the BitLocker CSP and the second section about how to configure the BitLocker drive encryption requirement. As the BitLocker CSP is new in Windows 10, version 1703, I thought it would be good to briefly go through the available settings.

Available settings

Let’s start by going through the available settings in the BitLocker CSP. The root node for the BitLocker CSP is ./Device/Vendor/MSFT/BitLocker and it contains the following settings.

Setting Description
RequireStorageCardEncryption This setting allows the administrator to require storage card encryption on the device.
RequireDeviceEncryption This setting allows the administrator to require encryption to be turned on by using BitLocker.
EncryptionMethodByDriveType This setting allows the administrator to configure the algorithm and cipher strength used by BitLocker.
SystemDrivesRequireStartupAuthentication This setting allows the administrator to configure whether additional authentication is required each time the computer starts.
SystemDrivesMinimumPINLength This setting allows the administrator to configure a minimum length for a TPM startup PIN.
SystemDrivesRecoveryMessage This setting allows the administrator to configure the recovery message or replace the existing URL.
SystemDrivesRecoveryOptions This setting allows the administrator to control how operating system drives are recovered.
FixedDrivesRecoveryOptions This setting allows the administrator to control how fixed data drives are recovered.
FixedDrivesRequireEncryption This setting allows the administrator to require BitLocker for fixed data drives to be writable on a computer.
RemovableDrivesRequireEncryption This setting allows the administrator to require BitLocker for a removable drive to be able to write data.

Configure settings

Now that I’ve been through all the available settings in the BitLocker CSP, let’s have closer look at the setting that enables the administrator to require BitLocker drive encryption. That’s the setting RequireDeviceEncryption. However, keep in mind that this still does require an interaction with the end-user. The end-user has to provide information about the currently used drive encryption and the end-user has to start the BitLocker drive encryption process. More about that in the end-user experience section. To require BitLocker drive encryption the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption
  • Date type: Integer
  • Value: 1

This configuration information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

BitLocker_IntuneHybridThe 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 Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 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 configurations are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices.

Microsoft Intune standalone (Azure portal)

BitLocker_IntuneStandaloneThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile, or add a row to an existing custom profile. With a new profile, make sure to select Windows 10 and later as Platform and Custom as Profile type. In the Custom OMA-URI Settings blade, add the custom settings by using the earlier mentioned OMA-URI settings.

Once the configurations are finished, the profile can be saved and can be deployed to Windows 10 devices.

End-user experience

Let’s end this post with the end-user experience. As I mentioned earlier, the end-user must still interact with the messages generated by the configuration to require BitLocker drive encryption. Once the configuration arrives at the Windows 10 device, the end-user will receive a toast message stating that “Encryption is needed”, as shown below on the left. After selecting that notification, the end-user will receive a dialog box with the question “Are you ready to start encryption”, as shown below on the right.

BitLocker_ToastMessage BitLocker_DialogBox

After checking the applicable boxes and clicking Yes, the end-user will get the standard BitLocker Drive Encryption wizard. During that wizard the end-user must specify the location to back up the recovery key, choose the encryption method and the end-user can start the encryption.

More information

For more information about the BitLocker CSP, please refer to this article about the BitLocker CSP.

Share

Offboard Windows 10 devices of Windows Defender Advanced Threat Protection

This week a follow-up on my post of last week. Last week was about onboarding Windows 10 devices for Windows Defender Advanced Threat Protection (ATP) and this week will be about offboarding Windows 10 devices of Windows Defender ATP. For devices that are leaving the company, for whatever reason, it’s good to first offboard those devices of Windows Defender ATP. That will remove the Windows Defender ATP settings from the device and the device will stop collecting and sending data. In this post I’ll show how to offboard Windows 10 devices, via Configuration Manager and Microsoft Intune, and I’ll show the end result. The steps in this post will be similar to the steps in the post of last week.

Configuration

Just like last week, there are multiple methods available to offboard Windows 10 devices of Windows Defender ATP. Those methods are Group Policy, Configuration Manager, mobile device management (including Microsoft Intune) and a local script. I’ll have a closer look at the configurations for offboarding Windows 10 devices via Configuration Manager and Microsoft Intune.

Create offboarding configuration file

Before starting with the configuration, it’s required to create an offboarding configuration file. The process for this is fairly simple and straightforward. Logon to the Windows Defender Security Center and select Endpoint Management. Now select Endpoint offboarding, select the configuration method and download the required file, as shown below. After selecting download, an additional confirmation message will show, mentioning the expiration date of the offboarding package. For security reasons an offboarding package will always expire after 30 days.

System Center Configuration Manager Mobile Device Management
WDATP_SCCM_Offboarding WDATP_MDM_Offboarding

Configure endpoints using Configuration Manager

The first configuration method that I would like to show is using Configuration Manager, by creating and deploying a Windows Defender ATP Policy.  This configuration method is only supported on Windows 10 devices, version 1607 and later, running the Configuration Manager client. On-premises mobile device management and Microsoft Intune hybrid MDM-managed computers are not supported. The following 6 steps show how to create the Windows Defender ATP Policy. After that, simply deploy the created policy.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Endpoint Protection > Windows Defender ATP Policies;
2 On the Home tab, in the Create group, click Create Windows Defender ATP Policy to open the Create Windows Defender ATP Policy Wizard;
3

CWDATPPW_General_OffOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the Windows Defender ATP policy;
  • Description: (Optional) Provide a description about the Windows Defender ATP policy;
  • Select Offboarding – Remove devices from the online service (for example, when the device is no longer managed).
4

CWDATPPW_ConfigFile_OffOn the Configuration File page, Browse to the WindowsDefenderATP.offboarding file that is available in the downloaded WindowsDefenderATPOffboardingPackage.zip file and click Next;

Note: The default name of the offboarding package, also contains the expiration date of the offboarding package.

5 On the Summary page, click Next;
6 On the Completion page, click Close.

Note: Make sure that a device is not targeted with an onboarding and offboarding configuration at the same time. This might cause unpredictable behavior.

Configure endpoints using Microsoft Intune

The second configuration method that I would like to show is using Microsoft Intune hybrid and Microsoft Intune standalone, Windows Defender ATP supports Microsoft Intune by providing OMA-URI settings to create policies to manage endpoints. To achieve this the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Offboarding
  • Date type: String
  • Value: [Content of the WindowsDefenderATP.offboarding file that is available in the downloaded WindowsDefenderATPOffboardingPackage_valid_until_yyyy-mm-dd.zip file]

Just to make sure that it’s absolutely clear, the value, of the OMA-URI configuration, is literally a copy-paste action of the content available in the WindowsDefenderATP.offboarding file. This information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

CI_WindowsATP_OffboardingThe 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 Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 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.

CIRule_WindowsATP_OffboardingIn this case, I also provide a screenshot of the configured rule. Again to make absolutely sure that it’s a lot of characters that the rule should comply to.

Once the configurations are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices.

Microsoft Intune standalone

CP_WindowsATP_OffboardingThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added by using the earlier mentioned OMA-URI settings.

Once the configurations are finished, the policy can be saved and can be deployed to Windows 10 devices.

Note: Make sure that a device is not targeted with an onboarding and offboarding configuration at the same time. This might cause unpredictable behavior.

End result

Let’s end this blog post by having a look at the end result. I’ll do that by showing that a successful offboarding can be verified in the registry of the Windows 10 device, as shown below. The OnboardingState should be set to 0.

WDATP_Registry_Offboarding

More information

For more information about Windows Defender ATP and the offboarding, please refer to the following articles:

Share

Onboard Windows 10 devices for Windows Defender Advanced Threat Protection

This week a blog post about onboarding Windows 10 devices for Windows Defender Advanced Threat Protection (ATP). Windows Defender ATP is a relatively new service that will help enterprises to detect, investigate, and respond to advanced attacks on their networks. In this post I’ll show how to onboard Windows 10 devices, via Configuration Manager and Microsoft Intune, and I’ll show the end result in the Windows Defender Security Center and the Configuration Manager administration console.

Configuration

There are multiple methods available to onboard Windows 10 devices for Windows Defender ATP, Group Policy, Configuration Manager, mobile device management (including Microsoft Intune) and a local script. I’ll have a closer look at the configurations for onboarding Windows 10 devices via Configuration Manager and Microsoft Intune.

Create onboarding configuration file

Before starting with the configuration, it’s required to create an onboarding configuration file. The process for this is fairly simple and straightforward. Logon to the Windows Defender Security Center and select Endpoint Management. Now simply select the configuration method and download the required file, as shown below.

System Center Configuration Manager Mobile Device Management
WDATP_SCCM_Enrollment WDATP_MDM_Enrollment

Configure endpoints using Configuration Manager

The first configuration method that I would like to show is using Configuration Manager, by creating and deploying a Windows Defender ATP Policy. By adding and deploying a client onboarding configuration file, via the Windows Defender ATP Policy, Configuration Manager can monitor the deployment status and the  Windows Defender ATP agent health. Windows Defender ATP is only supported on Windows 10 devices, version 1607 and later, running the Configuration Manager client. On-premises mobile device management and Microsoft Intune hybrid MDM-managed computers are not supported. The following 7 steps show how to create the Windows Defender ATP Policy. After that, simply deploy the created policy.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Endpoint Protection > Windows Defender ATP Policies;
2 On the Home tab, in the Create group, click Create Windows Defender ATP Policy to open the Create Windows Defender ATP Policy Wizard;
3

CWDATPPW_GeneralOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the Windows Defender ATP policy;
  • Description: (Optional) Provide a description about the Windows Defender ATP policy;
  • Select Onboarding – Add devices to the online service and start sending threat data for analysis.
4

CWDATPPW_ConfigFileOn the Configuration File page, Browse to the WindowsDefenderATP.onboarding file that is available in the downloaded WindowsDefenderATPOnboardingPackage.zip file and click Next;

5

CWDATPPW_AgentConfigOn the Agent Configuration page, select, depending on the requirements, None or All the file types and click Next;

6 On the Summary page, click Next;
7 On the Completion page, click Close.

Configure endpoints using Microsoft Intune

The second configuration method that I would like to show is using Microsoft Intune hybrid and Microsoft Intune standalone, Windows Defender ATP supports Microsoft Intune by providing OMA-URI settings to create policies to manage endpoints. To achieve this the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Onboarding
  • Date type: String
  • Value: [Content of the WindowsDefenderATP.onboarding file that is available in the downloaded WindowsDefenderATPOnboardingPackage.zip file]

Just to make sure that it’s absolutely clear, the value, of the OMA-URI configuration, is literally a copy-paste action of the content available in the WindowsDefenderATP.onboarding file. This information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

CI_WindowsATP_OnboardingThe 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 Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 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.

CIRule_WindowsATP_OnboardingIn this case, I also provide a screenshot of the configured rule. Again to make absolutely sure that it’s a lot of characters that the rule should comply to.

Once the configuration are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices.

Microsoft Intune standalone

CP_WindowsATP_OnboardingThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added by using the earlier mentioned OMA-URI settings.

Once the configurations are finished, the policy can be saved and can be deployed to Windows 10 devices.

End result

Let’s end this blog post by having a look at the end result. I’ll do that by providing a status view from the Windows Defender Security Center. Before doing that, it’s good to mention that a successful onboarding can be verified in the registry of the Windows 10 device, as shown below.

WDATP_Registry

Once the onboarding is successful for the Windows 10 devices, the information about those devices will start flowing to the Windows Defender Security Center. The Machines section in the Windows Defender Security Center will provide an overview of those devices and their status, as shown below.

WDATP_Machines

To see more information about the Windows 10 devices, click on a device and it will show a Machines view about the selected device. This view contains information about the logged on users, the reporting status, the alerts and the machine timeline. To get information in the Alerts section, I’ve simply created an EICAR test file, as shown below. This also enables me to select the alert and get more information about the alert, see the process tree and see the incident graph.

WDATP_Alerts

From a Configuration Manager perspective, I’ve saved the coolest information until the end. Windows 10 devices managed with the Configuration Manager client and successfully onboarded with the Windows Defender ATP Policy will also report information to Configuration Manager. This information can be viewed via additional columns in normal device views and collections. Even better, it will also show agent information in the Windows Defender ATP Status dashboard, as shown below.

WDATP_SCCM

Keep in mind that the Windows Defender ATP Status dashboard only shows information for Windows 10 devices managed with the Configuration Manager client and not for Windows 10 devices managed via MDM.

More information

For more information about Windows ATP and the onboarding, please refer to the following articles:

Share

Company Portal app enrollment for Windows 10

This week a small blog post about the Company Portal app enrollment experience, for Windows 10 Desktop devices, that has been recently added to the Company Portal app. This new experience enables the end-user to perform the enrollment procedure during the initial sign-in to the Company Portal app and aligns the enrollment experience with the other supported platforms.. This blog post will show this new enrollment experience, the new alterative enrollment experience and the end result.

Main end-user enrollment experience

Now let’s start by looking at the main new end-user enrollment experience on Windows 10 Desktop devices via the Company Portal app. This complete experience is nothing more than the following 4 simple steps.

1 CompanyPortal_01The end-user opens the Company Portal app and is prompted to provide a work or school account;
2 CompanyPortal_02The end-user provides its work account, which takes the end-user to the sign-in page of the company, provides its password and clicks Sign in;
3 CompanyPortal_03The end-user is brought to a new experience that enables the end-user to immediately start the enrollment of its device by clicking Yes;
4 CompanyPortal_04The end-user is shown a success message and only needs to click Done to continue in the Company Portal app with a successfully enrolled Windows 10 device.

Alternative end-user enrollment experience

The alternative new experience, for Windows 10 Desktop devices, is available when the end-user clicks Skip for now during step 3 mentioned above. This enables the following experience in the Company Portal app.

1 CompanyPortal_05The end-user opens the Company Portal app and should click on the message Either this device isn’t enrolled, or the Company Portal app can’t identify it. To install apps and gain access to company resources, you must enroll or identify this devices. Tap this message to get started.;
2 CompanyPortal_06The end-user is brought to a new experience that enables the end-user to immediately navigate to the standard Windows 10 enrollment experience, by clicking Enroll this device;
3 CompanyPortal_07The end-user is brought to the standard Windows 10 enrollment experience.

End result

The end result during both new enrollment experiences is the same. In both cases the end-user will end-up with a workplace joined and Microsoft Intune managed Windows 10 Desktop device, as shown below.

CompanyPortal_Result_01 CompanyPortal_Result_02
Share

Deploy the commercial ID via Windows 10 MDM

Yeah, I had some problems this week with thinking of a title that would fit with the content. Usually I’ve got the title before I start with the content, this week not even close. The main reason for that is the fact that this weeks blog post is mainly focused on distributing the commercial ID that’s used for connecting Windows 10 devices to Windows telemetry related solutions, like Upgrade Analytics (preview) and Update Compliance (preview). As those features and terminologies are not that widely known, yet, using commercial ID in the title might not be very catchy. That being said, I used it anyway. This blog post will provide an introduction about what can be achieved by deploying the commercial ID, what the required configurations are and the current administrator experience.

Introduction

Until recently Windows telemetry data, was mainly used as vital technical data from Windows devices about the device and how Windows and related software are performing. Nowadays sharing information with Microsoft helps make Windows and other products better, but can also help making internal processes and user experiences better, as well. Microsoft is in the process of developing sets of analytics customized for internal use. The first two examples of these sets are Update Compliance (preview) and Upgrade Analytics (preview). Update Compliance (preview) can be used to verify the update compliance of Windows 10 in the organization and Upgrade Analytics (preview) can be used to plan and manage upgrade projects to the latest build of Windows 10. Even for devices managed via Windows 10 MDM. This enables organizations to simply report about upgrade and update compliance on all Windows 10 devices. To make sure that the correct information is shown with the correct with organization, the commercial ID is used.

Configuration

Now let’s have a look at the configuration requirements, from a device perspective. To enable devices to report data and make sure that the information can be used for the right purposes, there are two configurations required:

  1. Windows telemetry must be enabled;
  2. Commercial ID must be configured.

Prerequisites

Before starting with the two configurations on the Windows 10 devices, it’s good to keep in mind that the following configurations must be in-place:

  • The organization must use the Operations Management Suite (OMS);
  • The Update compliance (preview) solution must be added to OMS;
  • The Upgrade analytics (preview) solution must be added to OMS.

Step 1: Enable Windows telemetry

The first configuration that must be in-place, is that Windows telemetry must be enabled. This should be at least configured to the basic level. The different levels and the corresponding values are shown below.

Level Data gathered Value
Security Security data only 0
Basic Security data, and basic system and quality data. 1
Enhanced Security data, basic system and quality, and enhanced insights and advanced reliability data. 2
Full Security data, basic system and quality data, enhanced insights and advanced reliability data, and full diagnostics data. 3

To make sure that the Windows 10 devices all have Windows telemetry enabled, the following OMA-URI configuration can be used:

  • OMA-URI: ./Vendor/MSFT/Policy/Config/System/AllowTelemetry
  • Date type: Integer
  • Value: [At least 1]

Now let’s have a look at how these configurations come together for Microsoft Intune hybrid and Microsoft Intune standalone. It’s not a step-by-step guidance, but it should provide enough information to get the correct configurations in-place.

Environment Configuration
Microsoft Intune hybrid

SystemTelemetry_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 Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 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 are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices.

Microsoft Intune standalone

SystemTelemetry_MSIsThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy wizard for Custom Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added by using the earlier mentioned OMA-URI settings.

Once the configurations are finished, the policy can be saved and can be deployed to Windows 10 devices.

Step 2: Configure commercial ID

The second configuration that must be in-place, is that the commercial ID must be configured. The commercial ID can be located and generated in the OMS portal. In the OMS portal navigate to Settings > Connected Sources > Windows Telemetry.

Note: Only regenerate a commercial ID key if the original ID key can no longer be used. Regenerating a commercial ID key resets the data in the workspace for all solutions that use the ID.

OMS_WindowsTelemetry

To make sure that the Windows 10 devices all have the correct commercial ID configured, the following OMA-URI configuration can be used:

  • OMA-URI: ./Vendor/MSFT/DMClient/Provider/ProviderID/CommercialID
  • Data type: String
  • Value: [The commercial ID]

Now let’s have a look at how these configurations come together for Microsoft Intune hybrid and Microsoft Intune standalone. It’s not a step-by-step guidance, but it should provide enough information to get the correct configurations in-place.

Environment Configuration
Microsoft Intune hybrid

DMClient_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 Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 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 are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices.

Microsoft Intune standalone

DMClient_MSIsThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added by using the earlier mentioned OMA-URI settings.

Once the configurations are finished, the policy can be saved and can be deployed to Windows 10 devices.

Administrator experience

Let’s end this blog post by having a look at the administrator experience. I’ll do that by providing a few status views from the OMS portal, related to the Update compliance (preview) and Upgrade analytics (preview) solutions. Before doing that, it’s good to mention that, besides the normal locations for MDM configurations, the commercial ID can be verified on a Windows 10 device in the registry, as shown below.

Reg_CommercialID

Update compliance (preview)

The Update compliance (preview) solution can be located in the overview of the OMS portal. After Windows 10 devices are reporting information, this solution can be used to get overviews about update compliance as shown below (and more).

Overall quality update status – Quality updates are cumulative and can contain both security and non-security fixes. Windows 10 devices that are up-to-date have the latest quality update installed. Besides this overall status overview, this solution provides an overview with the differentiation per OS version. These overviews are selectable and provide even more detailed information about the quality update status. OMS_QualityUpdateStatus
Overall feature update status – Windows 10 devices can be configured to be on Current Branch (CB), Current Branch for Business (CBB) or Long term Servicing Branch (LTSB). Windows 10 devices on the latest CB with the latest quality update installed are considered current. Besides this overall status overview, this solution provides an overview with the differentiation per OS version. These overviews are selectable and provide even more detailed information feature update status. OMS_FeatureUpdateStatus

Upgrade analytics (preview)

The Upgrade analytics (preview) solution can be located in the overview of the OMS portal. After Windows 10 devices are reporting information, this solution can be used to get overviews about the upgrade status, as shown below, and possible application and driver issues.

Note: The Upgrade analytics (preview) solution can also be integrated with Configuration Manager.

Upgrade overview – The Target version, for Windows 10 devices, in this solution can be configured via the Solution Settings. The configured version will impact the information shown in the overviews. Besides the upgrade overview, this solution provides overviews about discovered applications and drivers and their known issues. It does that by providing the following steps to plan an upgrade:

  • Step 1: Identify important apps;
  • Step 2: Resolve issues;
  • Step 3: Deploy;
  • Office add-ins;
  • Site discovery.
OMS_UpgradeOverview

More information

For more information about telemetry, upgrade analytics and update compliance, please refer to the following articles:

Share

Require multi-factor authentication for enrollment

This week’s blog post will continue about conditional access. However, this time I’m going to look at a specific scenario in which conditional access is the key to making it easy to solve. This week I’m going to show three options, well actually only two, for requiring multi-factor authentication (MFA) during the enrollment of a device. First I’m going through the different configuration options and after that I’ll show the end-user experience per configuration option.

Configuration options

Now let’s start by having a look at the different configuration options. When I’m looking at the different configuration options, I want to look a little bit further than just the Microsoft Intune enrollment. I also want to include the Azure AD join, as it’s a common additional configuration. That makes that to require MFA during the enrollment of a device, the following options are available:

  • Require MFA to join Azure AD;
  • Require MFA for Microsoft Intune enrollment;
  • Require MFA for Microsoft Intune enrollment for Windows devices only.

Option 1: Multi-factor authentication to join Azure AD

The first option is to require MFA to join a device to Azure AD. When Microsoft Intune is configured in Azure AD to automatically enroll during the Azure AD join, it’s possible to simply require MFA to join Azure AD. That would require the end-user to use MFA to join and enroll the device. However, the down-side of this configuration is that it’s really specific to Windows devices that can perform an Azure AD join. When other platforms are in the picture, this solution will not be enough to require MFA during every enrollment.

To configure the MFA requirement for joining Azure AD, the Azure portal and the Azure classic portal can be used. Both configuration options are described below.

Azure portal – In the Azure portal the requirement to use MFA to join devices to Azure AD can be configured by using the following steps.

  • In the Azure portal navigate to Azure Active Directory > Users and groups > Device Settings;
  • Select Yes with Require Multi-Factor Auth to join devices and click Save.
AzurePortal_MFA

Azure classic portal – In the Azure classic portal the requirement to use MFA to join devices to Azure AD can be configured by using the following steps.

  • In the Azure classic portal navigate to ACTIVE DIRECTORY > <Tenant>CONFIGURE;
  • Navigate to the section devices;
  • Select YES with REQUIRE MULTI-FACTOR AUTH TO JOIN DEVICES and click SAVE.
AzureClassicPortal_MFA

Note: Not only do both configuration options have the same effect, but both configurations options are stored in the same location. In other words, when this is configured in the Azure portal it will also show in the Azure classic portal and vice versa.

Option 2: Multi-factor authentication for Microsoft Intune enrollment

The second option is to require MFA to enroll a device into Microsoft Intune. This configuration would require the end-user to always use MFA to enroll a device. For every supported platform. The down-side of this configuration is that it’s really specific to Microsoft Intune enrollments. When there are devices that only need to perform an Azure AD join, this solution will not be enough to require MFA during every Azure AD join.

To configure the MFA requirement for enrolling into Microsoft Intune, the Azure portal and the Azure classic portal can be used. Both configuration options are described below.

Azure portal – In the Azure portal the requirement to use MFA to enroll devices to Microsoft Intune can be configured by using the following steps.

  • In the Azure portal navigate to Azure Active Directory > Enterprise applications > All applications > Microsoft Intune Enrollment > Conditional access;
  • Click Add and specify the following:
    • Specify a name to identify the conditional access policy;
    • In the Users and groups assignment, select All users and click Done;
    • In the Cloud apps assignment, Microsoft Intune Enrollment should be preselected;
    • In the Grant control, select Allow access and Require multi-factor authentication and click Select;
    • Click On with Enable policy and click Create.
AzurePortal_CA_MFA

Azure classic portal – In the Azure classic portal the requirement to use MFA to enroll devices to Microsoft Intune can be configured by using the following steps.

  • In the Azure classic portal navigate to ACTIVE DIRECTORY > <Tenant>APPLICATIONS > Microsoft Intune Enrollment > CONFIGURE;
  • Navigate to the section multi-factor authentication and location based access rules;
  • Select ON with ENABLE ACCESS RULES, select Require multi-factor authentication with RULES and click SAVE.
AzureClassicPortal_CA_MFA

Note: In the Azure portal there are multiple roads to eventually create a conditional access. One is as shown above, by starting with the application, and another is by going straight to Azure Active Directory > Conditional access. This is the overview location of conditional access that shows all the created policies. Adding a new policy at this location, only requires an additional actions to select the correct Cloud app.

Option 3: Multi-factor authentication for Microsoft Intune enrollment for Windows devices only

The third option used to be the option to require MFA to enroll a Windows device into Microsoft Intune. That configuration could be done through the Intune Silverlight portal and through the Configuration Manager console. The configuration is even still available in the Configuration Manager console. However, this option should not be used anymore. The advise is to use one of the other two options. This was also the most limiting MFA requirement, as it was only available for Windows devices.

End-user experience

Let’s end this post with a brief look at the end-user experience. It’s hard to point out any differences between the different methods. At least from a look-and-feel perspective. The only difference might be the moment of the MFA prompt. However, that might not even be noticed by a normal end-user. The end-user will simply get a MFA challenge during the authentication and will probably not notice the difference in timing.

In other words, choosing the right option really depends on the scenario that must be addressed. It will not further impact the end-user.

MFA

More information

For more information about multi-factor authentication and conditional access, please refer to:

Share

Conditional access is getting better and better and better

Yeah, I know, I’ve been using similar blog post titles recently. And yes, it might sound cheesy. However, looking specifically at conditional access, it’s easy to say that the current evolution, in the Azure portal, is better than it is in the Azure classic portal, which is better than it is in the Intune Silverlight portal. Based on that, maybe  “The evolution of conditional access” would have been a nice title also. In this post I will go through a little bit of history of conditional access, followed by going through the enhanced capabilities of conditional access in the Azure portal.

Little bit of history

Let’s start by looking at a little bit of history of conditional access. No, I won’t put all the evolutions on a timeline, but I will try to show the biggest changes. Conditional access started as a feature in the Intune Silverlight portal only. In that time it was limited to a few Office 365 services. Later on conditional access also became part of the Azure classic portal and the functionalities got expanded to include other cloud apps and published apps. Very recently conditional access also became part of the Azure portal (still in preview) and the functionalities got expanded to include multiple policies and many, many configuration options. Now let’s go through these evolution in a bit more detail.

Intune Silverlight portal – The Intune Silverlight portal is the portal were it all started for the conditional access functionalities. In the Intune Silverlight portal it’s possible to enable and configure conditional access for the following Microsoft cloud services:

  • Exchange Online;
  • Exchange On-premises;
  • Exchange Online Dedicated (new and legacy);
  • SharePoint Online;
  • Skype for Business Online;
  • Dynamics CRM Online.

Within the conditional access policies it’s possible to configure the following conditions:

  • Platforms (all or specific);
  • Browser (all or supported only);
  • Groups (targeted and/or exempted).
IntuneSilverlight_Example

Azure classic portal – The Azure classic portal is the portal that started with providing more capabilities by making conditional access configurations available as part of Azure AD. In the Azure classic portal it’s possible to configure conditional access for the following additional apps (in addition to the Intune Silverlight portal):

  • Software as a service (SaaS) apps connected to Azure AD;
  • On-premises apps published via the Azure AD Application Proxy.

Within the conditional access policies it’s possible to configure the following additional conditions (in addition to the Intune Silverlight portal):

  • Multi-factor authentication (always, when not at work, block when not at work).
AzureClassic_Example

Azure portal – The Azure portal is still in preview for the Azure AD functionalities. However, the Azure portal is were conditional access becomes  a grown-up functionality. The Azure portal also supports all the mentioned apps from the Azure classic portal and the Intune Silverlight portal. On top of that, it enables the ability to create one policy for all apps, or a policy per app, or even multiple policies per app.

Within the conditional access policies it’s also possible to configure all the mentioned conditions from the Azure classis portal and the Intune Silverlight portal. On top of that, it enables to ability to make every available combination of the available conditions.

Note: The Azure portal even includes the capability to configure conditional access for managed apps. This is part of the Intune mobile app management configuration.

Azure_Example

Note: At this moment all three locations are still available for configuring conditional access. When a conditional access policy is configured at multiple locations, the end-user only gets access when all requirements are met.

Conditional access in the Azure portal

This section is about a preview of the Azure AD management experience in the Azure portal.

Now let’s have a look at the new conditional access experience in the Azure portal and why these changes are really interesting. Let’s do this by going through the different controls and condition statements that are available in the Azure portal.

Policies

The first thing that’s important to know, is that there is no limit anymore in creating conditional access policies for specific apps. The configuration in the Azure portal enables the administrator to create multiple conditional access policies. Not just one per cloud app, but it can even be multiple policies per cloud app. Before every sign-in, Azure AD evaluates all applicable policies and ensures that all requirements are met before granting access to the end-user. Now let’s have a look at adding a policy in more detail.

Policy – When adding a new conditional access policies there are the following 4 sections that can be configured:

  • Name: Every conditional access policy requires a name. That name will be used to identify the policy;
  • Assignments: With assignments the administrator defines the criteria that need to be met, for the controls to be applied, in the form of a condition statement;
  • Controls: With controls the administrator can either block access or allow access. And by allowing access the administrator can also add additional requirements;
  • Enable policy: Every conditional access policy will only be applied when it’s enabled.

Azure_NewPolicy

Assignments

The next thing is to have a look the different assignments that can be part of the condition statement. The assignments can be configured for User and groups, Cloud apps and additional Conditions. When there are multiple assignments configured in the conditional access policy, all assignments are logically ANDed. If there are multiple assignment configured, all assignments must be satisfied.

User and groups – In the User and groups assignment, the administrator can configure to who the conditional access policy must be applied. This can be done by including all users, or by  selecting specific users and/or groups. When specific users must be excluded, that can be configured by adding those users in the exclude section of this assignment. Azure_UsersGroups
Cloud apps – In the Cloud apps assignment, the administrator can configure to what the conditional access policy must be applied. This can be done by including all cloud apps, or by selecting specific cloud apps. When specific apps must be excluded, that can be configured by adding those apps in the exclude section of this assignment. Azure_CloudApps

Conditions – In the Conditions assignment, the administrator can configure how the conditional access must be applied. This can be done by configuring conditions in the following areas:

  • Sign-in risk: In the Sign-in risk condition, the administrator can configure to which risk the conditional access policy must be applied. This can be done by selecting the risk level of High, Medium, Low and No risk;
  • Device platforms: In the Device platforms condition, the administrator can configure to which platforms the conditional access policy must be applied. This can be done by including all platforms, or by selecting specific platforms. When specific platforms must be excluded, that can be configured by adding those platforms in the exclude section of this condition;
  • Locations: In the Location condition, the administrator can configure to which locations the conditional access policy must be applied. The location is identified by the IP address of the device used by the end-user. This can be done by including all locations, or by selecting specific trusted IPs. When trusted IPs must be excluded, that can be configured by selecting those trusted IPs in the exclude section of this condition;
  • Clients apps: In the Client apps condition, the administrator can configure to which apps the conditional access policy must be applied. This can be done by selecting Browser and/or Mobile apps and desktop app.
Azure_Conditions

Controls

Let’s end this post by having a look at the different controls. The controls can be used to either block or allow access. And by allowing access the administrator can, and also must, add additional requirements.

Grant – In the Grant control, the administrator can configure what must be done when the configured conditions happen. This can be done by selecting Block access or Allow access. When the control is used to allow access at least one of the following requirements must be configured:

  • Require multi-factor authentication: The multi-factor authentication requirement can be used to require strong authentication. This can be used in combination with Azure multi-factor authentication, or with an on-premises multi-factor authentication provider (in combination with ADFS);
  • Require compliant device: The compliant device requirement can be used to require a device to be compliant to an additional device compliancy policy. That compliancy policy can be targeted through Microsoft Intune (or any other MDM management solution);
  • Require domain joined device: The domain joined device requirement can be used to require a device to be domain joined to an on-premises AD. The domain join requires automatic registration of the domain joined device in Azure AD.

When multiple requirements are configured in the conditional access policy, the administrator can choose to require all the selected controls or just one of them.

Azure_Grant

Note: Currently, when the control requires multi-factor authentication or a compliant device, the user will be prompted for multi-factor authentication irrespective of the device compliance state.

More information

For more information about conditional access via the Azure portal, the Azure classic portal, or the Intune Silverlight portal, please refer to:

Share

Managing Windows 10 IoT Core devices via MDM

This week a new challenge for a new blog post, managing Windows 10 IoT Core devices. The nice thing about Windows 10, even Windows 10 IoT Core, is the availability of MDM. The availability of MDM is what will help me with managing Windows 10 IoT Core devices. In this post I’ll go through the steps to create an enrollment profile to enroll Windows 10 IoT Core devices in Microsoft Intune hybrid. I’ll end this post with an overview of the end result in Configuration Manager

Configuration

Let’s start by looking at the configuration in Configuration Manager. To create an enrollment profile, for Windows 10 IoT Core devices, it’s required to provide a certificate profile and it’s optionally to provide a Wi-Fi profile.

Create certificate profile

The required component of the enrollment profile is, as mentioned before, a certificate profile. The certificate profile is used to automatically provision a trusted root certificate to the enrolled device. As part of preparing for the certificate profile, export a root certificate.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Compliance Settings > Company Resources > Certificate Profiles;
2 On the Home tab, in the Create group, click Create Certificate Profile to open the Create Certificate Profile Wizard;
3

CCPW_GeneralOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the certificate profile (max. 256 characters);
  • Description: (Optional) Provide a description about the certificate profile;
  • Select Trusted CA certificate.
4

CCP_TCACOn the Trusted CA Certificate page, provide the following information and click Next;

  • Browse to and select the Certificate file;
  • Select Computer certificate store – Root;
  • Certificate thumbprint will automatically populate.
5

CCPW_SPOn the Supported Platforms page, select Windows 10 and click Next;

Note: Windows 10 IoT Core doesn’t have it’s own platform option, which means that the generic Windows 10 should be used to make it applicable to all Windows 10 devices.

6 On the Summary page, click Next;
7 On the Completion page, click Close.

(Optional) Create Wi-Fi profile

The optional component of the enrollment profile is, as mentioned before, a Wi-Fi profile. In some scenarios this might be a required component, but it’s not required for the creation of an enrollment profile. Including a Wi-Fi profile in the enrollment profile can be useful when the Windows 10 IoT Core device needs the Wi-Fi profile for connecting with the Internet.

Create enrollment profile

After creating the required and optional components for the enrollment profile, it’s time to create the enrollment profile. The enrollment profile specifies settings that are required for the Windows 10 IoT Core device enrollment, including a certificate profile that will dynamically provision a trusted root certificate to the device and a Wi-Fi profile that will provision network settings if required.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > All Corporate-owned Devices > Windows > Enrollment Profile;
2 On the Home tab, in the Create group, click Create Enrollment Profile to open the Create Enrollment Profile wizard;
3

CEPW_GeneralOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the enrollment profile (max. 256 characters);
  • Description: (Optional) Provide a description about the enrollment profile;
  • Select as management authority Cloud.
4

CEPW_TrustedRootCertificateOn the Select Trusted Root Certificate page, select the earlier created certificate profile and click Next

5 On the Wi-Fi profiles page, optionally select the earlier created Wi-Fi profile and click Next;
6 On the Summary page, click Next;
7 On the Completion page, click Close.

Enrollment

After creating the enrollment profile and its required components, it’s time to look at delivering the enrollment profile to the Windows 10 IoT Core device. A Windows 10 IoT Core device doesn’t have the full-blown Windows 10 capabilities to perform a MDM enrollment. However, that doesn’t mean that they’re not capable. That’s were the enrollment package comes into the picture.

Export enrollment package

The first step in bringing the enrollment profile to the Windows 10 IoT Core device, is exporting the enrollment profile as an enrollment package.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > All Corporate-owned Devices > Windows > Enrollment Profile;
2 Select the earlier created enrollment profile and on the Home tab, in the Enrollment Profile group, click Export to open the Export Enrollment Package dialog box;
3

On the Export Enrollment Package dialog box, provide the following information and click Export;

  • EEP_GeneralValidity Period (days): Select the number of days that this package is valid;
  • Package File: Provide a unique name for the enrollment package;
  • Do not select the checkbox with Encrypt Package.
4 On the Export Enrollment Package dialog box, click OK;

Deploy enrollment package

The second step in bringing the enrollment profile to the Windows 10 IoT Core device, is copying the exported enrollment package to the Windows 10 IoT Core device. An alternative could be adding the enrollment package as a provisioning package to a Windows 10 IoT Core image.

1 Open File Explorer and remotely connect to the Windows 10 IoT Core device;
2 Copy the earlier created enrollment package to C:\Windows\Provisioning\Package;
3 Restart the Windows 10 IoT Core device.

End result

Now let’s end this post by looking at some of the information that will flow through the MDM channel into Configuration Manager. After restarting the Windows 10 IoT Core device it can take a couple of minutes before the device appears in Configuration Manager. The Windows 10 IoT Core device will show as a mobile device with the operating system IoTUAP (as shown below).

ConsoleOverview

After the first inventory of the Windows 10 IoT Core device, the information of the deivce will populate in the Resource Explorer. In my case, I used a Raspberry Pi 3 (as shown below on the left) and I installed a custom app (as shown below on the right).

RBP_DeviceInformation RBP_InstalledApps

The nice thing is that, as Windows 10 MDM is used in combination with Configuration Manager, I can extend the inventory (see the PTCLOUD entry above) and I can configure settings. For this I can use the available configuration service providers (CSP).

More information

For more about managing Windows 10 IoT Core devices and enrollment profiles (documentation for on-premises MDM), please refer to:

Share

The Software Center experience is getting better and better

Throughout my blog posts I always think its important to mention the end-user experience. This blog post will be mainly focused on the end-user experience in Software Center. Software Center went, from an end-user experience, through a complete revamp. The best thing is, it’s only getting better and better. Except for a few items, related to the devices of the end-user, Software Center is becoming the one place for the end-user to be. In this post I want to go through the latest changes to Software Center and show the related end-user experience.

Changes

Now let’s start with the latest changes to Software Center. It all started with a new modern look for Software Center and it quickly evolved to a easy customizable app. Especially in combination with a Microsoft Intune subscription. With the latest update to the Company Portal app, with a little bit imagination, one might say that both apps are starting to look like each other.

Look-and-feel

A lot has changed for the look-and-feel of Software Center. Starting with the, at this moment, latest build of Configuration Manager, the branding of Software Center and the Software Center dialogs can be applied according to the following rules:

  • If the Application Catalog website point site server is not installed, then Software Center and Software Center dialogs will only display the organization name as specified in the Client Settings;
  • If the Application Catalog website point site server is installed, then Software Center and Software Center dialogs will display the organization and name and color as specified in the Application Catalog website point site server properties;
  • If a Microsoft Intune subscription is configuration and connected to the Configuration Manager environment, then Software Center and Software Center dialogs will display the organization name, color and company logo as specified in the Microsoft Intune subscription properties.

Another nice addition to  the look-and-feel of Software Center is the improvement help end-users understand what software is new. The new apps will show with a clear notification.

Nowadays the look-and-feel of Software Center also provides a better separation between Applications, Updates and Operating Systems. All with their own section. Updates can be installed all together and Operating Systems provide an additional company branded Software Center dialog. Another new section is about Device compliance. This provides the end-user with a clear insight about the device compliancy and the possible access to resources.

Functional

Besides only look-and-feel adjustments, Software Center also received many functional adjustments. It started by the great addition to add user-targeted apps to the Application section. The latest and greatest functional adjustment builds on that addition and is the addition of the application approval process to Software Center. The end-user can now use Software Center to request applications that require administrator approval.

Another nice addition to the functional adjustments, is more on the background. Starting with the, at this moment, latest build of Configuration Manager, the administrator can now also deny a previously approved application.

End-user experience

Now let’s end this post with a scenario that will cover as many as possible great additions to Software Center as possible. I thought that using an application request scenario would cover as many as possible of these great additions. The only thing not shown in this scenario is the company branded Software Center dialogs, but, believe me, it looks great!

During the following scenario the end-user and the administrator will touch the complete application approval process by using, request, cancel, approve and deny.

1 SC_AppsOverviewThe end-user opens Software Center and enjoys the beautiful icons and notifications about new apps.
2 SC_AppRequestThe end-user would like to install Notepad++ 7.3.5 and notices that the app requires approval. The end-user provides optional information and clicks Request.
3 SC_AppRequestSubmittedThe end-user immediately receives the message that the request was submitted successfully.
4 The administrator approves the app request.
5 Toast_AppApprovedThe end-user receives a toast message that a requested app is approved.
6 SC_AppRequestApprovedThe end-user opens Software Center and now has the option to install Notepad++ 7.3.5. The end-user installs the app, by clicking Install and is happy.
7 The end-user no longer needs the app and the app is uninstalled.
8

The administrator denies the existing app request.

Note: When an administrator denies an already approved app the app is not automatically uninstalled from the end-user device.

9

SC_AppRequestDeniedThe end-user opens Software Center again and notices that Notepad++ 7.3.5 can no longer be installed.

Note: At this moment it looks like information about approved apps is stored locally on the device.

10 SC_AppRequestAgainThe end-user gets a new assignment and requests Notepad++ 7.3.5 again by providing optional information and clicking Requests.
11 SC_AppRequestAgainSubmittedThe end-user immediately receives the message again that the request was submitted successfully.
12 SC_AppRequestAgainCancelledThe end-user changes its mind and cancels the request for Notepad++ 7.3.5 by clicking Cancel request.

More information

More information about what’s new in the different current branch versions, please refer to this article about What’s new in System Center Configuration Manager incremental versions.

Share

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