Managing browser settings via Windows 10 MDM

This week a short blog post about managing browser settings via Windows 10 MDM. Most of these settings are not very special and are very well documented in the Policy CSP. However, the configuration of the home page is a small exception. Not just because the documentation is slightly off, but also because of an important change with the anniversary update of Windows 10. As most of the settings are very well documented, this post will be focused on managing the home page. I’ll provide basic information, the configuration information and show the end-user experience.

Information

Before starting about the configuration of home pages, via Windows 10 MDM, it’s good to mention a few important notes:

  • Browser settings for Microsoft Edge can be managed;
  • Browser settings for Internet Explorer cannot be managed;
  • HTTP is the default for home pages;
  • Multiple home pages can be enforced;
  • Home pages are supported on all Windows 10 for desktop editions;
  • Starting the anniversary update of Windows 10, the end-user cannot change the enforced home page.

Configuration

With this information in mind, let’s have a look at the options for configuring the home page in Microsoft Edge. The home page can be configured with a single page and with multiple pages. Per configured home page, a new tab will be opened. When a single home page must be configured, the URL alone is enough. When multiple home pages must be configured, the URLs must be separated by using the XML-escaped characters < and >.  Below is the required OMA-URI and example values, including configuration examples for Microsoft Intune standalone and Microsoft Intune hybrid.

  • OMA-URI: ./Vendor/MSFT/Policy/Config/Browser/Homepages
  • Values (single home page): petervanderwoude.nl
  • Values (multiple home pages): <petervanderwoude.nl><https://petervanderwoude.nl>
Microsoft Intune hybrid Microsoft Intune standalone
MIH_W10_Homepages MIS_W10_Homepages

End-user experience

Now let’s end with the end-user experience, starting with the anniversary update of Windows 10. When the end-user starts Microsoft Edge, the configured home page will show. When the end-user navigates to the settings of Microsoft Edge, the Open Microsoft Edge with setting is grayed out and shows the configured home page. Below are examples of that setting with a single home page and with multiple home pages.

Single homepage Multiple homepages
CSP_Homepage CSP_Homepage_2

More information

Fore more information about configuring browser settings via Windows 10 MDM, please refer to the documentation about the Policy CSP.

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.

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:

Simplify enrollment for Windows 10 devices

This week a small blog post about simplifying the enrollment experience for Windows 10 devices. When enrolling a Windows 10 device, for mobile device management (MDM), the end-user has to perform a specific enrollment procedure. That enrollment procedure can be simplified by providing the end-user with a deep link. This blog post will provide the configuration for that deep link and the end-user experience.

Configuration

The configuration is fairly simple, but, to many people, unknown. Providing the configuration, as part of this blog post, is mainly for creating awareness about the available configuration option. Windows 10 devices can be connected to MDM by using a deep link. In that case end-users will be able to click, or open, a link, from anywhere in Windows 10, and be directed to the MDM enrollment experience. The link, used for connecting a Windows 10 device, must always use the following format: ms-device-enrollment:?mode={mode_name}. Within this format the following parameters and values are available.

Parameter Value Description
mode mdm Specifies which mode will be used in the enrollment app

Note: Starting with Windows 10, version 1607, deep linking is only supported for connecting devices to MDM. It will not support adding a work or school account, joining a device to Azure AD, and joining a device to Active Directory.

This enables the IT administrators to provide the end-user with a link to directly launch the built-in enrollment app. The link should contain the URI ms-device-enrollment:?mode=mdm. Together with a user-friendly display text it can look like this Click here to enroll the Windows 10 device.

Note: When reading this from a Windows 10, version 1607, device, simply click on the link to experience the end-user experience.

End-user experience

The end-user experience is also fairly simple. The end-user can receive an email that contains a similar URI as mentioned in the configuration. Once the end-user clicks on the URI, the end-user will be directed straight to the place to enroll the Windows 10 device in device management. That would be the first screen shown below. When the end-user provides the right information and clicks Next, the end-user will be redirected to the identity provider. After providing the right information the end-user will get the second screen shown below. That’s it. That’s the complete enrollment experience.

