Categorizing devices

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

Information

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

  1. Create collections, or device groups, for each required category;

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

Configuration

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

Microsoft Intune hybrid

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

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

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

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

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

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

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

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

Microsoft Intune standalone

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

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

End-user experience

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

Company Portal app Company Portal web app
IMG_0086 IMG_0087

More information

Fore more information about categorizing devices, please refer to:

Share

Conditional access for published ConfigMgr reports

This week another post about the world of conditional access in Azure AD. Last week I started with looking at conditional access for Yammer. This week I’ll add-on to that idea by publishing a custom application, in this case my ConfigMgr reports, and apply conditional access to that configuration. To make it even better, it even allows a single sign-on configuration. In other words, I can use pre-authentication on Azure AD and use that token for the single sign-on experience of the end-user in the published application. Really nice!

Prerequisites

Before starting with the configuration, it’s important to know that his post does require two important prerequisites to be in place, which are not part of this post.

  1. Azure AD Application Proxy: This component is used for publishing an on-premises application. The steps to enable the Azure AD Application proxy are documented here;
  2. Windows Authentication: This is required to be able to use single sign-on in combination reporting services. The steps to configure Windows authentication on the report server are documented here.

Configuration

The configuration of conditional access, with single sign-on, for ConfigMgr reporting services contains four steps. The first step is to add the application, the second step is to configure the application, the third step is to enable device access rules and the fourth step is to configure the compliance policy.

Step 1: Add an application

Let’s start with the first step, which is publishing an application that will be accessible outside my network. This requires that the Azure AD Application Proxy is enabled and installed. The publishing of the application can be done via the Azure portal and the Azure Management portal. At this point I’m still using the Azure Management portal, as I can’t do every required configuration via the Azure portal, yet.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS and click ADD;

To publish the ConfigMgr Web Portal, select Publish an application that will be accessible from outside your network and provide the following information.

  • AzureADApp_CRNAME: [Specify a unique name for the published application]
  • INTERNAL URL: [Provide the internal ConfigMgr Web Portal URL]
  • PREAUTHENTICATION METHOD: Azure Active Directory

Step 2: Configure the application

The second step is to configure the application with a single sign-on experience for the end-user. As I’m using pre-authentication on Azure AD, to enable the option for conditional access, I don’t want to require the end-user to provide the credentials again. That’s why I want to configure single sign-on for the published application.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS > [New application] > CONFIGURE;

To enable single sign-on for the ConfigMgr Web Portal, provide at least the following information.

  • AzureADApp_CRAuthINTERNAL AUTHENTICATION METHOD: Integrated Windows Authentication
  • INTERNAL APPLICATION SPN: [Provide the internal SPN]
  • DELEGATED LOGIN IDENTITY: User principal name

Step 3: Enable device access rules

The third step is to configure the application with a conditional access experience for the end-user. As the application is now configured with pre-authentication on Azure AD, it’s a small step to enable a device access rule, which is enabling conditional access. That will make sure that all access attempts, from a device that doesn’t meet the configuration, will be denied.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS > [New application] > CONFIGURE;

To enable conditional access for the ConfigMgr Web Portal, switch ENABLE ACCESS RULES to ON and select with APPLY TO the users which the rules should apply.

AzureADApp_CRCATo make sure that all the devices must be compliant to access the ConfigMgr Web Portal, make sure to configure the applicable platforms with DEVICE RULES and click SAVE.

Note: With custom applications this configuration will be enforced for browsers and native applications.

Step 4: Configure compliance policy

The fourth and last step, an optional step, is to configure a compliance policy in Microsoft Intune standalone and Microsoft Intune hybrid. This configuration part hasn’t changed and is still the right addition to require additional settings on a device. A compliance policy defines the rules and settings that a device must comply with in order to be considered compliant. The configuration of the compliance policy differs between Microsoft Intune standalone and Microsoft Intune hybrid. After creating the compliance policy, it can be deployed to users like any other policy. It’s not required to configure and deploy a compliance policy. When no compliance policy is configured and deployed, the device will automatically be considered compliant.

