PowerShell DSC: Enterprise-grade Management of Node / Configuration ID Data

Early in the lifecycle of any technology, before widespread adoption, both the vendor and the user community go through a process of developing best practices through iterative experience. With PowerShell DSC, we are very much in the midst of that process. While that process is continual, it is often more challenging in the early phases.

There is a question that comes up frequently that came up again recently in a thread on PowerShell.org, titled “PowerShell DSC: Composite Configurations / Node GUID Management” in which a user asks:

I’d be curious to understand how others manage the (DSC Configuration ID) GUID associations in their environments. Do you maintain them in a flat file stored on the network somewhere? Do you upload them to a database? Do you use custom Active Directory attributes?

and PowerShell guru Don Jones responds:

I’m not sure AD is the right answer for everyone; a key part of DSC is that it doesn’t depend on AD. Now, in an environment where every node is in AD – sure, you could use an attribute there to track the machine’s DSC GUID. That’d work.

I certainly don’t think a spreadsheet is the way to go, but a SQL Server database would be a good solution. You could easily build a script that queried the database, built the necessary LCM MOFs, and pushed those to computers to configure them for pull.

While there may not be an official best practice, if we plan to scale for enterprise, the best practice is already well-known. I’ll share the answer with you in just a moment.

SIDEBAR: In case you are not 100% familiar, the Configuration ID (present in the Local Configuration Manager properties on a node managed with DSC) indicates a GUID which is used to get a particular configuration file from a server set up as a “pull” server. The GUID ensures that the correct configuration file is accessed. Each managed node (server) can pull down only one configuration, so ensuring secure and accurate management of node / GUID associations is of critical importance. Read more at http://technet.microsoft.com/en-us/library/dn249922.aspx.

Easy (but not ideal) Storage of Node GUID Associations

Before we talk about how to properly store these node GUID associations, let’s talk about how not to do it. From an enterprise point of view, less than ideal choices include (but are not limited to):

  • Text file
  • Excel file
  • Active Directory

It is not that these approaches will not work (for the most part), but they each present their own challenges. When we think about manageability for the enterprise, we need to think about authority (as in “authoritative sources of information”), security, scalability, and with due regard to process (change management, for one).

Text files and spreadsheets, even in a secure share, can likely be accessed by multiple administrators and even accidentally overwritten, making these poor choices as authoritative sources for maintaining an important setting such as the DSC Configuration ID. Since not all servers may be listed in Active Directory, it is equally unsuitable for the task. If you manage an enterprise and are using these approaches, now is a great time to consider a better, more secure and manageable approach.

Don was definitely onto something when he mentioned ‘a SQL database’, but the true enterprise best practice will be more specific that than that.

Best Practice Node GUID Management for the Enterprise

Before I just blurt out the answer, I want to provide a little background. Manageability for IT operations is a topic I think about a lot. I also frequently speak to audiences about process automation, management and cloud self-service for enterprises at Microsoft and community conferences like MMS, TechEd and System Center Universe. Here are links to a few of my recent sessions (MMS 2013, TechEd 2013 and TechEd 2014).

One point we emphasize in all of these sessions is the need to consider ITIL / ITSM as a core component of end-to-end design and best practices for process automation. This means integrating automated processes with our enterprise configuration management database base (CMDB), which stores two primary types of data (and the relationships between them):

  • Work items, including incidents, problems, changes, releases, etc.
  • Configuration items (aka CIs) like computers, network devices, etc.

Let me elaborate on why the CMDB is the ideal authoritative source to manage DSC Node / GUID associations.

Typically, 100% (or close) of the computers we manage with PowerShell DSC should be in the CMDB, even if they are not in Active Directory (such as UNIX / Linux systems and network devices), making it a more complete datasource than Active Directory (which is typically only one of many sources of data used to populate the CMDB). And it does not really matter which tool your organization has chosen to implement a CMDB: System Center 2012 Service Manager (SCSM), Remedy, CA, HP, ServiceNow.
All of these CMDBs will have a Computer CI class of some sort. While none of them will have a property on their Computer class called ‘DSC Configuration ID’, all will likely have extensible fields you can use for this purpose as well as a way to add a custom property to the computer class. The process will vary by platform, but here is a good tutorial on how to extend a CI class in SCSM 2012.

How to extend and populate a CI class in System Center Service Manager 2012

Just as we can query a MS SQL database with T-SQL or PowerShell, enterprise CMDBs will likely be hosted on MS SQL, Oracle or other OLE DB database accessible by similarly simple means. Retrieving a list of computers and their DSC Configuration ID from the SCSM CMDB will be a couple of simple lines of PowerShell.

What’s more, enterprise CMDBs have role-based security and auditing built in to identify who has added, removed or changed a CI (SCSM included), ensuring your computers and their DSC Configuration ID are secure.

Bottom line: In an enterprise where scale, security and manageability are important, the CMDB should be your go-to repository. We’ll explore using SCSM as this repository in-depth in a future installment.

Additional Resources

If you are new to PowerShell DSC, here are some resources to help you get further, faster.

Presentations (TechEd, etc.)

The DSC Book by Don Jones

Presentations (TechEd, etc.)

PowerShell DSC Articles and Samples on System Center Central

Presentations (TechEd, etc.)

PowerShell repository on Github

Presentations (TechEd, etc.)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.