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

Allow users to connect remotely to this computer via Windows 10 MDM (ADMX-style)

This week another blog post about new MDM capabilities that are introduced in Windows 10, version 1703. This post is focused on enabling the setting to allow users to connect remotely to this computer via Remote Desktop. To enable that specific setting, Windows 10, version 1703, introduced ADMX-backed policy via the Policy CSP. In this post I’ll provide a short introduction about ADMX-backed policies, which is actually a short summary of the Microsoft docs, and I’ll show a configuration example. I’ll end this post by showing the end-user experience.

Introduction

Starting with Windows 10, version 1703, the Policy CSP can now also handle ADMX-backed policies. In an ADMX-backed policy, an administrative template contains the metadata of a GPO. Each administrative template specifies the registry keys, and their values, that are associated with a GPO and defines the policy settings that can be managed. Each setting in an administrative template corresponds to a specific registry value. Windows maps the name and category path of a GPO to a MDM policy area, and policy name, by parsing the associated ADMX-file, finding the specified GPO, and storing the metadata in the Policy CSP. When the MDM policy is referenced, this metadata is referenced and determines which registry keys are set or removed.

Configuration

Now let’s have look at the configuration for enabling the setting to allow users to connect remotely to this computer. I’ll do that by first going through the available settings, related to Remote Desktop, and getting the required values. After that I’ll put those two together in a configuration example.

Available settings

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

Setting Description
AllowUsersToConnectRemotely This setting allows the administrator to configure remote access to computers by using Remote Desktop Services.
ClientConnectionEncryptionLevel This setting allows the administrator to specify whether to require the use of a specific encryption level.
DoNotAllowDriveRedirection This setting allows the administrator to specify whether to prevent the mapping of client drives in a Remote Desktop Services session (drive redirection).
DoNotAllowPasswordSaving This setting allows the administrator to control whether passwords can be saved on this computer from Remote Desktop Connection.
PromptForPasswordUponConnection This setting allows the administrator to specify whether Remote Desktop Services always prompts the client for a password upon connection.
RequireSecureRPCCommunication This setting allows the administrator to specify whether a Remote Desktop Session Host server requires secure RPC communication with all clients.

Available values

Now that I’ve been through the available settings related to Remote Desktop, let’s have closer look at the setting that enables the administrator to allow users to connect remotely to this computer. That’s the setting AllowUsersToConnectRemotely.

To get the available values for the AllowUsersToConnectRemotely setting, it’s good to double-check the configuration options in the local Group Policy Editor. The related GPO setting is named Allow users to connect remotely by using Remote Desktop Services and can be found at Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections. That shows that the only available values are Not Configured, Enabled and Disabled. Related to ADMX-backed policies, this translates to a value of <enabled /> or <disabled />. AllowRDP_GPO

Note: When a setting contains more configuration options, like the ClientConnectionEncryptionLevel setting, which relates to the Set client connection encryption level setting, then it’s required to dive into the ADMX-file that contains the GPO setting. The ADMX-file contains the available elements that are required when the setting is enabled. In this case the TerminalServer.admx. Minor detail, this ADMX-file doesn’t contain readable information related to the required setting. To find the related setting in that AMDX-file, my advise is to first find the setting in the related AMDL-file. In this case the TerminalServer.adml. That file contains readable information and shows the name of the setting in the ADMX-file. In this case the setting is TS_ENCRYPTION_POLICY. The additional element for that setting is TS_ENCRYPTION_LEVEL and the available values for that element are 1, 2 and 3. Every element must show as data in the ADMX-backed policy. Related to ADMX-backed policies, this could translate to a value of <enabled /><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>.

Together this means that to  enable the setting to allow users to connect remotely to this computer, the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/AllowUsersToConnectRemotely
  • Date type: String
  • Value: <enabled />

Configure settings and values

Let’s put the setting and values together. Together this information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

AllowRDP_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)

AllowRDP_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.

End-user experience

Let’s end this post with the end-user experience. This time I’ll do that by showing the configuration in the user interface and in the registry. Like with configuring the setting to allow users to connect remotely  to the computer, via GPO, the Allow remote connections to the computer setting is enabled and grayed-out, as shown below on the right. This also corresponds to the registry setting fDenyTSConnections at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services, as shown below on the right. As these are ADMX-backed policies, the settings are configured in the registry.

AllowRDPReg_MDM AllowRDPScr_MDM

More information

For more information about ADMX-backed policy and the Policy CSP, please refer to:

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

Conditional access and Google Chrome on Windows 10

This week a short blog post to create some awareness about conditional access for Google Chrome on Windows 10. Starting with Windows 10, version 1703, it’s now possible to use Google Chrome in combination with conditional access. It will no longer simply being blocked. This can be achieved by installing and enabling the Windows 10 Accounts extension in Google Chrome. The screenshot below contains the name and URL of the extension.

