This blog post deals with Windows 10 and the mechanisms enabling us to manage deploy and apply Policies in a modern way.

Introduction

Moat and Castle belong in the past

We are living in an important moment in the IT world. The well-known perimeter defense approach is starting and continuing to show its age and its effectiveness in favor of zero-trust approach. In a nutshell, zero-trust model literally breaks the very inside concept, representing companies as a Castle protected with a Moat.

ATAWAD

Nowadays, Companies workforce has the chance to be more and more flexible by working remotely, by having the choice of their devices and most of all by using increasingly Cloud resources. It is clear the way people work has changed forever. That way, organizations have to embrace this new way of working, frequently summed up by the concept of ATAWAD: “AnyTime, AnyWhere, Any Device” (you can also find ATAWADAC by adding Any Content notion)

Modern Management

As a result, companies need to change or adapt their management by moving to a cloud-based modern management. Let’s take the example of Windows 10 devices:
A legacy approach was to deploy:

Configuration or restriction policies by GPO from an on-premise service (like GPMC)
Deploying Windows patches and updates from an on-premise update service (like WSUS)
Deploying applications from an on-premises software service (like SCCM).

The main restriction here is that devices need to be able to contact all these services while being on the company’s internal network.

On the contrary, Modern Management allows administrators to deploy over-the-air:

Policies by using CSP
Windows patches with Windows Update as a Service, also known as Windows Update for Business (WUfB)
Applications directly from your SaaS Devices Management Console (Here with Workspace ONE UEM)

From GPO to CSP - From zero to hero

This blog post deals with Windows 10 and the mechanisms letting us manage deploy and apply Policies in a modern way.
As this topic is quite complicated and requires so many technical information, I am going to split this post into 4 parts:

Part 1: Deep Dive: OMA-DM Protocol and CSP Policies
Part 2: Deep Dive: Inbox ADMX-Backed policies and Baselines
Part 3: Deep Dive: Application or 3rd Party ADMX policies
Part 4: Windows Policies Troubleshooting

Let's begin this series of articles right now.

The "Sleep" button example

First of all, let’s take a simple policy example. Then, this example will allow us to describe what is going on technically under the hood.

As an administrator, I would like to set a policy from Workspace ONE UEM to personalize the Windows Start Menu of my targeted Windows 10 device by hiding the “sleep” button.

Here is a screenshot of the default Windows start menu before applying the policy:

Here is the expected result after applying the policy:

Windows Start Menu Once Policy is Applied

To apply this policy:

Log in to the Workspace ONE UEM Console as an administrator
Under DEVICES > Profiles & Resources > Profiles click ADD then Add Profile.
As Platform, select Windows.
As Device, select Windows Desktop.
As Context, select Device Profile.
Into the General Payload, add W10_PERSONALIZATION as the name of the profile and add a Smart Group.
Into the Personalization Payload, select HIDE next to the Sleep description:

Finally, click SAVE AND PUBLISH.
We now have a ready-to-use profile with the expected policy described above:

OMA-DM Protocol

Once the W10_PERSONALIZATION profile is published, Workspace ONE UEM has to communicate with the targeted Windows 10 Device to apply its policy. Hence, we have first to understand how Workspace ONE UEM console is able to communicate with Windows 10 devices.

Windows 10 devices are using management clients to communicate to Workspace ONE UEM console on behalf of the device. There are two primary management clients:

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

If each management clients serve their own and distinct purposes, OMA-DM Client is the only one to handle Microsoft CSPs (similar as GPO but in a modern way) as detailed above:

Workspace ONE UEM Solution Stack (source)

We now have our first main pilar of our windows 10 modern management journey: OMA-DM Protocol, a secure management protocol that runs HTTPS-based communication between a DM Server (Workspace ONE UEM) and a DM Client (located on the Windows 10 OS)

OMA-DM Session

The OMA-DM protocol is Client-initiated remote HTTPS DM session over SSL.
To illustrate the DM Session generated for our policy example, we can use several tools like:

Fiddler Everywhere described as a free web debugging proxy capturing all HTTP(S) traffic between the computer and the Internet.
SyncMLViewer which shows in real time all information based on OMA-DM Protocol exchanged between the Windows 10 device and the management system (Workspace ONE UEM here)

As SyncMLViewer is specifically dedicated to DM Session inspection, I have chosen to use this tool throughout the rest of this article.

So, after installing SyncMLViewer into my Windows 10 Device, here is the DM session logged when Workspace ONE UEM push the W10_PERSONALIZATION profile into the Windows 10 Device:

Expand Code

<!--- OmaDmSessionStart --->
<SyncML xmlns="SYNCML:SYNCML1.2">
  <SyncHdr>
    <VerDTD>1.2</VerDTD>
    <VerProto>DM/1.2</VerProto>
    <SessionID>51</SessionID>
    <MsgID>1</MsgID>
    <Target>
      <LocURI>https://ds801.awmdm.com/DeviceServices/Dm.svc/token/IH7dq/FB10319646E61845B7BBAA253AB2906F</LocURI>
    </Target>
    <Source>
      <LocURI>FB10319646E61845B7BBAA253AB2906F</LocURI>
    </Source>
  </SyncHdr>
  <SyncBody>
    <Alert>
      <CmdID>2</CmdID>
      <Data>1201</Data>
    </Alert>
    <Alert>
      <CmdID>3</CmdID>
      <Data>1224</Data>
      <Item>
        <Meta>
          <Type xmlns="syncml:metinf">com.microsoft/MDM/LoginStatus</Type>
        </Meta>
        <Data>user</Data>
      </Item>
    </Alert>
    <Replace>
      <CmdID>4</CmdID>
      <Item>
        <Source>
          <LocURI>./DevInfo/DevId</LocURI>
        </Source>
        <Data>FB10319646E61845B7BBAA253AB2906F</Data>
      </Item>
      <Item>
        <Source>
          <LocURI>./DevInfo/Man</LocURI>
        </Source>
        <Data>VMware, Inc.</Data>
      </Item>
      <Item>
        <Source>
          <LocURI>./DevInfo/Mod</LocURI>
        </Source>
        <Data>VMware7,1</Data>
      </Item>
      <Item>
        <Source>
          <LocURI>./DevInfo/DmV</LocURI>
        </Source>
        <Data>1.3</Data>
      </Item>
      <Item>
        <Source>
          <LocURI>./DevInfo/Lang</LocURI>
        </Source>
        <Data>en-US</Data>
      </Item>
    </Replace>
    <Final />
  </SyncBody>
</SyncML>

<SyncML xmlns="SYNCML:SYNCML1.2">
  <SyncHdr>
    <VerDTD>1.2</VerDTD>
    <VerProto>DM/1.2</VerProto>
    <SessionID>51</SessionID>
    <MsgID>1</MsgID>
    <Target>
      <LocURI>FB10319646E61845B7BBAA253AB2906F</LocURI>
    </Target>
    <Source>
      <LocURI>https://ds801.awmdm.com/DeviceServices/Dm.svc/token/IH7dq/FB10319646E61845B7BBAA253AB2906F</LocURI>
    </Source>
  </SyncHdr>
  <SyncBody>
    <Atomic>
      <CmdID>eba28838-edcf-4720-a9ca-5b59a55d6adc</CmdID>
      <Replace>
        <CmdID>fd302e07-8629-4ff4-9076-f2c61fd1d70a</CmdID>
        <Item>
          <Target>
            <LocURI>./Device/Vendor/MSFT/Policy/Config/Start/HideSleep</LocURI>
          </Target>
          <Meta>
            <Format xmlns="syncml:metinf">int</Format>
          </Meta>
          <Data>1</Data>
        </Item>
      </Replace>
    </Atomic>
    <Get>
      <CmdID>WindowsState:CIXCAhiITSIGEAog4pQBKFMwAThMQAlIQFgMaglWTXdhcmU3LDFwAnoMCLKUlYEGEMChmeQCgAEBigEIMjEuMS4wLjA=</CmdID>
      <Item>
        <Target>
          <LocURI>./Ignore</LocURI>
        </Target>
      </Item>
    </Get>
    <Final />
  </SyncBody>
</SyncML>

