Unlocking OSConfig: Windows Server 2025 Security Baselines and Drift Control

If you’re running Windows Server 2025 (or if your servers decide to surprise upgrade to it), OSConfig is a tool you’ll definitely want to check out. Microsoft hasn’t made a huge deal about it, but OSConfig quietly arrived in Windows Server 2025 with some powerful configuration management features. And here’s a bonus: it even works on Windows 11, thanks to dmosconfig.dll (even if Microsoft hasn’t officially called it out… we see it!).

In this post, we’ll dive into getting OSConfig up and running on your server, explore its role in enforcing security baselines, and uncover the brains behind it, such as dmosconfig.dll and the dcscvc service.

You’ll also see how OSConfig keeps configurations in line with its refresh task and built-in drift control (no GPOs!!!), letting you rest easy knowing your settings won’t wander. Plus, I’ll guide you through where OSConfig keeps its data in the registry, how to adjust its schedule with PowerShell, and how it follows a similar declared configuration model as Endpoint Privilege Management (EPM).

Why Use OSConfig?

OSConfig is more than just another configuration tool—it’s a powerhouse for enforcing and maintaining compliance across different scenarios. Microsoft has provided a few ready-made configurations, or “scenarios,” to address specific security needs, including some security features such as: Security Baseline, SecureCore, Defender, and App Control for Business (Windows Defender Application Control). Each of these scenarios is tailored for different aspects of security, allowing you to choose and apply configurations that meet your environment’s requirements without piecing together settings manually.

Key Benefits of OSConfig:

1. Declarative Configuration: Instead of fiddling with every little setting in GPOs or scripting each step, OSConfig uses configuration documents that define the end state. You simply tell OSConfig what you want, whether it’s enforcing a Security Baseline, enabling Defender policies, or locking down devices with Windows Defender application control, and it handles the “how.” This declarative model cuts down on errors and makes setup a breeze.

2. Compliance: OSConfig doesn’t just apply a baseline and walk away. With its built-in drift control, OSConfig periodically checks configurations to ensure they remain aligned with your specified scenario (e.g., Security Baseline Configuration or SecureCore). This means that every few hours, OSConfig scans for any drift from the baseline configuration and corrects it automatically if changes are detected—no need to wait for a GPO-style refresh or manually intervene.

3. Simplified Security Management Across Scenarios: OSConfig was built with security at its core, offering dedicated scenarios for managing different security aspects. With OSConfig, you can apply a complete Security Baseline or configure SecureCore settings to harden device security and know those settings will actually stick. This streamlined approach helps you maintain compliance without needing constant oversight.

4. Built-In Drift Control: OSConfig’s drift control keeps your configurations locked in place without constantly pinging your server. Every few hours, it does a quick compliance check, detecting any unauthorized changes and bringing them back to the baseline if necessary. It’s a smart, efficient way to keep everything on track, letting you focus on other tasks while OSConfig quietly handles the heavy lifting.

In short, OSConfig handles compliance checks and locks in security settings, so you don’t have to keep an eye on every detail yourself.

Installing the OSConfig PowerShell Module

To start using OSConfig, make sure the OSConfig PowerShell module is installed. Microsoft provides the module through the PowerShell Gallery, and you can find guidance in the official documentation.

To start, install the module in PowerShell:

Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force

Once installed, you’ll find the module in this folder:

C:\Program Files\WindowsPowerShell\Modules\Microsoft.OSConfig\1.1.0

This folder includes the essentials for OSConfig’s functionality:

After installing the module, the device will get a nice new enrollment! (where did I see this before)

Number 28 seems to relate to the Windows Admin Center Enrollment Type.

With the Module installed, let’s play around with it and find out what commands are provided. With these commands, we can configure certain OSConfig scenarios, check compliance, and adjust drift control.

Setting Up a Security Baseline

Now that the module is ready let’s get OSConfig up and running. We can do so by using the Set-OsconfigDesiredConfiguration and specifying one of the scenarios.

AppControl(Windows Defender application control), Defender/Antivirus,SecuredCore or SecurityBaseline

Please Note: Some OsConfig scenarios also work on Windows 11 if dmosconfig.dll is present.

This example below focuses on a server in a workgroup environment, aka workgroup member.

1. Deploying the Baseline: Start by enabling OSConfig and configuring it to apply a security baseline. The commands below enforce a baseline and perform compliance checks at regular intervals.

Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/WorkgroupMember -Default