EUE_1 EUE_3

More information

For more information about MDM enrollment and Windows 10, please refer to this article about MDM enrollment of Windows-based devices.

Bulk enrollment for Windows 10 devices

My first post after my vacation will be about bulk enrollment for Windows 10 devices. Not bulk enrollment for on-premises enrollment, but bulk enrollment for cloud enrollment. In other words, Microsoft Intune is required. This blog post will contain a short introduction about bulk enrollment, the configuration of bulk enrollment and the end-user and administrator experience with bulk enrollment.

Introduction

Bulk enrollment is a more automated method for enrolling devices, as compared to normal end-user enrollment, which requires end-users to enter their credentials to enroll the device. Bulk enrollment uses an enrollment package to authenticate the device during enrollment. That enrollment package also contains a certificate profile and optionally a Wi-Fi profile.

At this moment bulk enrollment for Windows 10 devices is not supported, or does not work, in all scenarios. Keep the following in mind when thinking about bulk enrollment for Windows 10 devices:

  • Bulk enrollment does not support Azure AD join;
  • Bulk enrollment does not work with Microsoft Intune standalone;
  • Bulk enrollment does work with Microsoft Intune hybrid, where the enrollment package is generated via the Configuration Manager console.

Configuration

Now let’s have a look at the configuration. The configuration of an enrollment profile for bulk enrollment contains two main steps. The first step is to create the enrollment profile and the second step is to create the enrollment package.

Step 1: Create enrollment profile

The first step is to create an enrollment profile. This can be achieved by performing the steps below. Before starting with the steps below, make sure that a certificate profile for the root certificate is available, as it’s a requirement during the creation of the enrollment certificate.

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

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

  • Name: [Specify an unique name for the enrollment profile];
  • Description: [Specify details that help identifying the enrollment profile];
  • Select Cloud with Management Authority.
4

CEP_CertificateOn the Select Trusted Root Certificate page, select the required root certificate profile and click Next;

Note: The certificate profile is required during the creation of the enrollment profile.

5

CEP_WiFiOn the Select Wi-Fi profile page, optionally select a Wi-Fi profile and click Next;

Note: The Wi-Fi profile is optional during the creation of the enrollment profile. This can be useful when the device must be configured to connect to Internet first.

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

Step 2: Create enrollment package

The second step is to create the enrollment package. The enrollment package is the actual file that is used to bulk-enroll devices. This file is created via the Configuration Manager administration console and can eventually be opened with the Windows Image and Configuration Designer (ICD),. Within the Windows ICD the configuration can be verified. To create the enrollment package, perform the following steps.

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

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

  • Validity period (days): [Specify an unique name for the enrollment profile];
  • Package File: [Specify details that help identifying the enrollment profile];
  • Select Encrypt Package.
4

EEPEPIn the Export Enrollment Package Encryption Password dialog box, select Copy to copy the encryption password and click OK to close the dialog box;

Note: The encryption password will not be saved. Make sure to store the encryption password to keep the ability to use the enrollment package.

Experience

Now it’s time to look at the experience, from both the end-user perspective and the administrator perspective. Both experiences show interesting information, which makes it good to show as part of this blog post.

End-user experience

From the end-user experience it’s interesting to show the usage of the enrollment package. Just to show how easy it works. However, the enrollment package must be physically delivered to the device of the end-user. Once the end-user double-clicks the enrollment package, the end-user receives the standard User Account Control (UAC) message followed by the messages show below. The first message is only applicable once the enrollment package is encrypted and the second message is always applicable. The second message simply show what the enrollment package will adjust and asks if the enrollment package is from a trusted source.

ppgk_Password ppgk_Trust

Once the enrollment is successful the end-user can verify the two places shown below. The first place is Settings > Accounts > Access work or school, which will show that the device is connected to MDM. The second place is Settings > Accounts > Access work or school > Add or remove a provisioning package, which will show the added provisioning package.

EnrollmentProfile EnrollmentPackage

Administrator experience