<SyncML xmlns="SYNCML:SYNCML1.2">
  <SyncHdr>
    <VerDTD>1.2</VerDTD>
    <VerProto>DM/1.2</VerProto>
    <SessionID>51</SessionID>
    <MsgID>2</MsgID>
    <Target>
      <LocURI>https://ds801.awmdm.com/DeviceServices/Dm.svc/token/IH7dq/FB10319646E61845B7BBAA253AB2906F</LocURI>
    </Target>
    <Source>
      <LocURI>FB10319646E61845B7BBAA253AB2906F</LocURI>
    </Source>
  </SyncHdr>
  <SyncBody>
    <Status>
      <CmdID>1</CmdID>
      <MsgRef>1</MsgRef>
      <CmdRef>0</CmdRef>
      <Cmd>SyncHdr</Cmd>
      <Data>200</Data>
    </Status>
    <Status>
      <CmdID>2</CmdID>
      <MsgRef>1</MsgRef>
      <CmdRef>eba28838-edcf-4720-a9ca-5b59a55d6adc</CmdRef>
      <Cmd>Atomic</Cmd>
      <Data>200</Data>
    </Status>
    <Status>
      <CmdID>3</CmdID>
      <MsgRef>1</MsgRef>
      <CmdRef>fd302e07-8629-4ff4-9076-f2c61fd1d70a</CmdRef>
      <Cmd>Replace</Cmd>
      <Data>200</Data>
    </Status>
    <Status>
      <CmdID>4</CmdID>
      <MsgRef>1</MsgRef>
      <CmdRef>WindowsState:CIXCAhiITSIGEAog4pQBKFMwAThMQAlIQFgMaglWTXdhcmU3LDFwAnoMCLKUlYEGEMChmeQCgAEBigEIMjEuMS4wLjA=</CmdRef>
      <Cmd>Get</Cmd>
      <Data>404</Data>
    </Status>
    <Final />
  </SyncBody>
</SyncML>

<SyncML xmlns="SYNCML:SYNCML1.2">
  <SyncHdr>
    <VerDTD>1.2</VerDTD>
    <VerProto>DM/1.2</VerProto>
    <SessionID>51</SessionID>
    <MsgID>2</MsgID>
    <Target>
      <LocURI>FB10319646E61845B7BBAA253AB2906F</LocURI>
    </Target>
    <Source>
      <LocURI>https://ds801.awmdm.com/DeviceServices/Dm.svc/token/IH7dq/FB10319646E61845B7BBAA253AB2906F</LocURI>
    </Source>
  </SyncHdr>
  <SyncBody>
    <Final />
  </SyncBody>
</SyncML>
<!--- OmaDmSessionComplete --->

Without going into details for the moment, it seems that this DM session consists of a series of 4 XML-Based Commands blocks, both blocks delimited by SyncML Tags.

We now have our second main pilar of our windows 10 modern management journey: OMA-DM Session consisting of a series of commands exchanged between a DM Server (Workspace ONE UEM) and a DM Client (Windows 10 Device)

OMA-DM Stack Overview : Protocol + Session

OMA-DM Messages

As seen above, the DM session consists of a series of commands exchanged between Workspace ONE UEM and the Windows 10 Device.

From SyncMLViewer tool, we are now clicking the SyncML Sessions/Messages tab to have a better understanding of what a DM session is made of. We can find on the left column:

A block listing all DM Session recorded
A block listing all DM Messages for a specific DM Session. These DM Messages are finally what it has been called "Commands" previously. We can validate that the current DM Session consists of 4 DM Messages.

SyncMLViewer: DM session and DM Message Detail

Some comments here:

To link each DM Messages belonging to the same DM Session, each DM Message has a specific XML Element Session ID: SessionID.
This Session ID is the same one for each DM Message. According to the above screenshot, its value is 51.
Each pair of Request/Response DM Messages are identified by a specific XML Element Message ID: MsgID.
Here, we have two pairs of DM Messages, the first one with the MsgID egal to 1 as we can see in the above screenshot. The seconde one has MsgID egal to 2.

A DM session can be divided into two phases:

Setup phase: This phase match with the first pair of Request/Response DM Messages with the MsgID egal to 1. The Windows 10 device sends an initiating message to Workspace ONE UEM. The Windows 10 device and Workspace ONE UEM exchange needed device information.
Management phase: This phase match with the last two DM Messages with the MsgID egal to 2. Workspace ONE UEM is in control. It sends management commands to the Windows 10 device and the Windows 10 device responds. Phase two ends when Workspace ONE UEM stops sending commands and terminates in the session.

Hence, when pushing the W10_PERSONALIZATION profile to the Windows 10 targeted Device:

A DM Session with a specific Session ID is created.
The DM Session is generally made of two pairs of Request/Response DM Messages (called One-Step Protocol), each identified by a Message ID.
Each DM Message is an XML-Based SyncML (Synchronization Markup Language) document.

Here is the generic structure of a SyncML Message:

<SyncML xmlns='SYNCML:SYNCML1.2'>
   <SyncHdr>
      <VerDTD>1.2</VerDTD>
      <VerProto>DM/1.2</VerProto>
      <SessionID>{Session ID}</SessionID>
      <MsgID>1</MsgID>
      <Target>
         <LocURI>{Target URI}</LocURI>
      </Target>
      <Source>
         <LocURI>{Source URI}</LocURI>
      </Source>
   </SyncHdr>
   <SyncBody>
      {DM Command(s)}
      <Final />
   </SyncBody>
