Easily configuring Windows Update for Business via Windows 10 MDM

This week a blog post about easily configuring Windows Update for Business (WUfB). I call it easily, as I did a post about something similar about a year ago. That time It was required to configure everything with custom OMA-URI settings. Starting with Configuration Manager 1706, an easier configuration option is available for the most important settings, by using the Configuration Manager administration console. For Microsoft Intune standalone this was already available for a while. In this post I’ll walk through the easy configuration options for Microsoft Intune hybrid and standalone and I’ll end this post with the end-user experience.

Configuration

Now let’s start by walking through the configuration steps for Microsoft Intune hybrid and standalone. However, before doing that it’s good to mention that at this moment Microsoft Intune hybrid and standalone still use the “old” branch names and are not yet updated to the “new” channel name(s). Also, keep in mind that currently not all the WUfB-settings are easily configurable. There are even differences between Microsoft Intune hybrid and standalone. Having mentioned that, every WUfB-setting, available in the Policy CSP, can also still be configured via custom OMA-URI settings.

Microsoft Intune hybrid

The configuration for Microsoft Intune hybrid must be done by using the Configuration Manager console. Simply walking through the wizard as shown below, will create the required policy. The policy can be deployed like a configuration baseline. The nice thing about the created policy is that it can be applied to devices managed via MDM and devices managed with the Configuration Manager client. The focus of this post is the devices managed via MDM.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Windows 10 Servicing > Windows Update for Business Policies;
2 On the Home tab, click Create Windows Update to Business Policy to open the Create Windows Update to Business Policy Wizard;
3 On the General page, provide unique name (max 200 characters) and click Next;
4

CWUfBPW_DefPolOn the Deferral Policies page, configure the following settings and click Next.

  • Defer Feature Updates
    • Branch readiness level: Select Current Branch or Current Branch for Business;
    • Deferral period (days): Select a value between 0 and 180;
    • Select Pause Feature Updates starting to prevent feature updates from being received on their schedule;
  • Defer Quality Updates
    • Deferral period (days): Select a value between 0 and 30;
    • Select Pause Quality Updates starting to prevent quality updates from being received on their schedule;
  • Select Install updates from other products to make the deferral settings applicable to Microsoft Update as well as Windows Updates;
  • Select Include drivers from Windows updates to also update drivers from Windows Updates.
5 On the Summary page, click Next;
6 On the Completion page, click Close;

Note: At this moment the policy can only be deployed to devices.

Microsoft Intune standalone

The configuration for Microsoft Intune standalone must be done by using the Azure portal. Simply walking through the blades, as shown below, will create the required update ring. The update ring can be assigned, after the creation, like anything else created in the Azure portal.

1 Open the Azure portal and navigate to Intune > Software Updates > Windows 10 Update Rings;
2 On the Windows 10 Update Rings blade, select Create to open the Create Update Ring blade;
3 On the Create Update Ring blade, provide unique name and select Settings to open the Settings blade;
4

W10UR_SettingsOn the Deferral Policies page, configure the following settings and select OK to return to the Create Update Ring blade.

  • Servicing branch: Select CB or CBB;
  • Microsoft product updates: Select Allow or Block;
  • Windows drivers: Select Allow or Block;
  • Automatic update behavior: Select Notify download, Auto install at maintenance time, Auto install and restart at maintenance time, Auto install and restart at a scheduled time or Auto install and reboot without end-user control;
  • Active hours start: Choose a time between 12 AM and 11 PM;
  • Active hours end: Choose a time between 12 AM and 11 PM;
  • Quality update deferral period (days); Provide a value between 0 and 30;
  • Feature update deferral period (days): Provide a value between 0 and 180;
  • Delivery optimization: Select HTTP only, no peering, HTTP blended with peering behind same NAT, HTTP blended with peering across private group, HTTP blended with internet peering, Simple download mode with no peering or Bypass mode.

Note: Depending on the choice made with Automatic update behavior, Active hours start and Active hours end can change to Scheduled install day and Scheduled install time.

5 Back on the Create Update Ring blade, select Create;

Note: It’s good to mention that it’s also possible to use the pause functionality for quality and feature updates without using custom URI settings. That can be achieved by selecting the created update ring and choosing Pause Quality or Pause Feature.

End-user experience

Important: The end-user experience is based on the current experience on Windows 10, version 1709 (RS3), which is currently available as Insider Preview build (build 16251).

I used Windows 10, version 1709 (RS3), for the end-user experience as it provides a clear view on the applied update policies. The examples below are based on the available settings in the different consoles. Below on the left is of a Microsoft Intune hybrid environment and below on the right is of a Microsoft Intune standalone environment. The show overview is available by navigating to Settings > Update & security > Windows Update > View configured update policy.

Configured_Hybrid Configured_Standalone

Another interesting place to look, is the registry. This is on the end-user device, but is more of interest for administrators. Starting with Windows 10, version 1607, the WUfB-configuration, configured via MDM, is available in the registry via HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\current\device\Update. The examples below are based on the available settings in the different consoles. Below on the left is of a Microsoft Intune hybrid environment and below on the right is of a Microsoft Intune standalone environment.

Registry_Hybrid Registry_Standalone

More information

