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

Super easy Office 365 ProPlus deployment via Windows 10 MDM

This week a blog post about a very nice new app type in Microsoft Intune standalone. The Office 365 Pro Plus Suite (Windows 10) app type. This app type makes it very easy to assign Office 365 ProPlus apps to managed Windows 10 by utilizing the Office CSP. Additionally, it also allows the installation of the Microsoft Project Online desktop client, and Microsoft Visio Pro for Office 365. I know, I’m not the first to write about this app type, nor will I be the last, but this app type needs all the attention it can get. It’s that nice. I’ll start this post with some prerequisites and important information, followed by the configuration. I’ll end this post with the administrator experience.

Good to know

Before starting with the configuration of the new app type, it’s good to know the following current limitations and requirements.

  • Devices must be running Windows 10, version 1703 or later. That version introduced the Office CSP;
  • Microsoft Intune only supports adding Office apps from the Office 365 ProPlus 2016 suite;
  • If any Office apps are open when Microsoft Intune installs the app suite, end-users might lose data from unsaved files. At this moment the end-user experience is not that pretty;
  • When the Office apps are installed on a device that already has Office installed, make sure to be aware of the following:
    • It’s not possible to install the 32-bit and the 64-bit Office apps on the same device;
    • It’s not possible to install the same version of the Click-to-run, and MSI versions of Office on the same device;
    • When an earlier version of Office is installed, using Click-to-Run, remove any apps that must be replaced with the newer version;
    • When a device already has Office 365 installed, assigning the Office 365 ProPlus 2016 suite to the device might mean that the Office subscription level must be changed.

Configuration

After being familiar with the current limitations and requirements, let’s continue with the configuration. The 10 steps below walk through the configuration of the Office 365 Pro Plus Suite (Windows 10) app type. After creating the app type, assign the app like any other app. Keep in mind that at this moment the app can only be assigned as Required, Not applicable or Uninstall. Available is currently not an option.

1 Open the Azure portal and navigate to Intune > Mobile apps > Apps;
2 Select Add to open the Add app blade;
3 AA_AppTypeOn the Add app blade, select Office 365 Pro Plus Suite (Windows 10) as App type to add the Configure App Suite, the App Suite Information and the App Suite Settings sections;
4 On the Add app blade, select Configure App Suite to open the Configure App Suite blade;
5 AA_ConfigureAppSuiteOn the Configure App Suite blade, select the Office 365 apps that must be installed and click OK to return to the Add app blade;
6 Back on the Add app blade, select App Suite Information to open the App Suite Information blade;
7

AA_AppSuiteInformationOn the App Suite Information blade, provide the following information and click OK to return to the Add app blade;

  • Suite Name: Provide a unique name for the app suite;
  • Suite Description: Provide a description for the app suite;
  • Publisher: Provide the publisher of the app;
  • Category: (Optional) Select a category for the app suite;
  • Display this as a featured app in the Company Portal: Select Yes or No. At this moment the app suite can only be deployed as  required, which means that there are not many reasons to select yes;
  • Information URL: (Optional) Provide the URL that contains more information about the app;
  • Privacy URL: (Optional) Provide the URL that contains privacy information about the app;
  • Developer: (Optional) Provide the developer of the app;
  • Owner: (Optional) Provide the owner of the app;
  • Notes: (Optional) Provide additional notes about this app;
  • Logo: (Optional) Select an image.
8 Back on the Add app blade, select App Suite Settings to open the App Suite Settings blade;
9

AA_AppSuiteSettingsOn the Add Suite Settings blade, provide the following information and click OK to return to the Add app blade;

  • Office version: Select the version of Office that should be installed, 32-bit or 64-bit;
  • Update channel: Select how Office is updated on the devices, current, deferred, first release current or first release deferred;
  • Automatically accept the app end user license agreement: Select Yes or No;
  • Use shared computer activation: Select Yes or No;
  • Languages: Select additional languages that should be install with the app suite. By default Office automatically installs any supported languages that are installed with Windows on the end-user device.
10 Back on the Add app blade, click Add;

Note: After adding the app suite it cannot be edited anymore. To make adjustments, delete the app suite and create a new. That makes it important to think about the configuration before creating one.

Administrator experience

Usually I’ll end this type of posts with the end-user experience, but in this scenario there is not much to see. I can show something like the running installation process or the installed products, but that’s not that exciting as it’s simply there. Having said that, from an administrator perspective there are some interesting things to look at. Let’s start with the most interesting one, which is actually available on the end-user device, the Office CSP key in the registry. This key can be found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeCSP and is shown below.

Reg_OfficeCSP

Within this registry entry, it actually shows the content of the configuration XML in the default of the key. This enables me to have a look at the default values used during the installation of the Office apps. Besides the values configured in the app type. Below is the configuration XML that belongs to my installation. It basically shows 3 options that are not configurable, ForceUpgrade, Product ID and Display Level. Knowing these values should help with explaining the installation behavior.

<Configuration>
     <Add Channel=”FirstReleaseCurrent” ForceUpgrade=”TRUE” OfficeClientEdition=”32″>
         <Product ID=”O365ProPlusRetail”>
             <ExcludeApp ID=”Access” />
             <ExcludeApp ID=”Groove” />
             <ExcludeApp ID=”InfoPath” />
             <ExcludeApp ID=”Publisher” />
             <ExcludeApp ID=”SharePointDesigner” />
             <Language ID=”nl-nl” />
             <Language ID=”en-us” />
         </Product>
     </Add>
     <Display Level=”None” AcceptEULA=”TRUE” />
     <Property Name=”SharedComputerLicensing” Value=”0″ />
</Configuration>

Also interesting to look at, from an administrator perspective, is the installation status in the Azure portal. Simply navigating to Intune > Mobile apps > Apps install status and selecting the assigned app, will provide an overview as shown below.

InstallStatus

More information

For more information about the Office CSP and using Microsoft Intune to deploy Office 365 ProPlus, please refer to the following articles:

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

Microsoft MVP 2017-2018!

Yeah! Awesome! Just received that great email that I’m awarded with the 2017-2018 Microsoft MVP Award for my contributions in the Enterprise Mobility technical communities!

MVP_2017 

To me this is always worth a small post on my blog. Not just because I’m very honored, very proud and very exited of receiving my third 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! Without their support I wouldn’t be able to contribute the way I am! A really big thank you to my wife and kids for letting me do my “thing”.

Me and my family are ready for another community driven year!

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