Configuring Workspace ONE Windows Baselines and Profiles

Overview

Workspace ONE provides several mechanisms for setting security and management policies on Windows devices, and this document details architectural and decision criteria for each option, as well as environmental considerations and troubleshooting. 

Note: During initiating and ongoing configuration of Workspace ONE UEM policies, administrators should consult internal security guidelines and coordinate with security professionals to ensure adherence with internal IT requirements.

This article focuses on policy types, precedence, and application/reapplication as presented within the following key topics:

• Policies
• Workspace ONE UEM Baselines
• Workspace ONE UEM Profiles, including Windows Profiles and the new Windows ADMX Profiles
• AD GPO integration and policy precedence
• Validating Profiles and Baselines
• Best Practices

Policies determine what users and devices can and cannot do from a functional and security perspective.  For the purposes of our discussion, policies is an overarching term that encompasses the following:

• Workspace ONE UEM Baselines
• Workspace ONE UEM Profiles
• Workspace ONE UEM Compliance policies
• Active Directory GPOs, including domain, site, and OU GPOs

If the same setting is applied via various policies, they will overlap and create an inconsistent user experience.

What if … ?

The most important aspects of applying policies to Workspace ONE UEM Windows devices are ensuring each policy is enabled in only one location and no conflicts exist.  Keep in mind some policies invoke default settings which were not overtly configured.

As an example, the configuration of Windows Updates is critical for enterprises to ensure up-to-date security for Windows devices, but with the ability to configure numerous Windows Update settings in several places, how does this impact users and devices?

Let’s look at a scenario where users are complaining because Windows Updates are being deployed at inopportune times to their Windows Desktops.  There are many settings related to Windows Updates, including when updates are downloaded, notifications, when settings are applied, type of updates, and more, but for this scenario, let’s delve into only those that relate to auto restart.  Auto restart following Windows Updates can be configured in multiple policy engines:

• CIS Level 1 Benchmark
  • Default: User notified that computer will automatically restart in 5 minutes
• Windows Profile
  • Default: Auto restart not enabled
• Windows ADMX Profile
  • Default: Auto restart disabled during locally defined active hours if not explicitly configured
• AD GPO
  • Default: Auto restart disabled during locally defined active hours if not explicitly configured

Based on enabling the following default policies/payloads, what would the user experience? 

Figure 1: Policy conflict example.

The short answer: It depends 

Let’s dissect this confusing scenario.  Based on only enabling these four payloads and keeping the defaults, auto restart would result in seemingly intermittent and unstable behavior because it’s configured within multiple locations.  This behavior is caused by Windows Update restart settings being controlled simultaneously by multiple policies, each of which independently reapplies its own defaults to the same Windows configuration values. As will be explained in this article, the default behavior differs between Workspace ONE UEM v2511 and earlier as compared with v2602 and later. 

Hint: the answer to this scenario is presented at the end of this article.

When policy refreshes occur at various intervals, an alternate setting may apply.  This not only creates an inconsistent user and security experience, plus it is certainly confusing for an admin troubleshooting the issue.

This is precisely why Omnissa recommends setting each policy in only one place and a clear understanding of policy precedence. The multiple policy types and related configurations are discussed in detail within this article.

Buckle up as we delve deep into the various types of policies, policy settings, and precedence, as well as walk you through how to ensure that your desired Workspace ONE UEM settings can be configured to prevail. 

Workspace ONE UEM policies: Baselines and Profiles

Under the Resource tab within the Workspace ONE UEM console, two key options are presented for configuring policies that control Windows devices: Profiles and Baselines.

Figure 2: Policy options for Windows devices: Profiles and Baselines.

Profiles and Baselines options are the primary options that will be discussed in depth because of their applicability to Windows devices.  Please note that Windows ADMX Profiles is a new option and will be addressed at length within the Windows ADMX Profile section.

Profiles and Baselines differ in terms of options and suitability for business and technical use cases, as well as Windows platform.  There are six Workspace ONE options for policy configuration as shown below.

Figure 3: Workspace ONE UEM Windows device policy types.

Workspace ONE UEM Baselines and Profiles should be configured to manage Windows Server and Desktop devices and user controls.  In this manner, Workspace ONE UEM manages and secures the application and enforcement of policies without integration with Active Directory (AD) Group Policy Objects (GPOs) and/or Entra ID (formerly Azure Active Directory).  As such, Workspace ONE policies applied to endpoints that are temporarily or permanently unattached from AD or Entra ID can effectively provide security, including non-domain-joined workgroup devices.   While Active Directory Group Policy can coexist with Workspace ONE, Omnissa does not recommend using GPOs to manage Windows policy settings that are being controlled through Workspace ONE UEM.

Before delving into the functionality of these policy types, here is a high-level overview of the key differences between Profiles and Baselines.

Figure 4: Key differences between Baselines and Profiles.

Being that all Baseline settings and many Profile options ultimately affect registry keys, it is necessary to ensure that no duplication exists in the overall configuration.  Where the same setting is configured in two or more places, conflicts may inadvertently occur similar to the Windows Update example cited earlier, causing user frustration and extensive administrative troubleshooting. 

Figure 5: Recommended approach to policy options.

Note that AD GPOs are excluded within this recommended approach.  Omnissa recommends that AD GPOs should not be used in addition to Workspace ONE Baselines and Profiles.  Not only does this create potential system conflicts, but it also increases troubleshooting and administration effort.  However, corporate GPO requirements are often dictated, and this is discussed in the What if AD GPOs must co-exist section.