From the administrator experience it’s interesting to look at, at least, the two places in the Configuration Manager administration console shown below. The first place is Assets and Compliance > Overview > All Corporate-owned Devices > Windows > Enrollment Profile, which will show the created enrollment profile including interesting details like Device Count. That device count relates to the number of devices that are enrolled via the enrollment profile. The second place is Assets and Compliance > Overview > Devices, which simply shows the devices in the environment. This is interesting as it will show that the Device Owner is set to Company for (bulk) enrolled devices.

CM_EnrollmentProfile CM_EnrollmentProfileDevice

More information

For more information about bulk enrollment for Windows 10, please refer to:

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:

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:

Windows 10 MDM and the MDM Bridge WMI Provider

This week another blog post about Windows 10 and OMA-DM, but this week will be short and different. Starting this week I won’t be referring to OMA-DM anymore, instead I’ll be referring to Windows 10 MDM. The main reason for that is change is to align with Microsoft. Also, it simply makes more sense. OMA-DM is the standards based protocol on which the Windows 10 MDM protocol is based. In other words, Windows 10 MDM is not exactly the same as the OMA-DM standards. Technically speaking it’s not wrong to refer to OMA-DM, but it simply makes more sense to refer to Windows 10 MDM.

That being said, this blog post will be different for another reason. This week I’ll try to bring Windows 10 MDM closer to the regular methods, by simply pointing out the existence of the MDM Bridge WMI Provider. This post is all about creating awareness.

MDM Bridge WMI Provider

One of the most heard comments about Windows 10 MDM is related to the lack of knowing what’s happening. Well, I can’t really take that away, maybe the newly introduced logging in 1607 can, but I can show how to see the changes of the Windows 10 MDM configurations.

The MDM Bridge WMI Provider is the bridge to the Windows 10 MDM capabilities. An easy method to see what’s happening is using a WMI Explorer, or something simple as Windows Management Instrumentation Tester (wbemtest). Simply connecting to the root\cimv2\mdm\dmmap namespace is similar to connecting to the MDM Bridge WMI Provider. The classes in this namespace all translate to a configuration service provider (CSP) of Windows 10 MDM. This makes it fairly easy to see what’s happening to the configurations done via Windows 10 MDM.

Below is an example of the MDM_Policy_Result01_Experience02 class, in which the AllowManualMDMUnenrollment instance property was changed during the enrollment of the device. That class and instance property relates to the configuration OMA-URI of ./Vendor/MSFT/Policy/Config/Experience/AllowManualMDMUnenrollment.

Before After
BeforeEnroll AfterEnroll

Knowing this immediately opens up another world. This enables everyone to get information through the MDM Bridge WMI Provider by simply using PowerShell. Looking at the previous example, I can simply use the following PowerShell command, as there is only one instance, to get the information as shown in the table below.

Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" ` -ClassName "MDM_Policy_Result01_Experience02"

Before After
BeforeEnroll_PS AfterEnroll_PS

This also means that the MDM Bridge WMI Provider can be used to trigger configuration changes through Windows 10 MDM. For now, I’ll leave that up to everyone’s imagination.

Important notes

There are a few important notes about the MDM Bridge WMI Provider that should be known and I’ll try to summarize them briefly:

  • Administrative permissions are required to connect with the MDM Bridge WMI Provider. Without those permissions there will be an access denied error when connecting to the MDM Bridge WMI Provider;
  • The local system context is required to view and adjust device settings. This can be achieved by using something like PsExec.exe;
  • Be aware that there is a difference between user settings and device settings. Specific user settings won’t show when connected in the system context and specific device settings won’t show when connected in the user context;
  • Be aware that my example mixed Config and Result properties and nodes. That’s related to the design of the Policy CSP. The Config section handles the configurations requests and the Result section provides a read-only path to the actual configuration.

More information

Fore more information about Windows 10 MDM, the Windows 10 CSP and the MDM Bridge WMI Provider, please refer to:

Managing Windows Update for Business on Windows 10 via OMA-DM