For more information about Windows Update for Business  and how it can be configured via Microsoft Intune hybrid and standalone, please refer to the following articles:

Share

A new discovery method: Meet the Azure Active Directory User Discovery!

This week a blog post about the addition of a new discovery method, as Configuration Manager 1706 introduces the Azure Active Directory User Discovery. This discovery method enables organizations to search Azure AD for user information. It adds the cloud-only users to the Configuration Manager environment and it adds additional attributes to the existing on-premises user objects. The attributes that are discovered are objectId, displayName, mail, mailNickname, onPremisesSecurityIdentifier, userPrincipalName and AAD tenantID. In this post I’ll show how to configure the Azure Active Directory User Discovery and I’ll show a couple of challenges that I faced during the configuration. I’ll end this post with the administrator experience. The configuration options for the administrator and the important places for the administrator to look for the additional information.

Configuration

Let’s start with the configuration, which actually can be as simple as walking through a wizard. During the steps shown below, I’ll show the required steps for the initial cloud services configuration. Some screenshots will indicate that I’ve got multiple cloud services configured already. Before starting with the configuration, it’s good to mention that I always create a separate web app for every cloud service. By doing that I make sure that every web app only has the required permissions for it’s specific use case. Having said that, follow the next steps to configure the Azure Active Directory User Discovery by creating new web apps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services;
2 On the Home tab, click Configure Azure Services to open the Azure Services Wizard;
3

ASW_AzureServiceOn the Azure Services page, select Cloud Management and click Next;

Note: When this is the first cloud services that is configured, this page also contains the option to select OMS Connector, Upgrade Readiness Connector and Windows Store for Business.

4 On the App Properties page, click Browse with Web app to open the Server App dialog box;
5 On the Server App dialog box, click Create to open the Create Server Application dialog box;
6

On the Create Server Application dialog box, provide the following information and click OK to return to the Server App dialog box;

  • ASW_CreateServerAppApplication Name: Provide a friendly name for the app (max 200 characters);
  • HomePage URL: Provide the homepage URL for the app (max 200 characters);
  • App ID URI: Provide the identifier URL for the app (max 200 characters);
  • Secret key validity period: Select 1 Year or 2 Years for the key validity period;
  • Azure AD Admin Account: Sign in with the tenant administrator account;
  • Azure AD Tenant Name: Automatically populated after signing in;

Note: Once a web app is already created for the cloud management service, pressing OK will result in an informational message stating “An Azure AD Web App already exists for this Tenant. Use the pre-existing app and then click OK

7 ASW_ServerApp2Back on the Server App dialog box, select the just created web app and click OK to return to the App Properties page.
8 Back on the App Properties page, click Browse with Native Client app to open the Client App dialog box;
9 On the Client App dialog box, click Create to open the Create Client Application dialog box;
10

On the Create Client Application dialog box, provide the following information and click OK to return to the Client App dialog box;

  • ASW_CreateClientAppApplication Name: Provide a friendly name for the app (max 200 characters);
  • Reply URL: Provide the reply URL for the app (max 200 characters);
  • Azure AD Admin Account: Sign in with the tenant
    administrator account;
  • Azure AD Tenant Name: Automatically populated after signing
    in;
11 ASW_ClientApp2Back on the Client App dialog, select the just created native app and click OK to return to the App Properties page;
12 ASW_AppBack on the App Properties page, verify the created and selected apps and click Next;
13

ASW_DiscoveryOn the Configure Discovery Settings page, select Enable Azure Active Directory User Discovery and click Next;

Note: Click Settings to configure the full discovery polling schedule and the delta discovery. The default schedule for the full discovery is once every 7 days and the default interval for the delta discovery is an interval of every 5 minutes.

14 On the Confirm the settings page, click Next;
15 On the Completion page, verify the results and close the wizard.

Challenges

During my initial configuration of the Azure Active Directory User Discovery , I encountered a few challenges. The most important challenges that I faced, are the following.

1 AzureReqPermUnauthorized error: After the Azure Active Directory User Discovery started, it immediately failed with an unauthorized error message. This was related to the permissions of the just created web and native app. The permissions were set correctly. However, it needed a trigger, by clicking Grant Permissions, to grant the permissions for all the accounts in the directory.
2 Unknown error: After the Azure Active Directory User Discovery started with a successful authentication, it failed again. This time with an unknown error message. This was related to an orphaned user account in Azure AD. For some reason Azure AD still contained an user account that was already removed from the on-premises AD, a long time ago. Removing the orphaned user account from Azure AD solved this challenge.

Administrator experience

Now let’s end this post with the most interesting part, the administrator experience. From an administrative perspective, this configuration introduces at least the following new items.

1 CloudManPropDiscover method: One of the most interesting items is the new Azure Active Directory User Discovery. After the configuration is finished the discovery method can be found by navigating to Administration > Overview > Cloud Services > Azure Services. Selecting the cloud management Azure service, provides the option Run Full Discovery Now. The properties of the cloud management Azure service, provide the option to reconfigure the discovery configuration of the Azure Active Directory User Discovery (as shown on the right).
2 AzureADDiscoverAgentLog file: One of the most important items is the new log file SMS_AZUREAD_DISCOVERY_AGENT.log. This log files provides the information about the full and delta discoveries of the Azure Active Directory User Discovery (as shown on the right). The nice part is that the log files also provides information about the Microsoft Graph requests that it uses for the discovery.
3 CloudOnlyUserCloud-only users: The most useful item is the availability of the cloud-only users in the on-premises environment. These users can be recognized by only having the Agent Name of SMS_AZUREAD_USER_DISCOVERY_AGENT (as shown on the right). The availability of the cloud-only users in the Configuration Manager environment, and the availability of the new attributes for existing users, enables a whole lot of new scenarios. Most of these scenarios are related to managing Windows 10 Azure AD joined devices with an Configuration Manager client.
4