A template Baseline should be used as the primary security policy configuration tool.  Some Profile and Baseline settings are rooted in the same registry key, so each setting should uniquely be applied from one policy type, preferably a Baseline, to avoid contentions and thus provide the desired end state.  Where settings overlap, Baseline settings are recommended to monitor security compliance. 

There is one exception is related to this recommendation: Windows Update settings.  Because Windows Update setting options within the CIS Benchmark are limited, Omnissa recommends configuring Windows Updates via a Windows ADMX Profile or a Windows Profile.

Baselines provide a built-in console mechanism to report on the state of each setting which subsequently facilitates compliance reporting. On the other hand, Profiles are simple, rapid, and flexible policy settings to configure device security.  To prevent conflict and unintended configuration, only configure a setting in one place.

In the example below, the Require a password when a computer wakes (plugged in) setting is shown within both a CIS Benchmark L1 Baseline and a Windows ADMX Profile.

Figure 6: Note that some policies can be configured within a Baseline and Profile.

The same setting should not be applied within both a Profile and a Baseline because overlapping settings create conflicts and issues.  Note that the Baseline setting is enabled by default within the respective template when selected, whereas the Profile setting is set to not configured. 

Where a setting can be configured within a Baseline template, i.e., Microsoft Security Baseline or CIS Benchmark Baseline, this is recommended over either type of Profile setting with one notable exception: Windows Updates should be disabled within a CIS L1 Benchmark because the options presented are minimal and do not provide the granularity needed for effective management.

To understand what should be configured where, the following subsections delve deep into Baselines and Profiles.  Baselines will be covered first since this should be your primary policy tool.

Workspace ONE UEM Baselines

Baselines should be the primary security policy due to the built-in industry templates.  Many CISOs and other Security professionals designate one of two industry templates as the corporate standard.  Thus, using a Baseline as the starting point for securing and managing Windows devices streamlines, simplifying adherence to security requirements.

In addition, Baselines enable security compliance reporting.  Specifically, reports can be run to show the devices that comply or don’t comply with these Baseline security settings.  Baseline security compliance reports will be covered later in this document.

Windows Security Baseline and CIS Benchmarks

Two predefined Baseline templates are available to align with security standards for Windows Desktop devices:

• Microsoft Windows Security Baseline represents Microsoft’s recommended settings.
• CIS Benchmarks provides more stringent controls in line with the Center for Internet Security (CIS) recommendations.  Two levels are available:
  • Level 1 addresses basic security requirements and is the most common selection.
  • Level 2 provides more stringent security settings that may result in reduced functionality.  Significant testing should be undertaken to ensure the desired security results align with user/device functionality requirements. 

Note that only the Windows Security Baseline is also available for Windows Servers.

Figure 7: Baseline options

Rather than repackaging existing AD GPOs, Omnissa recommends the configuration of either the Windows Security Baseline or the CIS Benchmarks baseline template as the primary policy type, rather than the Custom and Create Your Own options. 

The options presented within the two the Windows Security Baseline or the CIS Benchmarks baseline templates differ and are contingent upon the specific setting and selection.  As an example, the Microsoft Security Baseline defaults to a 10-minute account lockout duration, whereas the CIS Benchmark Level 1 defaults to 15 minutes, as shown below. 

Figure 8: Windows 11 Account Lockout Duration default setting comparison between Microsoft Security Baseline (left) and CIS Benchmark Level 1 (right).

Omnissa pre-loads these templates into Workspace ONE UEM to simplify initial and ongoing policy configuration to align with the respective security recommendations.  Like the Microsoft annual feature update schedule, the two Workspace ONE UEM industry-standard templates are updated approximately every 12 months. Baseline templates are versioned based on release date.

Although Windows 10 is in end of life, it is possible that these devices still exist within your environment.  For both security template options, the latest Windows 10 version is 22H2 based on the final release before end of life.  In addition, the options presented for Windows 10 differ from Windows 11, and additional Feature Release settings options vary as well. 

Security and compliance

Your Security team should help you establish the appropriate settings for your environment. The CISO of a health care entity may require the extreme stringency of CIS Benchmark Level 2, whereas the CISO of a manufacturing company may find that the Windows Security Baseline is suitable.

Baseline templates are provided as a starting point to assist in rapid deployment of industry standards and validated security posture.  Each modification to a template Baseline is a deviation from the recommended industry standards.

The configuration of the Baseline should align to the compliance reporting required by the security team. For example, if the security team validates the security posture of devices based upon the default CIS L1 Benchmark, with two modifications to suit business and technical requirements, then the Baseline should be configured and deployed in this manner.

How do Baselines work?

Baselines most closely resemble GPOs, and the settings are subsequently mapped to specific registry settings as local GPOs.  In the same way that a GPO configuration is a UI to a registry key, so too a Baseline configuration inherently affects a registry key.  A key differentiator of Baselines is that they are applied and enforced by the Workspace ONE Intelligent Hub and therefore can be deployed and updated over the air without line of sight to AD or Entra ID.

Figure 9: Baselines applied and enforced by Workspace ONE Intelligent Hub.

Baselines map to local GPOs on the endpoint.  Even though users may have local administrator rights, including access to the registry, Baseline compliance reporting ensures that any security-related changes made to the local registry impacts device compliance.  Of course, the Workspace ONE administrator may also lock down the registry as shown in this Baselines brief click-through demo.

Actual configuration of Baselines requires just a few steps, as shown below.

Figure 10: Configuration of Baselines

The common denominator of settings that impact Windows endpoints should optimally be controlled within one Baseline, with two notable exceptions:

• CIS Level 2 Baseline has been configured.  Level 2 implies higher security and inherently applies after Level 1 to maximize security, thus necessitating the need for two Baselines.
• Additional settings are required for a subset of devices, thus necessitating an additional Baseline, as discussed below.

