Configuration baselines in Configuration Manager: build, deploy and remediate drift

Compliance settings are the part of Configuration Manager (SCCM) that keeps checking a setting after you deploy it, and puts it back if someone or something changes it. In this post I'll build three typical configuration items (a registry value, a WQL query and a PowerShell script), bundle them into a configuration baseline and deploy it with remediation. Then I'll show where to confirm it's working.

How it works#

A configuration item (CI) contains settings, which say what to read (a registry value, a WMI property, a script's output and so on), and compliance rules, which say what the correct value is. A configuration baseline groups CIs. You deploy the baseline, not the individual CIs, to a device collection with an evaluation schedule. The client evaluates it, reports the result in state messages and remediates if you've allowed it to.

Check two client settings before you start. Compliance Settings › Enable compliance evaluation on clients must be Yes. Computer Agent › PowerShell execution policy controls whether unsigned scripts run. Its default is All Signed, so either sign your scripts or set Bypass for the devices that need them. From version 2207, client settings also include a script execution timeout for compliance settings.

Step-by-step#

1. A registry value with automatic remediation#

1. Go to Assets and Compliance › Overview › Compliance Settings › Configuration Items and choose Create Configuration Item. Give it a name, select Windows Desktops and Servers (custom) and, on Supported Platforms, pick the Windows versions it applies to.
2. On Settings, choose New and set: setting type Registry value, data type Integer, hive HKEY_LOCAL_MACHINE, key SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters, value RequireSecuritySignature. This value requires SMB client signing. Test it against older NAS devices first.
3. On the Compliance Rules tab, add a Value rule that says the setting must equal 1. Select Remediate noncompliant rules when supported and Report noncompliance if this setting instance is not found. You can also select Track remediation history when supported. Then choose a noncompliance severity; Critical with event also writes an event to the Application log.

Registry values are the easy case. If the value is wrong, the client sets it; if it's missing, the client creates it. Remediation only works when the rule's operator is Equals.

2. A WQL query that only reports#

Create a second CI the same way, this time with a WQL query setting that checks whether the system drive is BitLocker-protected:

• Namespace: root\cimv2\Security\MicrosoftVolumeEncryption
• Class: Win32_EncryptableVolume, property: ProtectionStatus, data type: Integer
• WHERE clause: DriveLetter = 'C:'

The rule is Equals 1 (protection on), with remediation left off. Not every CI should fix things: this one reports, and BitLocker policy does the enforcing (see BitLocker management in Configuration Manager).

3. A PowerShell script with discovery and remediation#

Scripts cover everything else. The third CI makes sure SMB 1.0 stays disabled. Use setting type Script and data type String. The discovery script:

$feature = Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
if ("$($feature.State)" -in 'Enabled', 'EnablePending') { 'NonCompliant' } else { 'Compliant' }

The remediation script:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart -ErrorAction Stop | Out-Null

Add a Value rule of Equals Compliant with remediation enabled. A few rules for scripts:

• The client runs PowerShell with -NoProfile and treats the script's output as the setting value, so output exactly one value and nothing else.
• To report a failed remediation properly, the script has to throw an exception. A non-zero exit code isn't enough, which is why the remediation uses -ErrorAction Stop.
• Leave Run scripts by using the logged on user credentials off for machine settings, so the script runs as Local System.
• The remediation doesn't restart the device. The feature shows DisablePending until the next restart, and the discovery script counts that state as compliant.

4. Build and deploy the baseline#

1. In Compliance Settings › Configuration Baselines, choose Create Configuration Baseline, name it and use Add › Configuration Items to add your CIs.
2. For co-managed devices whose Device configuration workload has moved to Intune, select Always apply this baseline even for co-managed clients. Without it, those devices don't apply the baseline.
3. Select the baseline and choose Deploy. Select Remediate noncompliant rules when supported and, if the collection has maintenance windows, Allow remediation outside the maintenance window. Then pick the collection and a schedule; daily is a sensible start for security settings.

Remediation needs both switches: the one on the compliance rule and the one on the deployment. With only one of them, you get reports but no fixes. That's the most common reason a baseline "doesn't remediate".

Verify#

On a test device, open Control Panel › Configuration Manager, go to the Configurations tab, select the baseline and choose Evaluate. View Report shows the result for every rule. You can also check from PowerShell:

Get-CimInstance -Namespace root\ccm\dcm -ClassName SMS_DesiredConfiguration |
    Select-Object DisplayName, LastComplianceStatus, LastEvalTime

If a CI reports an error or a script never seems to run, look in %WinDir%\CCM\Logs:

In the console, the deployment status shows devices as compliant, non-compliant, error or unknown. On the baseline's Deployments tab, right-click the deployment and choose Create New Collection to build a collection of non-compliant devices, ready for follow-up. Standard reports live in the Compliance and Settings Management category. If you tracked remediation history, the v_CIRemediationHistory view shows when each device was fixed (times are in UTC):

SELECT s.Name0 AS Device, h.RemediationDate
FROM v_CIRemediationHistory AS h
JOIN v_R_System AS s ON s.ResourceID = h.ResourceID
ORDER BY h.RemediationDate DESC

Tips & gotchas#

• Don't fight another policy. If a GPO or an Intune profile sets the same value, each tool keeps undoing the other, and the remediation history shows the same devices every cycle. Fix the setting at its source.
• Feed compliance into Conditional Access. A baseline can be evaluated as part of compliance policy assessment. On co-managed devices, an Intune compliance policy can then require compliance from Configuration Manager.
• Moving to Intune? The closest equivalents are Intune Remediations for detect-and-fix scripts and custom compliance for report-and-block.

References#

• Create custom configuration items for Windows desktop and server computers
• Common tasks for managing compliance with the Configuration Manager client
• Co-management workloads