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

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

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

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

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:

Share

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.

Share

Windows 10 and MAM-WE – Part 1: Configuration

This week another blog post about Windows 10. This time in combination with mobile app management without enrollment (MAM-WE). Due to the size of the blog post, I’ve decided to divide this post in 2 parts. This weeks post will provide a short introduction, followed by the required configurations. Next weeks blog post will be about the end-user experience.

Introduction

MAM-WE, for Windows 10, relies on Windows Information Protection (WIP) in combination with a new enrollment flow in Windows 10, version 1703. That new enrollment flow enables users to enroll their personal device for receiving only MAM policies. Those MAM policies are only applicable to activities performed by the work account and do not apply to the personal account. The part that makes it a bit funny is that it’s named MAM-WE and it’s still required to do an enrollment. However, that enrollment is only for MAM. It’s correct that it’s without MDM enrollment. In other words, no policies are applied to the personal device of the user. This is a very powerful combination with conditional access. 

Configuration

Now let’s have a look at the configuration of the MAM-WE enrollment, the configuration options of the MAM-WE app policy and the assignment of the MAM-WE app policy. I’ll show the locations of the configuration options and the available configuration options. In addition I’ll provide additional information about settings, to clarify the available configuration options.

Enable MAM-WE enrollment

Let’s start with the first step, which is enabling MAM-WE enrollment. The following steps will go through the steps to enable MAM-WE enrollment in the Azure portal.

1 Open the Azure portal and navigate to Azure Active Directory > Mobility (MDM and MAM);
2 Select Microsoft Intune to open the Configure blade;
3

Configure_MAMOn the Configure blade, configure a MAM User scope. To enable MAM-WE for Windows 10 devices this should be configured to either Some or All. Also, make sure that the MAM Discovery URL is correct. To be absolutely sure simply select Restore default MAM URLs. The other URLs are optional. Click Save to enable the functionality.

Create MAM-WE app policy

Let’s continue with the second step, which is creating the MAM-WE policy. The following steps will go through the steps to create the MAM-WE app policy in the Azure portal. The first 4 steps are required actions, the last 4 steps are mainly used for providing information about the available settings.

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, click Add a policy to open the Add a policy blade;
4

MAM-WE_Policy1On the Add a policy blade, provide an unique name for the MAM-WE app policy and select Windows 10 as the Platform. This will enable the required configuration options. At this moment the Enrollment state will be automatically configured to Without enrollment. It will also show an informational message about configuring the MAM-WE enrollment.

Now let’s go through the remaining configurations. Allowed apps in step 5, Exempt apps in step 6, Required settings in step 7 and Advanced settings in step 8. After going through these steps simply click Create to create MAM-WE policy;

5

MAM-WE_Policy2On the Allowed apps blade, click Add apps to open the Add apps blade. On the Add apps blade, it’s possible to configure Recommended apps, Store apps and Desktop apps.

  • The Recommended apps selection contains apps that are preconfigured and guaranteed enlightened for WIP;
  • The Store apps selection contains empty lines for manually adding store apps. To get the required information, simply use the Windows Store for Business website;
  • The Desktop apps selection contains empty lines for manually adding desktop apps. To get the required information, simply use the Get-AppLockerFileInformation cmdlet.

Note: Make sure that every configured app is enlightened for WIP. Without that confirmation the app can behave different than expected. For a lot more information see this article.

6 MAM-WE_Policy3On the Exempted apps blade, click Add apps to open the Add apps blade. On the Add apps blade, the configuration options are the same as with the Allowed apps. The only difference is that there are no Recommended apps preconfigured;
7

MAM-WE_Policy4On the Required settings blade, the Corporate identity and the MDM discovery URL are preconfigured. Only the Windows Information Protection mode must be configured. Choose between:

  • Hide overrides: WIP blocks inappropriate data sharing;
  • Allow overrides: WIP prompts the end-user for inappropriate data sharing;
  • Silent: WIP runs silently. It only logs and doesn’t block or prompt;
  • Off: WIP is turned off.

Note: Make sure to start with Silent or Allow overrides for a pilot group. This enables the administrator to add the used apps to the allowed apps list.

8

MAM-WE_Policy5On the Advanced settings blade, configures additional settings in the categories Network perimeter, Data protection and Access. A few important setting that should be considered are:

  • The Add network boundary setting in the Network perimeter category. This settings should be used to define a boundary of the work resources. Use this as a good starting point for defining cloud resources. Also, when using that as a starting point, make sure to also configure conditional access for those resources. This will complete the circle and will make sure that the end-user must do a MDM enrollment or MAM-WE enrollment before using work data;
  • The Revoke encryption keys on unenroll setting, in the Data protection category. This setting should be used to prevent the end-user from accessing locally stored encrypted work data after unenrolling;
  • The Show the enterprise data protection icon setting in the Data protection category. This setting should be used to make sure that the end-user is aware when working with work data.

Note: Make sure to be aware of the remaining available settings related to subjects like RMS and Windows Hello for Business, before finalizing the configuration.

Assign the MAM-WE app policy

The third and last step is assigning the MAM-WE app policy. The following steps will go through the steps to assign the MAM-WE pp policy to an Azure AD user group in the Azure portal.

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 just created policy to open the {policyname} blade;
3 MAM-WE_Policy_AssignmentOn the {policyname} blade, select User groups to open the User groups blade. On the User groups blade, select Add user group to open the Add user group blade. On the Add user group blade, select an AAD user group and click Select.

More information

For more information about app policies and WIP, please refer to:

Share

Deep dive configuring Windows 10 ADMX-backed policies

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

Setting

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

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

Value

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

Step 1: Enable the setting

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

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

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

Step 2: Configure the setting

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

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

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

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

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

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

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

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

Step 3: Complete setting

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

Result

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

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

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

TerminalServerADMX_Reg TerminalServer_Reg
Share

Quick tip: View device in Azure Active Directory

This week a quick and short blog post about the feature, in Configuration Manager, to view a device in Azure AD. This is small new feature that was introduced in Configuration Manager 1702 and is mainly used for getting additional information about the compliance state of domain joined devices. Devices managed by a Configuration Manager client. In this post I’ll show the steps to use that feature and I’ll show the provided information.

View device in Azure AD

The feature to view a device in Azure AD, is only available when looking at non-compliant or compliant devices.  This can be achieved by going through the steps below.

1 Open the Configuration Manager administration console and navigate to Monitoring > Overview > Compliance Settings > Compliance Policies;
2 In the Overall Device Compliance overview, click on the Non-Compliant, or the Compliant, section of the donut and the Overall Device Compliance – Non-Compliant, or Overall Device Compliance – Compliant node will show;
3a ViewDevice_SelectOption 1: Select the device and click View Device in Azure Active Directory in the Home tab;
3b ViewDevice_RightOption 2: Right-click the device and click View Device in Azure Active Directory;
4 When the current user is not an administrative user in Azure AD, an additional dialog box will show. Simply provide the credential of an administrative user that has the permissions to view the device information and logon;
5 ViewDevice_AzureADThe View Device in Azure Active Directory dialog box will show. This dialog box provides up-to-date information about the compliance state of the device, including the important property Compliance Expires. That provides the administrator with the information about when the current compliance status expires. 
Share

Easily configure Start via Windows 10 MDM

This blog post is about the ability to configure Start on Windows 10 devices. Mainly focused on Windows 10 Desktop devices. Before Windows 10, version 1703, it was already possible to configure the layout of Start by using the StartLayout setting. Windows 10, version 1703, introduces many, many more settings related to configuring Start via Windows 10 MDM. All of these settings are available via the existing Policy CSP. These new settings range from configuring settings available in the Settings panel until configuring settings related to the Power button and the user tile.

In this post I’ll go through almost all newly introduced settings and I’ll briefly show how to configure these settings by using Microsoft Intune hybrid and standalone. I’ll end this post by showing the effect of the configured settings for the end-user.

Available settings

As Windows 10, version 1703, introduced many new settings to manage Start, I thought it would be good to briefly go through these new settings. The root node for the Start related settings is, in the Policy CSP, ./Vendor/MSFT/Policy. The Start related settings are grouped below ./Vendor/MSFT/Policy/Config/Start and contains the following settings.

Setting Value Description
ForceStartSize 0 – Do not force
1 – Force non-fullscreen
2 – Force fullscreen
This setting allows the administrator to force the Start screen size
HideAppList* 0 – None
1 – Hide all app list
2 – Hide and disable
3 – Hide, remove and disable
This setting allows the administrator to configure Start by collapsing or removing the all app list.
HideChangeAccountSettings 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Change account settings option from the user tile.
HideFrequentlyUsedApps* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the the most used apps.
HideHibernate 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Hibernate option from the Power button.
HideLock 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Lock option from the user tile.
HidePowerButton* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the the Power button.
HideRecentJumplists* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Recently used items option from the jumplists.
HideRecentlyAddedApps* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the recently added apps.
HideRestart 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Restart option from the Power button.
HideShutDown 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Shutdown option from the Power button.
HideSignOut 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Sign out option from the user tile.
HideSleep 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Sleep option from the Power button.
HideSwitchAccount 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Switch account option from the user tile.
HideUserTile* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the user tile.
NoPinningToTaskbar 0 – Pinning enabled
1 – Pinning disabled
This setting allows the administrator to configure the taskbar by hiding the option to pin and unpin apps on the taskbar.

*Setting requires restart to take effect.

Configure settings

After going through the available settings in the Start node, of the Policy CSP, let’s have a closer look at the configuration of those settings. These available settings can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

Start_IntuneHybridThe 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 settings.

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)

Start_IntuneStandAloneThe 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 settings.

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

Effective settings

Let’s end this post with the end-user experience. However, I’ll do that a bit different as I usually do. I’ll do that by showing the settings, and options, that are affected by the available settings.

Start_SettingsThe first section of configurable settings are all related to settings in the Settings panel. More specifically, Settings > Personalization > Start. In this section the following settings can be configured (as shown in the screenshot):

  • HideAppList;
  • HideRecentlyAddedApps;
  • HideFrequentlyUsedApps:
  • ForceStartSize;
  • HideRecentJumpLists.

Note: I’ve had some issues with configuring the HideAppList setting.

Start_PowerButtonThe second section of configurable settings are all related to the Power button. I’ll show these settings, by showing the available options of the Power button and the related setting. In this section the following settings can be configured (as shown in the screenshot):

  • HideSleep:
  • HideHibernate;
  • HideShutdown;
  • HideRestart;
  • HidePowerButton.

Start_UserTileThe third section of configurable settings are all related to the user tile. I’ll show these settings, by showing the available options of the user tile and the related setting. In this section the following settings can be configured (as shown in the screenshot):

  • HideChangeAccountSettings;
  • HideLock;
  • HideSignOut;
  • HideSwitchAccount;
  • HideUserTile.

More information

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

Share