Solution

  • Workspace ONE

Type

  • Document

Level

  • Intermediate

Category

  • Operational Tutorial

Product

  • Workspace ONE UEM

OS/Platform

  • Windows 10

Use-Case

  • Modern Management

Understanding Windows 10 Group Policies: VMware Workspace ONE Operational Tutorial

Introduction

Purpose of This Group Policy Object Tutorial

As you make the move to Windows 10 modern management, you are likely to encounter challenges with group policy management. Common challenges include:

  • Increasing user mobility deconstructing the traditional workspace
  • Multiple management tools creating policy conflicts 
  • Figuring out how to push policies to domain-joined, Azure-joined, or even workgroup devices
  • Lack of feature parity between profile configurations and traditional group policy objects (GPOs). 

Whatever challenges you face, this operational tutorial covers the benefits and the steps to consider when moving to cloud-based group policies and other configurations. If you are trying to figure out how to apply policies on and off the domain, enforcing those policies offline, track compliance, using inbox or application AMDX policies and don’t know where to start in VMware Workspace ONE®  UEM (aka AirWatch), then you have come to the right place. 

This tutorial is broken up into the following core sections:

  1. Planning and Preparation: Determine your current GPO estate and plan your migration strategy
  2. Analyzing and Rationalizing: Determine which policies need to move to Workspace ONE and which method(s) you will use to make a move: migrating or modernizing.
  3. Modernizing and Migrating: Learn the prescriptive steps required to modernize with Workspace ONE Baselines or migrate with Workspace ONE AirLift.
  4. Validation, Compliance, and Enforcement: Learn how to validate configured policies on the device manually (if needed) versus leveraging Workspace ONE to report on compliance and locally enforce configured policies.

Keep in mind that every use-case is different, and the methodology discussed here should serve as high-level guidelines. Just as Windows 10 is ever evolving, Workspace ONE UEM is also continuously evolving.

group policy objects (GPOs)

Audience

This operational tutorial is for PC lifecycle management (PCLM) administrators and Workspace ONE IT administrators. Familiarity with configured policies or required configurations and security baselines in your environment is assumed, including Active Directory structure, group policy objects (GPOs), and application (3rd party) ADMX policies. Knowledge of additional technologies such as VMware Workspace ONE® UEM, Microsoft Endpoint Configuration Manager, or any other technology that configures policies on Windows devices is recommended.

Preparing to Move Group Policies

Evaluating Your Current Group Policy State

Before you begin on your journey of managing group policies  in the cloud with Workspace ONE UEM, you must determine your current GPO state.  

Use the following questions to evaluate your current state:

  • Are the end-users on the managed Windows 10 devices local admins? Enforcement of policies is top-of-mind when end-users have local admin rights on managed devices. If enforcement and compliance of policies are a concern in your use-case, consider leveraging Workspace ONE Baselines as much as possible.
  • Are you currently or planning to Azure Cloud join your Windows 10 devices? On-premises policies require devices to be joined to the local domain. While many organizations are moving to the cloud, it’s essential to consider if you will be joining your devices to the Azure Cloud, on-premises domain, or hybrid joined. Consider moving all policies to Workspace ONE UEM if devices will no longer leverage the on-premises domain. Keep in mind; you also may have some devices in various domain states.
  • Are you currently or planning to use an industry-standard baseline? Organizations that leverage industry-standard baselines such as Windows 10 Security Baseline or CIS Microsoft Windows Desktop Benchmarks can leverage the Baselines feature in Workspace ONE UEM to deploy policies from these industry-standard templates.
  • Do you want to move all policies or a subset of policies over to Workspace ONE UEM? Decide which policies need to move to Workspace ONE UEM. It is helpful to obtain a full list of policies then categorize them into groups such as personalization, security, system, BitLocker, Defender, Internet Explorer, and Chrome. It is also good to know how these policies are currently being configured, such as MBAM, domain group policies, or ADMX templates.
  • Are you ready to manage all your policies from the cloud? Policy conflict, collisions, and order of precedence are concerns that develop during the modernization implementation phase. To avoid this topic altogether, consider having a single source of truth and manage all policies from the cloud using Workspace ONE. I will address these concerns in more detail later on in this tutorial.
  • Who is the owner of the policies set in the organization? Involve and collaborate with anyone in the organization who is responsible for managing, configuring, and securing Windows devices. The planning and analyzing phases should not be completed in a vacuum, as we have seen success when other teams are involved especially the security team.
  • Will there be discrete policy sets for different employees, or a standardized approach for all use cases? Understanding which policies are applied to which users/groups is vital. You will be asked to assign policies in Workspace ONE UEM leveraging smart groups throughout the tutorial. In order to prepare, you should decide how you plan for policies to be applied. If you leverage Workspace ONE AirLift to analyze policies then pay attention Scope of Management column in the policy validation report, or the Organizational Units column in the Workspace ONE AirLift dashboard to gain insight into where the current policies are being assigned.

Using Workspace ONE AirLift to Analyze Group Policies

A large part of leveraging cloud-based group policies starts with assessing your current policy landscape and determining if these policies need to move over to Workspace ONE UEM. Workspace ONE AirLift simplifies the validation and conversion of traditional group policies (GPOs) to MDM based policies (CSPs).

If you currently do not have any group policies on your domain or just want to start fresh, then you can leverage Workspace ONE Baselines to get started using an industry-standard policy template.

1. Download Workspace ONE AirLift

Setup and configure the latest version of Workspace ONE AirLift. Once installed, Workspace ONE AirLift points to your domain, and aggregates all of your Windows 10 group policies.

Note: You are not required to connect Workspace ONE AirLift to Microsoft Endpoint Configuration Manager (ConfigMgr), formerly known as Microsoft System Center Configuration Manager (SCCM).

Workspace ONE AirLift aggregates all of your domain's Windows 10 group policies.

2. Generate a Group Policy Report in AirLift

To generate a group policy report:

  1. Navigate to the Policies page.
  2. Select your policies.
  3. Click the Report button.

AirLift then generates a .CSV file with the following column headers:

  • GPO Name
  • Path, Name
  • Value
  • Sub-Values
  • Scope of Management
  • Bound Workspace ONE Profiles
  • AirLift Legacy ID
  • Hidden, Minimum Windows 10 Version
  • Maximum Windows 10 Version
  • Created Time in Utc
  • Modified Time in Utc
  • Validation Message
  • Validation

The name of the report will always be unique and adheres to the following format: PolicyValidationsReport.YYYYMMDDTHHMMSS.csv.

Note: You can download a sample policy report by clicking More, then Policy Validations Report at the top of this document's window.

3. Analyze and Rationalize Group Policies

Now you are ready do some serious group policy housekeeping. This is a great time to clean up the GPOs that you might have carried forward over the years across different OS versions.

Allocate time and collaborate with the appropriate teams to determine which group policies are still relevant. For this cleanup exercise, plan to categorize and evaluate each policy line by line.

  1. Categorize: In your spreadsheet, assign each group policy a category in the GPO Name column. Common categories include: personalization, security, system, BitLocker, Defender, Internet Explorer, and Chrome. Then, create a new tab for each category for the responsible team to evaluate line by line.
  2. Evaluate: Now you are ready to evaluate your group policies. Go through the appropriate category tab of your spreadsheet line by line. For each policy, decide your next step:
    • Move - Migrate this policy to Workspace ONE. Keep in mind that some policies (such as BitLocker and personalization) are covered by equivalent Workspace ONE UEM profiles.
    • Drop - Clean out legacy policies so that you only move over policies that are necessary for your organization.
    • Do Not Migrate -  Select this option for domain-dependent group policies that are tied to domain-joined devices. Try to use this option sparingly.

Note: Complementary to Workspace ONE AirLift, you can also leverage the Microsoft MDM Migration Analysis Tool (MMAT) to generate a report of which polices map to modern policies. This might be beneficial if you want to quickly run an assessment on your local domain-joined machine to get an idea of how many policies can be mapped to modern policies.

4. Modernize or Migrate

After building your report, you need to decide how you want to move your policies. You can either modernize using Workspace ONE Baselines, or you can migrate them using AirLift. For more details refer to the next section, Choosing the Correct Policy Delivery Model.

  • Modernize with Workspace ONE Baselines: This option leverages the group policy framework and has a similar impact as local group policy objects for Windows 10 but is delivered and managed via the cloud. This is the preferred option for those with more initial time to modernize their policies. Leveraging Workspace ONE Baselines provides:
    • Allows for a one-to-one mapping of traditional GPO policies but removes the on-premises dependencies.
    • Reporting and enforcement capabilities of policies.
    • Reduces the time and effort of managing the lifecycle of policies long term via the Workspace ONE console.
    • Provides comprehensive coverage for inbox GPOs while not requiring VPNs back to the on-premises network.

However, you cannot build your own baseline from scratch. You must leverage one of the industry-standard templates: Windows 10 Security Baseline or CIS Microsoft Windows Desktop Benchmarks. Though, these templates can be fully customized for your use-case.

  • Migrate with Workspace ONE AirLift: This option converts policies to the modern configuration service provider (CSP) equivalent. This option is best for organizations wanting to quickly and easily move policies to Workspace ONE. However, this option also loses flexibility in the long term to manage individual policy settings, as the group of settings are now contained within one Custom Settings (XML) Profile in the Workspace ONE UEM console. In addition, currently, there is no enforcement of these policies on the device.