Environment Configuration
Microsoft Intune standalone

CustomApp_MISIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Compliance Policies and click Add….

To configure a compliance policy,  choose, based on the requirements, between the applicable available Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version settings.

Microsoft Intune hybrid

In the Configuration Manager administration console navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies and click Create Compliance Policy.

CustomApp_MIHTo configure a compliance policy, choose, based on the requirements, during the Create Compliance Policy Wizard the Supported Platforms and choose between the applicable Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version Rules.

Note: Compliance policies can be used independently of conditional access. When used independently, the targeted devices are evaluated and reported with their compliance status.

End-user experience

After the configurations of adding the application, enabling the device access rules and configuring the compliance policy, it’s time to look at the end-user experience. This time I’ll go through all the common scenario’s that the end-user can end up with. Starting with the initial configuration of the application in Azure AD. Once the application is created in Azure AD and the end-user tries to access them without being licensed, or without being assigned to the application, the end-user can expect the messages shown below.

Not licensed Not assigned
IMG_0080 IMG_0083

Once the end-user is licensed and is assigned to the application, the end-user reaches the conditional access checks of Azure AD. When the device of the end-user is not enrolled, or not compliant, the end-user can expect the messages shown below.

Not enrolled Not compliant
IMG_0079 IMG_0082

Once the end-user has the device enrolled and compliant, the end-user reaches the published application. In this case the ConfigMgr reports. When the end-user has no permissions within the ConfigMgr reports, the end-user will still be able to sign-in. However, the end-user will receive a message, as shown below, about missing the necessary permissions. When the end-user has the required permissions, the end-user will be able to browse through the reports as shown below.

No permissions All requirements met
IMG_0081 IMG_0084

Note: During my tests I’ve upgraded from SQL Server 2014 to SQL Server 2016. Even though SQL Server 2016 looks much better, my mobile devices like to display the reports from SQL Server 2014 much more. In other words, I could simply display my reports when using SQL Server 2014 and my reports wouldn’t display information when using SQL Server 2016. The permission setup works in both configurations.

More information

For more information about conditional access, applications in Azure, compliance policies in Microsoft Intune and Windows authentication for reporting services, please refer to:

Share

Conditional access for Yammer

This week I’ll open a new world of conditional access. The world of conditional access in Azure AD. I’ll open that world of conditional access by looking at conditional access for Yammer. Conditional access for Yammer cannot be configured through the Microsoft Intune administration console. However, that doesn’t mean that conditional access for Yammer doesn’t exist. The configuration of conditional access for Yammer is available through the Azure Management portal. In this post I’ll go into more detail about conditional access via Azure AD, the required configurations and the end-users experience.

Introduction

About a month ago Microsoft released conditional access policies as a preview feature in Azure AD for iOS, Android and Windows (Windows 7, Windows 8.1 and Windows 10, build 1607). These policies can help IT organizations with controlling data, by restricting access to managed devices only. Policies can be applied on a per-application basis to require that devices are managed by the IT organization and that devices are configured correctly.

In case that conditional access functionality sounds familiar, that’s possible. At this moment this conditional access functionality creates an overlap with the conditional access policies that can be configured through Microsoft Intune. Conditional access configurations done via Microsoft Intune will reflect to the configurations in Azure AD and vice versa. However, Azure AD already provides more configuration options and supports a lot more applications. Every application, that authenticates with Azure AD, is supported!

Configuration

The configuration of conditional access for Yammer contains two steps. The first step is to enable device access rules for Yammer and the second step is to configure the compliance policy.

Step 1: Enable devices access rules for Yammer

Let’s start with the first step, which is the configuration of the device access rule in the Azure Management portal. This configuration will make sure that all access attempts from a device that doesn’t meet the configuration will be denied. The configuration has to be done through the Azure Management portal and takes effect immediately after saving the configuration,

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

Yammer_DBARIn the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS > Office 365 Yammer > CONFIGURE;