</SyncML>

SyncML message Generic Structure

A SyncML message has two child elements:

The SyncHdr element. It serves as the container for the revisioning routing information in the DM Message.
The SyncBody element type serves as the container for the contents of the DM message.

SyncHdr Element detail

The SyncHdr Element can be seen as the Header Element into an HTML Page (Hdr stands for Header).
Into the SyncHdr element, we MUST find:

The Session ID to indicate the ID of the current DM Session.
The Message ID to indicate the ID of the current DM Message.
The Message Target Uniform Resource Identifiers (URI).
The Message Source URI.

Here is a SyncHdr focus example coming from a DM Message of our example:

Quick comments here.

We may wonder where the value FB10319646E61845B7BBAA253AB2906F comes from.
This value, FB10319646E61845B7BBAA253AB2906F, is referring to:

The DeviceClientId on Registry located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\MDMDeviceID :

UDID on Workspace ONE UEM Console when displaying device detail view:

Device Detail View into Workspace ONE UEM

We also may wonder how the Windows 10 Device knows when initiate a DM Session. The DM Client (Located on the Windows 10 Device) supports the ability to configure push-initiated DM Session. Using the Windows Notification Services (WNS), Workspace ONE UEM can request the Windows 10 device to establish a DM Session with Workspace ONE UEM through a push notification. During enrollment, the Windows 10 Device registers a persistent connection with the WNS cloud.
We can retrieve WNS informations directly into Workspace ONE UEM Console on the Device Detail View:

SyncBody Element detail

The SyncBody Element can be seen as the Body Element into an HTML Page.
The SyncBody element is going to be detailed in the next chapter.

We now have our third main pilar of our windows 10 modern management journey: OMA-DM Messages which is an XML-Based SyncML document.

OMA-DM Stack : Protocol + Session + Message Overview

OMA-DM Command

The SyncBody Element contains DM Commands or, in other words, Settings to apply into the Windows 10 Device. These settings are all exposed or expressed via Configuration Service Providers (CSPs).
A CSP, represented in a conceptual tree, is an interface structure to read, set, modify, or delete configuration settings on the device. These settings map to registry keys or files.
Furthermore, CSPs use SyncML DM Message as carriage payload.

Also, Workspace ONE UEM leverages CSPs when an administrator creates and assigned profiles in the console.

Let's go back to Workspace ONE UEM Console:

Under DEVICES > Profiles & Resources > Profile, select W10_PERSONALIZATION Profile
Click the </> XML button

A Modal Window appears with the CSP embedded into a SyncML Payload.

In general, The standard syntax is as following:

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

With:

OMA-DM Elements	Description
Command (Cmd)	Supported values for the Custom Settings profile are: Add – adds the CSP policy to the device. This performs an implicit add, only use Add when the policy requires an Add, otherwise use a Replace command. Replace – overwrites or adds any data from the CSP policy to the device. Delete – removes the CSP policy from the device. Exec – performs an action from the CSP policy on the device, such as reboot.
Unique number in the profile (CmdID)	Unique number to identify each command in the profile. We can use 1, 2, 3… for example for each new command within a custom profile. The CmdID must be unique for each command in the same profile, however do not have to be unique across profiles. It is recommended to use a GUID value.
Int or Chr (format)	Either integer (int) or character (chr). Based on the values specified (data) in the CSP policy.
/Policy Scope/ (LocURI)	Either ./Device/ if policies are applied to the device, or ./User/ if policies are applied only under user’s profile.
Policy sub-categories (LocURI)	Policy path
Settings (data)	A valid value defined from the CSP or in the ADMX file.

As we can see, the CSP used is Start/HideSleep and here is its definition from Microsoft:

On SyncMLViewer side, we can find this XML code under the SyncBody Element:

We now have our last main pilar of our windows 10 modern management journey: DM Command including Configuration Service Providers (CSPs).

Conclusion

We saw in this blog post that OMA-DM Policies support Standard Microsoft CSP but OMA-DM also support:

Inbox ADMX-Backed policies: The OS group policies which are included and located in the C:\Windows\PolicyDefinitions folder.
Application or 3rd Party ADMX policies: These are 3rd party application settings which are defined in the ADMX. The ADMX will need to be downloaded and ingested into devices.

We are going to details these other policies in other blog posts.

Deep Dive: OMA-DM Protocol and CSP Policies