Diagnose policy compliance and baseline drift

A compliance result is a measurement with a scope

Keep the intended setting, measurement method, target, expected value, baseline version and observation time together. A deployed baseline doesn’t mean this endpoint was measured against that revision. For a Group Policy change, keep the GPO ID/domain, client processing results and actual application behavior too.

This note uses Configuration Manager current branch where it is deployed, alongside offline SCT baseline validation. A Configuration Manager configuration baseline is an assessment/deployment construct, distinct from an AD GPO. SCT does not generate the old SCM DCM packs; do not try to make a retired CAB workflow the foundation of current monitoring. Current SCT format boundaries.

Follow the chain to the last successful stage

Follow the stages until you find where progress stopped. A baseline can exist in the console without a deployment to the intended collection. A disconnected client can evaluate a previously downloaded baseline, then report when it reconnects. Configuration Manager’s compliance model explains the separate operations.

A branch laptop’s central report may predate its remediation while its local evaluation is newer. An assignment in the console also doesn’t tell you whether the laptop downloaded the latest item revision. Compare both timelines before changing the rule or forcing broad reevaluations.

Identify the deployment, not just its display name

One baseline can have different deployments, collections and schedules. In an existing Configuration Manager PowerShell session connected to the appropriate site drive, a read-only query is:

Get-CMBaselineDeployment -Name 'Workstation security assessment' |
    Select-Object AssignmentName,AssignmentUniqueID,TargetCollectionID

Keep every matching assignment and choose the intended one explicitly. Use its assignment GUID to find the deployment’s client scheduler entries; a baseline name won’t identify the same thing. See deployment correlation and scheduling.

The configured evaluation schedule is a target, not a guaranteed completion time. Inspect the current client’s launch conditions, pending state and randomization in Scheduler.log when an expected run is absent. Group Policy’s refresh/foreground requirements, compliance evaluation and central report refresh have separate clocks. Shortening one interval cannot repair a failure in another stage.

Read unknown and error states honestly

In deployment status, follow Error to the discovery/evaluation error, and Non-Compliant to the failed rule and observed value. Unknown means no compliance report for that deployment. On the client’s Configurations tab, Unknown can instead mean it hasn’t evaluated the baseline yet. Unreported devices won’t necessarily all have the same cause.

Configuration Manager can return a rule as compliant when its item wasn’t detected or wasn’t applicable, without evaluating the rule. If you’re checking that a required protection exists, look at applicability and coverage behind the green aggregate. See Microsoft’s monitoring semantics.

Count expected targets, received assessments, applicable/evaluated items, mismatches, errors and stale/unknown results separately. Ninety matching observations from ninety reports tell you nothing about ten intended endpoints that never reported. Keep those devices visible in the fleet result.

Drill down to a testable finding

For a disputed item, retain:

1. The device/user and the baseline/item revision actually evaluated.
2. The detection/applicability outcome and the specific rule.
3. The expected and discovered values, including type, units and source.
4. Evaluation time, execution context and any error.
5. The relevant GPO processing instance and an independent check of the setting or operation.

Describe what the test actually found: “this applicable rule read this value at this time” tells you more than “password policy failed.” If it uses a script, check exactly what the script reads and returns. For registry data, check the hive/view and user context. Fix a mistaken discovery rule before changing production to satisfy it. Configuration-item definitions distinguish settings, rules, detection and supported platforms.

Use the client’s logs to locate the gap

Collect the relevant time window rather than an unbounded directory dump:

Use the current log reference and deployment guide to check each log’s scope. Match item/deployment IDs and timestamps before combining messages. Some logs also cover applications or software updates; finding a message in one doesn’t identify the baseline involved.

Validate a fresh result and keep remediation deliberate

The client caches evaluation results for 15 minutes. A reevaluation inside that period can return cached data; after a controlled change, establish that a genuinely new evaluation occurred before interpreting the same result as failed remediation. Client evaluation/cache behavior.

Assessment and automatic remediation need separate decisions. A supported remediation rule can change registry, WMI or script-managed state, and deployment options govern whether remediation may occur outside maintenance windows. Review those settings and script behavior before using an assessment as if it were passive. Remediation deployment options.

After a repair, test the protection and dependent application, then check a fresh local evaluation and its central result. Does the drift return after policy refresh, application installation or restart? That can point to another source changing the setting. Repeatedly correcting the value won’t fix that cause. Keep the approved exception or remediation and the next check with the finding.