To enable conditional access for Yammer, switch ENABLE ACCESS RULES to ON and select with APPLY TO the users which the rules should apply.

To make sure that all the devices must be compliant to access Yammer, make sure to configure the applicable platforms with DEVICE RULES and click SAVE.

Note: With Yammer this configuration will be enforced for browsers and native applications.

Step 2: Configure compliance policy

The second step is the configuration of the compliance policy in Microsoft Intune standalone and Microsoft Intune hybrid. This configuration part hasn’t changed and is still the right addition to require additional settings on a device. A compliance policy defines the rules and settings that a device must comply with in order to be considered compliant. The configuration of the compliance policy differs between Microsoft Intune standalone and Microsoft Intune hybrid. After creating the compliance policy, it can be deployed to users like any other policy. It’s not required to configure and deploy a compliance policy. When no compliance policy is configured and deployed, the device will automatically be considered compliant.

Environment Configuration
Microsoft Intune standalone

Yammer_MISIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Compliance Policies and click Add….

To configure a compliance policy,  choose, based on the requirements, between the applicable available Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version settings.

Microsoft Intune hybrid

Yammer_MIHIn the Configuration Manager administration console navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies and click Create Compliance Policy.

To configure a compliance policy, choose, based on the requirements, during the Create Compliance Policy Wizard the Supported Platforms and choose between the applicable Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version Rules.

Note: Compliance policies can be used independently of conditional access. When used independently, the targeted devices are evaluated and reported with their compliance status.

End-user experience

After the configuration of the device access rule and the compliancy policy is completed, it’s time to look at the end-user experience. An enrolled and compliant device will give the end-user the normal experience. A not enrolled device, or a not compliant compliant device, will give the end-user a message based on the status of the device, when the end-user is trying to access Yammer. Those messages are shown below, using an iOS device using the default browser as an example.

Not enrolled Not compliant
IMG_0073 IMG_0074

More information

For more information about conditional access, related to applications in Azure AD and compliance policies, please refer to the following articles:

Share

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.

Share

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:

Share

Operations Management Suite connected with ConfigMgr

This blog post is about a pre-release feature, which means that it’s included in the product for early testing in a production environment, but should not be considered production ready.

This week another blog post about a pre-release feature. This time it’s the Pre-release – Microsoft Operation Management Suite (OMS) Connector feature that is also introduced in ConfigMgr 1606. It’s a good follow-up on my post of last week, as I can reuse Azure components that I created for the connection with the Windows Store for Business. Before starting with the configurations of this blog post, make sure to create an Operations Management Suite account here.

Introduction

The Operations Management Suite is a cloud-based IT management solution that helps IT organizations to manage and protect the on-premises and cloud infrastructure. IT organizations can use the Microsoft Operations Management Suite (OMS) Connector, at this moment, to import data of collections from ConfigMgr to the Operations Management Suite. This makes data from the ConfigMgr environment visible in the Operations Management Suite.

Note: At this moment only collection memberships can be imported to the Operation Management Suite. I wouldn’t be surprised to see more options at a later stage.

Configuration

Now lets have a look at the actual configurations that are required to get the Microsoft Operations Management Suite (OMS) Connector up-and-running. To connect the Operations Management Suite with ConfigMgr the following four steps are required.

Step 1: Enable pre-release feature in ConfigMgr

The first step, similar to last week, is to enable the Pre-release – Microsoft Operation Management Suite (OMS) Connector pre-release feature, as it must be turned on in ConfigMgr. This can be achieved by performing the following steps.

1 First open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Sites;
2 Select the top-level site in the hierarchy and select Hierarchy Settings, in the Home tab, to open the Hierarchy Settings Properties;
3 In the Hierarchy Settings Properties, navigate to the General tab, select Consent to use Pre-Release features and click OK;
4 Now navigate to Administration > Overview > Cloud Services > Updates and Servicing > Features;
5 Right-click Pre-release – Microsoft Operation Management Suite (OMS) Connector and select Turn on.