WUfB_DeferThis week another blog post about Windows 10 and OMA-DM. This week I’m going to have a look at managing Windows Update for Business on Windows 10. However, this time I’ll group the currently available policy settings per subject, to easily provide some more background information. Also, by now I assume that I don’t have to go through all the steps to create a Configuration Item or a Configuration Policy anymore.

To manage Windows Update for Business, IT organizations can use the Policy configuration service provider (CSP) and to report about Windows Update for Business IT organizations can mainly use the Update CSP. During this blog post I’ll provide more information about Windows Update for Business, the Policy CSP, the Update CSP and the available policy configurations. I’ll end this post with configuration examples for Microsoft Intune standalone and Microsoft Intune hybrid.

Introduction

Let’s start with a short introduction about Windows Update for Business. What is it and how is different from Windows Update and Windows Server Update Services (WSUS). Windows Update for Business enables IT organizations to keep the Windows 10 devices always up to date with the latest security updates and Windows features by directly connecting these devices to Windows Update. By only using policies, Windows Update for Business is an easily established and implemented system which enables IT organizations to exercise control on how their Windows 10 devices are updated.

IT organizations can specify which devices go first in an update wave, and which devices will come later, and can make the delivery of updates to branch offices and remote sites, with limited bandwidth, very efficient.
Windows Update for Business can even be used in combination with existing management tools, such as ConfigMgr. It basically allows IT organizations to manage how and when Windows 10 devices receive updates and upgrades and provides controls to help organizations validate update quality as well as time their update deployments.

Configuration

Now let’s have a look at the configuration options for Windows Update for Business via OMA-DM. I’ll have a look at how to defer updates and upgrades, how to pause updates and upgrades and how to optimize the deployment. However, it should be noted that at this moment not everything can be configured via OMA-DM, yet.

Policy CSP & Update CSP

Before really looking at the configuration scenarios, it’s good to have a quick look at the Policy CSP and the Update CSP. The Policy CSP enables IT organizations to configure company policies on Windows 10 devices. Those policies also include the configuration options for Windows Update for Business, The Update CSP enables IT organizations to get information about the update status of Windows 10 devices. Below is a quick overview of both CSPs.

Policy CSP Update CSP
PolicyCSP UpdateCSP

Defer upgrades

To use Windows Update for Business, Windows 10 devices must be configured to Current Branch for Business (CBB). This can be configured by using one of the following policies.

Policy Description
Update/BranchReadinessLevel

  • 16 (default) – Systems takes upgrades from Current Branch (CB). 
  • 32 – System takes upgrades from Current Branch for Business (CBB).
New for Windows 10, version 1607. Allows the IT organization to set a device to the Current Branch or the Current Branch for Business servicing branch.
Update/RequireDeferUpgrade

  • 0 (default) – User gets upgrades from Current Branch (CB).
  • 1 – User gets upgrades from Current Branch for Business (CBB).
Allows the IT organization to set a device to the Current Branch or the Current Branch for Business servicing branch.

Defer upgrade and update periods

Windows Update for Business provides IT organizations the ability  to control when updates and upgrades are deployed to their Windows 10 devices. This can be achieved by specifying deferral windows from when the updates and upgrades are initially made available on Windows Update. There are restrictions as to how long IT organizations can delay updates and upgrades. The following table details the deferral periods and supported values.

Policy Description
Update/DeferFeatureUpdatePeriodInDays

  • Supported values are 0-180.
New for Windows 10, version 1607. Allows the IT organization to defer Feature Updates for up to 180 days.
Update/DeferQualityUpdatePeriodInDays

  • Supported values are 0-30.
New for Windows 10, version 1607. Allows the IT organization to defer Quality Updates for up to 30 days.
Update/DeferUpdatePeriod

  • Supported values are 0-4.
Allows the IT organization to delay updates for up to 4 weeks.
Update/DeferUpgradePeriod

  • Supported values are 0-8.
Allows the IT organization to delay upgrades for up to 8 months.

Pause upgrades and updates

Windows Update for Business also provides IT organizations the ability to pause updates and upgrades on a per device basis. This pause functionality ensures that no updates or upgrades will be made available for the specified device. The device will remain in this state until the configured period has passed or when the device is specifically “unpaused”. At that point updates are auto-resumed. The following table details the pause options and the supported values.