Two non-template Baselines 

If there is a need to apply additional specific settings, Windows ADMX Profiles should be considered before the non-template Baseline options.  Please see the Windows ADMX Profile section for more information.

Non-template Baseline options are:

• Custom Baseline, which is an additional step within the industry-standard template Baseline wizard that relies on a GPO export.
• Create Your Own Baseline, which is a standalone option that enables selection from the Windows 10/11 policy catalog.

Although the interface presented within both additional options appears similar, the process and recommendation differ:

Figure 11: On left, Add Policy option following configuration of industry-standard template; on right, presentation of standalone Add Policy Option within Create Your Own Baseline.

Omnissa does not recommend using these Baseline types independent of a template Baseline; either the Windows Security Baseline or the CIS Windows Benchmark should be the primary Baseline.  In particular, the use of the Custom Baseline is not recommended. Omnissa recommends the use of Create Your Own Baseline as a last resort only if the setting is not available within a Windows Profile, Windows ADMX Profile, and/or use of an industry template Baseline.

Below is a detailed description of the two additional types of Baselines.

  Custom Baseline

Although Custom Baselines may initially appear to be the easiest and fastest policy transition method for new deployments, this tool is not recommended for several reasons:

• The local device must have lgpo.exe installed
• Maximum size is 5 MB
• Modification is not possible; a new GPO import is required
• Limited visibility and reporting; compliance status cannot be tracked for individual settings
• Troubleshooting is more complex

A Custom Baseline allows existing GPOs to be imported and serve as the basis for Workspace ONE UEM policies.  After exporting a GPO backup file from Active Directory, it must be compressed into a ZIP file that is smaller than 5 MB in size and uploaded as shown below.

Figure 12: Steps to create Custom Baseline.

Although a Custom Baseline does provide a blank slate mechanism to import existing GPOs that can be applied by the Workspace ONE UEM engine, it is not recommended for the reasons discussed above.  If additional Baseline settings are required, the Create Your Own option could be selected.

 Create Your Own Baseline

Create Your Own Baseline enables administrators to apply GPO-like policies based on the respective Windows version and feature release.  Options include Window 10 and 11, as well as feature release versions.

Assuming that a template Baseline provides the majority of common settings for all Windows devices and is the primary policy, a Create Your Own Baseline may be configured to append the core Baseline with one or several policies.  Because each policy must be individually designated, it would be time consuming to apply a large number of policies this way.

For example, the standard Baseline templates do not include settings related to USB peripherals.  By using the Create Your Own Baseline functionality, this setting can easily be incorporated into a supplemental Baseline. 

Figure 13: Example of Add Policy option within Create Your Own Policy

Please note that in most cases, Windows ADMX Profiles will provide an easier and more streamlined option for additional settings.

Workspace ONE UEM Windows Profiles

There are three options for Windows Profiles: Windows Rugged, Windows, and Windows ADMX.  Unless you have specialized Windows Rugged devices, such as MobileDemand tablets, your selection for Windows devices should be either Windows or Windows ADMX as explained below.

Figure 14: 3 types of Windows profiles

Profile functionality

The Profile type selected and the Windows operating system impact Profile functionality.  The underlying processes for management and enforcement are an important aspect of Workspace ONE Windows Profiles. 

Before delving into Windows and Windows ADMX Profiles, below is an overview of several key terms:

• Open Mobile Alliance Device Management (OMA-DM), which is a transport protocol standard inherent in Windows Desktop devices
• Configuration Service Provider (CSP) is an API-like set of commands that interface with Windows Desktop devices via OMA-DM
• Synchronization Markup Language (SyncML) is the CSP command format
• Workspace ONE Intelligent Hub is not only the client software installed on enrolled devices but also the proprietary Omnissa mechanism for many aspects of Windows Profiles

What is OMA-DM?

OMA-DM is a standard transport protocol for secure remote device management and configuration.  When a Windows Desktop device is enrolled into a Mobile Device Management (MDM) system such as Workspace ONE UEM, OMA-DM transports the settings that configure, manage, and enforce some or all policies on that device. 

Windows Desktop devices inherently include OMA-DM, whereas Windows Servers do not.

What is a CSP?

A CSP is an XML-based interface to read, set, modify, or delete device configuration settings that map to registry keys, files, or permissions.  Workspace ONE UEM leverages CSPs when an administrator creates and assigns most Windows Profile payloads within the console. Windows devices then securely apply CSP settings at boot time and again at eight-hour intervals, as well as when modified.   When the respective Profile is deleted or no longer applies to that user/device, the CSP setting is removed.

Figure 15: Windows Profile/CSP configuration process.

Policy CSP explained

There are numerous collections of CSPs that contain various settings.  Payloads within the Workspace ONE Windows Profiles may be individual Policy CSP settings or an entire CSP. 

The most commonly referenced CSP is the Policy CSP because it contains often-used individual settings.   There are other collections of CSPs, such as the Firewall CSP.  While some Windows Profile payloads use items within In the Windows Policy CSP, other payloads utilize other CSPs.

Below is a list of settings governed by the Policy CSP.

Figure 16: Policy CSP setting options

What is Synchronization Markup Language (SyncML)?

How are CSPs pushed to Windows devices?  CSP commands are formatted in Synchronization Markup Language (SyncML) and are propagated via the Open Mobile Alliance Device Management (OMA-DM) protocol.  The Workspace ONE UEM Windows endpoint processes the CSP(s) and applies the setting(s).

What is Workspace ONE Intelligent Hub?