SQL_svUserUser properties: The overall most interesting, most important and most useful item is by far the information in the database. The main user tables and views now contain additional fields for cloud-related information. Some nice information can be found on the right, were I used a simple query to get information about user that contain attributes from the Azure Active Directory User Discovery. The query I used here was:

SELECT Unique_User_Name0,User_Principal_Name0,AADTenantID,AADUserID,CloudUserId
FROM v_R_User
WHERE AADTenantID IS NOT NULL

More information

For more information about the Azure AD user discovery and how to use and configure it, please refer to the following articles:

Share

Easily predeclaring corporate-owned devices

This week another post about (easily) predeclaring corporate-owned devices. Starting next week, I’ll introduce some new feature of Configuration Manager 1706. This post is basically a part 2 of my post about predeclaring corporate-owned devices. The big difference, this time it’s about Microsoft Intune standalone were this feature is just recently introduced. Predeclaring corporate-owned devices is an easy method to differentiate between corporate and personal devices and immediately tag those devices. I’ll start this post with a little bit information, followed by the configuration. I’ll end this post with the administrator experience.

Information

Let’s start with some information about predeclaring corporate-owned devices. An Intune administrator can now create and import a comma-separated values (.csv) file that lists International Mobile Equipment Identifier (IMEI) numbers or serial numbers. Intune uses these identifiers to set Ownership as Corporate. IMEI numbers can be declared for all supported platforms and serial numbers can be declared for iOS and Android devices only. Each IMEI or serial number can have details specified in the csv file for administrative purposes.

Configuration

Before I’m going to walk through the required configuration steps, it’s good to provide some information about the format of the csv files that can be used. To create the list, create a two-column csv list without a header. Add the IMEI or serial numbers in the left column, and the device details in the right column. A csv file can only contain or IMEI numbers, or serial numbers. The device details are limited to 128 characters and are for administrative use only. Details aren’t displayed on the device. The current limit is 500 rows per csv file. An example for serial numbers would look like the following.

RF8xxxxRZP,Company-owned Android device
F9FxxxxxxHK9,Company-owned iOS device

With this information and the example, I’ll now walk through the configuration steps.

1 Open the Azure portal and navigate to Intune > Device enrollment > Corporate device identifiers;
2 On the Corporate device identifiers blade, select Add to open the Add identifiers blade;
3

AddIdentifiersOn the Add identifiers blade, select Serial as Identifier type, select the created csv file with Import identifiers and click Add to return to the Corporate device identifiers blade;

Note: When importing IMEI numbers, simply select IMEI as Identifier type. Also, notice the message below the selected csv file, it already shows the total number of device identifiers that are found within the csv file.

4

Back on the Device identifiers blade it will now provide an overview of the just imported device identifiers;

SuccesImport

Administrator experience

Let’s end this post with the administrator experience. After a device of the csv file is enrolled, there are a few good places to look in the Azure portal. The first place is Intune > Device enrollment > Corporate device identifiers. This location shows the imported device identifiers and will now also show Enrolled as the STATE of the imported device identifier.

SuccesEnroll

The second place is Intune > Devices > All devices. This location shows all the enrolled devices and now also shows Corporate as OWNERSHIP of the device.

EnrollCorporate

This is the easiest method for an administrator to differentiate between corporate and personal devices. It enables the administrator to target specific actions only to corporate-owned devices and even enables the administrator to create an easy road to blocking personal devices. More about that in a later post. Also, keep in mind that the ownership will not change for already enrolled devices. The corporate identifiers must be imported before the devices are enrolled.

More information

For more information about predeclaring corporate-owned devices, please refer to this article about adding corporate identifiers.

Share

Require minimum platform version or app version when using MAM-WE

This week a relatively short blog post about the recently introduced feature to require a minimum platform version, app version and Intune app protection policy SDK version, when using MAM-WE. This enables organizations to require end-users to update their personal devices when using apps to connect to company resources. That can be very useful when specific platform and/or app updates introduce important new features, or fix important bugs. In other words, a great feature! In this post I’ll go through the available settings, the configuration options and the end-user experience.

Configuration

Let’s start by having a look at the configuration. I’ll do that by first going through the available settings, followed by going through how to configure those settings in an app protection policy.

Available settings

Since May 2017 it’s possible to set additional requirements for MAM-WE that enforces the following policies before connecting to company data:

  • Minimum app version;
  • Minimum platform version;
  • Minimum Intune app protection policy SDK version (iOS only).

Most of these settings are available for both Android and iOS. Microsoft Intune supports minimum version enforcement for platform versions, app versions, and Intune app protection policy SDK. Setting a minimum version enforcement for the Intune app protection SDK, is currently only available for iOS. The configuration is also available when configuring an app protection policy for Android, but in that case the configuration will not work and will not save (at this moment).