Policy Description
Update/PauseDeferrals

  • 0 (default) – Deferrals are not paused.
  • 1 – Deferrals are paused.
Allows the IT organization to pause updates and upgrades for up to 5 weeks. Paused deferrals will automatically be reset after 5 weeks, or when the value is set back to 0.
Update/PauseFeatureUpdates

  • 0 (default) – Feature Updates are not paused.
  • 1 – Feature Updates are paused for 60 days.
New in Windows 10, version 1607. Allows the IT organization to pause Feature Updates for up to 60 days. Paused Feature Updates will automatically be reset after 60 days, or when the value is set back to 0.
Update/PauseQualityUpdates

  • 0 (default) – Quality Updates are not paused.
  • 1 – Quality Updates are paused for 35 days.
New in Windows 10, version 1607. Allows IT Admins to pause Quality Updates. Paused Quality Updates will automatically be reset after 35 days, or when the value is set back to 0.

Optimize delivery

By grouping machines into similar deferral periods, IT organizations can cluster devices into deployment or validation groups which can be used as a quality control measure as updates are deployed in Windows 10. With deferral windows and the ability to pause, IT organizations can effectively control and measure update deployments by rolling out to a small pool of devices first to verify quality, prior to a broader roll-out in the organization.

At this moment Windows 10 doesn’t provide configuration options via OMA-DM to specifically configure a device in a specific group. However, it’s still possible to configure a specific set of devices with a similar deferral period and to take advantage of the default configuration in Windows 10 to get updates from PCs on my local network,

Update approval

Windows Update for Business also provides IT organizations with the ability to restrict the updates that are installed on a device to only those on the update approval list. That list can be configured via the Update CSP and enables the IT organization to accept the End User License Agreement (EULA) on behalf of the end-user. This can be configured by using the following policy.

Policy Description
Update/RequireUpdateApproval

  • 0 – The device installs all applicable updates.
  • 1 – The device only installs updates that are both applicable and on the Approved Updates list.
Allows the IT organization to restrict the updates that are installed on a device to only those on an update approval list. It enables the IT organization to accept the EULA associated with the approved update on behalf of the end-user.

Example configuration

Now let’s end this post slightly different as usual. This time not with the end-user experience, but with example configurations, as I didn’t provide any throughout this post. Also, the biggest end-user experience is already shown in the picture at the beginning of this post, which is showing a grayed-out Defer upgrades setting. Below is an example of the RequireDeferUpgrade setting in Microsoft Intune hybrid (Configuration Item) and Microsoft Intune standalone (Configuration Policy).

Microsoft Intune hybrid Microsoft Intune standalone
WUfB_MIH WUfB_MISA

More information

Fore more information about Windows Update for Business, the Update CSP and the Policy CSP, please refer to:

Reporting Windows Defender health on Windows 10 via OMA-DM

About a year ago I did a blog post about managing Windows Defender on Windows 10 via OMA-DM, by using the available policies in the Policy CSP. This week I’m going to have another look at Windows Defender, on Windows 10, but this time from a reporting perspective. This time I want to report about the health of Windows Defender on the Windows 10 devices that are managed via OMA-DM. To get that type of information I can use the Defender configuration service provider (CSP). The Defender CSP contains the information about the health of Windows Defender.

During this blog post I’ll go through the Defender CSP, the required configuration to get the Windows Defender health information and the administrator experience.

Defender CSP