Intelligent Hub is not only the Workspace ONE client software for enrolling devices for endpoint management, but it is also Omnissa’s proprietary system for remotely configuring, managing, and enforcing Windows policies.  Some Windows Profiles and all Windows ADMX Profiles utilize Intelligent Hub for this purpose.

Windows Desktop and Windows Server policy differences

Windows Servers cannot make use of OMA-DM/CSP functionality; thus, the only Profile option for these devices is Windows ADMX Profiles because all Windows ADMX Profiles solely utilize Intelligent Hub.

Figure 17: Windows Desktop vs. Windows Server Profile configuration and options

Windows Profiles and Windows ADMX Profiles differences

With the introduction of Windows ADMX Profiles, administrators now have two valid profile types to consider for managing Windows devices.  This section will help you distinguish which profile type should be selected based on your requirements and environmental criteria.

The following chart shows the key differences between Windows Profiles and Windows ADMX Profiles.

Figure 18: Key differences between Workspace ONE Windows Profiles and Windows ADMX Profiles

Windows Profiles

The Windows Profile option has existed within the Workspace ONE UEM console for many years.  Note the following characteristics of this profile type:

• Limitations.  With a limited set of options, extensive management of device and user functionality is constrained.  For example, only 28 Windows Desktop device payload options are presented.
• Lack of defined registry settings.  Because the specific registry settings impacted by the configuration are not presented, it is possible that settings specified within another policy may unknowingly overlap with those configured within a Windows Profile. 

Figure 19: Windows Profile > Windows Hello payload managed via OMA-DM/CSP

• Management.  Some payloads, such as Password, Encryption/BitLocker, Peer Distribution, and Intel vPro, are managed via Intelligent Hub.  OEM Updates and BIOS payloads are managed via Dell, and all other payloads are managed via Microsoft Configuration Service Providers (CSPs).  Specifically, the individual payloads and corresponding management are shown below:

Figure 20: Windows Profile payloads and respective management

  Windows ADMX Profile

The new Windows ADMX Profile was released in early 2026 to provide robust policy management and provides these features:

• Intelligent Hub Management.  All payloads are managed via Intelligent Hub, making this profile type the only option suitable for Windows Servers.  Windows Server devices can only be managed via Intelligent Hub; OMA-DM/Microsoft Configuration Service Providers are not present on Windows Server computers.

Figure 21: ADMX Profile: Windows Hello payload managed via Intelligent Hub

• Registry location.  The exact registry setting that is impacted by each configuration option is presented.
• Hundreds of Payloads.  Over 350 device payload options are presented, each with a myriad of individual options.  New payloads will be added in the future.
• Horizon integration.  Approximately 100 settings are available to manage Omnissa Horizon resources from within various related payloads.
• Platform/version support.  The Windows Desktop and/or Windows Server versions are clearly designated, ensuring suitability for the desired platform and version.  In addition, informational verbiage is provided for each option.
• Manage common applications.  Initially, some common applications can be managed via Windows ADMX Profiles and more will likely be added in the future.

Figure 22: Common applications can be managed via Windows ADMX Profiles

When to use Windows Profiles vs. Windows ADMX Profiles

When to use which Profile type depends on the following:

• Platform: Windows Desktop vs. Windows Server.  Profile settings for Windows Server can only be configured as Windows ADMX Profiles, whereas Windows Desktops can use either Windows Profile or Windows ADMX Profile payloads.
• Availability of settings within each Profile type.  Not all Profile settings are available in both Profile types.  For example, Intel vPro and Wi-Fi settings are only available within the Windows Profile option and cannot be transitioned to Windows ADMX Profiles.  Conversely, Windows Updates options are presented in both Windows Profiles and Windows ADMX Profiles, with the latter providing some additional options.
• Existing settings.  It is not necessary or recommended to immediately transition existing Windows Profile settings to Windows ADMX Profiles.  After thorough review, some payloads may permanently remain configured as Windows Profiles, whereas others may be optimized via new Windows ADMX Profile options.

For Windows Desktops, Omnissa recommends the following approach:

• Is this a new or existing configuration?
  • If new, is the payload or configuration option available in one or both profile types? 
    • If only one, select the available option.
    • If available within both, review the options available within each type.  Most likely, the Windows ADMX Profiles will provide more robust configuration options, and you should thus configure this option.
  • If existing, does the present Windows Profile configuration address all requirements?
    • If yes, keep the current Windows Profile as is.
    • If not, review the corresponding Windows ADMX Profile options and determine the optimal settings.  Create the corresponding Profile and fully test.

Figure 23: Windows Profile decision tree

As will be discussed within the Workspace ONE Baselines/Profiles + GPOs section, Active Directory Group Policy objects should not used for policy configuration if possible.

Creating a Windows Profile

Creating a Windows Profile is based on the following steps:

Figure 24: Creating a new Windows Profile.

First, select Resources > Profiles & Baselines > Profiles > Add > Add Profile > Windows or Windows ADMX.  Here you will be presented with two contexts: User Profile and Device Profile.

Figure 25: Context options: User Profile and Device Profile.

Both the User Profile and Device Profile selections provide the ability to choose from the various payloads.  In most cases, the Device Profile option is selected to ensure uniformity for all devices.

For a detailed explanation about how to configure Profile settings, please see Omnissa Docs.

One payload per Profile

Omnissa recommends only designating one payload per Profile, regardless of whether Windows Profiles or Windows ADMX Profiles are configured.  In the BitLocker example below, this implies that this Profile would be based on only the BitLocker payload settings and no other payloads would be included in that Profile.

Figure 26: Payload settings on the left pane of Profile.