Note: Policy Enforcer, a VMware Fling, checks and remediates restriction policies on a Workspace ONE managed Windows 10 device. However, as a Fling, Policy Enforcer has not been tested thoroughly for the group policy (CSPs) enforcement use-case.

Choosing the Correct Policy Delivery Model

Workspace ONE UEM provides the administrator with multiple different deployment models for their current GPO policies. It is important that an administrator is aware of the different options available in Workspace ONE and the caveats around each of these models, to ensure the correct model is chosen.  

Workspace ONE UEM Policy Deployment Models

A critical part of ensuring the correct policy model is chosen in Workspace ONE UEM is to have a sound understanding of each of the options. Workspace ONE UEM allows for an administrator to apply group policies as: 

  • Configuration Service Providers (CSP) – Applied through the existing Windows 10 Profiles or via a Custom Settings profile. 
  • Workspace ONE Baselines – Using either the Microsoft Windows 10 Security Baselines or CIS Microsoft Windows Desktop Benchmark, or a Custom Baseline based on a GPO backup. 

The export of GPO settings from Workspace ONE AirLift will help you determine which of the Workspace ONE UEM policy delivery models work best for the individual settings. As part of the GPO remediation process that you’ll undertake with your internal teams, a decision should be made around what is the best place to enable that policy inside of Workspace ONE.  

Configuration Service Providers (CSPs)

A configuration service provider (CSP) is an interface to read, set, modify, or delete configuration settings on the device. These settings map to registry keys or files. Most of the CSPs support SyncML for over-the-air configuration of the device.  

Workspace ONE UEM leverages CSPs when an administrator creates and assigned profiles in the console. In most cases, the OMA-DM client is responsible for delivering the CSP setting to the devices. 

Administrators of Workspace ONE UEM can choose to create CSPs in three different ways: 

  • Profiles that are listed in the Workspace ONE UEM console. 
  • Custom Settings profiles created using VMware Policy Builder. 
  • Custom Settings profiles exported from AirLift. 

For more information regarding CSPs, refer to the Understanding Windows 10 Configuration Service Providers (CSPs) and Custom Profiles section in the appendix.  

Workspace ONE Baselines

Baselines allow you to keep all your devices secure with industry-recommended settings and configurations. It uses a cloud-based micro service that handles the policy catalog of settings to apply on devices. Baselines are based on GPOs and function in similar ways. For more information regarding Baselines, refer to Workspace ONE Baselines Overview

Workspace ONE allows for an administrator to create baselines based on industry-certified templates such as the CIS Microsoft Windows Desktop Benchmark and the Microsoft Windows 10 Security Baseline. You can add additional policies to a baseline that you create from an easy-to-use catalog of thousands of policies based on the Microsoft ADMX files. 

An administrator can also upload a GPO backup into the Workspace ONE UEM console as a custom baseline. This requires LGPO.exe to be deployed to the Windows 10 device. 

Comparison of the Unified Endpoint Management Policy Models

Given both CSPs and Baselines are both important policy delivery methods in Workspace ONE, it is imperative that you understand the pros and cons of each. It is important for an administrator to understand which delivery model makes the most sense for the requirement and how best to apply their GPO setting in the Workspace ONE platform. 

Policy Delivery Method Pros Cons
Configuration Service Provider (CSP)
  • “Modern” policies that are built for the cloud-first architecture 
  • Uses the OMA-DM communication channel 
  • New features/settings are likely to be implemented as CSPs rather than more legacy policy methods 
  • Settings are removed from the device when the profile is deleted 
  • Console-implemented CSPs are easy for an admin to visualize and edit 
  • One-time enforcement of the CSP setting 
  • No reinforcement period built in 
  • Not all CSPs are displayed in the console UI, so admins may need to use VMware Policy Builder to create the custom settings profiles 
  • CSPs implemented as custom profiles need to be edited in the XML by the admin. Not intuitive by design, but is simpler with VMware Policy Builder 
Workspace ONE Baseline (using templates)
  • Uses an industry validated template by CIS or Microsoft 
  • Settings enforced at a reapplication interval 
  • Baseline compliance is reported in the console 
  • Settings are removed from the device when the baseline is unassigned 
  • Admins need to start with the preconfigured template settings and augment accordingly 
  • Large administrative setup if there are lots of GPOs and if most aren’t already in the baseline 
  • Needs significant testing to ensure that the baseline meets the customer’s requirements 
Workspace ONE Baseline (custom baseline)
  • Quick and easy to move from traditional Group Policy Management 
  • Less rigor around testing required, since it is an export of an already working GPO 
  • Requires LGPO.exe to successfully apply 
  • Limited visibility and reporting of custom baseline settings 
  • No baseline lifecycle management – an admin will need to upload a new GPO export if they want to modify the baseline 

Policy Delivery Model Guidelines

The following guidelines are the best practices when assessing existing GPOs and determining which is the most effective delivery method through Workspace ONE. 

  1. Policies that are implemented in the Profiles section of the Workspace ONE UEM console should be utilized before any alternative method.
  2. For configuration settings that don’t get updated often (e.g. WiFi settings, encryption settings, restrictions), these should be implemented using the CSPs. If the setting does not already exist as a profile in the console, you can use VMware Policy Builder or AirLift to export the setting.
  3. If the user doesn’t have administrative rights on their Windows 10 machines, most configuration settings applied cannot be changed by the user.
  4. For policies that need to be reinforced within a defined time interval, these should be implemented through Workspace ONE Baselines, based on an industry template.
  5. It is recommended to start with a Workspace ONE Baseline based on the Microsoft Windows 10 Security Baselines or CIS Microsoft Windows Desktop Benchmark and the policies that need reinforcement and reporting.
  6. GPO backups uploaded as a custom baseline are not a recommended approach for all of your GPO policy settings. You will find that custom baselines lack the ability for full lifecycle management such as, reporting and making edits directly via the console.
  7. Custom ADMX policies should be assessed to determine if there are more optimized delivery models for these settings. Workspace ONE can deliver scripts and transforms to augment applications to have the desired configurations.
  8. For the remaining custom ADMX policies, the recommended approach is to use Workspace ONE AirLift to move them into Workspace ONE UEM as a custom settings profile.  

You should leverage AirLift for assessing the GPOs that are implemented in the environment. AirLift provides you with a list of GPOs that are applied to Windows 10 endpoints in the environment. Similar to the assessment process used to Move or Drop specific policies during rationalization, you should concurrently decide the preferred delivery model of each setting in Workspace ONE UEM. 

Sample Policy Decision

The following example demonstrates the recommended end states for discovered GPO settings that were discovered in an organization. The report was exported from AirLift, you can download a copy of this file by using the More tab on the menu bar.

In this example, almost all devices in the fleet are running Windows 10 1909, connected to the traditional on-premises Active Directory domain. All of the end users are standard users on their machines, so they do not have elevate privileges to change settings pushed down by policy. Some of the applications are pushed to the user on-demand, while the remaining are made available through the Workspace ONE Intelligent Hub Catalog. 

I have included an explanation as to why each of the GPO settings should be implemented in Workspace ONE UEM using that chosen method. The reasoning used here is based on the Policy Delivery Model Guidelines listed above. These guidelines are critical to implementing policies correctly in Workspace ONE UEM.  

Note: You can download the Report Outcome using the More tab on the menu bar of this document. Pay close attention to columns P and Q.  

Upon reviewing the assessment of the GPOs discovered in this environment, 34% of these settings should be applied using the CSPs. This can be done using the console UI, VMware Policy Builder and a subset are done through the AirLift export function. 

Baseline implementation makes up 33% of the end-state for settings. This is because they may not map to an existing CSP, or they need to be reapplied within a specified time interval. 

Recommended Implementation Outcome Number of GPO Settings Percentage of Total
Add as additional policy to the CIS Benchmark or Microsoft Security Baseline 33 32.67%
CSP, using VMware Policy Builder 4 3.96%
CSP, exported using AirLift 10 9.90%
CSP, via the Workspace ONE UEM Console 21 20.79%
Determine if the setting is necessary as it was deprecated in 1809. If needed for a subset of devices, export as a custom baseline. 1 0.99%
Do not implement in Workspace ONE UEM 28 27.72%
Duplicate of another GPO Setting 4 3.96%
Total  101 100%

It is important that this end-state analysis is done as part of your GPO rationalization procedure. This will ensure only the necessary settings will be moved over into Workspace ONE UEM and will allow for effective lifecycle management of these settings. 

Getting Started Tips

Below are a few tips before diving into the prescriptive steps on leveraging Workspace ONE Baselines to modernize policies, Workspace ONE AirLift to migrate policies, handling 3rd party ADMX policies, and using VMware Policy Builder.

  • Think about the steps you will take to manage the transition as well as the lifecycle of each policy. For example, first, decide which policies will move, then create or migrate that policy/profile in Workspace ONE UEM, then un-assign from the domain, then assign the policy in Workspace ONE.
  • In order to optimize the assignment process in Workspace ONE, an administrator should do one of the following:
    1. Change your device-based organizational units (OUs) to user-based OUs.
    2. Map your Device Collections as Workspace ONE Smart Groups using AirLift.
    3. Use Workspace ONE Sensors and Intelligence to tag devices migrated from ConfigMgr.
  • If you have not checked out the recently enhanced Smart Group filter categories, be sure to take a look. You can now create groups based on the device manufacturers and specific models as well as filter devices by enrollment type such as Azure AD OOBE devices.
  • How do you properly handle policy collisions? Which policies take precedence? How will you ensure enforcement of policies? I will cover these topics in detail later on in this tutorial, so keep reading!
  • Don’t forget about creating Workspace ONE UEM profiles for matching policies, our scripting capabilities, and to leverage VMware Policy Builder!
  • Consider: You might keep on-premises domain policies enabled which you don't want to migrate or modernize in Workspace ONE. These policies were marked as Do Not Migrate in the previous steps. This makes sense of policies which are dependent on the device being domain joined. This way these policies are applied to domain joined devices and other devices are not affected which also prevents policy collisions.