Configure app protection policy

Now let’s have a look at configuring the available settings in an app protection policy. I’ll do that by going through the steps for creating an app protection policy for iOS that provides a warning message when the iOS platform is not at the specified minimum version. Configuring the remaining settings can be done by following similar steps, as shown in the screenshot in step 6. That screenshot shows all the new available settings. Also, keep in mind that it might require multiple app protection policies when targeting specific apps and versions.

1 Open the Azure portal and navigate to Intune App Protection > App policy;
2 Select Add a policy to open the Add a policy blade;
3 On the Add a policy blade, provide a unique name for the app protection policy and select Apps to open the Apps blade;
4 On the Apps blade, select the required apps and click OK to return to the Add a policy blade;
5 Back on the Add a policy blade, select Settings to open the Settings blade;
6

APP_NewSettingsOn the Settings blade, select Yes with Require minimum iOS operating system (Warning only), specify a minimum version with iOS operating system and click OK to return to the Add a policy blade;

Note: When specifying a version number it’s required to specify at least a major and minor version. Only a major version is not sufficient. In my example I used 10.3.3 for easy testing, as the current iOS version is 10.3.2.

7 Back on the Add a policy blade, click Create;

Note: When creating an app protection policy for Android devices, the option to configure a specific minimum Intune SDK version is available. However, it won’t be configurable.

End-user experience

Let’s end this post by looking at the end-user experience. Depending on the configuration, the end-user might be unable to access the targeted application if the minimum requirements through the app protection policy are not met at the three different levels mentioned above. Let’s start mildly. Below are examples of an iOS device trying to use the Outlook app to connect to Exchange Online. On the left is an example of a warning notification about the platform version and on the right is a warning notification about the app version. These notifications can be closed and the app can be used as normal.

IMG_0110 IMG_0111

Now let’s take it one step further. Below are examples of an Android device trying to use the Outlook app to connect to Exchange Online. On the left is an example of a blocking notification about the platform version and on the right is an example of a blocking notification about the app version. At this moment, the end-user may either remove their account (for multi-identity applications), or go back to close the app and update the version of the app or platform.

Screenshot_20170715-080322 Screenshot_20170715-081738

More information

For more information about the available app protection policies, please refer to:

Share

Combining MAM-WE and app configuration

This blog post is about a potentially really great feature, which is a combination of MAM-WE and app configuration policies. This enables the administrator to provide a preconfigured app, once the end-users signs in to the app with company credentials. I named it a potentially really great feature, because the availability of apps that support this combination of features will make or break the use of this feature. In this post I’ll provide a quick introduction to this feature, followed by a configuration example with the Intune Managed Browser.I’ll end this post with the end-user experience.

Introduction

Let’s start with a quick introduction. MAM-WE with app configuration, also known as MAM targeted configuration, allows an app to receive configuration data through the Intune App SDK. The format and variants of this data (the keys and values) must be defined and communicated by the application owner/developer. The Microsoft Intune administrators can target and deploy the configuration data via the Intune Azure console. The app configuration data is pushed through the MAM Service directly to the app, instead of through the MDM channel.

Configuration

The configuration in this post will be based on the Intune Managed Browser, which is, to my knowledge, currently the only app that works with this great combination of features. At this moment, MAM targeted configuration is available on iOS and Android. For iOS, the app must have incorporated Intune APP SDK for iOS (v 7.0.1) and be participating in app configuration settings.

Available settings

Before starting with the actual configuration, let’s start by looking at the available configuration settings. The nice thing is that very recently a few configuration keys have been released by Microsoft. The Intune Managed Browser can now be preconfigured for Azure AD App Proxy redirection, with a specific homepage, with a list of bookmarks and with a list of allowed or block websites. That provides  us with the following list of keys and example values. The name of the keys provide a clear indication of their configuration usage.

Key Example value
com.microsoft.intune.mam.managedbrowser.AppProxyRedirection true
com.microsoft.intune.mam.managedbrowser.homepage https://www.petervanderwoude.nl
com.microsoft.intune.mam.managedbrowser.bookmarks Search|https://www.google.nl
com.microsoft.intune.mam.managedbrowser.AllowListURLs https://*.petervanderwoude.nl/*
com.microsoft.intune.mam.managedbrowser.BlockListURLs https://*.facebook.com/*

Note: The separation character for multiple bookmarks is || and the separation characters for multiple allow/block URLs is |.

Configure app configuration policy

After looking at the available settings, let’s have a look at the actual configuration. The configuration of MAM targeted configuration, can be done by using the Azure portal and following the steps below. After creating the app configuration policy, don’t forget to assign it to an user group.

1 Open the Azure portal and navigate to Intune App Protection > App configuration;
2 Select Add Config to open the Add app configuration blade;
3 AAC_NameOn the Add app configuration blade, provide a unique name for the app configuration policy and select App to open the Targeted apps blade;
4 AAC_AppsOn the Targeted apps blade, select the Managed Browser (Android), the Managed Browser (iOS) and click OK to return to the Add app configuration blade;
5 Back on the Add app configuration blade, select Configuration to open the Configuration blade;
6

