Configuring Windows Baselines and Profiles: Workspace ONE Technical Walkthrough

Overview

Workspace ONE Unified Endpoint Management (UEM) enables administrators to securely deliver and manage any app on any device, including Windows.  This guide will focus specifically on Windows devices only.

There are numerous ways to create policies and controls for Windows devices.  This guide covers the options and recommended steps that should be undertaken when implementing and managing Windows devices. 

Note: Before initiating 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:

1. Policies
2. Workspace ONE UEM Baselines
3. Workspace ONE UEM Profiles
4. AD GPO Integration and Precedence
5. Validating Profiles and Baselines
6. Best Practices

Policies

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

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

Multiple policies may overlap and create an inconsistent user experience.  For example, if an administrator wishes to disable Bluetooth on all Windows devices in a call center, there are numerous places where this setting can be configured—and potentially create conflicts. 

Based on the following configuration, would Bluetooth be allowed or prohibited?

Figure 1: Policy conflict example.

The short answer: Both, dependent upon which policy was applied last. 

Let’s dissect this confusing scenario.  Based on only these three settings, Bluetooth settings would conflict because it’s configured as both an AD GPO and a Workspace ONE Baseline.  Because neither setting has initial precedence, either Bluetooth policy may win at startup.  When GPOs refresh approximately every 90 minutes, the Bluetooth GPO would reapply, overriding the Baseline policy and would thus be allowed. 

What happens next is contingent upon whether Baselines are configured to reapply.  Because the Workspace ONE UEM policy was set within a Baseline, it would then supersede the GPO at a specified interval if reapplication were configured and then Bluetooth would be prohibited until the GPO reapplied, at which time it would once again be allowed.  Certainly, confusing for the administrator, as well as an inconsistent user and security experience!

Frustration would mount due to the various policy types, precedence, and reapplication times, and this would be exacerbated if the administrator did not know that a related GPO even existed.  Lastly, and perhaps most importantly, if best practices were followed such that GPOs were not enabled, Bluetooth would initially and consistently remain prohibited.

The short answer to remediating this issue is that Omnissa recommends setting policy in one place. This article will delve deep into 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; SDK Profiles and Profile Resources cannot be used to configure Windows devices.

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

Figure 3: Workspace ONE UEM Windows device policy types.

Workspace ONE UEM Profiles and Baselines should be configured to manage Windows devices and user behavior.  In this manner, Workspace ONE UEM controls the application and enforcement of policies without integration with Active Directory (AD) and/or Entra ID (formerly Azure Active Directory).  As such, endpoints that are temporarily or permanently unattached from AD or Entra ID can be secured and controlled, including non-domain-joined workgroup devices.

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 Bluetooth example cited earlier, causing user frustration and extensive administrative troubleshooting. 

Figure 5: Recommended approach to policy options.

In general, a template Baseline should be used as the primary policy configuration tool and supplemented with an additional Baseline, if necessary, plus numerous Profiles. Some Profile and Baseline settings are exact duplicates, so each setting should uniquely be applied from one policy type, preferably a Baseline, to avoid contentions and thus provide the desired end state. 

Baselines provide a mechanism to report on the state of each setting, and therefore facilitate compliance reporting. On the other hand, Profiles are simple, rapid, and flexible policy settings to configure device usage.  To prevent conflict and unintended configuration, only configure a setting in one place.

As an example, an administrator wishes to enable the firewall on Windows endpoints.  The firewall state may be set to on from within both a Profile and a CIS L1 Baseline, as shown below:

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

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, whereas the Profile setting is set to not configured.  A key consideration is that most Workspace ONE profiles are applied and enforced via OMA-DM, while Baselines are applied and enforced via the Workspace ONE Intelligent Hub.  In all cases where overlap may occur, the Baseline setting is recommended rather than the Profile setting.

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 policy type due to inherent industry templates and security compliance reporting.  Specifically, reports can be run to show the devices that comply or don’t comply with these security settings.  Baseline security compliance reports will be covered later in this document.

Two predefined Baseline templates are available to align with security standards: Windows Security Baseline and CIS Windows Benchmarks.   The options presented within the two Baseline template types differ and are contingent upon the specific selection. 

• 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 that should cause minimal if any issues.
  • 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. 

Figure 7: Baseline options.

Rather than repackaging existing AD GPOs, Omnissa recommends the use of one of these Baseline templates as the primary policy type, rather than the Custom and Create Your Own options. 

Baseline templates are provided as a starting point to assist in rapid deployment of industry standards and validated security posture. Making significant changes to a template Baseline alters 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.

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. Baselines are versioned based on release date.

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. 

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

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.

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 Additional Types of Baselines 

There are two additional options to apply policies using Baselines:

• Custom Baseline, which is an additional step within the industry-standard template Baseline wizard that relies on a GPO file.
• 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 if the use of an industry template is not appropriate.

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

 Custom Baseline

Although Custom Baselines may initially appear to be the easiest 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 an existing GPO 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 should 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. 

Workspace ONE UEM Profiles

There are three options for Windows Profiles: Windows Rugged, Windows, and Windows (Beta).  Please note that as of August 2024, Windows (Beta) is experimental.  Unless you have specialized Windows Rugged devices, such as MobileDemand tablets, Windows is the optimal choice for configuring Profiles.

Figure 14: 3 types of Windows profiles.

Creating a Windows Profile

Creating a Windows Profile is based on the following steps:

Figure 15: Creating a new Windows Profile.

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

Figure 16: Context Options: User Profile and Device Profile.

Both the User Profile and Device Profile selections provide the ability to choose from the various payloads, which are groups of settings.  Payloads are often referred to as commands or Configuration Service Providers (CSPs) but there are some exceptions  For example, the BitLocker payload is deployed via Workspace ONE Intelligent Hub using Powershell commands.

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

Further, many payload settings are equivalent to Baseline settings because they are rooted in the same registry key.  Where settings overlap, Baseline settings are recommended. 

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

What is a Configuration Service Provider (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 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 18: Windows Profile/CSP configuration process.

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.  OMA-DM is the industry standard for secure remote device configuration.  The Workspace ONE UEM Windows endpoint processes the CSP(s) and applies the setting(s).

There are numerous collections of CSPs that contain various settings.  CSPs are referred to as Payloads within the Workspace One Profiles screen. 

 Policy CSP Explained

The most commonly referenced type of CSP is the Policy CSP because it contains many often-used settings.  Do keep in mind that there are other collections of CSPs.

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

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

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 19: 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. 

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.

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 20: Within Freestyle Orchestrator, Profiles can be installed or removed.

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.

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

Replacing Baselines

Because Baseline precedence is based on the latest creation/edit date such that the newest Baseline applies last, those settings prevail.  Thus, the newly created or modified Baseline will prevail.

When applying your Baseline(s), utilize Smart Groups.  If your Smart Groups are designated based on Windows version, this simplifies and automates the grouping of the appropriate devices.  Windows 10 v22H2 is the equivalent of version 10.0.19045, and Windows 11 v23H2 is the equivalent of version 10.0.22631.  Thus, you should set up your Smart Groups to reflect the following: 

Figure 21: Configuring Smart Groups based on Windows version number facilitates Baseline assignment.

What if AD GPOs Must Be Integrated 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.  This section will address the associated considerations and implications.

Figure 22: Various printer and driver policy types that may impact Windows devices, as well as Horizon virtual desktops.

Using the example of printers and respective drivers controlled by policy, this can become complicated 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 typically have some AD GPOs applied, some Workspace ONE policies, and additional policies that impact the device and user experience as configured by the Horizon administrator.  This implies that multiple settings related to printers and drivers 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, AD/Entra ID policies 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 undesired to non-functional.
• Policy precedence focuses on the cadence for applying and reapplying policies, including when policies may be overwritten.
  • Where policy conflicts exist, such as the Bluetooth 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.

Policy Precedence

Where 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, but if both policy types set both firewall and Bluetooth differently, a conflict may exist.

Where individual policy conflict settings occur, “last write wins” creates precedence initially and when reapplied.  This is why it is so important to configure each policy setting in just one place.

Default Initial and Subsequent Application of GPOs, Baselines, and Profiles

By default, the following policy types are applied at startup and reapplication:

Figure 23: Default Policy Types and Precedence

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

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

Confusing?  Yes!  Recommended?  No!

Workspace ONE Precedence

If GPOs are a non-negotiable staple of your IT environment, one or both of the following Workspace ONE settings can be used to modify default behavior and facilitate Workspace ONE precedence.

• MDM Wins over Group Policy, where the same Policy CSP setting could be applied via GPO, and Workspace ONE will apply the CSP setting.
• Reapply Baseline, which enables Baselines to be reapplied at a designated hourly interval.

Figure 24: Resulting precedence.

Where GPOs are also configured to apply to Workspace ONE devices, MDM Wins Over GP should most commonly be enabled as a Best Practice, however, Reapply Baseline may also be beneficial.

Both the MDM Wins Over GP and Reapply Baseline settings are ultimately registry settings, and the respective sections describe how to designate either or both settings.

MDM Wins Over GP

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.

Configuring MDM Wins Over GP Setting

Configuration of this setting ultimately impacts a registry key:

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

Figure 25: 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. 

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 presented above, i.e., MDMWinsOverGP_ProviderSet and MDMWinsOverGP_WinningProvider, are automatically generated.

Reapplying Workspace ONE UEM Baselines and Profiles

Workspace ONE UEM Baselines and Profiles are applied at startup, and Profiles reapply every 8 hours.  There is no configuration or enablement required for Profile refresh.

Workspace ONE Baselines do not reapply by default but can be configured to 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.

Configuration of this setting ultimately impacts a registry key:

• HKLM\Software\Airwatch\ReapplyBaseline

Figure 26: ReapplyBaseline registry key set to 8 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 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 8 hours:

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

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 27: Profiles summary screen. Note that each Profile includes only 1 payload as is recommended.

Below is the Baselines summary screen:

Figure 28: 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 29: 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.

Troubleshooting

In addition to the validation steps described above, it may be necessary to troubleshoot issues related to Profiles and Baselines. 

Windows Policy Analyzer Utility

To ascertain which Workspace ONE policies apply to Windows devices, the Workspace ONE UEM Policy Analyzer for Windows tool may be beneficial.  This tool shows the assigned Policies and Baselines applied, as well as potential conflicts. 

This utility is accessible from https://techzone.omnissa.com/utilities#workspace-one-tools and offered as-is, not supported, and used at your own expense and risk.

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 30: 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 31: Best Practices.

Summary and Additional Resources

This tutorial provided the steps and methodology for managing Windows endpoints using Policies—Baselines, Profiles, and if required, AD/Entra ID GPOs.  Ensuring that settings are not duplicated across various policies is critical for success.

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 an Active Directory Domain Controller. Individual Profiles should be configured based on a single payload, typically resulting in several 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 Security and Policy Management 

• Windows Modern Management Security Design and Implementation
•  Enabling BitLocker Encryption to Remote Windows Devices: Workspace ONE Operational Tutorial

 Windows Update Patching 

• Managing Windows Updates for Windows Devices

 Windows Troubleshooting 

• Troubleshooting Windows Devices: Workspace ONE Operational Tutorial

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 
•          Anil Agarwal, Product Manager, Omnissa
•          Phil Helmling, Adoption Product Manager, Omnissa
•          Saurabh Jhunjhunwala, Customer Success Engineer, Omnissa

Feedback

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

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