LCM event log entries for different ConfigurationMode settings

This topic contains 4 replies, has 3 voices, and was last updated by Profile photo of Ameer Deen Ameer Deen 2 years, 6 months ago.

  • Author
    Posts
  • #15588
    Profile photo of Jeff Pflum
    Jeff Pflum
    Participant

    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?

  • #15589
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #15716
    Profile photo of Ameer Deen
    Ameer Deen
    Participant

    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 ?

  • #15731
    Profile photo of Jeff Pflum
    Jeff Pflum
    Participant

    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.

  • #15757
    Profile photo of Ameer Deen
    Ameer Deen
    Participant

    Awesome, glad it was useful!

You must be logged in to reply to this topic.