Win10AccountsExt

Introduction

The Windows 10 Accounts extension for Google Chrome provides a single sign-on experience, to supported websites, to end-users that have a Microsoft supported identity on Windows 10,. Also, the Windows 10 Accounts extension for Google Chrome is required when the organization has implemented conditional access policies, to get the expected end-user experience. Currently, the Windows 10 Accounts extension for Google Chrome supports Azure AD identities.

End-user experience

Now let’s have a look at the end-user experience on a Windows 10, version 1703, device. I’ll go through the expected end-user behavior, with and without the Windows 10 Accounts extension for Google Chrome.

Chrome_WithOutExt_CAScenario: Google Chrome without the Windows 10 Accounts extension and with a conditional access policy that requires a compliant or domain joined device.

In this scenario, even when the device is complaint or domain joined, the device will be blocked when not using the Windows 10 Accounts extension. In this scenario, the end-user will receive a message that the current browser is not supported.

Chrome_WithOutExtScenario: Google Chrome without the Windows 10 Accounts extension and with a conditional access policy that uses app enforced restrictions on browsers of non-compliant or non-domain joined devices.

In this scenario, even when the device is complaint or domain joined, the device will have a limited experience when not using the Windows 10 Accounts extension. In this scenario, the end-user will receive a message that a limited experience is applied.

Chrome_WithExtScenario: Google Chrome with the Windows 10 Accounts extension and with a conditional access policy that requires a compliant or domain joined device, or with a conditional access that use app enforced restrictions on browsers of non-compliant or non-domain joined devices.

In these scenarios, with the Windows 10 Accounts extension enabled, the end-user experience will be the same as with Microsoft Edge or Internet Explorer. In this scenarios, the end-user will get the full experience.


Note
: The blue Windows-logo is an indication that the Windows 10 Accounts extension is enabled in Google Chrome.

Share

Easily configure desktop and lock screen image via Windows 10 MDM

This blog post uses the Personalization configuration service provider (CSP) to manage the desktop and lock screen image on Windows 10 devices. This CSP was added in Windows 10, version 1703, which is currently available as Insider Preview build.

This blog post is about the ability to easily configure separate images for the desktop and the lock screen on Windows 10 devices. Before Windows 10, version 1703, this was possible by using an MSI or by using the EnforceLockScreenAndLogonImage setting. However, the latter setting was only able to configure the lock screen image and not the desktop image. Windows 10, version 1703, introduces the Personalization CSP, which enables the administrator to manage the desktop and lock screen image. In this post I’ll briefly go through the available settings in the Personalization CSP and I’ll show how to configure the desktop and lock screen image via Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the end-user experience.

Configuration

Now let’s start with the configuration. Like last week I’ll split the configuration in two sections. The first section is about the available settings in the Personalization CSP and the second section is about the configuration of the desktop and lock screen image.

Available settings

As the Personalization CSP is new in Windows 10, version 1703, I thought it would be good to briefly go through the available settings. The root node for the Personalization CSP is ./Vendor/MSFT/Personalization and it contains the following settings.

Setting Description
DesktopImageUrl This setting allows the administrator to specify an image to be used as desktop image.
DesktopImageStatus This setting allows the administrator to query the status of the desktop image.
LockScreenImageUrl This setting allows the administrator to specify an image to be used as lock screen image. 
LockScreenImageStatus This setting allows the administrator to query the status of the lock screen image.

Configure settings

After going through the available settings in the Personalization CSP, it’s good to know that only the DesktopImageUrl and the LockScreenImageUrl are configurable settings. The other two settings can only be used to query the status. To configure the desktop and lock screen image, the following OMA-URI configurations can be used (in both cases the data type and value are the same):

  • OMA-URI – Desktop image: ./Vendor/MSFT/Personalization/DesktopImageUrl
  • OMA-URI – Lock screen image: ./Vendor/MSFT/Personalization/LockScreenImageUrl
  • Data type: String
  • Value: [<PATH>\<FILE>]
    • In this value <PATH> can be a http(s) url, or a file url;
    • In this value <FILE> can be a jpg, jpeg or png image.

This configuration information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

Personalization_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)

Personalization_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.

End-user experience

As usual, let’s end this post with the end-user experience. Before really going to the end-user experience, it’s good to show an easy method to verify the configuration. The configuration can be verified In the registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP. At this location it shows the url and the status of the desktop and lock screen image. Even better, it also show the local path of both images. In other words, whether the image is local, or remote, it will always be cached and used from a local location, as shown below.

Registry_Personalization

The real end-user experience is, of course, not in the registry. The real en-user experience can be easily found when logging on to the configured Windows 10 device. The desktop image will be configured, as shown below on the right, and the lock screen image will be configured, as shown below on the left.

LogonScreen_Example Desktop_Example

More information

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

Share