LCM event log entries for different ConfigurationMode settings

DSC
1

I have been reviewing the “Microsoft-Windows-Desired State Configuration/Operational” log to see what gets logged for various settings of ConfigurationMode.

When the LCM is configured for “ApplyAndMonitor”, if a configuration value is incorrect, it logs a “Warn” level entry with an Event ID = 4249 that state:

>>>
From LCM, message is
Completed processing test operation. The operation returned False.
<<<

This is good, but is there a way to have it provide more information regarding what configuration is set incorrectly? If you are using “ApplyAndMonitor” mode the configuration would likely need to be corrected by some other means, so trying to figure out what is not correct could be difficult.

When the LCM is configured for “ApplyAndAutoCorrect”, if a configuration value is incorrect, it doesn’t log anything that states that something was corrected, much less what was corrected. I think it might be useful if it did especially if things were needing to be correct often so you could try and figure out why. Thoughts?

2

Kinda maybe.

This is kind of a shift in thinking. If you’re concerned about something specific being different, then you’re meant to just let DSC fix it, so it isn’t different anymore. DSC isn’t intended to be a setting-by-setting “auditing” tool. I do understand how that could be useful in some situations, but it isn’t the problem DSC was designed to solve.

You can GET the information. You’d dig not into the Operational log, but instead start a diagnostics trace and use the more-detailed Diagnostics log.

In “ApplyAndAutocorrect,” the intent is that DSC just makes sure nothing is different. Therefore, you don’t need to know what was different, because nothing is.

Again… it’s important to understand the problem that DSC is trying to solve, and not try to get it to solve other problems. It’s designed to give you a top-level “yes or no” indication, or even better to force a machine into a desired state. It isn’t designed to do a line-by-line audit.

3

I’m probably still getting used to the shift in thinking as Don suggests. While testing pull configurations, I do find some output to be useful. The following is just a copy of the scheduled task script that DSC runs periodically. It forces a consistency check instead of waiting until the RefreshFrequencyMins elapses. The “-verbose” flag added here, however, provides more details on the changes being applied:

# Declare params for CIM Method
$params = @{
  'NameSpace' = 'root/Microsoft/Windows/DesiredStateConfiguration';
  'Cl' = 'MSFT_DSCLocalConfigurationManager';
  'MethodName' = 'PerformRequiredConfigurationChecks';
  'Arguments' = @{Flags = [System.UInt32]1} 
}

# Call CIM Method to force consistency check
Invoke-CimMethod @params -Verbose

I’m using splatting instead of back ticks just like Don suggests :). When I run the above command from a PowerShell prompt to pull a config containing a test resource like this:

File TestFile {
     Ensure = "Present"
     DestinationPath = "c:\temp\HelloWorld.txt"
     Contents = "Hello World!"
}

I can get some verbose output like below:

VERBOSE: [VOSTRO]:                            [[File]TestFile] The system cannot find the file specified.
VERBOSE: [VOSTRO]:                            [[File]TestFile] The related file/directory is: c:\temp1\HelloWorld.txt. 
VERBOSE: [VOSTRO]: LCM:  [ End    Test     ]  [[File]TestFile]  in 0.0262 seconds.

Once I’m confident that the configuration works the way I want it to, I just let DSC do it’s thing to ensure the consistency just like Don says.

Still learning. Thoughts on approach ?

4

Using the “-verbose” switch with Invoke-CimMethod was an excellent suggestion!

I have a pretty long configuration and the LCM kept logging that the configuration was incorrect (i.e. using ApplyAndMonitor" for ConfigurationMode). When I used -verbose, I could see which resource was returning “false” during the test. It turns out that there’s (what I believe) a “bug” in the cAppPool community resource (cWebAdministration module) I downloaded from PowerShellOrg/DSC repository on GitHub. It was incorrectly using the “-eq” operator when it should be using the “-cne” operator when comparing the password associated with the identity the pool runs under. Without using the technique you suggested, I’m not sure how I would have been able to isolate where in the configuration the problem was occurring.

Thanks!

BTW - I submitted an “Issue” at PowerShellOrg/DSC repository on GitHub. I am new to GitHub, so hopefully submitting an issue is the best way to note what I found for the benefit if others.

5

Awesome, glad it was useful!