ACC_ConfigOn the Configuration blade, provide similar information as the earlier mentioned NAME and VALUE (examples) pairs and click OK to return to the Add app configuration blade;

7 Back on the Add app configuration blade, click Create;

End-user experience

Let’s end this post by looking at the end-user experience. I created an app configuration, as mentioned in this post, but added a couple more bookmarks. Below are a couple of examples of the Intune Managed Browser on an iOS device. On the left is an example of an app configuration including a homepage, and on the right is an example of an app configuration excluding a homepage.

IMG_0108 IMG_0109

More information

For more information about configuring the Intune Managed Browser, please refer to this article about Manage Internet access using Managed browser policies with Microsoft Intune.

Share

Set default app associations via Windows 10 MDM

This blog post will be about setting default app associations, or file type associations, on Windows 10 devices. Starting with Windows 10, version 1703, it’s possible to set the default app associations via Windows 10 MDM. In this post I’ll briefly go through this setting and I’ll show how to configure the setting via Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the end-user experience.

Configuration

Starting with Windows 10, version 1703, a new setting was introduced that allows an administrator to set the default file type and protocol associations. When set, default associations will be applied on sign-in to the PC. Every sign-in. In other words, the end-user can make adjustments. However, once the end-user signs-out and signs-in again, the default associations will be applied again. This does require the PC to be Azure AD joined.

Get the required information

Let’s start by getting the required information to configure the custom OMA-URI setting. The required OMA-URI setting is available in the Policy CSP.

OMA-URI setting: ./Vendor/MSFT/Policy/Config/ApplicationDefaults/DefaultAssociationsConfiguration

The required OMA-URI value requires the following steps to get it in the correct format.

1 On Windows 10, version 1703, navigate to Settings > Apps > Default apps and configure the required default apps;
2 Open Command Prompt and run DISM /Online /Export-DefaultAppAssociations:DefAppAss.xml to export a required app associations file;
3

Base64Encode_orgOpen your favorite Base64 encoder and encode the content of DefAppAss.xml to Base64 format.

In my example I was only interested in switching to Internet Explorer as the default browser and keeping Microsoft Edge as the default for PDF reading. That allowed me to remove all the remaining content from the DefAppAss.xml. Then I used base64encode.org to easily encode the remaining content of the DefAppAss.xml to Base64 format (see screenshot).

4 The result in Base64 format is the OMA-URI value.

Configure the setting

After getting the required information, let’s have a closer look at the configuration of the setting. The setting can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

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

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

Microsoft Intune standalone (Azure portal)

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

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

Note: This post is based on the custom OMA-URI settings configuration. At some point in time this configuration can come available via the UI of Microsoft Intune standalone and/or hybrid.

End-user experience

Now let’s end this post by having a quick look at the end-user experience. Below on the left is the default Windows configuration and below on the right is the applied policy with the custom app associations. I know that this doesn’t provide a lot of information. However, it does show one important fact, which is that there is nothing preventing the end-user from making adjustments. The end-user can still make adjustments, but those adjustments will be reverted during the next sign-in.

DefaultBrowser_Edge DefaultBrowser_IE

More information

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

Share

Conditional access and apps that cannot be installed on the device

This week a relatively short blog post related to conditional access. More specifically, about the ability to create a compliance policy with an apps that cannot be installed list. Before starting, let’s start with the minor detail that this is a Microsoft Intune hybrid only configuration at this moment. Introduced in Configuration Manager 1702. I’ll start this post with a short introduction, followed by the required configurations. Including how to find the required information. I’ll end this post with the end-user experience on an iOS and Android device.

Introduction

Let’s start with a short introduction about the apps that cannot be installed list. The apps that cannot be installed list is an additional rule that can be configured as part of a compliance policy. When the end-user installs an app from the apps that cannot be installed list, the end-user will be blocked when trying to access corporate email and other corporate resources that support conditional access. The end-user will be blocked until the app is removed from the device. This rule requires the app name and the app ID when adding an app to the apps that cannot be installed list, defined by the admin. The app publisher can also be added, but it’s not required.

This rule is supported on iOS 6+, Android 4.0+ and Samsung KNOX Standard 4.0+.

Configuration

Now let’s walk through the steps to add an app to the apps that cannot be installed rule of a compliance policy. Let’s start by getting the required app ID, followed by the steps to use that information in a compliance policy.

Get app ID

First get the app ID, as it’s required information for the apps that cannot be installed rule. An app ID is the identifier that uniquely identifies the app within the Apple and Google application services. I’ll use the OWA app as an example.

Android

The app ID for Android can easily be found in the Google Play store URL that was used to browse to the app. As an example see the app ID for the OWA app in the following URL (bold): https://play.google.com/store/apps/details?id=com.microsoft.exchange.mowa&hl=en

iOS

The app ID for iOS is a bit more challenging. To find the app ID, follow the next steps.

1 Find the ID number in the iTunes store URL. As an example see the ID for the OWA app in the following URL (bold): https://itunes.apple.com/us/app/owa-for-ipad/id659524331?mt=8;
2 Open a web browser and navigate to the following URL, using the example ID of the OWA app: https://itunes.apple.com/lookup?id=659524331;
3 Download and open the 1.txt file;
4 1_txtIn the 1.txt file, search for the text bundleId. The value with the text is the app ID. With the OWA app example, the app ID is com.microsoft.exchange.mowa.

