In this blog, we go back in time and look at how Windows device management really started.
How Microsoft built the first framework for managing devices, how the blueprint described in US Patent 20070113186A1 “On-the-Fly Device Configuration and Management” became the foundation of Windows MDM, and how that same OMA DM-based design shaped everything that followed.
The Blueprint Behind Every Intune Policy
Every time a Windows device checks in with Intune and applies a policy, it follows a model that was already described almost twenty years ago. The 2005 patent introduced the idea of a device management tree.
It explained how Windows could expose settings as nodes in that tree, how an internal Configuration Manager component could route commands, and how Configuration Service Providers (CSPs) would apply those changes on the device.
Each setting in Windows could be represented as a URI path in that tree. For a deep dive on how the MDM client uses this model in policy delivery, see the blog by Patch My PC titled The Truth About the 8-Hour Intune Sync (…).
When the management server wanted to change something, it sent a command to that path.
A translator mapped the URI from the server to the correct location inside Windows, keeping the system flexible even when internal structures changed.
That concept still describes the heart of Windows MDM today.
But while the patent solved how configuration could be applied, it did not yet define how a device and server would communicate.
How OMA DM was introduced
That missing piece already existed elsewhere…to be precise, in the Windows Phone.
The Windows Phone 8.1 Enterprise Device Management Protocol introduced an OMA DM (SyncML) client that could send and receive configuration commands over HTTPS. The funny thing? It’s still there in the OMA DM Windows code.
The OMA DM Protocol defined the entire conversation: the server sent Get, Add, Replace, or Exec commands, and the device replied with status messages.
The Transitional Years: Windows 7 and 8
While Windows Phone had a full OMA DM client, Windows 7 and 8 did not.
They relied on older management frameworks (Group Policy, WMI, and enterprise provisioning tools) but internally began adopting elements of the same model described in the patent.
- Windows 7 introduced Provisioning XML (ProvXML) support through Windows Embedded and Windows Mobile Device Center, a simplified cousin of the device management tree.
- Windows 8 added Workplace Join and the first signs of Modern MDM enrollment, using a lightweight DMClient derived from the Windows Phone stack.
It still used SyncML and OMA DM internally, but only for a small set of CSPs focused on device identity and policy. - The Configuration Service Provider concept formally appeared in Windows 8.1 RT, using the same DMClient provisioning described in the Windows Phone 8.1 documentation.
These steps turned the patent’s theory into a cross-platform implementation that could run on both phones and PCs, setting the stage for full OMA DM management in Windows 10.
From Windows 8.1 to Windows 10
When Microsoft introduced Windows 10, it unified those components.
The existing OMA DM client from Windows Phone became part of the desktop operating system and connected directly to the patent’s management framework.
OMA DM handled the transport and session layer.
The internal Configuration Manager handled the logic.
CSPs performed the actual configuration.
That combination became the modern MDM channel still used by Intune and other services today.
At the core of that channel sits the same structure that makes it all possible, the device management tree.
The Management Tree
At the center of this model is the tree described in the 2005 patent. It acts as a structured map of every configurable part of Windows. Each branch of the tree represents a category, such as registry, certificates, or policies. Each leaf represents a single setting that can be read or changed.
Example from the Policy CSP:
If Intune sends a command to
./Device/Vendor/MSFT/Policy/Config/BitLocker/RequireDeviceEncryption,
The device knows exactly which setting to enforce. The 2005 patent illustrated the same idea with a FileSystem branch:
./Vendor/Company/FileSystem/%CE2%/foo.txt
The %CE2% variable represented the storage root and could be translated to something like
./Vendor/Company/FileSystem/Storage/Windows/foo.txt
showing how translators could automatically rewrite a URI to match the internal structure of the device.
In both the old and modern designs, the management service interacts with these nodes using simple operations:
- GET → read the current value
- SET → apply a new value
- GET → confirm success
This loop — GET, SET (REPLACE), GET — became the language of Windows MDM.
Translators – The Silent Bridge
The translator component from the patent was designed to keep compatibility between Windows versions. It can rewrite URIs or values before they reach the CSP, letting older management servers keep working even if internal paths have changed.
These translators are registered in the system registry and still operate today inside the Windows CSP framework. They quietly ensure that the same management paths keep functioning as Windows evolves.
When Windows 10 arrived, this entire system, translators, CSPs, and the OMA DM client, came together for the first time.
From Phones to Windows
When Microsoft extended OMA DM from Windows Phone to Windows 10, each CSP became a branch in the management tree. Examples:
- Policy CSP – security and configuration settings
- PassportForWork CSP – Windows Hello for Business
- Certificate CSP – certificate delivery and renewal
- Update CSP – Windows Update configuration
OMA DM delivered SyncML messages from Intune to the Device Management Client (DMClient).
The Configuration Manager processed them and passed each request to the correct CSP, which applied the change on the device. That architecture remains intact today, a direct continuation of the Windows Phone 8.1 protocol extended to the desktop.
The Limits of OMA DM
OMA DM is reliable and well-defined but transactional. Every change requires a command, a response, and a confirmation. It lacks built-in mechanisms for state drift detection or offline enforcement.
Perfect for mobile devices, less ideal for always-connected PCs.
Microsoft needed a way to describe what the device should look like, not just a list of commands to execute.
From OMA DM to WinDC and MMPC
One thing is for sure when moving from OMA DM to Windc, OMA DM isn’t gone, it’s still the backbone.
The classic SyncML-based protocol continues to handle enrollment, transport, and communication between the device and the management service.
What’s changing is what sits on top of it.
Windows Declared Configuration (WinDC) adds a new layer through the Declared Configuration CSP.
Instead of firing off multiple SET → GET → SET commands, the device now works with a single GET/SET exchange, one declarative document that describes the entire desired state.
The device applies it, enforces it locally, and keeps itself compliant even offline.
OMA DM still carries the payload, but the payload itself has evolved.
The Microsoft Management Platform Cloud (MMPC) powers this shift behind the scenes.
It’s the infrastructure that connects Intune, Windows, macOS, Linux, and Windows Server through one unified management plane, using the same familiar endpoints: *.dm.microsoft.com
So while OMA DM remains the core, WinDC redefines how configuration flows through it, from procedural commands to a single declarative state document. And this is only the beginning. The next post will dive into what that Declared Configuration CSP really does inside Windows, how it interprets the document, enforces it, and why it may change how policy delivery works altogether.
Want to see how Patch My PC makes modern management easier in action? Book a demo and explore it yourself.
