Desired State Configuration (DSC) Nodes Deployment and Conformance Reporting Series (Part 1): Series agenda, Understanding the DSC conformance endpoint

  • Article

In any configuration management process, once the configuration is applied to the target systems, it is necessary to monitor these systems for any configuration drift. This is an important step and Desired State Configuration (DSC), which is addressed differently depending on the chosen deployment mode for DSC - push mode or pull mode.

In the push method for configuration delivery, the configuration MOF file is copied manually or via another solution to the target machine, and the Start-DscConfiguration cmdlet provides an immediate indication of success or failure of the configuration change (You can also run Start-DscConfiguration and specify -computer.  This assumes the modules are there but it invokes over WinRM).

Now, in large scale deployments, it is likely you will want to look at the pull method of configuration delivery. In this mode, the target systems receive or download configuration from a pull service, based on their ConfigurationID. This can either be a SMB file share or a REST-based pull service endpoint. When using the REST-based pull service endpoint, to facilitate monitoring of configuration enact process, we can deploy a conformance endpoint that provides the last configuration run status from the target node.

This blog series will focus on some examples of how to optimize pull mode configuration deployment, and how to report on the health of DSC nodes in such an environment

This whole series has been a joint effort with guest blogger Ravikanth Chaganti. It is our first series of posts with Ravi, but he’s been PowerShell MVP since 2010 and a regular contributor to PowerShellMagazine.com . He also publishes on his own blog . More specifically in this series, Ravi is behind the updated configuration to simultaneously deploy the pull service and conformance endpoints, and how to query and report with the conformance endpoint. It’s been a pleasure to work on this content with Ravi, and we look forward to any potential collaboration in the future!

Blog post series agenda

There are 4 blog posts in this series:

  1. Series agenda, Understanding the DSC conformance endpoint (this post)
  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?

Understanding the conformance endpoint

You may wonder why there are separate posts to report on the status of configuration being downloaded/applied (blog post #3), and to report on enforcement (upcoming blog post #4). This relates to something that is critical to understand before implementing the conformance endpoint: As of today, the conformance endpoint retrieves status about nodes as they download/apply configurations – or fail to do so. While this first level of information is important (understanding that configuration application should work if this first process is “green”), it does not provide status about whether a node is actually compliant regarding the configuration it is supposed to enforce. Blog post #4 explains ways to surface the actual configuration health and drifts, something we may also revisit and enhance as Windows Management Framework (WMF) 5.0 brings new features.