Configure compliance policy

After finding the app ID, it’s now time to use that information in a compliance policy. Below are the required steps for creating a compliance policy and adding the OWA app to the apps that cannot be installed list. After creating the compliance policy, simply deploy it like any other policy.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
2 Click Create Compliance Policy to open the Create Compliance Policy Wizard;
3 On the General page, provide a unique name, select Compliance rules for devices managed without the Configuration Manager client and click Next;
4 On the Supported Platforms page, select iPhone or/and iPad or/and Android or/and Android For Work and click Next;
5

IH_BlockedAppListOn the Rules page, click New to open the Add Rule dialog box. In the Add Rule dialog box, select Apps that cannot be installed and click Add to open the Add app to blocked application list dialog box. In the Add app to blocked application list dialog box, specify the Name and App ID of the app and click OK, OK, Next;

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

End-user experience

When the configuration is done, let’s have a look at the most important thing, the end-user experience. Below on the left is the end-user experience when connecting to corporate resource with conditional access enabled. This is a standard message for non-compliant devices. Below on the right is the additional information in the Company Portal app. In this case it will clearly show (at least on iOS) that the end-user must first uninstall the OWA app to get a compliant device. The first row is an iOS device, the second row is an Android device.

IMG_0107 IMG_0106
Screenshot_20170624-075046 Screenshot_20170624-074745

Note: From an administrator perspective, have a look at Monitoring > Overview > Deployments for a clear view of which end-users are non-compliant for the compliance policy.

Share

Using the Desktop App Convertor to create a Windows app package

This week something completely different compared to the last few weeks, maybe even months. This week I’m going to create some awareness for the Desktop App Converter (DAC). DAC is a tool that can be used to bring desktop apps to the Universal Windows Platform (UWP) by using the Desktop Bridge. In this post I’ll start with a short introduction about the Desktop Bridge, followed by an introduction and the usage of DAC. I’ll end this post by providing some deployment considerations.

Desktop Bridge

Lets start with a short introduction about the Desktop Bridge.

desktop-bridge-4

The Desktop Bridge, also known as the Desktop to UWP bridge, is the infrastructure that is built into the platform that lets the administrator distribute Windows Forms, WPF, or Win32 desktop app or game efficiently by using a modern Windows app package.
This package gives the app an identity and with that identity, the desktop app has access to Windows Universal Platform (UWP) APIs. These UWP APIs can be used to light up modern and engaging experiences such as live tiles and notifications. Use simple conditional compilation and runtime checks to run UWP code only when the app runs on Windows 10. Aside from the code that is used to light up Windows 10 experiences, the app remains unchanged and the administrator can continue to distribute it to the existing Windows 7, Windows Vista, or Windows XP user base. On Windows 10, the app continues to run in full-trust user mode just like it’s doing today.

Desktop App Convertor

There are multiple methods available to create Windows app packages, from manual packaging (MakeAppx.exe) until using Visual Studio or third-party tooling. All of these are out of scope for this post. IIn this post ’m going to specifically look at using DAC.

Introduction

DAC can be used to bring desktop apps to the UWP. This includes Win32 apps and apps that are created by using .NET 4.6.1. While the term “Converter” appears in the name of this tool, it doesn’t actually convert the app. The app remains unchanged. However, this tool generates a Windows app package with a package identity and the ability to call a vast range of WinRT APIs. The converter runs the desktop installer in an isolated Windows environment by using a clean base image provided as part of the converter download. It captures any registry and file system I/O made by the desktop installer and packages it as part of the output. For an overview of the workflow, have a look the picture below.

DAC_Workflow

DAC can be very convenient in cases where the app makes lots of system modifications, or if there are any uncertainties about what the installer does. DAC also does a few extra things. Here are a few of them.

  • Automatically register preview handlers, thumbnail handlers, property handlers, firewall rules, URL flags;
  • Automatically register file type mappings that enable users to group files in File Explorer;
  • Register public COM servers;
  • Automatically sign the package so that it can be easily tested;
  • Validate the app against Desktop Bridge and Windows Store requirements.

Requirements

The goal of this post is to create a Windows app package by using DAC. However, before using DAC, make sure that the system meets the following requirements.

Setup environment

When the system meets the requirements, lets start with setting up the environment. To use DAC for packaging an app that uses an installer, use the following steps to install and set up DAC.

1 Download and install the Desktop App Convertor app;
2 Download the Desktop App Convertor base image that matches the current operating system (in my case I downloaded BaseImage-15063.wim to C:\Temp);
3 Right-click the Desktop App Convertor app and select Run as administrator to start the DesktopAppConvertor console window;
4 In the DesktopAppConvertor console window, set the PowerShell execution policy by using Set-ExecutionPolicy ByPass;
5

In the DesktopAppConvertor console window, set up the convertor by using DesktopAppConvertor.exe –Setup –BaseImage .C:\Temp\BaseImage-15063.wim –verbose

Note: Make sure to adjust the location and name of the base image when using a different location and/or version;

6 If needed, restart the computer.

Create Windows app package

