Understanding Windows Group Policies: VMware Workspace ONE Operational Tutorial

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 Security Baselines or CIS Microsoft Windows Desktop Benchmark, or a Custom Baseline based on a GPO backup. 

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.  

Given both CSPs and Baselines are important policy delivery methods in Workspace ONE, you must understand the pros and cons of each. An administrator needs 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. 

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), 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 VMware Dynamic Environment Manager to deliver ADMX.
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 VMware Dynamic Environment Manager to deliver ADMX via Workspace OEN UEM. 

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.

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.

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

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.

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 device 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 prevents user access to 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.

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.

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/unassigned when the devices upgrade to the next Windows version.

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

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 the Name of the baseline, for example, Windows 10 1903 Security Baseline to see additional info such as compliance, versions, and install status.

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.

You can see which baselines are applied to a device on 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. 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.

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.

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.  

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.

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.

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.

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.

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.

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.

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.  

In your browser, navigate to https://vmwarepolicybuilder.com.

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.

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.

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.

1. In the upper-right corner of Workspace ONE UEM Console, select Add.
2. Select Profile.

Select the Windows icon.

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

Select Windows Desktop.

Select Device Profile.

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

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

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

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.

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.

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

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.

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.

1. In the upper-right corner of Workspace ONE UEM Console, select Add.
2. Select Profile.

Select the Windows icon.

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

Select Windows Desktop.

Select Device Profile.

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.

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

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

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.

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.

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

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

• Leverage samples from VMware Code Sample Exchange
• Use existing profiles to create custom settings
• Manually create SyncML

Microsoft publishes a Configuration Service Provider (CSP) reference 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.

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.

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.

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.

Now, we will import Chrome AMDX Settings into Dynamic Environment Manager. To download the Chrome ADMX files,  see Chrome Enterprise policy list.

1. Select ADMX-based Settings.
2. Click Select Categories to edit the policies.

1. Select any categories you want to edit the policy for.
2. Click OK.

1. Enter a Name for the policy. For example, Chrome Settings.
2. Review the number of categories selected.
3. Click Edit Policies to make modifications to the policy.

Select a Policy to edit it.

After the policy is edited, click OK.

Note that the Policy State should change. In this case, it has changed to Enabled.

1. Review the configured ADMX policies.
2. Click Save.

Next, we need to export the Dynamic Environment Mnager Configuration Settings into a *.demconfig file to upload into Workspace ONE UEM.

1. In the Dynamic Environment Manager console, after you have made all the configuration settings you want to change, click the star icon.

Select Import NOAD.xml

1. In the Dynamic Environment Manager installation location, you will find a folder called NoAD Mode.
2. Within the NoAD Mode folder, select NOAD Workspace ONE UEM Sample XML.
3. Click Open.

Select Import License File.

1. In the Dynamic Environment Manager download location, you should have downloaded the VMware DEM.lic file.
2. Click Open.

After you have imported the License File AND the NOAD.xml then Save the Config. Save it to a location so you can upload this config to Workspace ONE UEM.

1. Select the General tab.
2. Give the Policy a name. In this example, it is Dynamic Environment Manager
3. Give the Policy a description. In this example, it is Chrome ADMX
4. Select the target Smart Groups.

1. Select the Dynamic Environment Manager Payload.
2. Click Configure.

Click Upload to upload your DEM Config file.

Select Choose File.

1. Select your DEM config file and ensure that the file has been selected.
2. Click Save.

1. Review the DEM Config file selected.
2. Click Save and Publish to deliver the profile.

Review the Device Assignment and click Publish.

Review the Policy In Workspace ONE UEM admin console. Ensure it has an Assignment Type and Assigned Groups.

In the Workspace ONE UEM console, navigate to the DEM Policy and select Edit.

1. Navigate to the Dynamic Environment Manager payload.
2. Click to Download the DEM Config (You can edit this in the DEM Console).
3. Click Add Version to add a new version of the DEM Config.
4. After Config changes have been made to the DEM Config, click Change and upload the new DEM Config file.

In the Dynamic Environment Manager Console, click the star and select Open. Navigate to the downloaded DEM Config file and make any changes necessary. Save the file and upload this new Config to Workspace ONE UEM.

On the Device Details View, confirm that the Dynamic Environment Manager policy is applied.  

1. Select the Profiles tab.
2. Confirm the Dynamic Environment Manager Policy is applied.

As we are applying Chrome ADMX Policies via Dynamic Environment Manager, we will confirm the Chrome Settings are applied.

1. Open the Chrome Browser and select the Menu.
2. You will notice Managed by your Organization - this means that Chrome settings are applied.

As we have configured the Home page, we can confirm this setting in the Chrome Settings.

1. In Chrome, navigate to the On startup tab.
2. Review the Home Pages that have been configured.

You have successfully added the Dynamic Environment Manager Configurations to Workspace ONE UEM for deployment.  

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 the 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. 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. When you feel comfortable with the policies and how they are applied to the device, you can use 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.

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 the command prompt to programmatically generate the report.

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
• Scripts in Apps & Books
• Custom Settings Profile (shown below)

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.

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.

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.  

1. Expand the Status menu.
2. Click Non-Compliant.

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

1. Log in 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.

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.

Note that when using Workspace ONE UEM custom settings profiles, the Atomic node is not required as this is auto-populated for you and 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>

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 are included and located in the C:\Windows\PolicyDefinitions folder. Format is always chr. And settings require encoded XML or using <![CDATA[…..]]>. For more information refer to Understanding ADMX-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 3^rd party application settings that 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 manually handle 3rd party ADMX Policies.

1. Find the 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, and ensure it’s supported for your device type, edition, and version. Click the CSP to obtain more information.
3. Replace the highlighted code in yellow with the 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>

You should be using VMware Policy Builder however we will discuss what 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 use the short-link http://aka.ms/CSPList. For this example, let's look at setting the Homepage for the Edge browser. To configure the Edge browser, we will be using the Policy CSP, and focused on Browser/Homepages. From here we can see the supported Windows 10 editions, the allowed Scopes (user/device) and a description of what this setting 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 the .admx file using the GP name. The policy definition provides information on the registry key path for the setting, supported platform, and if the policy has parameters or if you can activate/deactivate the policy.
5. Follow the SyncML syntax to modify the below example for your use case:

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

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

First, let's understand the processing and precedence for group policy objects. Overall the last write/applied takes precedence and overwrites existing policies. 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, see Group Policy Processing and Precedence and Group Policy Hierarchy.

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