Desired State Configuration (DSC) Nodes Deployment and Conformance Reporting Series (Part 4): Using Operations Manager to check for configuration enforcement

  • Article

In the previous post for this series, we discussed how the conformance server reports on the health of configuration download/application on the nodes. Here, we will look at how you can report if nodes are actually enforcing their expected configuration. For example, let’s say you wanted a specific file to be present on a node. Is this file currently present? Can we consider the machine compliant from that standpoint?

On a DSC-enabled node with a configuration applied, one way to query this information is to Test-DSCConfiguration. This cmdlet returns true or false, depending on…you guessed it…if the node is currently enforcing the expected configuration or not.

Today, we will look at how you can use the Operations Manager component of System Center to surface this enforcement information in a centralized console. This post explains the inner workings and features of a sample “Management Pack” for Desired State Configuration - that we are providing for download - and similar concepts could be applied to other monitoring solutions.

image_thumb38

Stay tuned for more news on this topic, as there are several improvements planned in that area in Windows Management Framework (WMF) 5.0 current and future previews. For example, this sample management pack uses the same cmdlet to query WMF 4.0 and 5.0 nodes, and does not leverage new WMF 5.0 cmdlets like Get-DscConfigurationStatus. We’re looking at providing a more complete management pack leveraging these new features, including more lightweight and detailed status queries, and also the ability to work on triggers instead of monitoring schedules. The main goal of the release of this sample is to get you acquainted with the possibilities, with future enhancements on the way.

How does the sample management pack work?

Once imported in the Operations Manager console, this management pack will be automatically distributed to all machines running an Operations Manager agent. Each machine will then “discover” if it is running WMF 4.0 or higher, and if a DSC configuration is active. Both conditions need to be validated, in order for a node to show up in the “DSC Nodes” state view from the management pack. It does not matter if the node is configured to use “pull” or “push” mode, as both situations are monitored, and identified as such in the console.

image_thumb39

As you can in the middle/bottom pane in the previous screenshot, other properties are also discovered, like the PowerShell version, the refresh mode (push or pull) and the configuration mode (Apply and Monitor, Apply and AutoCorrect…). You can use these in the monitoring views, but also to create groups. The management pack comes with a set of dynamic groups, feel free to explore how they are structured. Groups can then be used to filter views or apply monitoring exceptions (called “overrides” in the Operations Manager world). For example, the “non remediated” alert view is scoped to nodes that have a configuration mode set to “Apply ad Monitor”.

image_thumb40

Once a DSC configuration has been discovered on a node, a “monitor” will regularly check if the configuration is being enforced, by running Test-DscConfiguration. Depending on the outcome, the monitor and node turn to a warning state or stay/return to a healthy state. This history can also be seen in the node’s “Health Explorer” in the Operations Manager consoles (full console or web console). This also means that you can leverage built-in Operations Manager features like Availability or Configuration Changes reports!

image_thumb29

An associated alert is then triggered as needed. It is also automatically closed if the configuration is returned to an enforced state, either manually or automatically. (As a side note, you may want to create custom views for alerts closed in the last 24 hours, so you can also see which situations were remediated automatically)

image_thumb30

When a node is in a warning state, you would have to investigate the reason why. One of the ways to do so could be to use the “Get DSC Configuration” tasks included in the sample management pack. This tasks can be located on the right side of the console, unless the task pane has been collapsed in the console options. The task uses the Operations Manager agent channel to run the Get-DscConfiguration cmdlet directly on the corresponding agent, and returns the output. Once again, WMF 5.0 should provide new ways to provide more details in the console.

In our example, the simple configuration being applied and checked is this one, and it just tries to ensure a directory is present locally, copied from a network folder as needed:

image_thumb37

This is what the task returns for a machine where the expected file and folders where not found:

image_thumb31

And this is what it returns for a machine where the file/folder are indeed present, as expected. Actual output will depend on the configuration applied to the machine.

image_thumb32

 

Download location

The sample management pack is provided unsealed at this location:

BC-DLButtonDark

 

Prerequisites and installation/configuration process

  1. Import the management pack in the Operations Manager console. This sample management pack was created and tested with System Center 2012 R2 Operations Manager
  2. (optional) Updates discovery and monitoring intervals. By default, discovery runs every day, and monitoring runs every hour.

Remember that DSC nodes will only show up in the state view if they are running WMF 4.0 or WMF 5.0 Preview, AND have a configuration enabled.

 

A few notes

  • Test-DscConfiguration may create some noise when it is run when a configuration is pending a reboot – since the new configuration can make changes while test continues to work against the old one.
  • Test-DscConfiguration is also less lightweight on the machine, than more optimized methods coming in WMF 5.0. The impact should likely not be visible anyway, since the monitor runs every hour by default, and can be configured for a different interval. Again, stay tuned for more information on this, and how to leverage it with a monitoring solution.

We hope you will find this information and sample management pack useful, and are looking forward more announcements in this area.

Blog post series agenda

  1. Series agenda, Understanding the DSC conformance endpoint
  2. How to deploy a pull service endpoint and automate the configuration of the DSC nodes
  3. How to leverage the conformance endpoint deployed along with part of the pull service endpoint, to report on accurate configuration deployment and application : Are my DSC nodes downloading and applying the configurations without encountering any errors?
  4. Some options to determine if the nodes are conformant with the given configuration: Are my DSC nodes conformance with the configuration they are supposed to enforce? (this post)