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.

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:

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:

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.

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.

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!

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.

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:

Windows 10, MAM-WE and Office desktop apps

The last couple of weeks I did blog posts about the configuration and the end-user experience of Windows 10 and MAM-WE. One of the most common questions I received was, “what about the Office desktops apps?”. In this blog post I’ll provide the steps to get the required information about the Office desktop apps, for usage within MAM-WE app policies (or any other WIP-related policies). I’ll also show how to use that information in the MAM-WE app policy and I’ll show the end-user experience. Including some of the current challenges with the end-user experience.

Important: Keep in mind that the Office desktop apps are not yet mentioned on the list of enlightened Microsoft apps for use with WIP (see this article). That could mean that the apps might behave different than expected. As my end-user experience section will show, make sure to test carefully before implementing.

Get Office desktop information

Lets start by getting the required information about the Office desktop apps. These methods are the same for every desktop app that must be configured with any WIP-related policy. There are two methods available, the first method is using the Get-AppLockerFileInformation cmdlet, and the second method is using the Local Security Policy editor to create an AppLocker configuration XML file. I’ll use the PowerShell method in this post. Simply using the mentioned cmdlet, as shown below, provides the information that is needed for adding desktop apps to the MAM-WE app policy,

(Get-AppLockerFileInformation -Path “C:\Program Files\Microsoft Office\root\Office16\excel.exe”).Publisher

For the most common Office desktop apps, version 1609, this results in the following information.

PublisherName ProductName BinaryName BinaryVersion
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 EXCEL.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 OUTLOOK.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 POWERPNT.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 WINWORD.EXE 16.0.7369.2130

Add Office desktop information

The next step is to add the Office desktop app information, to the MAM-WE app policy. For the step-by-step activities, please refer to my post about configuring MAM-WE app policies for Windows 10. Here I’ll only show the required actions for adding the Office desktop app information to a MAM-WE app policy. The following steps go through adding the Office desktop apps to an existing Windows 10 MAM-WE app policy.

1 Open the Azure portal and navigate to Intune mobile application management;
2 Select App policy to open the App policy blade;
3 On the App policy blade, select the [Windows 10 MAM-WE app policy] to open the [Windows 10 MAM-WE app policy] blade;
4 On the [Windows 10 MAM-WE app policy] blade, select Allowed apps to open the Allowed apps blade;
5

On the Allowed apps blade, click Add apps to open the Add apps blade. On the Add apps blade, select Desktop apps. On the Desktop apps blade, provide the following information and click OK to return to the Allowed apps blade.

  • NAME: Provide a name for the desktop app;
  • PUBLISHER: Provide the PublsherName of the Get-AppLockerFileInformation cmdlet;
  • PRODUCT NAME: Provide the ProductName of the Get-AppLockerFileInformation cmdlet
  • FILE: Provide the BinaryName of the Get-AppLockerFileInformation cmdlet
  • MIN VERSION: (Optional) Provide a minimum version of desktop app. This can be used to, for example, make sure that at least a version is used that’s WIP enlightened;
  • MAX VERSION: (Optional) Provide a maximum version of desktop app.

MAMWE_AddOffice

6

Back on the Allowed apps blade, click Save to save the adjustments.

Note: At this moment the Allowed apps blade will show the same NAME as the PRODUCT NAME for manually added apps.

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll show the end-user experience by opening a work document. The first action is to open a work document via Word Online. Once opened I’ll select Edit Document > Edit in Word. This provides me with the question “How do you want to open this?”, as shown below on the left. It doesn’t mention that Word 2016 opens work and personal files, but I can open the document with Word 2016. Once opened, I’m still able to copy content to non-managed apps. When I choose Word Mobile, I’m not able to copy content to non-managed apps.

The second action is to download a work document from SharePoint Online. Once downloaded I select Open with. This provides me with the question “How do you want to open this work file?”, as shown below on the right. It correctly shows that Word 2016 opens work and personal files. However, again I’m still able to copy content to non-managed apps. When I choose Word Mobile, I’m not able to copy content to non-managed apps.

MAMWE_OfficeWord1 MAMWE_OfficeWord2

This clearly shows that this configuration enables the end-user to use Office desktop apps for work data. However, at this moment, it also clearly shows that it provides the end-user with more options on work data than the company might like.

More information

For more information about enlightened apps and Microsoft apps, please refer to:

Windows 10 and MAM-WE – Part 2: End-user experience

This week part 2 of my blog post about Windows 10 and MAM-WE. Last week it was about the configuration, this week it’s about the end-user experience. I’ll start this post with a short introduction about the settings that are configured for the end-user experience in this post. After that I’ll show the end-user experience with the enrollment, with accessing data and after enrollment.

Introduction

As I explained last week, there are a few Important settings that should be considered. The end-user experience shown throughout this post is based on the following configuration:

  • Allowed apps: Microsoft Edge, PowerPoint Mobile, Excel Mobile, Word Mobile, IE11, Microsoft Remote Desktop, Microsoft Paint, Microsoft OneDrive, Notepad;
  • Required settings:
    • Windows Information Protection mode: Allow Overrides;
  • Advanced settings:
    • Network boundary: All Microsoft cloud services;
    • Revoke encryption keys on unenroll: On;
    • Show the enterprise data protection icon: On.

Enroll device

Now let’s start with the end-user experience for enrolling the Windows 10 device. Keep in mind that the end-user must be Microsoft Intune licensed and must be using at least Windows 10, version 1703. The en-user can now navigate to Settings > Accounts > Access work or school and click Connect (see below on the left). This will start the enrollment experience that is similar to a normal MDM enrollment. The difference is in the background process. Once MAM enrollment is enabled, Windows 10, version 1703, will enroll the device for MAM. After enrollment this can be verified by selecting the work or school account and by clicking Info. This will show the information about the Management Server Address that points to the MAM check-in URL (see below on the right).

MAMWE_Enrollment1 MAMWE_Enrollment2

Note: After enrolling the device, an administrative user can find an additional device for the end-user in Azure AD. That device has the Trust Type attribute set to Workplace and the Managed By attribute set to None.

Access cloud work data

After enrolling the device it’s possible to connect to the configured Microsoft cloud services, like SharePoint Online. With and without conditional access configured. Browsing to SharePoint  Online will show the enterprise data protection icon, the briefcase, next to the URL (see below on the top). When clicking on the enterprise data protection icon, a message will show indicating that the website is managed (see below on the bottom).

petervanderwoude.nl
petervanderwoude.nl

Access local work data

When connecting to the configured Microsoft cloud services, like SharePoint Online, it’s also possible to download data, like documents. The downloaded documents will be marked as work data. The fact that it’s work data, ensures that the documents are encrypted. The work data can be recognized by the enterprise data protection icon, the briefcase, and by the File ownership. The File ownership will be set to the company (see below on the left). Work data can only be opened with managed apps. A clear example will show when using Open with > Choose another app. That will show the programs that can be used to open the document, including information about if the program can open work or personal files (see below on the right).

MAMWE_Local1 MAMWE_Local2

Copy work data

Now that it’s possible to open work data, it’s good to have a look at the behavior with copying content. In this case, opening work data, like a document, in Word Online (as shown below on the left) and Word Mobile (as shown below on the right).

MAMWE_WordOnline MAMWE_WordMobile

When copying content to an unmanged app, like WordPad, the end-user will be prompted for giving temporary access to use work content (as shown below). After clicking Give access, the content will be copied and the action will be logged.

MAMWE_Confirm

Note: Keep in mind that every activity related to accessing work data, is logged, in the Event Viewer, In the EDP-Audit-Regular log.

Switch owner

After enrolling the device it’s possible to switch the owner of local data. It’s even possible to switch the owner of the data, when selecting to download it. That enables the end-user to switch personal data to company data and company data to personal data (as shown below). When marked as work data, the data will be encrypted. When marked as personal data, the data will be unencrypted and free accessible.

MAMWE_Switch

Note: Keep in mind that every activity related to switching the owner of work data, is logged, in the Event Viewer, in the EDP-Audit-Regular log.

Unenroll device

Another important end-user action is unenrolling the device. With the current configuration this will revoke the encryption keys, which will revoke the end-user access to downloaded work data (as shown below on the left). It’s also really important to know that setting Revoke encryption keys on unenroll to Off will not revoke the end-user access to downloaded work data (as shown below on the right). The indication that it’s work data is still available, but the end-user has full access.

MAMWE_Unenroll1 MAMWE_Unenroll2

Note: Keep in mind that setting Revoke encryption keys on unenroll  to No, should only be used in specific scenarios. Using it in a normal production configuration will create major data leakage.