“SecurityBaseline/WS2025/WorkgroupMember” refers to the specific baseline you want to enforce. This baseline document serves as the foundation for OSConfig to check against.

1. Trigger a Compliance Check – Once the baseline is set, you can initiate a compliance check manually if needed by using the get-OSConfigDesiredConfiguration command.

This compliance check verifies that the current system state matches the baseline and reports any discrepancies.

1. Adjust the Compliance Refresh Interval – You can also modify the frequency at which OSConfig checks for compliance (drift control) by setting a custom refresh interval.

Set-OSConfigDriftControl -IntervalMinutes 45  # Sets the refresh interval to 45 minutes.

These commands allow you to automate the management of configuration baselines and ensure they’re enforced continuously.

Now that we know what OSConfig is and how to set up a security baseline, let’s dive deeper into how it keeps everything in compliance.

DMOsConfig.dll: The Brain Behind OSConfig

Meet dmosconfig.dll, the real powerhouse behind OSConfig. This DLL does the heavy lifting, reading configuration documents and enforcing settings to match your policies. Think of it as the ultimate enforcer, ensuring OSConfig’s configurations stick.

Then there’s the declared configuration service, dcscvc, which keeps everything in line by continuously monitoring and enforcing those configurations.

This service is the “one” handling all the Declared Documents and ensuring the policies are applied to the device. Let’s examine how this task applies those declared documents.

The Declared Configuration Service (dcscvc)

At the heart of OSConfig’s drift control lies the dcscvc service. This service processes configurations/policies through three essential stages: raw, cooked, and applied. Each stage plays a distinct role in transforming a configuration document from a simple set of instructions into active policies that shape your server’s state. (GET-TEST-SET)

1. Raw: When a configuration or policy document is first loaded, it enters the system in its raw state. At this stage, the configuration exists exactly as defined in the declared document, without any processing. Think of it as the unfiltered instructions that OSConfig will later refine.

2. Cooked: Next, dcscvc takes this raw data and processes it into a “cooked” state, converting the configurations into a system-compatible format. This stage ensures that each setting is validated and prepared for enforcement, reducing the risk of errors when it’s applied.

3. Applied: Finally, dcscvc moves the cooked configurations to the applied state, turning them into active policies that govern the server’s behavior. Once applied, these configurations become the “live” settings on the server. OSConfig’s job isn’t done here, though—it continuously monitors these applied settings to ensure they align with the declared baseline.

This structured flow (raw → cooked → applied) is key to OSConfig’s reliability. By processing each stage separately, OSConfig ensures that only validated, compatible settings make it to the active state, reducing the risk of misconfigurations.

Drift Control: The Refresh Task and the Raw → Cooked → Applied Flow

Now, here’s where OSConfig’s drift control magic truly kicks in—the refresh task.

Sounds a bit like Config Refresh, right? Well, actually, it is indeed.

Config Refresh is for the old-school legacy Intune Policies.

The Declared Configuration Refresh Schedule (Config Refresh on Steroids ) is for the new kind of settings called declared documents.

Before zooming into the refresh schedule, let’s discuss the state/stages of the declared documents first.

This refresh schedule runs regularly (cadence), checking the active policies (in the applied state) against the baseline document to detect any drift. If a setting, let’s say EnableSmartScreen, has been changed outside of OSConfig’s control, the refresh task will spot this inconsistency, triggering windows declared configuration service (WinDC) to reapply the baseline settings and bring the configuration back to compliance(even offline!! But then again..when would a server be offline.. its not a notebook)

Let’s look at what this flow looks like

The Refresh Task Flow

Let’s start examining the Refresh Schedule by looking at this flowchart first.

Here’s a breakdown of this flow:

1. Start Refresh Task – The refresh task is triggered on schedule, kicking off a scan to verify configurations against the baseline.

2. Check Raw Configuration – The first step is to check the “raw” configuration, stored in HKEY_LOCAL_MACHINESOFTWAREMicrosoftDeclaredConfigurationRaw. This raw data reflects the original, unprocessed settings as defined in your configuration document.

3. Verify Cooked Configuration – OSConfig then processes the raw data into a format that the system can interpret and enforce, known as the “cooked” configuration. This cooked configuration is stored under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DeclaredConfiguration\Cooked.

4. Check for Discrepancies – The cooked configuration is then checked against the active system settings. If OSConfig detects any drift (for example, if EnableSmartScreen was disabled outside OSConfig’s control), it will mark this discrepancy for correction.

5. Set Cooked Configuration – OSConfig resets the cooked configuration to align with the baseline, ensuring that any changes are reverted to the intended settings.