All configurations should be determined in conjunction with your Corporate Security team and should be fully tested.  Do not configure the same setting within two or more policies as this will create a conflict similar to the initial Windows Update auto reboot example cited initially in this article. 

Note: The Windows Updates policies offer numerous settings and options, and these are discussed in depth in the Windows Updates guide.  The BitLocker Encryption policies likewise offer many options and are fully explored in the BitLocker guide.

Now that you’ve created Baseline(s) and Profiles, these must be appropriately assigned.

Assignment of Baselines and Profiles

Assigning Baselines and Profiles to SmartGroups is the last step before publishing.  In addition to designating the SmartGroup(s) to which the Baselines and Profiles will be applied, one or more SmartGroups can be excluded.

Figure 27: Assigning a Smart Group with exclusion.

When considering the downstream impact of Profiles and Baselines, review not only the Smart Group assignment, but also the exclusions. 

When applying your Baselines and Profiles, utilize Smart Groups.  If your Smart Groups are designated based on Windows version, this simplifies and automates the grouping of the appropriate devices.  As an example, Windows 11 v25H2 is the equivalent of version 10.0.22631.  Thus, you should set up your Smart Groups to reflect the following: 

Figure 28: Configuring Smart Groups based on Windows version number facilitates assignment

In most cases, assignment based on Smart Groups and configuring deployment are suitable for the final step, but you may also wish to consider deploying via Freestyle Orchestrator if you have additional requirements.

Replacing and unassigning Baselines and Profiles

By unassigning a Baseline and/or Profile from a Smart Group, it will cease to be applied/reapplied.  If you would like the change to apply immediately, a reboot is required.  An administrator can force Windows devices to reboot either immediately or after a specified period of time.

Starting with Workspace ONE v2602, Baseline precedence is based on the latest creation/edit date such that the newest Baseline applies last, those settings prevail.  As an example, if a newly created or modified Baseline is configured, those settings will overwrite and take precedence over those contained in previous Baseline(s). 

Before replacing and unassigning any policy, thorough testing is recommended.

Creating a Freestyle Orchestrator workflow to control Profiles

In addition, Profiles can be installed and removed via a Freestyle Orchestrator workflow.  Please note that Baselines cannot be deployed via Freestyle Orchestrator.

Please see Freestyle Orchestrator documentation for instructions.

Figure 29: Within Freestyle Orchestrator, Profiles can be installed or removed

What if AD GPOs or other settings must co-exist with Workspace ONE Baselines and Profiles?

Omnissa recommends that AD GPOs not be used in conjunction with Workspace ONE UEM Baselines and Profiles.  However, some corporate mandates require that specific GPOs are invoked for some or all devices and users, and Workspace ONE admins may or may not have access to the directory service that houses these corporate GPOs.  In addition, Omnissa recommends locking users and applications from making changes to policies via GPOs or the registry.  This section will address the associated considerations and implications.

Figure 30: Various device certificate policies that may impact Windows devices, as well as Horizon virtual desktops.

Using the example of device certificates controlled by policy, this can become exponentially more complex when AD GPOs also exist. Where AD GPOs are applied to a Windows device, this adds one more type of policy and is further impacted by precedence.  Horizon virtual desktops managed via Workspace ONE may have some AD GPOs applied, some Workspace ONE policies, and additional policies that impact the device and consequently the user experience as configured by the Horizon administrator.  Further, new Windows ADMX Profiles offer numerous options for Horizon policies, including some focused on certificates.

As a result, this implies that multiple settings related to certificates may be configured in numerous places.   Unless addressed correctly, the ultimate functionality may not align with expectations and troubleshooting becomes extremely complex.

Where AD GPOs, as well as Workspace ONE Baselines and Profiles are deployed, the result is that numerous policies are applied and reapplied at different times.  Administrators will need to carefully consider the downstream impact. 

• Access to AD/Entra ID impacts whether GPOs are applied; when a device and user are offline, GPOs will not apply.
  • AD GPOs rely on line-of-sight connectivity, whereas Workspace ONE Baselines and Profiles apply over the air without access to AD/Entra ID.  If access to AD/Entra ID is not possible, only the Workspace ONE Baselines and Profiles will apply.
• Policy conflict may occur when the same policy ultimately impacts the same registry setting.
  • If the same or related policies are configured in various places, the ultimate impact on the device and user experience may range from intermittent to undesired or possibly even non-functional.
• Policy precedence focuses on the cadence for initially applying and then reapplying policies, including when policies may be overwritten.
  • Where policy conflicts exist, such as the Windows Update reboot scenario discussed at the beginning of this article, policy type priority and application/reapplication time can create seemingly intermittent issues. Precedence will be discussed in greater detail below.

Note: If GPOs must be used in conjunction with Workspace ONE Baselines and Profiles,
success is contingent upon ensuring that there is no policy duplication or conflict.

Initial and ongoing Policy precedence

Where multiple AD GPOs and Workspace ONE Baselines and/or Profiles are configured that impact the same or related registry keys, which setting take precedence?  Because these settings ultimately impact the registry on the Windows device, the short answer is that the last setting applied takes precedence.   As such, unexpected and/or intermittent results may occur.

The sequence order and precedence of GPOs, Baselines, and Profiles have a major impact as to which settings ultimately win at startup, as well as after the various policy types are reapplied.  Precedence applies based on each individual setting.  For example, if one policy type sets firewall on and another policy type sets Bluetooth on, these two policies will not create a final conflict; however, if one or both policy types set firewall and/or Bluetooth differently, a conflict will arise.

To avoid issues with policy precedence, it is important to configure each policy setting in just one place.  In addition, thorough testing is recommended based on not only initial device behavior but also ongoing behavior.