Step 2: Register ConfigMgr as web application in Azure AD

The second step, similar to last week, is to create an application in Azure AD. I actually used the same application, which is the reason why these steps are identical. That application doesn’t have to contain resolvable URLs, as it only will be used to create a connection between the Operations Management Suite and ConfigMgr. This can be achieved by performing the following steps.

1 In the Azure Management portal, select the related Azure AD and click APPLICATIONS > ADD to open the What do you want to do? dialog box;
2 In the What do you want to do? dialog box, click Add an application my organization is developing to open the ADD APPLICATION wizard;
3

AddApp_1On the Tell us about your application page, specify the following information and click on the Arrow sign;

  • Name: [Specify a unique name for the application]
  • Type: WEB APPLICATION AND/OR WEB API
4

AddApp_2On the Add properties page, specify the following information and click the Check sign to complete the wizard and to add the app.

  • Sign-on URL: [Specify any URL]
  • App ID URI: [Specify any URL]

Note: In both cases the URL doesn’t have to be a resolvable address.

5 In the created app click CONFIGURE;
6

AppKeysIn the category Keys select a duration and click SAVE;

Note: The key will be created after clicking SAVE and can only be retrieved while on this page

Step 3: Provide ConfigMgr with permissions on Operations Management Suite

The third steps is to provide the Azure AD app with permissions to access the Operations Management Suite. This will allow us to use the Azure AD app to connect ConfigMgr to the Operations Management Suite. This can be achieved by performing the following steps.

1 First open the Azure portal and select Browse > Log Analytics (OMS) to open the Log Analytics (OMS) blade;
2 On the Log Analytics (OMS) blade, click Add to open the OMS Workspace blade;
3

OMSWorkspaceOn the OMS Workspace blade, provide the following information and click OK;

  • OMS Workspace: [Specify a name]
  • Subscription: [Select the subscription]
  • Resource group: Create new [Specify a name]
  • Location: [Select a location]
  • Pricing tier: [Select a pricing tier]

Note: I’m specifically creating a new resource group to create the option to only provide ConfigMgr with permissions to that OMS Workspace. Simply because that’s the only thing within the resource group.

4 Now select Browse > Resource groups to open the Resource groups blade;
5 On the Resource groups blade, select the just created resource group to open the Settings blade;
6 On the Settings blade, select Users to open the Users blade;
7 On the Users blade, select Add to open the Add access blade;
8

OMSRGAddAccessOn the Add access blade, select Select a role to configure the exact permissions, select Add users to select the Azure AD app and click OK;

Note: Without specifying these permissions there will be an error message during the configuration wizard in ConfigMgr.

Step 4: Create connection to Operations Management Suite in ConfigMgr

The fourth steps is to create the connection to the Operations Management Suite in ConfigMgr. This connection will be created by using the information of the Azure AD app. This can be achieved by performing the following steps.

1 In the Configuration Manager administration console, navigate to Administration > Overview > Cloud Service > OMS Connector;
2 On the Home tab, click Create connection to Operations Management Suite to open the Connection to Operations Management Suite Wizard;
3 On the General page, click Next;
4

OMSW_AzureADOn the Azure Active Directory page, specify the following information and click Next;

  • Tenant: [Specify the Azure AD tenant]
  • Client ID: [Specify the Client ID of the just created Azure AD app]
  • Client secret key: [Specify the Client secret key of the just created Azure AD app]
5

OMSW_OMSConnectionOn the OMS Connection page, specify the following information and click Next.

  • Azure subscriptions: [Select the subscription]
  • Azure resource group: [Select the just create resource group]
  • Operations Management Suite Workspace: [Select the just created workspace]
  • Select device collections that OMS can get data for: [Specify the collections that can be used]

Note: This information will be pre-selected once the Azure AD app has enough permissions on the resource group. Only the collections must still be configured.

6 On the Summary page, click Next.
7 On the Completion page, click Close.
Note: The documentation states that after a while the Microsoft Monitoring Agent will be installed. In my testing this was not the case and I installed the agent manually.