Modernize Group Policies Using Workspace ONE Baselines

What Are Workspace ONE Baselines?

Keeping your devices configured to best practices is a time-consuming process. Workspace ONE Baselines enforce device security using industry-recommended configurations and settings. These configurations significantly reduce the time it takes to set up and configure Windows devices along with other configuration options within the Workspace ONE solution.

Baselines use the VMware Policy Catalog Service, a cloud-based micro-service that handles storing the policy catalog. If you are an on-premises customer, ensure that your environment can communicate with the micro-service. For more information, see the On-Premises Network Requirements documentation.

Prerequisites for Baselines

The following list of items are the minimum requirements for baselines:

  • Workspace ONE UEM 1907 or later
  • Workspace ONE UEM Admin with Manage/View Baselines Roles
  • Workspace ONE Intelligent Hub 1907 or later
  • Workspace ONE Advanced or greater
  • If you are an on-premises customer, ensure that your environment can communicate with the micro-service. For more information, see the On-Premises Network Requirements documentation.
  • Only when using Custom Baselines: LGPO.exe located at %ProgramData%\AirWatch\LGPO
    • Leverage this sample for deploying LGPO.exe to your devices.

Deploying Baselines

To ensure that Baselines use only the best settings and configurations, VMware offers industry-standard baselines, including the CIS Microsoft Windows Desktop Benchmarks and Windows 10 Security Baselines.These Baselines are based on the Windows OS version of your devices. During configuration, you can choose which baseline to use and customize any of the baseline policies. You can also add any additional policies you need as part of the configuration process. These policies are Microsoft ADMX policies. We will see how to deploy and customize a sample Windows 10 Security Baseline.

1. Create New Baseline

Log in to the Workspace ONE UEM console using an admin account that has access to Baselines (Manage and View Baselines), then navigate to Devices > Profiles & Resources > Baselines. Click New to create a new Baseline.

2. Configure General Settings

Configure the General settings:

  1. Type Windows 10 1903 Security Baseline for Baseline Name.
  2. Type Corporate Windows 10 1903 Security Baseline with customizations for the Description.
  3. Click Next.

3. Select a Baseline Template

Select the pre-configured baseline and version, that is best for your organization’s use-case. Use the tooltip to learn more about each option. It is not advisable to choose the Custom Baseline option at this time. For more details, refer to the Using Custom Baselines section. For this example:

  1. Select Windows 10 Security Baseline.
  2. Select Version 1903 from the dropdown.
  3. Click Next.

Pro Tip: Depending on your use-case, some default policy configurations can disrupt your current workflows on your managed Windows devices. Ensure you fully test the end-to-end workflow, on UAT or non-production devices, to ensure everything is working properly especially if you have not previously used a baseline. For example, when using the CIS Windows 10 Benchmarks you may notice that the Workspace ONE app and other UWP (Store apps) do not install or launch properly. You will have to customize the baseline to configure the following policies:

  • Disable all apps from Microsoft Store set to Enabled or Not Configured
  • Turn off the Store application set to Disabled or Not Configured

4. Customize the Baseline

You can now review or customize the policies from the Windows 10 Security Baseline to meet your organization’s needs. Each setting will have a useful tooltip to assist in understanding each configuration option. You can find settings using the search Filter option or by manually expanding each section to find the policies.

  1. Type deny write access for the search filter.
  2. Select Deny write access to removable drives not protected by BitLocker.
  3. Use the dropdown menu to change this policy to Disabled.
  4. Check out the tooltip for the details of this policy.
  5. Click Next.

5. Add Policies (Optional)

If your use case contains policies that are not part of the standard template, then you can leverage this step that allows for the granularity of fully configuring devices policies. Use the search field to find additional policies, then configure them for your needs.

  1. Type prevent access to registry into the search. Notice that real-time search results are populated as you type. Select Prevent access to registry editing tools. Note that the catalog contains both machine and user policies. You can quickly see these details via the dropdown.
  2. Use the dropdown menu to set this policy to Enabled. Enabling this policy disables the user to access regedit. Note that Disable regedit from running silently is set to Yes by default. This will prevent users from using regedit via command-line with the /s (silent) switch.
  3. Click Next.

6. Review the Summary

You can now review all of the settings and configurations you have made. This screen shows you the selected baseline, any customizations made, as well as the additional policies. You can go back to make edits or move on to save and assign to devices.

After reviewing the summary, click Save & Assign.

7. Assigning the Baseline

The next step is to assign the baseline to a group(s) of devices leveraging Smart Group(s). Smart Groups allow you to customize assignments based on various factors such as the platform, ownership, user group, OS version, model, device tag, enterprise OEM, and even individual devices or users by name. You can also choose to exclude specific groups such as executives or select members of the organization.

There are endless ways to deploy your baselines. However, I would recommend starting with the guidelines set by Microsoft when using Windows 10 Security Baselines or Center for Internet Security when using CIS Microsoft Windows Desktop Benchmarks. I would then recommend choosing one of the two following methods for deploying baselines:

  1. Assignments based on Groups: assign baselines based on the current grouping structure you have for deploying apps and profiles. Remember that you can create new Smart Groups as well, which can align with your domain user groups.
  2. Assignments based on Windows version: assign baselines based on Windows 10 version. It is recommended not to create Smart Groups tied to a singular version, but to create a Smart Group for the targeted version and above. For example, Windows 10 1903 or later devices. Doing this will prevent a baseline from being removed/un-assigned when the devices upgrade to the next Windows version.

NOTE: Before choosing a method to implement, please refer to the Baseline Lifecycle Management section to fully understand how baselines are applied over time to devices.

8. Baseline List View

Once the baseline is assigned, you can click View under Install Status to quickly see the deployment status of the baseline. For more details, you can click on the Name of the baseline, for example, Windows 10 1903 Security Baseline to see additional info such as compliance, versions, and install status.

Baseline Lifecycle Management

Managing Baselines Overview

You can manage your baselines from the Baselines list view. From here, you can edit and delete existing baselines. If you delete an industry-standard baseline that was pushed to devices, the device settings revert to before the baseline was published based on the snapshot stored by Workspace ONE UEM.

Assigned Device List View

You can see which baselines are applied to a device in the Device Details page on a per-device basis. You can also view the current baseline status on all assigned devices on the Devices page. Note, when you first publish the baseline, it will install but will be in Pending Reboot status. The end-user will also receive a toast notification stating, “Workspace ONE policies have been updated. Please restart your device to apply the updates”. Compliance info will update once the device is rebooted. For more information on compliance, refer to the Baseline Compliance section.

Baseline Lifecycle Workflow

Understanding the baseline lifecycle workflow is essential to answering questions such as:

  1. What happens when I assign multiple baselines to a single device?
  2. What happens when I edit or delete a baseline when I have multiple baselines assigned to the same device?
  3. How do I move from 1903 to 1909 baselines when my devices update from 1903 to 1909?
  4. What happens when a baseline is inherited from a top-level organization group, and a lower level baseline is created and assigned?

Refer to the below samples where each color represents a different baseline policy. They are all assigned to the same device. When a baseline is assigned to a device or a currently assigned baseline is updated or removed, then all baselines are removed and re-applied in order from the oldest created/modified to the newest created/modified. The last baseline (newest), which is applied, will overwrite any overlapping policies on the device. The two samples show how these baselines are applied along with the expected resultant baseline on the device. Keep in mind that adding multiple baselines to the same device will skew compliance reporting since the resultant baseline could possibly be a mix of various baselines.

Note: It is not recommended to have multiple baselines assigned to the same device.

Sample 1: 3 Baselines Assigned to a Device

In the below example, baseline A, B, and C have all been assigned to the same device. They are ordered by the age of the baseline, meaning the longest living or oldest modified baseline will be stacked at the bottom. When applied, the baseline at the top of the stack has the greatest precedence and will override any overlapping policies. In this example, all of B is overwritten by A, and the result contains policies from baselines A and C.  

Example 2: 3 Baselines Assigned to a Device

In the below example, baseline A, B, and C have all been assigned to the same device. Building off the above example, baseline B was recently modified and re-applied to the device. Using the same ordering and stacking method, B is list listed at the top of the stack. Notice now that the resulting applied policies contain policies from all baselines.

Applying New Baselines

The next question is, how do I move from one baseline to the next version of that baseline? Using the same ordering methods, the best method would be to create the next baseline and apply that baseline, then remove the older baseline you want to replace. This way, the device will always have a baseline assigned during the transition. Once again, if you want to match a Windows 10 version with a baseline version, it is recommended to assign the baseline to a Smart Group, which contains Windows 10 <version> or later.

Managing Baselines in a Multi-tenant Deployment

Before creating your baselines at the top-most or a lower-level organization group, let's explore what this looks like in the console. Overall, the same methods of applying baselines on devices apply with respect to ordering and precedence. Thus, if you create a top-level baseline and never modify it, all baselines will be stacked on top of this baseline, allowing admins below to modify any overlapping policies. Admins will only have visibility to baselines created at the same level or any child organization. The best way of seeing which baselines are applying to each device is from the device details view, then clicking on Baselines.