Where individual policy conflict settings occur, “last write wins” creates precedence initially and when reapplied.  Where the same exact setting is configured within multiple policies, there is no prioritization of which policy type will initially win, with two exceptions. 

There are two types of precedence that can be configured to always win:

• Multiple Workspace ONE Baselines.  Where multiple Baselines are applied, the most recent Baseline based on the latest date stamp will supersede older Baselines starting with Workspace ONE v2602.
• MDM Wins over Group Policy setting.  Where Workspace ONE Windows Profiles contain the same Policy CSP settings as GPOs, enabling MDM Wins over GP forces the Windows Profile setting to prevail.

In addition, two other configurations can alter the behavior of policy reapplication:

• Reapply Baseline.  The behavior of this setting varies based on whether your environment is running Workspace ONE v2511 or earlier as compared with Workspace ONE v2602 or later.
  • v2511 and earlier: Enable Baseline reapplication based on a configurable number of hours.
  • v2602 and later: In addition to enabling Baseline reapplication based on a configurable number of hours, this same setting enables reapplication of Windows ADMX Profiles based on that same number of hours.  Note that without configuration, both Baselines and Windows ADMX Profiles reapply every 1 hour by default.
• Config Refresh for CSPs.  This policy setting enables customizing the refresh interval for CSP-based Windows Profiles from the default of 8 hours.

Lastly, starting with Workspace ONE v2602 and later, the most recent Baseline takes precedence over older Baselines, and Baseline settings take precedence over Windows ADMX Profile settings.  This precedence applies not only at device initiation, but also during reapplication, which occurs by default every 1 hour.

MDM Wins over Group Policy setting

In all Workspace ONE versions where Workspace ONE Windows Profiles (and Baselines?) are in use and where GPOs are a non-negotiable staple of your IT environment, the MDM Wins over Group Policy setting should be invoked to nullify the corresponding Policy CSP-based GPO.  This means that where the same Policy CSP setting could be applied via GPO, Workspace ONE will take precedence for the CSP setting. 

For example, if you enable Wifi settings within a Workspace ONE Windows Profile and disable within a GPO, Wifi settings will ultimately prevail because the Workspace ONE Windows Profile will take precedence as shown below.

Figure 31: Impact of MDM Wins over GP setting

However, where a setting is not controlled by the Policy CSP, as is the case for proxy settings, the MDM Wins over GP setting will not prevail.  Why?  This is because the MDM Wins over Group Policy setting is only applicable to the Policy CSP settings and not all CSP settings, thus it is relevant only to Windows Profiles settings running on Windows Desktop devices that rely on OMA-DM and the Policy CSP; this setting has no bearing on non-Policy CSP settings and Windows ADMX Profiles. 

Where GPOs are also configured to apply to Workspace ONE Windows devices, MDM Wins Over GP should most commonly be enabled as a Best Practice where Windows Profiles that rely on the Policy CSP settings are in use. 

Note that even where MDM Wins over Group Policy has been enabled, there are a few settings that Microsoft has excluded from taking precedence, such as the Windows Server Update Service. 

 MDM Wins Over GP configuration

What does it mean that MDM Wins over GP applies to the Policy CSP, but not all CSPs?  Policy CSP is a subset of all CSPs, and thus this setting only applies to the Policy CSP.  While many of the most common settings are controlled by the Policy CSP, other GPOs that are not Policy CSPs will apply despite enabling MDM Wins Over GP.

With this setting enabled, if Workspace ONE and a GPO attempt to apply a setting to same Policy CSP, then the Workspace ONE setting will prevail.  However, if the ultimate setting is configured via a GPO setting and it is not configured by a Workspace ONE policy that affects the same setting and/or it is not a Policy CSP setting, then the GPO setting will apply.

Because of the potential for settings to overlap, testing is strongly recommended.

Configuration of this setting ultimately impacts a registry key:

• HKLM\Software\Microsoft\PolicyManager\current\device\ControlPolicyConflict

Figure 32: Registry impact of Profile setting: MDM Wins Over GP.

MDM Wins Over GP setting can be applied as a Profile using an XML file template. 

Alternatively, you can create a Powershell script and propagate as a script or via Freestyle Orchestrator. 

The registry file (.reg) should contain the following:

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\ControlPolicyConflict]
"MDMWinsOverGP"=dword:00000001

When the MDMWinsOverGP key is configured, the two additional keys shown above, i.e., MDMWinsOverGP_ProviderSet and MDMWinsOverGP_WinningProvider, are automatically generated.

Reapply Baseline setting

Reapply Baseline causes Baselines to be reapplied at a designated hourly interval for Workspace ONE v2511 and earlier, and this same setting also results in Windows ADMX Profiles being applied in that same interval.

Specifically, the pre- and post-v2602 differences are as related to this setting are as follows:

Figure 33: Reapply Baseline setting based on Workspace ONE version

Note that Windows ADMX Profiles are also applied every 1 hour by default and that configuration of this setting impacts not only Baselines but also Windows ADMX Profiles.  Windows Profiles are not impacted by this setting.

Where the Workspace ONE version is v2511 or earlier, Workspace ONE Baselines do not reapply by default but can be configured to do so based on an interval based on hours.  If there is no entry for the interval or it is set to 0, ReapplyBaseline will not be invoked.

Conversely, if your environment is based on v2602 or later, the reapplication times of both Baselines and Windows ADMX Profiles defaults to one hour and can be modified via the same Reapply Baseline setting.

Please note that if this setting has previously been invoked, when your environment is upgraded to v2602 or later, it will apply to both Baselines and Windows ADMX Profiles.

Configuration of Reapply Baseline setting

Configuration of this setting ultimately impacts a registry key that must be created:

• HKLM\Software\Airwatch\ReapplyBaseline

Figure 34: ReapplyBaseline registry key set to 2 hours.

The ReapplyBaseline registry key can be applied as a Profile using an XML file template.

Alternatively, you can create a Powershell script and propagate as a script or via Freestyle Orchestrator. 

The first step is to create a registry file.  The registry file (.reg) contains the following based on this example showing an interval of 2 hours:

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\AIRWATCH\ReapplyBaseline]
"Interval"=dword:00000002

Config Refresh for CSPs setting

By default, Workspace ONE CSP-based Windows Profiles are reapplied every 8 hours.  If configured, the Config Refresh for CSPs setting causes Policy CSP-based Windows Profiles to be reapplied at a customized interval ranging from 30 minutes to 24 hours.

Note that Hub-based Windows Profiles are reapplied every 4 hours by default and cannot be modified.  Config Refresh for CSP only applies to Policy CSP Windows Profiles and does not apply to non-Policy CSP Windows Profiles, including Hub-based Windows Profiles.

To invoke the Config Refresh for CSP setting, it is necessary to create a custom Profile. 

The resulting output of this configuration is as shown below.  The Cadence entry defines the interval based on minutes.

Figure 34: Config Refresh set to 30 minutes

Workspace ONE UEM Baselines/Profiles + GPOs

Where GPOs also exist, the resultant policy behavior when the defaults are accepted as is may not yield the desired outcome.  Commonly, this precedence order is not suitable or desirable for most Workspace ONE UEM Windows environments.  Why?

• Where conflicts exist, GPO settings may overwrite Profiles and Baselines at startup.
• GPO settings will continue to overwrite Profiles and Baselines by reapplying approximately every 90 minutes.  Depending on the exact timing and additional settings, Baselines and Profiles may supersede GPOs for a limited amount of time until GPOs are reapplied.
• Depending on the version, Workspace ONE Profiles and Baselines reapplication processes vary.
• User controls and experience may vary at each reapplication interval, creating intermittent inconsistency.

Confusing?  Yes!   GPOs recommended?  No!

Initial and subsequent application of GPOs, Baselines, and Profiles

The default initial and subsequent reapplication of GPOs, Baselines, and Profiles vary based on the Workspace ONE UEM version:

• All current versions up to and including v2511
• v2602 and later

Default behavior of Workspace ONE UEM v2511 and earlier

The default behavior of Workspace ONE Baselines and Profiles in combination with GPOs is as shown below where Workspace ONE UEM v2511 and earlier is deployed.

Figure 35: Default initial and reapplication of policies for Workspace ONE UEM v2511 and earlier

The default configuration reapplies most settings in a timely manner; however, the lengthy reapplication time for CSP-based Windows Profiles, as well as no Baseline reapplication, should be considered. 

Recommended configuration for Workspace ONE UEM v2511 and earlier

To address the lengthy reapplication time for CSP-based Windows Profiles and lack of Baseline application, Omnissa recommends configuring three specific settings:

• MDM Wins over GP if GPOs exist to overwrite Policy CSPs with Workspace ONE Profiles
• Reapply Baseline to ensure that Baseline(s) are reapplied on a prescribed interval
• Configure Refresh to ensure that CSP-based Windows Profiles are reapplied more frequently

Where possible, GPOs should not be used for policy configuration, and only one Baseline should exist to avoid contention.  Note that it is not possible to configure the reapplication frequency Hub-based Windows Profiles. 

Regarding the specific reapplication time, Omnissa recommends 4 hours or fewer to maximize the security of your Windows devices.  The interval decision should be made in conjunction with your Security team.

Figure 36: Recommended configuration of reapplication settings for Workspace ONE UEM 2511 and earlier

Default behavior of Workspace ONE UEM v2602 and later

The default behavior of Workspace ONE Baselines and Profiles in combination with GPOs is as shown below where Workspace ONE UEM v2602 and later is deployed.

Figure 37: Default initial and reapplication of policies for Workspace ONE UEM v2602 and later

Note that if more than one Baseline is applied, the most recent Baseline takes precedence.  Also, if the same setting is configured within both a Baseline and Windows ADMX Profile, the Baseline configuration wins over the Windows ADMX Profile setting.

Recommended configuration for Workspace ONE UEM v2602 and later

Consider invoking the following settings to address the lengthy reapplication time for CSP-based Windows Profiles, as well as overwriting Policy CSPs:

• MDM Wins over GP if GPOs exist to overwrite Policy CSPs with Workspace ONE Profiles
• Configure Refresh to ensure that CSP-based Windows Profiles are reapplied more frequently

Where possible, GPOs should not be used for policy configuration, and only one Baseline should exist to avoid contention.  Note that it is not possible to configure the reapplication frequency Hub-based Windows Profiles. 

Because Baselines and Windows ADMX Profiles are reapplied every 1 hour by default, it will not be necessary to reconfigure the Reapply Baseline setting unless a longer interval is desired.  Note that if the Reapply Baseline interval had been configured previously, that setting will prevail once your environment is upgraded to v2602.

Regarding the specific reapplication time, Omnissa recommends 4 hours or fewer to maximize the security of your Windows devices.  The interval decision should be made in conjunction with your Security team.

Figure 38: Recommended configuration of reapplication settings for Workspace ONE UEM 2602 and later

Summary of Workspace ONE UEM v2602 and later policy changes

Workspace ONE UEM v2602 introduces several new changes that impact the initial application and subsequent reapplication of Baselines and Profiles:

• Windows ADMX Profiles have zero reliance on CSPs, thus the MDMWinsOverGP setting has no bearing if only Windows ADMX Profiles are in use
  • This setting is only applicable to Windows Profiles
• New default reapplication interval for Baselines
  • Baselines reapply every 1 hour unless configured otherwise
• New default reapplication interval for Windows ADMX Profiles
  • Windows ADMX Profiles reapply every 1 hour unless configured otherwise
• Modification of the impact of the Reapply Baseline registry key
  • Reapply Baseline registry key modifies both Baselines and Windows ADMX Profiles

Although now available for all versions, the Config Refresh setting offers a configurable update interval for CSP-based Windows Profiles.

Validating Profiles and Baselines

As has been described within this document, the three types of policies—Profiles, Baselines, and GPOs—need to be carefully controlled to create the desired endpoint security behavior.  Thorough testing is strongly recommended.

To see which Workspace ONE UEM Profiles and Baselines apply to Windows devices, the respective configuration screens provide pertinent information.  Both policy types show:

• Options for deleting, editing, and managing
• Version number of each policy
• Filtering options to minimize the screen output

Below is the Profiles summary screen:

Figure 39: Profiles summary screen. Note that each Profile includes only 1 payload as is recommended.

Below is the Baselines summary screen:

Figure 40: Baselines summary screen.

Security compliance of Baselines

Security compliance status is a key reason to implement Baselines because being able to readily determine compliance status is likely important to your Security team. 

To view Baseline security compliance, select the specific Baseline to look at the compliance status of the Windows Security Baseline or CIS Benchmarks Baseline.  Note that the compliance status of Custom Baselines cannot be viewed.

• Security compliance.  Compliance status is based on the following:

• Compliant = 100% compliance
• Intermediate Compliance = 85-99% compliance
• Non-Compliant = Below 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.

Figure 41: Baseline security compliance status.

In addition, the compliance link shows details about the policy set applied to a device, which may be useful in identifying policies that are preventing full compliance.

When a Baseline is first published, it will be in “pending install” state.  The end user will also receive a notification stating, “Workspace ONE policies have been updated. Restart your device to apply the updates.”

Once installed on the device, it will move to Pending Reboot state. Once the device is rebooted, and the user logged in, the Compliance Status of the device will be reported to the console.

Compliance policies

Compliance policies offer a series of rules and actions that can be configured with automatic actions for non-compliance.  Unlike Baselines and Profiles, Compliance policies uniquely provide actions or enforcement.

For example, if a device does not have Windows Updates and Antivirus applied properly, cumulative enforcements steps could be configured that start with requesting device check-in and sequentially terminate with removal of Workspace ONE applications and/or enterprise wipe.

To configure, access Security > Compliance policies.

Figure 42: Compliance policies

Like Baselines, the status of Compliance policies can be used by Security teams to gauge device status and compliance of Windows devices.

Troubleshooting

In addition to the validation steps described above, Event Viewer may be helpful when troubleshooting issues related to Profiles and Baselines. 

Event Viewer

On the user device, Event Viewer may reveal failures that impact propagation.  For example, if OMA-DM communications fail, this could impact Profiles.  The contents of Application and Service Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin may be helpful.

Figure 43: Event Viewer data from Application and Service Logs > Microsoft > Windows > Device Management-Enterprise-Diagnostics-Provider > Admin

Best Practices

Below is a summary of Best Practices related to policy configuration.

Figure 44: Best Practices.

Windows Update auto restart scenario

Armed with the information presented in this article, let’s revisit the initial scenario presented as related to the Windows Update auto restart setting.  As you may recall, the setting could be configured in four places. 

Below is a summary of Omnissa’s recommended configuration:

Figure 45: Recommended Windows Update auto restart setting configuration

Summary and additional resources

Omnissa recommends that Baselines should be configured as the primary control and security mechanism to enable compliance reporting and the state of configuration settings. Both Baselines and Profiles deploy over-the-air and therefore do not require line of sight to Active Directory / Entra ID. Individual Profiles should be configured based on a single payload, typically resulting in multiple Profiles deployed to devices configuring specific usability type settings. 

All configurations should align with your corporate security guidelines and in collaboration with your corporate security professionals.

Additional resources

For step-by-step instructions to configure Baselines and Profiles, please see Omnissa documentation.

• Baselines
• Profiles

For more information about managing and securing Windows devices with Workspace ONE, you can explore the following resources:

 Windows Management 

• Enabling BitLocker encryption to remote Windows devices
• Workspace ONE Windows Multiuser
• Chip-to-cloud management with Intel vPro

 Windows Updates and Applications 

• Managing Windows Updates for Windows Devices
• Deploying Workspace ONE applications to Windows devices

 Windows Troubleshooting 

• Troubleshooting Workspace ONE Windows Devices

Changelog

The following updates were made to this guide:

About the Author and Contributors

This guide was written by:

•          Jo Harder, Sr. Technical Marketing Architect, Omnissa

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

•          Grischa Ernst, Product Manager, Omnissa
•          Camille Debay, Product Manager, Omnissa 
•          Phil Helmling, Lighthouse Architect, Omnissa
•          Saurabh Jhunjhunwala, Lighthouse Architect, Omnissa
•          Justin Johnson, Staff Solution Engineer, Omnissa
•          Dean Flaming, Staff Solution Engineer, Omnissa
•          Chase Bradley, Lighthouse Architect, Omnissa

Feedback

Your feedback is valuable, and recommendations for updates are welcomed.

To comment on this paper, contact Omnissa at tech_content_feedback@omnissa.com.