Troubleshooting a Large DSC ConfigurationStatus Folder and Repairing Broken DSC State
A surprisingly large C:\Windows\System32\Configuration folder can consume tens of gigabytes on a Windows Server. One common cause is the DSC (Desired State Configuration) status history stored in the ConfigurationStatus folder.
In this case, the folder contained more than 30,000 status files and consumed over 40 GB of disk space. Although the Local Configuration Manager (LCM) was configured to retain status information for only a limited number of days, old files were still present, indicating that the cleanup process was no longer working correctly.
A structured approach helps determine whether the problem is caused by excessive status files, corrupted DSC state information, or a failing configuration.
The process consists of three main steps:
- Analyze the current DSC configuration and status history.
- Clean up old status files that are no longer needed.
- Repair DSC and identify any configuration resources that are failing.
Following these steps helps reclaim disk space, restore DSC functionality, and identify configuration issues that may prevent DSC from running successfully.
A large ConfigurationStatus folder is often the first sign that DSC status retention is no longer working correctly. Before making any changes, determine how much space is being consumed and whether old status files are accumulating.
First identify the operating system version:
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
This helps determine whether known DSC issues may apply to the server version.
Count the number of status files:
(Get-ChildItem "C:\Windows\System32\Configuration\ConfigurationStatus").Count
A very high number may indicate that status files are no longer being cleaned up automatically.
Calculate the total size:
Get-ChildItem "C:\Windows\System32\Configuration\ConfigurationStatus" -File |
Measure-Object Length -Sum
Review the oldest files:
Get-ChildItem "C:\Windows\System32\Configuration\ConfigurationStatus" |
Sort-Object LastWriteTime |
Select-Object -First 10
Review the newest files:
Get-ChildItem "C:\Windows\System32\Configuration\ConfigurationStatus" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 10
Comparing old and new files helps determine whether retention is working and whether DSC is still actively generating status data.
The ConfigurationStatus folder contains historical DSC execution information. When retention stops working correctly, the folder can grow to many gigabytes and contain thousands of old files.
Before deleting anything, stop the WinRM service and create a backup location:
Stop-Service WinRM
New-Item D:\DSCBackup -ItemType Directory
A practical approach is to remove status files older than 30 days:
Get-ChildItem "C:\Windows\System32\Configuration\ConfigurationStatus" |
Where-Object LastWriteTime -lt (Get-Date).AddDays(-30) |
Remove-Item -Force
This removes only historical status information and leaves recent records intact.
After the cleanup, verify whether DSC can read the remaining status information:
Get-DscConfigurationStatus | Select-Object StartDate,Type,Status
If DSC status retrieval works again, the problem was likely caused by old or corrupted status files.
If the same deserialization error continues to appear even after removing the historical data, the issue is likely deeper than the status history itself and may involve corrupted DSC state information or a failing DSC configuration.
Cleaning the folder reduces disk usage, but additional troubleshooting may still be necessary to restore full DSC functionality.
If cleanup does not resolve the issue, the next step is to investigate DSC itself.
First restart the relevant services:
Restart-Service WinRM -Force
Restart-Service WmiApSrv -Force -ErrorAction SilentlyContinue
Next, review the DSC operational log for detailed error messages:
Get-WinEvent -LogName "Microsoft-Windows-DSC/Operational" -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List
The operational log often reveals the resource responsible for the failure.
To test the current DSC configuration, manually start a configuration run:
Start-DscConfiguration -UseExisting -Wait -Verbose
In this scenario, DSC reported a failure in the MSFT_AccountPolicy resource while attempting to update the Minimum_Password_Length setting.
This indicates that:
- DSC is still able to load the current configuration.
- The active configuration contains a failing resource.
- The failure may be caused by a conflict with local or domain password policies.
- Corrupted DSC status information may be generated when the configuration repeatedly fails.
At this stage, review the DSC configuration source and verify whether password policy settings should still be managed by DSC. Correcting or removing the failing configuration and then applying a new configuration is typically the final step in restoring a healthy DSC environment.
Once the folder size is known, inspect how DSC is configured and whether it should be removing old status records.
Check the types of files stored in the status folder:
Get-ChildItem "C:\Windows\System32\Configuration\ConfigurationStatus" |
Group-Object Extension |
Sort-Object Count -Descending |
Select-Object Count, Name
This provides insight into what DSC is generating and whether unexpected file types are present.
Review the Local Configuration Manager (LCM) configuration:
Get-DscLocalConfigurationManager | Select-Object *
Pay particular attention to:
| Setting | Purpose |
|---|---|
| ConfigurationMode | Defines how DSC applies configurations |
| RefreshMode | Determines how configurations are received |
| StatusRetentionTimeInDays | Controls how long status history is kept |
| RefreshFrequencyMins | Defines how often DSC checks for updates |
Finally, inspect the recorded DSC execution history:
Get-DscConfigurationStatus -All
If DSC reports deserialization errors, the status history or DSC state information may be corrupted and additional repair steps will be required.
Comments