1. Parent Organization Group Admin View of Baselines

The parent-level admin has visibility and can edit, delete, and assign all baselines at the parent and children levels. Notice, the admin can see the Windows 10 1909 Security Baseline managed by the Child of Tech Zone group.

2. Child Organization Group Admin View of Baselines

The child-level admin has visibility and can edit, delete, and assign baselines at its child-level and below. Admins do not have visibility to baselines assigned from a parent organization group.

3. Device View of Assigned Baselines, Device lives in the Child of Tech Zone group

The device is managed at the Child of Tech Zone organization group, thus inherits the parent baselines as well as the baseline assigned at the child-level.

You can choose how you want to deliver baselines with respect to organization groups and admins at those groups. Each use-case is different, but understanding how baselines are applied and managed in a multi-tenant environment can help you plan accordingly.

Using Custom Baselines (LGPO)

If you have an existing Group Policy Object (GPO) backup file, you can create a custom baseline with those policies. You can add additional policies to your existing GPO when creating a custom baseline. Custom baselines should be used sparingly as you lose out on compliance reporting, and easily editing the custom baseline as you will have to manually make changes then re-upload the GPO backup. If you have some non-ADMX GPOs that you want to quickly push to devices, then you can leverage a custom baseline. Deploying LGPO.exe to your managed Windows devices is also a requirement to using custom baselines.

1. Steps to Deploying a Custom Baseline

  1. Leveraging LGPO.exe to capture a GPO backup, or leverage a previously generated GPO backup.
  2. Create a new baseline in Workspace ONE UEM, choose the Custom Baseline, then click Upload.
  3. Upload the GPO backup, then optionally select any additional policies.
  4. Assign the custom baseline. Note the baseline will only apply after LGPO.exe is detected on the device.  

Modernize Group Policies Using VMware Policy Builder

What is VMware Policy Builder?

Workspace ONE UEM delivers policies to devices through profiles. Many policies are available for direct configuration within the Workspace ONE UEM console.

If a policy is not available in the UI, you can use the Custom Settings profile. This profile allows you to upload XML to configure the Windows 10 Configuration Service Providers (CSPs) and publish its settings to devices. For more information on this topic, refer to the appendix section on Understanding Windows 10 Configuration Service Providers (CSPs) and Custom Settings Profiles.

The VMware Policy Builder tool is a VMware Fling that saves you time and effort creating the XML by:

  • Generating XML (SyncML) using the form-based UI
  • Configuring multiple CSPs
  • Dynamically generating SyncML
  • Filtering through options

The following video explains how VMware Policy Builder works in more detail:

Prerequisites

Before you can begin the exercises in this tutorial, you must meet the following prerequisites:

Logging In To VMware Policy Builder

2. Log In to VMware Policy Builder

Log into Policy Builder using My VMware credentials.

If you have a My VMware account do the following to log in.

  1. Enter the email address you use for My VMware account.
  2. Enter the password for your My VMware account.
  3. Click the Login button to log into the Policy Builder.

If you do not have a My VMware account, click on Sign up for an account to get started.

 

Reviewing VMware Policy Builder Features

Most of the steps in this exercise use the VMware Policy Builder. This section walks through the VMware Policy Builder's UI and its key features.  

Review CSPs in VMware Policy Builder
  1. Click CSPs to see the list of Configuration Service Providers (CSPs) the tool can configure.
  2. Select a CSP and click Configure to enter configuration parameters and automatically generate SyncML.
  3. Click Modify to open a page which allows you to paste in and modify existing SyncML.
  4. Click Generate GUID to create and copy a GUID  to the clipboard. Some CSP configurations require a GUID to be passed in. You can also use this for generating GUIDs which are needed when manually constructing custom settings profiles, for example, for application ADMX policies.
  5. From the drop-down menu, select the supported Windows 10 operating systems you want to use.  CSPs are unique and specific to the OS version you are targeting.  
  6. From the MDM Security Baselines drop-down menu, access install and remove settings required for deploying baselines. Use the tooltip for more information.
  7. Review the list of CSPs and associated Device Description Framework (DDF) files. DDF files contain the configuration details of a CSP in XML format.

Setting Application Defaults

In this section, use VMware Policy Builder to create and configure an application defaults custom profile for a Windows 10 device - something that is routinely done through traditional group policy management. Keep in mind this policy is only supported on Azure AD joined devices, for more information on this policy refer to Application Defaults policies.

1. Open Policy CSP Settings

Configure a custom policy.
  1. Type Policy in the filter box, to quickly find the Policy CSP.
  2. Select the Policy check-box.
  3. Click the Configure button to begin creating a custom policy.

2. Configure the Application Defaults Policy

Generate SyncML.
  1. Collapse User and expand Application Defaults.
  2. Enter the Application Defaults XML into the Default Associations Configuration field. You can obtain this XML by running the following command with elevated permissions on a Windows 10 command prompt with the desired associations configured: dism /online /export-defaultappassociations:appassoc.xml
  3. Select Replace. Using replace allows us to set these settings and re-push the custom profile if we need to make changes in the future.
  4. Click the Copy button to copy the SyncML.  
  5. Notice the SyncML is generated for you dynamically including the configuration data you entered. Policy Builder uses the following format when it detects XML <![CDATA[<xml_data>]]>. You may have noticed that the reference for the Application Defaults policy said that the XML needs to be base64 encoded then place between the <Data> tags. Both of these options are supported but the main point here is VMware Policy Builder is intelligent and knows how to support both options dynamically.

Note: Keep track of the copied SyncML, because its required to for the Workspace ONE UEM configuration.

Creating an Application Defaults Custom Settings Profile

In this section, create a Custom Settings profile for Windows 10 that contains the SyncML generated in the policy builder. Then, use Workspace ONE UEM to push the application defaults policy to an Azure AD Joined Windows 10 device, and verify the setting applied.  

2. Select Platform

Select the Windows icon.

Note: Make sure that you select Windows and not Windows Rugged.

3. Select Device Type

Select Windows Desktop.

4. Select Context

Select Device Profile.

5. Configure General Settings

  1. Enter Application Defaults as the Name.
  2. Under Smart Groups, select All Corporate Dedicated Devices.

6. Open Custom Settings

  1. Scroll down to the bottom on the left pane, and select Custom Settings.
  2. Click Configure.

7. Configure Custom Settings

Paste SyncML

Paste the SyncML you copied earlier into the textbox next to Install Settings, leave all other defaults.

8. Generate Delete SyncML

Generate and copy delete SyncML.

Back in VMware Policy Builder:

  1. Select Delete. Selecting Delete will remove the configured policy and is needed for the Removing Settings portion of the Custom Settings profile.
  2. Click Copy.

9. Remove Settings

Back in the Workspace ONE UEM console:

  1. Paste the SyncML you copied into the textbox next to Remove Settings, leave all other defaults.
  2. Click Save and Publish.

10. Confirm Device Assignment and Publish

  1. Verify the profile is assigned to the correct device.
  2. Click Publish to push the custom profile down to your Windows 10 device.

Updating an Existing Secure Assessment CSP

In this exercise, we will use VMware Policy Builder to update existing SyncML and update the Secure Assessment (test taking) settings.

1. Copy Existing SyncML

<Replace>
	<CmdID>7799f76f-68c4-45fd-a068-ec08e9df04ac</CmdID>
	<Item>
		<Target>
			<LocURI>./Vendor/MSFT/SecureAssessment/LaunchURI</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>https://techzone.vmware.com</Data>
	</Item>
</Replace>
<Replace>
	<CmdID>f7d12e74-cd43-4f9c-9c85-a99a7abffadd</CmdID>
	<Item>
		<Target>
			<LocURI>./Vendor/MSFT/SecureAssessment/TesterAccount</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>student</Data>
	</Item>
</Replace>
<Replace>
	<CmdID>1e71adb5-5cd5-4ae1-ab58-26dc1870e918</CmdID>
	<Item>
		<Target>
			<LocURI>./Vendor/MSFT/SecureAssessment/AllowScreenMonitoring</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">bool</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>True</Data>
	</Item>
</Replace>
<Replace>
	<CmdID>ea2fd9fb-bbf0-4e70-add4-6a919d2979de</CmdID>
	<Item>
		<Target>
			<LocURI>./Vendor/MSFT/SecureAssessment/RequirePrinting</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">bool</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>True</Data>
	</Item>
</Replace>
<Replace>
	<CmdID>7ae93f1d-d480-4265-8809-1c472776ea6b</CmdID>
	<Item>
		<Target>
			<LocURI>./Vendor/MSFT/SecureAssessment/AllowTextSuggestions</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">bool</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>True</Data>
	</Item>
</Replace>

Select all of the SyncML above. For existing custom settings profiles, you can select the radio button next to the profile, then click on the </XML> button. Only copy the XML from <Replace> to </Replace> being sure not to copy the <Atomic> tags.

2. Paste the SyncML

use VMware Policy Builder to update existing SyncML.
  1. Click the Modify button.
  2. Paste the copied SyncML into the SyncML pane.  Notice the SyncML dynamically updated. Update the Launch URL from https://techzone.vmware.com to https://bit.ly/2zk0QTP.
  3. Update Allow Screen Monitoring, Require Printing, and Allow Text Suggestions from On to Off.
  4. Click the Copy button to copy the SyncML. Notice how when you make updates via the UI on the left, that the SyncML is updated on the right.

Creating a New Secure Assessment Custom Settings Profile