Administrator experience

After the configuration is completed the administrator can view the configuration details in the administration console via Administration > Overview > Cloud Services > OMS Connector. The administrator can use the Properties to add additional collections to the configuration.

OMSConOverview

To actually start importing information about the collection memberships, the administrator still has to do one little configuration within the Operation Management Suite console. This can be achieved by navigating to Settings > COMPUTER GROUPS > SCCM and selecting Import Configuration Manager collection memberships.

OMSDashboard

This is also a location where the administrator can view the information about the collection memberships that are imported in the Operations Management Suite. This can be achieved by simply clicking on <xx> computers with the collection memberships detected or <xx> Configuration Manager site server collections imported. That provides the administrator with an overview as show below and enables the administrator to look at some details. The same overview can be achieved by simply using Log search.

OMSOverview

More information

For more information about syncing data from ConfigMgr to the Operations Management Suite, please refer to this article about Sync data from Configuration Manager to the Microsoft Operations Management Suite.

Share

Windows Store for Business synchronized with ConfigMgr

This blog post is about a pre-release feature, which means that it’s included in the product for early testing in a production environment, but should not be considered production ready.

This week a blog post about the Windows Store for Business Integration feature that is introduced in ConfigMgr 1606. This feature is introduced as a pre-release feature. Before starting with the configurations of this blog post., make sure to sign up for Windows Store for Business here.

Introduction

The Windows Store for Business is where organizations can find and purchase Windows apps. By connecting the Windows Store for Business to ConfigMgr, organizations can synchronize the list of apps with ConfigMgr, view these in the ConfigMgr administration console, and deploy them like any other app. The Windows Store for Business supports two types of licensed app:

  • Online – This license type requires users and devices to connect to the Windows Store for Business to get an app and its license. It requires Windows 10 devices to be Azure AD domain-joined;
  • Offline – This license type enables organizations to cache apps and licenses to deploy them directly within their on-premises network, without connecting to the Windows Store for Business or having a connection to the Internet.

It’s also good to know that ConfigMgr supports managing Windows Store for Business apps on Windows 10 devices running the ConfigMgr client and Windows 10 devices that are enrolled via MDM.

Note: At this moment there is no support for paid apps from the Windows Store for Business.

Configuration

Now lets have a look at the actual configurations. The configuration requires the following four steps to synchronize the Windows Store for Business with ConfigMgr.

Step 1: Enable pre-release feature in ConfigMgr

The first step is to enable the Windows Store for Business integration pre-release feature, as it must be turned on in ConfigMgr. This can be achieved by performing the following steps.

1 First open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Sites;
2 Select the top-level site in the hierarchy and select Hierarchy Settings, in the Home tab, to open the Hierarchy Settings Properties;
3 In the Hierarchy Settings Properties, navigate to the General tab, select Consent to use Pre-Release features and click OK;
4 Now navigate to Administration > Overview > Cloud Services > Updates and Servicing > Features;
5 Right-click Windows Store for Business integration and select Turn on.

Step 2: Register ConfigMgr as web application in Azure AD

The second step is to create an application in Azure AD. That application doesn’t have to contain resolvable URLs, as it only will be used to create a link between the Windows Store for Business and ConfigMgr. This can be achieved by performing the following steps.

1 In the Azure Management portal, select the related Azure AD and click APPLICATIONS > ADD to open the What do you want to do? dialog box;
2 In the What do you want to do? dialog box, click Add an application my organization is developing to open the ADD APPLICATION wizard;
3

AddApp_1On the Tell us about your application page, specify the following information and click on the Arrow sign;

  • Name: [Specify a unique name for the application]
  • Type: WEB APPLICATION AND/OR WEB API
4

AddApp_2On the Add properties page, specify the following information and click the Check sign to complete the wizard and to add the app.

  • Sign-on URL: [Specify any URL]
  • App ID URI: [Specify any URL]

Note: In both cases the URL doesn’t have to be a resolvable address.

