PowerShell DSC: Choosing Between Apply and ApplyAndAutoCorrect

The Problem: DSC Says Compliant, But the Server Isn’t

You deploy a PowerShell DSC configuration that sets a Windows service to Automatic and starts it. Days later, an administrator changes the service to Disabled for troubleshooting and forgets to change it back. DSC still reports the node as compliant because the Local Configuration Manager (LCM) is running in Apply mode: it checks the state, notices the difference, logs it, and stops there. The service stays disabled until someone notices the outage.

This is a common engineering decision in PowerShell DSC. The LCM is the agent that runs on every target node. It decides whether DSC merely reports drift or actively repairs it. Choosing the wrong ConfigurationMode means your configuration documents drift instead of preventing it.

LCM Configuration Modes: Apply, ApplyAndAutoCorrect, ApplyAndMonitor

The LCM runs consistency checks on a schedule you define. During each check, it compares the node against the compiled Management Object Framework (MOF) file and acts based on ConfigurationMode:

• Apply: Applies the configuration once, then reports any drift in subsequent checks without changing anything.
• ApplyAndAutoCorrect: Applies the configuration and automatically corrects drift on every consistency check.
• ApplyAndMonitor: Applies once and reports drift, but does not correct it; used mainly for testing new configurations.

ApplyAndAutoCorrect is the self-healing option. It keeps production servers close to their declared state without manual intervention, but it can also reboot a node or overwrite an intentional emergency change if your resources trigger those actions.

Worked Example: Configure LCM for Auto-Correction

Run the following on the target Windows Server in an elevated PowerShell session (Run as Administrator). Replace C:\DSC\LCMConfig with your actual output folder.

# Save this as Configure-LCM.ps1
Configuration LcmAutoCorrect {
    Node 'localhost' {
        LocalConfigurationManager {
            ConfigurationMode = 'ApplyAndAutoCorrect'
            RefreshFrequencyMins = 30
            RebootNodeIfNeeded = $true
        }
    }
}

# Compile the MOF
LcmAutoCorrect -OutputPath C:\DSC\LCMConfig

# Apply the LCM settings
Set-LocalConfigurationManager -Path C:\DSC\LCMConfig -Verbose

Where to run: Target node, elevated PowerShell console.
Permissions: Local Administrators group; DSC writes to WMI and the LCM registry.
Expected check: Set-LocalConfigurationManager should return without red error text. The verbose stream shows the LCM accepting the new refresh frequency and mode.
Risk: With RebootNodeIfNeeded = $true, a resource that requires a restart can reboot the server during a consistency check. Schedule this during a maintenance window or set it to $false until you confirm resources are restart-safe. To revert, change ConfigurationMode to Apply and re-run Set-LocalConfigurationManager.

Verify the Result

After the first consistency cycle, run these checks on the same node:

# Confirm the LCM is in the expected mode
Get-DscLocalConfigurationManager | Select-Object ConfigurationMode, RefreshFrequencyMins

# Test current compliance against the applied MOF
Test-DscConfiguration -Verbose

# Review recent consistency runs
Get-DscConfigurationStatus -Last 5

Test-DscConfiguration returns True when the node matches the desired state. Get-DscConfigurationStatus shows each run, start time, and whether resources were modified. For deeper troubleshooting, open Event Viewer and look in the Applications and Services Logs > Microsoft > Windows > Desired State Configuration channel for operational events.

Limitation: Auto-Correction Can Fight Intentional Changes

ApplyAndAutoCorrect does not distinguish between accidental drift and a deliberate, temporary change. If an administrator stops a service for maintenance, DSC may restart it on the next cycle. In environments with frequent ad-hoc changes, start with Apply to measure drift volume, then enable auto-correction only on resources you are confident should never drift.

DSC v1 on older Windows Server versions also has limited error handling for concurrent configurations. Confirm your management framework version before deploying:

$PSVersionTable.PSVersion
Get-DscResource | Select-Object Name, ModuleName | Format-Table -AutoSize

Actionable Closing

Pick one non-production server and set its LCM to ApplyAndAutoCorrect with a 30-minute refresh. Run Test-DscConfiguration after the first cycle, then intentionally change a non-critical setting and confirm DSC corrects it within the refresh window. Once you trust the behavior, promote the setting to production servers in stages, and document which resources are allowed to trigger reboots.