Now that we have updated our Secure Assessment SyncML, you will either be updating the SyncML in the existing custom settings profile or creating a new secure assessment custom settings profile. In this example, we will be creating a new secure assessment custom settings profile.

2. Select Platform

Select the Windows icon.

Note: Make sure that you select Windows and not Windows Rugged.

3. Select Device Type

Select Windows Desktop.

4. Select Context

Select Device Profile.

5. Define the General Settings

  1. Enter a profile name, such as Secure Assessment in the Name text box.
  2. Scroll down to Smart Groups, click the field, and select All Corporate Dedicated Devices from the list that populates.

Note: Do not click Save & Publish at this point. This interface allows you to move around to different payload configuration screens before saving.

6. Open Custom Settings

  1. Scroll down to the bottom on the left pane, and select Custom Settings.
  2. Click Configure.

7. Configure Custom Settings

Paste the SyncML you copied earlier into the textbox next to Install Settings, leave all other defaults.

8. Generate Delete SyncML

Back in VMware Policy Builder:

  1. Select Delete for Launch URI and Tester Account. Selecting Delete will remove the configured policy and is needed for the Removing Settings portion of the Custom Settings profile.
  2. Click Copy.

9. Remove Settings

Back in the Workspace ONE UEM console:

  1. Paste the SyncML you copied into the textbox next to Remove Settings, leave all other defaults.
  2. Click Save and Publish.

10. Confirm Device Assignment and Publish

  1. Verify the profile is assigned to the correct device.
  2. Click Publish to push the custom profile down to your Windows 10 device.

Configuring Custom Settings to Use Pre-released Configuration Service Providers (CSPs)

The Custom Settings payload provides a way to use newly released Windows functionality in Workspace ONE UEM. When you want to use the new features supported on Windows Insider builds, you can use the Custom Settings payload and SyncML (XML) code to enable or disable certain settings manually.

Requirements

You must generate SyncML code to leverage the Custom Settings payload using one of the following methods:

Microsoft publishes a Configuration Service Provider (CSP) reference site available on their web site. https://aka.ms/CSPList

The custom settings profile appends the appropriate SyncML atomic tags to the beginning and the end of the code. You must generate the appropriate code between any <Add>, <Replace>, <Delete>, or <Exec> tags.

Optionally, you can also condense the size of the code by removing all whitespace, and linearizing the SyncML code.

SyncML without Atomic Tags Sample

The following text is an example of SyncML without atomic tags.

<Replace>
	<CmdID>1f67a1bf-2d83-497f-ab4f-dc94a1c17449</CmdID>
	<Item>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Reboot/Schedule/DailyRecurrent</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>2020-04-21T08:30:00</Data>
	</Item>
</Replace>

Making Updates/Deleting Custom Settings Profiles

Workspace ONE UEM automatically uses built-in logic for fully integrated payloads. For instance, when removing a profile, Workspace ONE UEM sends a delete action to remove the profile payload’s configurations.

In contrast, when using Custom Settings, you must use the delete tag to remove settings. However, do not include the data tags - only the LocURI is needed.

To update custom settings, use the replace tag.

Remove Scheduled Daily Reboots Sample  

<Delete>
	<CmdID>1f67a1bf-2d83-497f-ab4f-dc94a1c17449</CmdID>
	<Item>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Reboot/Schedule/DailyRecurrent</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data/>
	</Item>
</Delete>

Using Samples from VMware Sample Exchange

Workspace ONE UEM provides a seamless experience when using custom settings for Windows 10 devices. You can find fully tested and validated samples at the VMware Code Sample Exchange. Pay attention to the support Windows 10 Edition as some samples apply only to Surface Hub devices (Team) or require Enterprise or Education editions. For more information and to access the samples, see VMware Sample Exchange.

Using Existing Profiles to Create Custom Settings

Many organizations who deploy on-premises or dedicated SaaS environments may not be able to use the latest feature updates to keep up with Windows 10 releases. You can use your user acceptance testing (UAT) environment to create the profile and then export the generated SyncML, and paste it into your production environment. This allows you to take advantages of newly released capabilities between the time it is released and your production environment is upgraded to support these features.

1. Create a Windows Profile

Create a Windows profile from the Workspace ONE UEM Console using existing payloads. For new features, copy SyncML from your UAT environment, then paste the SyncML into a custom settings profile in your production environment.

Before you begin, make sure the Windows 10 version and edition are supported. Additionally, you must verify there are no Workspace ONE Intelligent Hub dependencies.

Important: Only use this procedure to test new CSP capabilities before deciding to upgrade your environment to the latest version.

2. Edit the Profile

  1. Select the radio button next to your new profile.
  2. Click </>XML.

Migrate Group Policies Using Workspace ONE AirLift

Exporting Group Policies Using AirLift

Many device management profiles available in Workspace ONE UEM (such as BitLocker, Personalization, Windows Updates, etc) may overlap with your existing group policies.

Before you begin exporting group policies using AirLift, take steps to prevent overlapping policies. Review your existing group policies, and identify those that can be converted into a device management profile in Workspace ONE.

Once you've narrowed your list, you're ready to begin migrating the remaining group policies using AirLift. To learn more about this migration, see the Workspace ONE AirLift operational tutorial.

Updating Exported Group Policies in Workspace ONE UEM

For exported group policies, Workspace ONE AirLift creates a custom settings profile in Workspace ONE UEM. To update these policies, you can manually modify them in the custom settings profile.

To make updates more visual, use VMware Policy Builder to modify existing custom settings profiles. Copy the entire Install Settings text and paste it into VMware Policy Builder. Policy Builder then dynamically builds out the UI, allowing you to make the updates. Then, it copies and pastes the text back into the Workspace ONE UEM Custom Settings profile's install settings.

Migrate Application (3rd Party) AMDX Policies

Using Workspace ONE AirLift to Migrate Application (3rd Party) ADMX Policies

You can leverage Workspace ONE AirLift to quickly migrate application AMDX policies from your domain to Workspace ONE UEM. These policies are imported into Workspace ONE UEM as Custom Settings profiles. This section explores how to move some sample Chrome policies from the domain over to Workspace ONE UEM.

1. Meet Prerequisites

Before you begin, make sure Workspace ONE AirLift is fully installed and configured. For more information refer to Getting Started with Workspace ONE AirLift.

2. Getting Started with AirLift

Launch AirLift and authenticate using your admin account. On the Get Started with AirLift screen, click Plan.

Alternatively, if you have hidden the Getting Started page, click Policies.

3. Exporting Chrome ADMX Policies

For this example, we connected to a domain which applied Google Chrome ADMX policies to devices and will migrate these Chrome ADMX policies to Workspace ONE UEM. To see if you are currently applying any ADMX policies, you can search for Administrative Templates in your list.

  1. Search or click on Google Chrome under GPO Name.
  2. Select some or all Chrome policies using the checkboxes.
  3. Click Add to Export.
  4. Click on Ready to Export.

4. Review ADMX Policy Details

You can click on the policy for more information about that policy and its configured values. This view will also show you the exportable versions. You can also generate a report of all of the policies. In this example, you can see the Enable saving passwords to the password manager is Disabled.

5. Export ADMX Policies

Again, select all policies then click Export All. You can take a look at the domain's current policy assignments in the Organizational Units column. You can you this to help you decide who to map these policies to in the Workspace ONE UEM console.

6. Export ADMX Policies to Workspace ONE UEM

Now you can export the Chrome policies to the Workspace ONE UEM console.

  1. Type Chrome Policies for Profile Name.
  2. Select your Workspace ONE Organization Group, in this example this will be the Digital Workspace Tech Zone group.
  3. Select the Profile Context. Device context will apply the policies to all users on the device, while User context will only apply the policies to the enrolled user.
  4. Click Export.

7. Review the Chrome Policies Profile

Once the policies are exported you will see a list of the policies. Click Chrome Policies under Status to take you to the generated custom profile in Workspace ONE UEM.

Managing the 3rd Party ADMX Policy Lifecycle

It's important to understand how 3rd party ADMX policies work on the back end, as well as how to update these policies in the future. To install an ADMX policy on managed devices, Workspace ONE AirLift exports the ADMX ingestion CSP into a Workspace ONE UEM custom settings profile. The policy configurations are also included in the same custom settings profile.

For more information on custom settings profiles refer to Understanding Windows 10 Configuration Service Providers (CSPs) and Custom Settings Profiles. For more information on how ADMX files are ingested and policies are set in Workspace ONE UEM, refer to Manually Handling 3rd Party ADMX Policies.

1. Open the AirLift Generated Policy in Workspace ONE UEM

In the Workspace ONE UEM console, assign the newly created profile to managed Windows 10 devices. By default, the profile is set to auto deploy, and has a description of "Profile created by AirLift."

Open the AirLift Generated ADMX Policy in Workspace ONE UEM

Click on the name of your profile, for example, Chrome Policies.

2. Open the Custom Settings Profile

  1. Scroll down to Custom Settings.
  2. Click Custom Settings.
  3. Click Add Version.

3. Update the ADMX Ingestion to use Replace Action

To make policy modifications to the custom settings profile created by AirLift, you must update both <Add> and </Add> commands to <Replace> and </Replace>.

Using the replace command allows you to make updates to the profile with out having to change the LocURI for each policy node. To do this, copy the Install Settings. Then, use a text editor to find the Add commands to replace. Finally, paste the entire block of text back.