After setting up the environment, lets start with converting an app. Well, as mentioned before, it’s not actually converting an app, it’s creating a Windows app package. That being said, to use DAC for creating a Windows app package that has a setup executable file, use the following steps.

1 Get the content available locally of the installer that must be converted (in my case I used KeePass-1.33-Setup.exe and placed it in C:\Temp);
2 Right-click the Desktop App Convertor app and select Run as administrator to start the DesktopAppConvertor console window;
3

In the DesktopAppConvertor console window, start the conversion by using DesktopAppConverter.exe -Installer C:\Temp\KeePass-1.33-Setup.exe -InstallerArguments “/SILENT” -Destination C:\Temp -PackageName “MyKeePass” -Publisher “CN=PTCLOUD” -Version 0.0.0.1 –MakeAppx –Sign –Verbose -Verify

Note: Make sure to adjust the parameters to reflect the information of the app and its location. Also, make sure to run a silent installation, as DAC needs to run the installer in unattended mode.


The parameters are used for the following purpose:

  • Installer: The path to the installer of the application;
  • InstallerArguments: The arguments to run the installer silently;.
  • Destination: The destination for the converter’s appx output;
  • PackageName: The name of the Windows app package;
  • Publisher: The publisher of the Windows app package;
  • Version: The version of the Windows app package;
  • MakeAppx: A switch that triggers the creation of the Windows app package;
  • Sign: A switch that triggers the signing of the Windows app package, with a generated certificate. This can be used for easily testing the created Windows app package;
  • Verify: A switch that triggers the verification of the Windows app package against the Desktop Bridge and Windows Store requirements.
4

Install_KeePassTest the application by installing the auto-generated.cer and simply double-clicking the created Windows app package (in my case MyKeePass.appx) and clicking Install.

Note: An alternative method is not signing the Windows app package and using the Add-AppxPackage cmdlet.

Result

After creating the Windows app package, lets have a look at the results. There many things to look at, but, for this post, the most interesting thing is the created report (VerifyReport.xml). That report will provide a quick overview of the results for the created Windows app package. Below is the report available for the created KeePass app, on the left, and the report for a created Notepad++ app, on the right. A successful check on the left and a failed check on the right. The KeePass app shows no issues with the the Desktop Bridge and Windows Store requirements, while the Notepad++ app shows an issues with administrative permissions. An easy first check for a new Windows app package.

CDAA_KeePass petervanderwoude.nl

Deployment considerations

Now that the Windows app package is created it’s time to think about deploying the Windows app package. The most logical options are publishing the Windows app package to the Windows Store and using deployment tooling to distribute the Windows app package. The Windows Store can be used in combination with the Windows Store for Business and the deployment tooling can be one of my favorites, Microsoft Intune or Configuration Manager.

For publishing the Windows app package to the Windows Store, use this form to start the onboarding process. For distributing the Windows app package via Microsoft Intune and Configuration Manager, it’s important to sign the Windows app package. The used certificate must be of a trusted vendor, or must be installed in the trusted root/ trusted people certificate store.

More information

For more information about de Desktop Bridge and the Desktop App Convertor, please refer:

Share

Deep dive configuring Windows 10 ADMX-backed policies

A couple of weeks ago, I did a my blog post about configuring a Windows 10 ADMX-backed policy. That time I used a relatively easy setting to configure and I briefly mentioned how to configure a more advanced setting. That raised some questions, which triggered me to do a deep dive in configuring those more advanced settings. In this blog post I’ll show, in a step-by-step overview,  how to construct the OMA-URI setting and value for a more advanced setting.

Setting

I’ll use the ClientConnectionEncryptionLevel setting as an example again. A big difference with the previous time is that the docs are greatly improved. By default, the docs now already provide information about the corresponding Group Policy setting and the location of the Group Policy setting. The docs already provide the following information about the settings.

MDM CSP setting path/ name
RemoteDesktopServices\ClientConnectionEncryptionLevel
Group Policy English name
Set client connection encryption level
Group Policy English category path
Windows Components\Remote Desktop Services
Group Policy name
TS_ENCRYPTION_POLICY
Group Policy ADMX file name
terminalserver.admx

Value

The default information in the docs make it relatively easy to find the required setting and it’s basic values. Now let’s go through the steps to find all the required information for more advanced settings. A more advanced setting, to me, is a setting that must be enabled and requires additional data.

Step 1: Enable the setting

Let’s start with the first step, which is enabling the setting. The following steps will go through the steps to find the Group Policy setting and enabling it.

1 Open the Group Policy Management Editor and navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security;
2 Right-click the setting Set client connection encryption level and select Edit;
3

GPO_SetClientConnectionEncryptionLevel_1In the Set client connection encryption level dialog  box, it’s possible to enable and disable the setting. After enabling the setting it shows an advanced setting to configure, the Encryption Level. In this example I want to enable the setting. That means that I need to use <enabled/> as value for my OMA-URI setting. However, as the advanced setting needs an additional data element, I also need to find the appropriate data for that element.

Step 2: Configure the setting

The next step is the advanced configuration of the Group Policy setting. The following steps will go through finding the available values and how those values can be used in a OMA-URI setting.

1 Open TerminalServer.admx and navigate to the TS_ENCRYPTION_POLICY policy setting;
2