5 In the created app click CONFIGURE;
6

AppKeysIn the category Keys select a duration and click SAVE;

Note: The key will be created after clicking SAVE and can only be retrieved while on this page

Step 3: Configure ConfigMgr as management tool in the Windows Store for Business

The third steps is to configure the Azure AD app as a management tool in the Windows Store for Business. This will create a link between the Azure AD app and the Windows Store for Business, which will allow us to connect ConfigMgr to the Windows Store for Business. This can be achieved by performing the following steps.

1 In the Windows Store for Business portal, select Settings > Management tools;
2 On the Management tools page, click Add a management tool to open the Add a management tool dialog box;
3 AddManagementToolOn the Add a management tool dialog box, search for the just created and configured app and click Add to return to the Management tools page;
4

ActivateManagementBack on the Management tools page, click Activate next to the just added management tool.

Note: Only one management tool can be active for the Windows Store for Business.

Step 4: Add Windows Store for Business account to ConfigMgr

The fourth steps is to add the Windows Store for Business account to ConfigMgr. This will create a link between the Windows Store for Business and ConfigMgr by using the information of the Azure AD app. This can be achieved by performing the following steps.

1 In the Configuration Manager administration console, navigate to Administration > Overview > Cloud Service > Windows Store for Business;
2 On the Home tab click Add Windows Store for Business Account to open the Windows Store for Business Configuration Wizard;
3 On the General page, click Next;
4

WSfB_ConfigurationOn the Configuration page, specify the following information and click Next;

  • Tenant: [Specify the Windows Store for Business tenant]
  • Client ID: [Specify the Client ID of the just created Azure AD app]
  • Client secret key: [Specify the Client secret key of the just created Azure AD app]
  • Location to store application content downloaded from the Windows Store for Business: [Specify the location to store the content of the offline licensed Windows Store for Business apps]
5 WSfB_LanguageOn the Language page, select the languages that should have Application Catalog entries for the synchronized apps and click Next.
6 On the Summary page, click Next.
7 On the Completion page, click Close.

Administrator experience

After the configuration is completed the administrator can view the sync status and the configuration details in the administration console via Administration > Overview > Cloud Services > Windows Store for Business.

WSfBOverview

Once the synchronization is completed the administrator can view the synchronized apps in the administration console via Software Library > Overview > Application Management > License Information for Store Apps.

WSfBLicensedApps

This is also the location where the administrator can create applications based on the information synchronized from the Windows Store for Business. This can be achieved by simply selecting an application from the list and clicking Create Application.

More information

For more information about managing apps from the Windows Store for Business, please refer to this article about Manage apps from the Windows Store for Business with System Center Configuration Manager.

Share

Conditional access for Exchange Online to the max

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

Scenario

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

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

Configuration

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

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

Block the OWA app

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

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

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

Block Exchange ActiveSync apps with basic authentication

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

1

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

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

2

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

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

3

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

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

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

Block default browsers on iOS and Android

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

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

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

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

ADFS_DenyChrome

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

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

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

Result

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

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

More information

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

Share

Conditional access for browsers

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

Introduction

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

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

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

Configuration

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

Exchange Online SharePoint Online
OWAExchangeOnline OFBSharePointOnline

End-user experience

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

Android

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

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

iOS

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

Non-compliant Compliant
IMG_0058 IMG_0056
IMG_0059 IMG_0057

Windows 10

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

More information

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

Share

Microsoft MVP 2016!

Awesome! Yesterday I received that great email that I’m awarded the 2016 Microsoft MVP Award in Enterprise Mobility (contribution area ConfigMgr & Microsoft Intune).

MVP2016

Probably many already read this on Twitter or on Facebook, but I just had to write a small post on my blog. Not just because I’m very honored, very proud and very exited of receiving my second award in a row, but also because I just need to let everyone know that it’s made possible by my great family. Without their support, this blog wouldn’t exist! A really big thank you to my wife and kids for letting me do my “thing”.

I’m ready for another community driven year!

Share