Note: The replace command is not supported for all Windows 10 versions. If you run into issues, you may have to keep the Add command. For more details on the supported Windows 10 versions please refer to the Win32 app policy configuration article.

  1. Update the <Add> and </Add> commands to use Replace as shown below. To simplify viewing the changes the contents in between the Data tags have been removed. Do not make any changes to any of the content in between the Data tags.
  2. Click Save and Publish.

4. Updating Policy Configurations

Now let’s discuss making updates to policies from your ADMX template (Custom Settings profile). The top part of the Install Settings is ingesting the ADMX template, then you will see Replace commands for each policy. Each policy will have a matching Delete action in the Remove Settings section. To make updates simply search for the policy name you want to edit, then edit the values, and re-push the profile.

It is best to make edits in your text editor of choice, then copy the entire block of text, also called SyncML back to the profile when you are done making your updates. In this example, we want to update Chrome’s Spell Check settings. We can see that this policy is enabled and is enabling spell check for en-US (U.S. English language). From here you can disable the policy or update the language to something different or add more languages. You can reference ADMX file for more details on the format. For more information on making edits to ADMX settings, refer to the Manually Handling 3rd Party AMDX policies.

Manually Handling Application 3rd Party ADMX Policies

Workspace ONE AirLift can be used to move application ADMX policies from your domain to Workspace ONE UEM as a custom profile. This section explores how to ingest ADMX templates and configure application policies using Workspace ONE instead of AirLift.

For more information, see the appendix section on Understanding Windows 10 Configuration Service Providers (CSPs) and Custom Settings Profiles.

1. ADMX Ingestion using Custom Settings Profile

  1. Download the .ADMX and .ADML files from the application's website. This example uses Google Chrome’s .ADMX and .ADML files which can be download here. The bundle will contain both the MSI installer and the ADM/ADMX files.
  2. Ingest the ADMX template to the device. This installs the ADMX template onto the device so that it will understand the application (3rd party) policies.

The following code block is a template for ingesting ADMX files using a Custom Settings Profile. Update appname and filename and paste your ADMX file contents starting with <policyDefinitions> and ending with </policyDefinitions>.

<Replace>

<CmdID>Insert GUID</CmdID>

<Item>

<Meta>

<Format>chr</Format>

<Type>text/plain</Type>

</Meta>

<Target>

<LocURI>./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/appname/Policy/filename.admx</LocURI>

</Target>

<Data>

<![CDATA[ copy of the downloaded ADMX start with <policyDefinitions>…..</policyDefinitions>]]>

</Data>

</Item>

</Replace>

3.     The following code block shows a sample of Chrome.admx Ingestion using Custom Profile. You can also refer to the Chrome ADMX sample hosted on VMware {code} sample exchange.

<Replace>
	<CmdID>Insert GUID</CmdID>
	<Item>
		<Meta>
			<Format>chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/Chrome.admx</LocURI>
		</Target>
		<Data>
			<![CDATA[ copy of the downloaded Chrome.admx start with <policyDefinitions>…..</policyDefinitions>]]>
		</Data>
	</Item>
</Replace>

Note: Using the Replace command will allow you to ingest and set policy configurations in the same custom settings profile. Using the Replace command is not always supported. If you run into issues you will have to use the Add command. For more details on the supported Windows 10 versions please refer to the Win32 app policy configuration article.

Important: Certain registry keys are NOT allowed to be overwritten, so you must modify the registry keys in the downloaded .ADMX file in order for it to be ingested to the device. For more details on which keys are not allowed to be modified refer to the Win32 app policy configuration article. Camille Debay wrote an ADMX validation PowerShell script that automatically checks if any of the forbidden keys are used. Download the script from VMware {code} or directly on GitHub.

2. Configure ADMX Policies

  1. Configure the ADMX Values Template
<Replace>
	<CmdID>Insert GUID</CmdID>
	<Item>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Policy/Config/appname~Policy~Full Policy Category Path/policyname</LocURI>
		</Target>
		<Data>
			<![CDATA[<…../>]]>
		</Data>
	</Item>
</Replace>

2.     Construct the LocURI for Each Policy. Let's explore how to construct    the needed appname~Policy~Full Policy Category Path parameters.

  • Appname is the appname set in the ingest code:

<LocURI>./Device./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/appname/Policy/filename.admx</LocURI>

  • Full Policy Category Path:  start with parent category of the policy defined in the ADMX file policy definition section <parentCategory ref="…." />, then find the full category in the category definition. Concatenate each category with ~

For example:

  • LocURI for ingest Chrome.admx:

<LocURI>./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/Chrome.admx</LocURI>

  • LocURI to disable Password Manager:

<LocURI>./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~PasswordManager/PasswordManagerEnabled</LocURI>

Set the settings using the guidance in the SyncML syntax for ADMX-Backed policies section or using the samples for each data type in Understanding ADMX-backed policies.

Managing Baselines and Group Policies

Overview

This section provides you with the information needed to:

  • Validate policies on the Windows 10 devices.
  • Ensure devices comply with assigned baselines.
  • Enable group policy enforcement.

Validating Configured Policies

Using Microsoft Security Compliance Toolkit

You can use Policy Analyzer which is part of the Microsoft Security Compliance Toolkit to generate reports of the local policies applied to a device, or to compare local policies to various baselines for validation or even compare various baselines to each other.

  1. Download Policy Analyzer from the Microsoft Security Compliance Toolkit. You can choose to also download Windows 10 Security Baselines files. These can be used later to compare these policies to the local policies on the device.
  2. Extract the PolicyAnalyzer.zip file, then launch PolicyAnalyzer.exe. Note for more information, refer to the Policy Analyzer PDF in the same directory.
  3. You can move any .PolicyRules files for a baseline into the Policy Rule sets in directory to have it appear as an option in Policy Analyzer. If you select to capture the Local policy Policy Analyzer will save a Policy Rule file, I would recommend renaming this file to provide you with some clarity.
  4. It is recommended to capture the Local Policy before applying baselines from Workspace ONE then again after. You can compare (click View/Compare) both the before and after to the targeted baseline to see the differences.  Once in the comparison window, navigate to View, then select Show only Conflicts.

Policy Analyzer is extremely useful for troubleshooting and for fully understanding what policies are being applied to the device. Once you feel comfortable with the policies and how they are applied to the device, you can move to using the built in Workspace ONE Baselines compliance capabilities.

The following image shows a sample comparison using Policy Analyzer of a Windows 10 1909 device local policies to the Windows 10 Version 1909 Security Baseline.

Using Policy Analyzer, part of the Microsoft Security Compliance Toolkit

Leveraging MDM Diagnostic Information

There are two ways to generate a report which shows the applied configuration service provider policies on the device. You can use the Windows 10 settings GUI or leverage command prompt to programmatically generate the report.

Option 1: Export your Management Log Files

Pull the MDM diagnostic report from your Windows device.

Open the Windows 10 settings menu, then navigate to Accounts.

  1. Click Access work or school.
  2. Click Export your management log files.
  3. Click Export.

Option 2: Use Command Prompts

Alternatively, from the command prompt on a managed Windows 10 device, run the following command to see all of the configured modern policies, blocked group policies, and unmanaged policies. This command validates what is configured on the device and is a great troubleshooting resource, as well.

%SYSTEMROOT%\System32\MDMDiagnosticsTool.exe -out <Output Folder Path>

Review the MDM Diagnostic Report

Both of the above options will generate the following report which contains detailed information (when expanded) about the device and it's configured policies. You can also use the Blocked Group Policies section to help visualize policy collisions between Workspace ONE UEM and group policies.

MDM Diagnostic Report Sample

Enforcing Configured Group Policies

Enabling Local Enforcement of Baselines

There are multiple ways to enable local enforcement of baselines. To execute a script that adds the reapply registry key on a device, you can use:

  • Sensors
  • Product Provisioning
  • Script in Apps & Books
  • Custom Settings Profile (shown below).

Enforcing Configured Group Policies Using a Custom Settings Profile

This is a current workaround which needs to be complete to enable enforcement of baselines on Windows 10 devices. However, there are plans to enhance the product to not require this step.

Install Settings

<wap-provisioningdoc id="fd699da0-d511-4a60-b0aa-4c3e841c937e" name="customprofile">/
	<characteristic type="com.airwatch.winrt.registryoperation" uuid="5a173f8a-2b03-4593-a846-5efc3eb9dce9">
		<parm RegistryPath="HKLM\SOFTWARE\AIRWATCH\ReapplyBaseline" Action="Replace">
			<Value Name="Interval" Data="12" Type="DWORD" />
		</parm>
	</characteristic>
</wap-provisioningdoc>

Remove Settings

<wap-provisioningdoc id="45d1450f-944e-46d3-8c3f-b333f93b1e7b" name="customprofile">/
	<characteristic type="com.airwatch.winrt.registryoperation" uuid="c631d6ae-2ac1-46f6-a4a0-aeae9915c5cf">
		<parm RegistryPath="HKLM\SOFTWARE\AIRWATCH\ReapplyBaseline" Action="Remove">
			<Value Name="Interval" Data="12" Type="DWORD" />
		</parm>
	</characteristic>
</wap-provisioningdoc>

The following screenshot shows what the device should look like after enabling the reapply baselines registry key.

This is what the Windows 10 what the device should look like after enabling the reapply baselines registry key.
Registry Item Value
Path Computer\HKEY_LOCAL_MACHINE\SOFTWARE\AIRWATCH\ReapplyBaseline
Name Interval
Type REG_DWORD
Data 0 - disabled; Decimal value for reapply interval in hours