TerminalServerADMXThe <elements> section contains the configurable data elements and its possible values. As shown on the right, the configurable data element is named TS_ENCRYPTION_LEVEL and the configurable values are:

  • 1 = TS_ENCRYPTION_LOW_LEVEL;
  • 2 = TS_ENCRYPTION_CLIENT_COMPATIBLE;
  • 3 = TS_ENCRYPTION_HIGH_LEVEL.
3 Open TerminalServer.adml and navigate to the TS_ENCRYPTION_POLICY string;
4

TerminalServerADMLThe ADML contains the readable string of the display names mentioned in the ADMX. Around the TS_ENCRYPTION_POLICY string I can see the following display names for the previously mentioned values:

    • TS_ENCRYPTION_LOW_LEVEL =  Low Level;
    • TS_ENCRYPTION_CLIENT_COMPATIBLE = Client Compatible;
    • TS_ENCRYPTION_HIGH_LEVEL = High Level.
5

GPO_SetClientConnectionEncryptionLevel_2Back to the Set client connection encryption dialog box, I can now translate the available configuration options to values for my OMA-URI setting. When I compare the TerminalServer.admx (and TerminalServer.adml) with the available configuration options, I can translate them like this:

  • Client Compatible = 2;
  • High Level = 3;
  • Low Level = 1.
6 Putting the advanced setting and its available configurations together, gives me the following data element for configuring the Encryption Level to Low Level: <data id=”TS_ENCRYPTION_LEVEL” value=”1″/>;

Step 3: Complete setting

Now I can put step 1 and step 2 together and enable the setting and configure the required additional configuration. When I want to enable Set client connection encryption level and set the Encryption Level to Low Level, I can use the following value for the OMA-URI setting: <enabled/><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>.

Result

Let’s have a look at the result, when I’m configuring the following OMA-URI setting:

  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/ClientConnectionEncryptionLevel
  • Date type: String
  • Value: <enabled/><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>

As I’m basically configuring Group Policy settings, the best place to look for a successful configuration is the registry. Below on the left is another look at the TerminalServer.admx in which I show the registry key that will be configured. On the right I show the configured registry key and it’s value.

TerminalServerADMX_Reg TerminalServer_Reg
Share

Conditional access and named locations

This week another blog post about a recently introduced feature that can be used in commination with conditional access, named named locations. Within conditional access policies, named locations can be used like trusted IPs. The complication with trusted IPs was that it’s actually a feature configuration of multi-factor authentication. That did not really make a lot of sense. In this post I’ll look at the configuration of named locations and how those configurations can be used within a conditional access policy.

A very good scenario for named locations in a conditional access policy is using Office 365 in a terminal services environment. It enables organizations to make an exclusions for a specific named location. In this post I’ll use an example that will blocks access to SharePoint Online with the exception of the configured named location.

Configuration

Now let’s start with having a look at the configuration of named locations and how those named locations can be used within conditional access policies.

Named location

Named locations is a feature of Azure AD that enables administrators to label trusted IP address ranges in their organizations. In the environment, administrators can use named locations in the context of the detection of risk events to reduce the number of reported false positives for the Impossible travel to atypical locations risk event type. However, since recently named locations are also available for use in Azure AD conditional access policies under preview. To create a named location in Azure AD, use the following 3 steps.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Named locations;
2 On the Named locations blade, click New location to open the New blade;
3

CA_NamedLocationOn the New blade, provide a Name and IP range, and click Create;

Note: Even though the example shows that a private IP range is used, for usage with conditional access policies that doesn’t make sense. Use a public IP range. When a device arrives with Azure AD, for authentication, it provides the public IP address to Azure AD (see also the blocked example in the end-user experience section).

Conditional access policy

Using named locations within conditional access policies, is similar to using trusted IPs in conditional access policies. The biggest difference is the location of the configuration. Trusted IPs is a feature configuration of multi-factor authentication, while named locations is a feature configuration of conditional access. To use the configured named location within a conditional access policy, to block all external access to SharePoint Online, follow the 7 steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 CA_UsersGroupsOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 CA_SharePointOnlineOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 SharePoint Online and click Done;
5 CA_ExcludeLocationOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Locations to open the Locations blade. On the Locations blade select Yes with Configure, select All locations on the Include tab, select All trusted IPs in the Exclude tab and click Done. Back in the Conditions blade, click Done;
6

CA_BlockAccessOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: This configuration will make sure that all locations are blocked access to SharePoint Online, with the exclusion of the named location. The devices within the named location can now connect to SharePoint Online without any additional requirements.

7 On the New blade, select On with Enable policy and click Save.

End-user experience

As usual, let’s end this post with the end-user experience. Below on the left is an example of a connection to SharePoint Online within the configured named location and below on the right is an example of a connection to SharePoint Online outside of the named location. The blocked example clearly shows the external IP address that’s used to connect to SharePoint Online and that it’s blocked by conditional access.

SP_AllowedAccess SP_BlockedAccess

Note: Yes, the blocked example shows the same IP address, as the named location configuration. To simulate a good test, I simply temporarily adjusted the IP range of the named location. That allowed me to easily test the blocked behavior on my devices.

More information

For more information about conditional access and named locations, please refer to:

Share