6. Apply Cooked to Active Policies – The corrected, cooked configuration is applied to the system’s active policies, stored in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System. This ensures that all settings on the device are now compliant with the declared document.

7. Finalization and Logging – OSConfig logs the changes and finalizes the refresh task, recording any corrections it made during the process. This logging provides a record of enforcement actions, helping administrators audit changes.

8. Completion – With all settings verified and adjusted as needed, the refresh task completes. The system configuration is now back in compliance with the declared baseline.

This raw → cooked → applied flow ensures that OSConfig only applies validated settings, minimizing the chance of configuration issues while keeping your policies in line. Through this structured approach, OSConfig offers robust drift control, automatically detecting and correcting any unauthorized changes.

Where OSConfig Lives: The Configuration Flow from JSON to Registry

OSConfig uses a combination of file storage and registry entries to manage, apply, and monitor configurations. Here’s how the process unfolds:

Metadata Storage:

The baseline metadata for each policy, including descriptions, compliance details, and severity levels, is stored in the registry under:

This metadata provides OSConfig with essential information about each setting, such as default values, schema, and compliance requirements (e.g., AllowLocalSystemNULLSessionFallback). This is the foundational layer that OSConfig references to understand each policy’s intended behavior.

JSON Document Creation in ProgramData:

When a new configuration or baseline is applied, the JSON file with all the settings will be first created in the C:\ProgramData\Microsoft\DCHost\OS folder

This JSON document (such as E17005D5-A50E-4E57-BE94-1DAF469C6F93_device_SecurityBaselineWS2025WorkgroupMember@2411.0) contains all the details of the security baseline, including specific settings, values, and metadata for each policy. This file serves as the blueprint OSConfig uses for enforcement.

Registry Initialization:

OSConfig then references this JSON file to initialize or update entries in the registry under: HKEY_LOCAL_MACHINESOFTWAREMicrosoftDeclaredConfigurationHostOSConfig

This step involves creating registry keys for each setting specified in the baseline, essentially “loading” the configurations from the JSON file into the system’s registry.

Policy Enforcement and Drift Control:

Once the configuration data is established in the registry, OSConfig’s dcscvc service uses it to enforce the baseline settings and continuously monitor for compliance. The refresh task periodically checks for drift and, if necessary, references both the JSON file and registry entries to revert settings back to the baseline.

This flow, from JSON file creation to registry initialization and continuous monitoring, ensures that OSConfig maintains a reliable and persistent configuration state. By storing data in both ProgramData and the registry, OSConfig is equipped to handle configuration enforcement and drift control with minimal disruption to the system.

OSConfig and EPM: Two Sides of Declared Configuration

 If you’ve worked with Endpoint Privilege Management (EPM), OSConfig might feel a bit like déjà vu. Both OSConfig and EPM rely on declared configuration models, meaning they don’t just apply settings once and forget about them. They make sure those settings stick.

EPM is all about managing privilege elevation rules and controlling who can run what with elevated permissions. OSConfig, on the other hand, takes this concept and applies it to server configurations and security baselines, keeping everything locked down just the way you want.

Both tools have built-in drift control, so if anything strays from the defined policies, they’ll pull it right back in line. Both store policies are declared documents, giving them a blueprint to follow and making it easy to spot any discrepancies. Essentially, OSConfig brings the same self-healing compliance model to server configurations that EPM brings to privilege management, automatically correcting issues as they pop up.

It’s like having a system watchdog in place that knows exactly how things should look and acts fast if anything is out of place.

 Wrapping Up: OSConfig Today… and a Hint at What’s Next?

OSConfig isn’t just another configuration management tool, it’s a powerful, structured approach that ensures your server configurations stay locked in and compliant. With dcscvc handling the raw → cooked → applied flow and the refresh task keeping a constant eye out for drift, OSConfig provides reliable, automated control over your server’s settings and lets you deploy a security baseline within seconds.

But here’s the exciting part: if declared configuration policies can keep servers in line without the need for GPO-style refresh cycles, why stop there? Imagine a future where Intune pushes configuration baselines to workstations just like OSConfig does for servers. No more waiting for GPO refreshes—just a seamless, automated refresh task that keeps every device securely aligned with policy.

Declared configuration policies for Windows 2025 servers might just be the start. If OSConfig is anything to go by, we could be on the brink of a new era in device management, one where your entire fleet, from servers to workstations, stays securely in line with minimal intervention. I, for one, am eager to see where this journey takes us!