Using Policy Enforcer (Fling)

Policy Enforcer is used to check and remediate restriction policies on a Workspace ONE managed Windows 10 devices. If a user attempts to override a configured Policy CSP (not a baseline) setting by editing the Windows Registry, Policy Enforcer will compare the current value with the MDM configured value and reset the registry if the values differ. This is helpful if using Workspace ONE AirLift for the policies which are part of the Policy CSP. To get started download the Policy Enforcer on the VMware Fling website.

Reviewing Baseline Compliance

Workspace ONE UEM 1910 introduced the ability to track endpoint compliance and monitor drift from the console. Thus removing the need for 3rd-party tools to check compliance.

1. View the Baseline Summary Tab

 
  1. In the Workspace ONE UEM console, navigate to Devices > Profiles & Resources > Baselines.
  2. Review the Compliance Status section. This view allows you to monitor and respond based on the level of compliance required by your InfoSec teams:
    • Compliant = 100% compliance
    • Intermediate Compliance = 99-85% compliance (for customers adhering to the Windows 10 Security Baseline or CIS Microsoft Windows Desktop Benchmarks)
    • Non-Compliant = Less than 85% compliance
    • Not Available = The Workspace ONE UEM console does not have a compliance sample for the device. You can force a sample by simply opening the baseline and publishing it again.

Note: Baseline compliance status only applies to baselines created using the UI. You cannot see the compliance status for custom baselines created using ZIP packages, unless you add additional policies from the add policies screen.

2. View the Baseline Devices Tab

Click the Devices tab for baselines to view individual devie compliance.
  1. Click the Devices tab to view all of your devices along with details about their installation status and compliance.
  2. Click on the device’s Friendly Name to go to the Device Details page and view all the baselines and profiles assigned to the device.
  3. Click on the Compliance status link to bring up details about the device's policy set, and to identify which group policies are causing compliance issues.

3. Filter a Device's Compliance Status Details

The Compliance view gives you a list of all of the policies set on the device from the assigned baseline. From here, you can use the filter to find non-compliant policies.  

Review group policy compliance for a specific Windows 10 device.
  1. Expand the Status menu.
  2. Click Non-Compliant.

4. Review the Device's Non-Compliant Group Policies

This view gives you a clear picture of the non-compliant group policies on the Windows 10 device.

 gives you a clear picture of the non-compliant group policies on the Windows 10 device.

Summary and Additional Resources

Summary

This tutorial provided the steps and methodology for modernizing or migrating policies to the cloud using Workspace ONE Baselines and Workspace ONE AirLift, along with various other tools. Keep in mind that every use-case is different, and the methodology discussed in this tutorial should serve as high-level guidelines. Just as Windows 10 is ever involving, so is our product. The product is continuously evolving to align with our vision of providing consumer simple, yet enterprise secure cloud-based policy management, validation, and enforcement using the VMware Workspace ONE platform.

Changelog

 

 

About the Authors and Contributors

This tutorial was written by:

  • Josué Negrón, EUC Staff Architect, End-User-Computing Technical Marketing, VMware

Appreciation and acknowledgment for considerable contributions from the following subject matter experts:

  • Mike Nelson, Sr. Solutions Architect, End-User-Computing R&D, VMware
  • Fiona (Yongli) Xie, Sr. Consultant, Professional Services, VMware
  • Brooks Peppin, Sr. Solutions Architect, End-User-Computing R&D, VMware
  • Adarsh Kesari, Staff Solutions Architect, End-User-Computing R&D, VMware

This tutorial was also reviewed by the following subject matter experts:

  • Anjali Sinha, Member of Technical Staff, End-User-Computing R&D, VMware
  • Camille Debay, Staff Customer Success Architect, Customer Success, VMware
  • Vandana Soundera Raj, Sr. Product Manager, End-User-Computing R&D, VMware
  • Lisa Matragrano, Sr. Product Marketing Manager, End-User-Computing Mobile Marketing, VMware
  • Grischa Ernst, EUC Staff Customer Success Architect, Customer Success, VMware
  • Scot Curry, Sr. Staff Solutions Engineer, End-User-Computing SE, VMware
  • Darren Weatherly, Sr. Technical Marketing Architect, End-User-Computing Technical Marketing, VMware
  • Chris Tillier, Sr. Solutions Architect, End-User-Computing R&D, VMware

Feedback

Your feedback is valuable. 

To comment on this tutorial, contact VMware End-User-Computing Technical Marketing at euc_tech_content_feedback@vmware.com.

Appendix

Understanding Windows 10 Configuration Service Providers (CSPs) and Custom Settings Profiles

1. Getting to the Custom Settings Profile Option

  1. Login to Workspace ONE UEM console.
  2. Navigate to Devices->Profiles & Resources->Profiles, then click on Add->Add Profiles.
  3. Select Windows, then Windows Desktop, and Device Profile.
  4. Input general information for the custom profile.
  5. Click Custom Settings, then Configure.

2. OMA-DM Client versus WAP-Provisioning

Management clients communicate to Workspace ONE UEM on behalf of the device. There are two primary management clients:

  • OMA-DM (Open Mobile Alliance Device Management)
  • Workspace ONE Intelligent Hub

The clients serve their own, distinct purposes, and rely on different services to establish real-time communication with Workspace ONE UEM. The Workspace ONE Intelligent Hub leverages wap-provisioning, while the OMA-DM client uses the OMA-DM protocol. The OMA-DM client is built into the Windows OS and owns the MDM relationship.

For more information, refer to Understanding the Workspace ONE UEM Solution Stack in the Troubleshooting Windows 10 Tutorial.

2.1. WAP-Provisioning Examples

The following have not historically been very well documented. A few examples are provided to explain how to use some of the wap-provisioning capabilities. Keep in mind, the Workspace ONE Intelligent Hub is required when leveraging wap-provisioning capabilities.

2.1.1. Create, Modify, or Delete Registry Keys

There are many ways of setting registry keys via Workspace ONE UEM, but one method you are likely not aware of is using a custom profile. This can be useful for quickly adding, editing or removing a registry key. You can use one profile to add or modify multiple key value pairs. For more details refer to How to Set Registry values using the Custom Settings Profile in Workspace ONE UEM.

2.1.1.1. Example 1: Registry Operation Template
<wap-provisioningdoc id="Insert GUID" name="customprofile">/
	<characteristic type="com.airwatch.winrt.registryoperation" uuid="Insert GUID">
		<parm RegistryPath="HKLM or HKCU with full path" Action="Replace/Remove">
			<Value Name="Registry Name" Data="Registry Data" Type="String/Binary/DWORD/QWORD/MultiString/ExpandString" />
		</parm>
	</characteristic>
</wap-provisioningdoc>
2.1.1.2. Example 2: Generate a Chrome Browser Cloud Management (CBCM) Enrollment Token

For more information, please refer to Enroll browsers with VMware Workspace ONE (Windows and macOS).

<wap-provisioningdoc id="Insert GUID" name="customprofile">/
	<characteristic type="com.airwatch.winrt.registryoperation" uuid="Insert GUID">
		<parm RegistryPath="HKLM\SOFTWARE\Policies\Google\Chrome" Action="Replace">
			<Value Name="CloudManagementEnrollmentToken" Data="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" Type="String" />
			<Value Name="CloudManagementEnrollmentMandatory" Data="1" Type="DWORD" />
		</parm>
	</characteristic>
</wap-provisioningdoc>
2.1.1.3. Example 3: Remove the Chrome Browser Cloud Management (CDCM) Enrollment Token
<wap-provisioningdoc id="Insert GUID" name="customprofile">/
	<characteristic type="com.airwatch.winrt.registryoperation" uuid="Insert GUID">
		<parm RegistryPath="HKLM\SOFTWARE\Policies\Google\Chrome" Action="Remove">
			<Value Name="CloudManagementEnrollmentToken" Data="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" Type="String" />
			<Value Name="CloudManagementEnrollmentMandatory" Data="1" Type="DWORD" />
		</parm>
	</characteristic>
</wap-provisioningdoc>

2.1.2. Executing PowerShell Commands

The examples below are for the install settings, you can choose what to use for remove settings. You can use an empty command or revert settings. This is not the only way to execute PowerShell commands/scripts within Workspace ONE, refer to How to Deploy PowerShell Scripts to see two other methods. If you want to deploy more complex scripts as opposed to just a simple command using this method, check out the PowerShell profile blog post.

2.1.2.1. Example 1: Create Firewall Rule
<wap-provisioningdoc id="Insert GUID" name="customprofile">
	<characteristic type="com.airwatch.winrt.powershellcommand" uuid="Insert GUID">
		<parm name="PowershellCommand" value="New-NetFirewallRule -DisplayName 'Block WINS' -Direction Inbound -Action Block -RemoteAddress WINS"/>
	</characteristic> 
</wap-provisioningdoc>
2.1.2.2. Example 2: Removing ConfigMgr Client
 <wap-provisioningdoc id="Insert GUID" name="customprofile">
	<characteristic type="com.airwatch.winrt.powershellcommand" uuid="Insert GUID">
		<parm name="PowershellCommand" value="Invoke-Command -ScriptBlock {C:\windows\ccmsetup\ccmsetup.exe /uninstall}"/>
	</characteristic> 
</wap-provisioningdoc>

2.1.3. Modifying Profiles

This is not recommended but could be used in a case where you want to exclude one of the mandatory settings being pushed. Keep in mind, if you choose this option, you will lose out on using the dedicated UI for the profile, thus lifecycle management will require additional effort.

3. Standard Syntax for OMA-DM Protocol (SyncML)

Note that when using Workspace ONE UEM custom settings profiles, the Atomic node is not required as this is auto populated for you thus is not shown below. For more information refer to, OMA-DM protocol common elements.

<command>
	<CmdID>unique number in the profile</CmdID>
	<Item>
		<Meta>
			<Format>int or chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Target>
			<LocURI>./Policy Scope/Vendor/MSFT/Policy/Config/policy sub-categories</LocURI>
		</Target>
		<Data>settings</Data>
	</Item>
</command>
OMA-DM Elements Description
Command (Cmd)

Supported values for the Custom Settings profile are: 

  • Add – adds the CSP policy to the device. This performs an implicit add, only use Add when the policy requires an Add, otherwise use a Replace command.
  • Replace – overwrites or adds any data from the CSP policy to the device. 
  • Delete – removes the CSP policy from the device. 
  • Exec – performs an action from the CSP policy on the device, such as reboot. 
For more information refer to, DM protocol commands.
Unique number in the profile (CmdID) Unique number to identify each command in the profile. You can use 1, 2, 3… for example for each new command within a custom profile. The CmdID must be unique for each command in the same profile, however do not have to be unique across profiles. It is recommended to use a GUID value. 
Int or Chr (format) Either integer (int) or character (chr). Based on the values specified (data) in the CSP policy. 
./Policy Scope/ (LocURI)

Either ./Device/ if policies are applied to the device, or ./User/ if policies are applied only under user’s profile.

For more information refer to, user targeted versus device targeted configurations.
Policy sub-categories (LocURI) Policy path defined from the Configuration Service Provider Reference site or in the ADMX file.
Settings (data) A valid value defined from the CSP or in the ADMX file.

4. Supported Types of OMA-DM Policies

  1. Standard Microsoft CSP: Built-in to the Windows 10 OS, varies based on Windows 10 version and edition. Data can be integer (int) or string (chr). You can quickly build these profiles using VMware Policy Builder or refer below for the manual steps.
  2. Inbox ADMX-Backed policies: The OS group policies which are included and located in the C:\Windows\PolicyDefinitions folder. Format is always chr. And settings requires encoded XML or using <![CDATA[…..]]>. For more information refer to, Understanding AMDX-backed policies. You can quickly build these profiles using VMware Policy Builder or refer below for the manual steps.
  3. Application or 3rd Party ADMX policies: These are 3rd party application settings which are defined in the ADMX. The ADMX will need to be downloaded and ingested into devices. Format is always chr. Settings require encoded XML or using <![CDATA[…..]]>. You can leverage Workspace ONE AirLift to handle 3rd party ADMX policies or can manually handle 3rd party ADMX Policies.

5. Creating Custom Profiles for Standard Microsoft CSP

  1. Find reference to Microsoft supported CSP using this link https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider or this short-link https://aka.ms/csplist.
  2. Search for the desired CSP setting, ensure it’s supported for your device type, edition, and version. Click on the CSP to obtain more information.
  3. Replace the highlighted code in yellow with information provided from the reference.
<command>
	<CmdID>unique number in the profile</CmdID>
	<Item>
		<Meta>
			<Format>int or chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Target>
			<LocURI>./Policy Scope/Vendor/MSFT/Policy/Config/policy sub-categories</LocURI>
		</Target>
		<Data>settings</Data>
	</Item>
</command>

5.1. Example 1: Setup a policy to NOT show the information for the last user who logged on

<Replace>
	<CmdID>4986697b-474e-4c1c-a7fa-4026113788e3</CmdID>
	<Item>
		<Meta>
			<Format>int</Format>
			<Type>text/plain</Type>
		</Meta>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Policy/Config/ LocalPoliciesSecurityOptions/InteractiveLogon_DoNotDisplayLastSignedIn</LocURI>
		</Target>
		<Data>1</Data>
	</Item>
</Replace>

5.2. Example 2: Setup a policy to display messages when user attempt to logon

<Replace>
	<CmdID>90c1dda3-bcd6-4344-aa96-3bc15f07253a</CmdID>
	<Item>
		<Meta>
			<Format>chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Policy/Config/ LocalPoliciesSecurityOptions/InteractiveLogon_MessageTextForUsersAttempting</LocURI>
		</Target>
		<Data>This machine is for restricted user only</Data>
	</Item>
</Replace>

6. Creating Custom Profiles for Inbox ADMX-backed Policies

You should be using VMware Policy Builder however we will discuss what all is done on the back-end to properly understand what is happening.

These inbox ADMX policies are processed into MDM policies during the OS-Build time and located in %SystemRoot%\policydefinitions. Only the ones listed in the reference link below are supported.

  1. Find the specific policy in the Microsoft CSP reference link or using the short-link http://aka.ms/CSPList. For this example, lets look at setting the Homepage for the Edge browser. To configure the Edge browser, we will be using the Policy CSP, and focused in on Browser/Homepages. From here we can see the supported Windows 10 editions, the allowed Scopes (user/device) and a description of what this settings does and most importantly the ADMX Info which contains the GP Name (HomePages) and the supported and expected values.
  2. Make a note of the GP name in the reference. In this example the GP name is HomePages.
  3. Copy the .ADMX file to a temporary location and open in Notepad++ or your preferred text editor.
  4. Find the policy definition in .ADMX file using GP name. The policy definition provides information of the registry key path for the setting, supported platform, and if the policy has parameters or just simply enable or disable.
  5. Follow the SyncML syntax to modify the below example for your use-case:

6.1. Example 1: Policy to Set Edge's Homepages

<Replace>
	<CmdID>d1a2daaa-9388-412c-be94-ef8e4310712b</CmdID>
	<Item>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Policy/Config/Browser/HomePages</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">chr</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>
			<![CDATA[<techzone.vmware.com>,<login.vmware.com>]]>
		</Data>
	</Item>
</Replace>

6.2. Example 2: Disable the Use of Password Manager in Edge

<Replace>
	<CmdID>6b2f77cb-3169-4934-b3fa-58994f7e50fc</CmdID>
	<Item>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Policy/Config/Browser/AllowPasswordManager</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">int</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>0</Data>
	</Item>
</Replace>

Group Policy (GPO) & MDM Policy (CSPs) Processing & Precedence

Throughout the tutorial, various policy options were introduced and it quickly becomes apparent that having multiple mechanisms for setting/modifying the device's policies gets complex. We explored the overall best practices and methodology for modernizing and migrating policies. It is recommended to limit the overlap of technologies being used per device: for example, do not attempt to use AirLift's migration of policies to custom settings policies, baselines, and existing GPOs all applied to the same device. When you leverage a new mechanism its best practice to disable/un-assign the other method. However, we understand there will be use-cases where this is not possible; most notably when working across teams: Workspace ONE UEM admin versus Domain GPO admin. The following section attempts to explain the processing order of policies and which policy types take precedence over others.

1. GPO Processing and Precedence

group policy objects GPOs LGPO

First, let's understand the processing and precedence for group policy objects. Overall the last write/applied takes precedence and overwrites existing policies. Therefore, it is vital to understand the processing order for GPOs. Referring to the image you can see that local GPOs are processed first, therefore it also has the lowest precedence.

For more details on this topic refer to Group Policy Processing and Precedence and Group Policy Hierarchy.

2. Default Order of Precedence for GPOs and MDM Policies

The default when applying both GPOs and MDM policies on a device is that GPO policies win, or supersede, MDM policies. Therefore, by default GPOs have a higher precedence than MDM policies on the device. To more clearly define MDM policies, these are policies based on the Microsoft Configuration Service Providers (CSPs). Refer to Policy CSPs supported by Group Policy for more details regarding conflicts.

It is also important to note that throughout the tutorial we discuss leveraging Workspace ONE Baselines and AirLift to apply policies on the device. Baselines are based on GPOs and depending on the policy can be applied on the device using DEM, SecEdit, AuditPol, or LGPO (only custom baselines). Meanwhile, AirLift converts policies to CSPs and creates custom settings profiles in the Workspace ONE UEM console.

2.1. Enabling the Control Policy Conflict to Allow MDM to Win

There is a way to force MDM policies to win, or supersede, GPO policies. In this case, MDM policies would have a higher precedence than GPO policies on the device. Their is a CSP which can be deployed to managed devices which enable this behavior. You can leverage the Control Policy Conflict part of the Policy CSP which sets the MDM Wins Over GP policy to ensure MDM (Policy CSPs supported by Group Policy) policies wins over group policies.

Additionally, you can validate policy conflicts by Validating Configured Policies and using the MDM Diagnostics Tool to generate a report to see MDM versus GPO policy conflicts and which policy has precedence on the device.

Install Settings

<Replace>
	<CmdID>c28cc6ca-982c-4490-955a-93ef2fb00936</CmdID>
	<Item>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">int</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data>1</Data>
	</Item>
</Replace>

Remove Settings

<Delete>
	<CmdID>9ae93437-7c43-44d9-956c-6fcf9eeda756</CmdID>
	<Item>
		<Target>
			<LocURI>./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP</LocURI>
		</Target>
		<Meta>
			<Format xmlns="syncml:metinf">int</Format>
			<Type>text/plain</Type>
		</Meta>
		<Data/>
	</Item>
</Delete>

 

Filter Tags

  • Workspace ONE
  • Intermediate
  • Operational Tutorial
  • Document
  • Workspace ONE UEM
  • Windows 10
  • Modern Management