DefenderCSPBefore starting with the required configuration to get the information about the health of Windows Defender, it’s good to have a quick look at the Defender CSP. That CSP is used to configure various Windows Defender actions across the enterprise. More specifically, I will go through the Health node. That node contains the information about the Windows Defender health status that I’m looking for.

  • ComputerState: This node provides the current state of the device;
  • DefenderEnabled: This node shows if the Windows Defender service is running;
  • RtpEnabled: This node shows if the real-time protection is running;
  • NisEnabled: This node shows if the network protection is running;
  • QuickScanOverdue: This node shows if a Windows Defender quick scan is overdue;
  • FullScanOverdue: This node shows if a Windows Defender full scan is overdue;
  • SignatureOutOfDate: This node shows if the Windows Defender signature is outdated;
  • RebootRequired: This node shows if a reboot is required;
  • FullScanRequired: This node shows if a Windows Defender full scan is required;
  • EngineVersion: This node shows the version number of the Windows Defender engine;
  • SignatureVersion: This node shows the version of the Windows Defender signatures;
  • DefenderVersion: This node shows the version of Windows Defender;
  • QuickScanTime: This node shows the time of the last Windows Defender quick scan;
  • FullScanTime: This node shows the time of the last Windows Defender full scan;
  • QuickScanSigVersion: This node shows the signature version used during the last quick scan;
  • FullScanSigVersion: This node shows the signature version used during the last full scan.

Configuration

Now it’s time to start with the required configuration to enable the ability to report about the Windows Defender health of Windows 10 devices managed via OMA-DM. However, it’s good to note that this is currently only possible in Microsoft Intune hybrid, as we need to extend the inventory on Windows 10 devices.

The Health node of the Defender CSP contains exactly the information that I’m looking for and that I would like to add to the inventory of my Windows 10 devices. Luckily, in a Microsoft Intune hybrid environment I can extend the hardware inventory to include specific OMA-URI settings. OMA-URI settings that can be added to the hardware inventory are shown, in the picture above, in a rectangular shape (and are documented with a supported Get operation).

All of the available settings, in the Health node of the Defender CSP, support the Get operation. If I want to add a custom class to the hardware inventory, with all the the available settings of the Health node, I can use the following in a MOF file.

[ SMS_Report (TRUE),
   SMS_Group_Name (“PTCLOUD Windows10 DefenderHealth”),
   SMS_Class_ID (“MICROSOFT|Windows10_DefenderHealth|1.0”),
   Namespace (“Reserved”),
   SMS_DEVICE_URI (“”) ]


class Windows10_DefenderHealth : SMS_Class_Template
{
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/ComputerState”)]
      String ComputerState;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/DefenderEnabled”)]
      Boolean DefenderEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/RtpEnabled”)]
      Boolean RtpEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/NisEnabled”)]
      Boolean NisEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanOverdue”)]
      Boolean QuickScanOverdue;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanOverdue”)]
      Boolean FullScanOverdue;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/SignatureOutOfDate”)]
      Boolean SignatureOutOfDate;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/RebootRequired”)]
      Boolean RebootRequired;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanRequired”)]
      Boolean FullScanRequired;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/EngineVersion”)]
      String EngineVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/SignatureVersion”)]
      String SignatureVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/DefenderVersion”)]
      String DefenderVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanTime”)]
      String QuickScanTime;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanTime”)]
      String FullScanTime;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanSigVersion”)]
      String QuickScanSigVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanSigVersion”)]
      String FullScanSigVersion;
};

This MOF file can be used to extend the hardware inventory by simply performing the following steps in the Configuration Manager console.

1 In the Configuration Manager console, and navigate to Administration > Overview > Client Settings;
2 Open the Default Client Settings, navigate to Hardware Inventory and click Set Classes;
3

WindowsDefenderInvIn the Hardware Inventory Classes, click Import and Open the new MOF file.

This will add the new class for the inventory and will show it between the existing classes.

Also note that the dataldr.log will show the creation of the new class.

Result

Now let’s end this post with the most important thing, the visualization. The extension to the hardware inventory will make sure that the information about the Windows Defender health is reported by Windows 10 devices that are managed via OMA-DM. It will add the information, like every extension to the hardware inventory, to a custom table, with it’s own custom view, in the database. That will make it relatively easy to create a custom report, as shown below, to display the information in a readable form to the administrative users.

Administrator experience
WDExampleReport

Also, keep in mind that the information will also be available in the Resource Explorer, of the Configuration Manager console, for the Windows 10 devices that are managed via OMA-DM.

More information

Fore more information about the Defender CSP and the Policy CSP, please refer to: