Baselines vs Policies vs GPO’s
There is always a lot of confusion which policy will win if you configure one setting in different policy approaches. In this article I hopefully can clarify some of the open and unclear topics.
Following topics will be covered in this article:
Baselines are a great solution to apply GPOs in a modern management environment. Right now, Baselines still have some limitations and you need to know how Baselines will behave before you use it.
It’s quite easy to deploy a whole GPO – or even a set of GPOs – to a device via Baseline. If you have a GPO backup or an export with lgpo.exe you can import those settings to a Workspace One Baseline.
If you have a set of GPO’s you want to deploy also in the Workspace One environment, you are now able to easily do it.
But before those settings will be applied you need to deploy the LGPO.exe to every device that will receive baselines. If you want to use the default baselines (Microsoft or CIS) you don’t need the LGPO.exe.
LGPO.exe is included in the Microsoft Security Compliance Toolkit
The easiest way to deploy this tool is to use product provisioning.
Therefor navigate to “Files/Action” and create a new action. After you entered a name and a description, open the Files tab and choose the extracted LGPO.exe file. Download Path should be:
We don’t need to add manifest data – the pure copy command is enough to deploy the file.
After we saved the file action, we need to create a product. Navigate to “Product List View” and add a product.
Enter a name and choose a smart group that should receive the LGPO.exe file. Open the Manifest tab and add a new manifest.
Choose “Install Files/Actions” for Action(s) To Perform and choose the newly created action for deploying LGPO.exe. After creating the product make sure, that the product deployment is activated.
Now we can check if the file is successfully deployed.
On a client navigate to
Hint: ProgramData is a hidden folder – so you have to activate “Show hidden folder” or just copy paste the path in the explorer.
A folder named “LGPO” should now exists and the LGPO.exe file should be stored in this folder.
Now we can deploy custom baselines and we are able to go a little deeper into the baseline topic.
If you are working with GPO’s you would expect that baselines will work nearly the same.
Actually the behavior is a little bit different. While GPO’s are applied every 90 Minutes + 30 Minutes random timer, baselines are only applied once. Currently there will be no reapply – there are plans to change this behavior and enable the functionality to re-apply the baseline.
Right now, Workspace One Baselines are only applied once and will not re-apply – even after a reboot there will be no re-apply.
And this behavior will also affect how baselines are processed.
We have following scenario:
Baseline 1: Account lockout threshold = 10
Baseline 2: Account lockout threshold = 20
Baseline 3: Account lockout threshold = 5
So, all baselines configure the same setting. If we are talking a GPO point of view the GPO which is enforced or closest to the object will win. Since there is no such thing like baseline ordering, the latest applied baseline will win. Means the following:
If Baseline 1 is applied first, Baseline 2 second and Baseline 3 last – Baseline 3 will always set the settings that are configured in the baseline – in this case Account lockout threshold will be 5.
If Baseline 2 is applied first, Baseline 3 second and Baseline 1 last – Baseline 1 will always set the settings that are configured in the baseline – in this case Account lockout threshold will be 10.
If Baseline 3 is applied first, Baseline 1 second and Baseline 2 last – Baseline 2 will always set the settings that are configured in the baseline – in this case Account lockout threshold will be 20.
This behavior makes it quite hard to work with baselines with different values for the same setting.
Best way to avoid this problematic is to configure a setting in only one baseline.
Profiles are the main configuration possibility of all MDM devices. Introduced in Windows 8, Windows also now able to be configured via MDM. Windows is supports the Open Mobile Alliance Device Management (OMA DM). Nearly everything in Windows is now manageable via an MDM solution. In the Microsoft world the configuration settings are named Configuration Service Provider (CSP). A CSP is an interface in the client operating system, between configuration settings specified in a provisioning document, and configuration settings on the device. CSPs are like Group Policy client-side extensions, in that they provide an interface to modify. Typically, these settings map to registry keys, files or permissions. Some of these settings are configurable, and some are read-only.
There is a documentation with all possible CSPs.
Every setting that is listed in the CSP documentation is possible to configure.
The main Settings are already provided by Workspace One. If you need to configure additional settings, you are able to create custom profile settings.
For that scenario, VMware provides a helpful website (you need a my vmware account):
The policy builder makes it quite simple to create custom profiles.
You want to set “Require Device Encryption” for BitLocker. First thing is to look at the BitLocker CSP at Microsoft:
Here you can see if your operating system supports the CSP. If yes, we take a look at the supported values. In this case it is an integer value with 0 (for disable) and 1 (for enable).
Now we navigate to the policy builder website and open the BitLocker CSP (always make sure you choose the right Windows 10 version).
If you type “1” into the empty line under “Require Device Encryption” the SyncML is created on the right site.
<Replace> <CmdID>bf6668ea-1830-4631-8dcd-30d266a0759e</CmdID> <Item> <Target> <LocURI>./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">int</Format> <Type>text/plain</Type> </Meta> <Data>1</Data> </Item> </Replace>
We now have the content for our profile. If you open your Workspace One Console and create a new device profile for Windows, you can paste the SyncML content to the “Custom Settings” tab.
Right now, there is no function to order profiles. Means that if you have several policies with the same setting but different configurations, you cannot make a clear statement which attitude wins.
Sometimes the more restrictive setting will win – sometimes the latest created policy will win.
The good thing is, that all devices are configured the same way – no matter at what time the device was configured.
There is a small toll to reevaluate restriction profiles: https://flings.vmware.com/policy-enforcer
GPO’s are the default configuration settings that are used in an on-prem Active Directory.
To find out more about GPO’s:
Which setting will win?
The latest applied setting will win. Means if the GPO setting is applied at startup and the MDM profiles are applied after that, the MDM profile will win – till the GPO will be reapplied.
Problem is the reevaluation of GPO’s. GPO’s are reapplied in a schedule. The worst case would be, that GPO and Profile (or Baseline) both configure one setting with different values. If you have the default configuration of GPO’s the GPO’s will be reapplied every 90 minutes + 30 minutes random time. Workspace One Profiles are only applied once.
As example we use the background picture setting.
In the GPO is picture 1 configured as background picture.
In Workspace One is picture 2 configured as background picture.
Device starts -> GPO is applied -> Picture 1 -> MDM Policies are applied -> Picture 2
Device runs -> GPO is reapplied -> Picture 1
So, make sure, that you configure one setting only once!
GPO will always win because of the GPO is the only policy that will be reapplied.
Baselines and Profiles are only applied once.
Make sure that a setting is only configured once!