More easily manage DSC nodes with sample Configurations–Part 3

In Part –1, we went over some of the new modules and scripts that I put together to help track GUID and Thumbprint information on a DSC Pull Server, and then used the install-*.ps1 scripts to install a new pull server as well as “Register” a node with it.  For part 2, we reviewed the DevOps model and how it drove the organizational separation of files, and then the various configuration files themselves.  For part 3, we are going to add passwords to the mix, the final part of the management puzzle.  In order to do that, we will configure a password file, populate it with some values, and build a configuration.

Setting up a Password repository

First things first:  the main reason I had such a delay in Past 3 was the realization that parts of my functions weren’t working properly.  So I retooled them, which means we have to re-download them.  Anyone coming from an earlier version only needs two files: the build-and-deploy master script, and the cDSCManager module.  Existing configurations and data should be just fine.  Relink for the lazy: https://github.com/Justin-DynamicD/DSC-Manager

The new module has a retooled “Import-PasswordXML” function.  While it’s typically called out by other cmdlet/functions we can leverage to setup a password repo very simply:

Import-PasswordXML [–XMLFile <string>] [–ToSession]

Both parameters are optional.  The first flag will specify an alternate xml file to store passwords in.  By default, they will be placed in the same management folder as the nodes.csv file.  If no file is found, it will create a file with a dummy entry to help new users with the format.  This is a clear text file, so for now lock this file away somewhere safe.  The function will dump all the passwords into a hashtable so it can be used by other functions, particularly useful for splatting.  Optionally, the “”-ToSession” switch will dump the variables directly into the current session.  The later switch is never used in my modules, but again:  a nice to have.

image

The credentials xml file is a pretty simple format.  You merely need to enter the variable name and credentials.  These variables get added to the wildcard node (“*”) in the configurationdata hashtable generated by Update-DSCMConfigurationData function.

Using the Passwords in a configuration

Because the function stamps all passwords in an encrypted format into the wildcard node, they are usable by _any_ node that needs passwords for their various configurations.  Therefore, if you haven’t guessed, it’s important that every variable remains unique.  Calling each variable is a straight forward process.  In the example composite configuration, you can see the domain controller passwords requested:

image

As wildcard entries apply to all nodes, each variable is called as a unique element of the node.  The Composite resource will then receive the data process it accordingly.  Another thing worth noting here: DSC configurations do not support splatting.  All variables in a call must be present.  If your imported password is missing, an empty parameter will get passed to the resource … which is not the same is skipping.  It also means that if you setup a new resource block then every defined parameter MUST exist on the node being passed to it.  To refer even further to the resource “DCConfig”, if I were to create a node and it didn’t have “DomainName” defined, DSC would error during operation, even if the resource being called had that parameter set as optional (Mandatory=$false).

On Parameters and Splatting

A final note on splatting.  In the original build-and-deploy sample, I called every variable individually which is … well … kind of a pain.  I’ve sense compiled all the variables into one large $parameters variable, much like an .ini file.  That said, mandatory parameters won’t accept splatting.   I don’t know why, but there is an easy way around this problem:  created a custom object out of each entry and passed it to the modules that way.  The result is a shorter line and more convenient:

Old Line:

Update-DSCMPullServer -Configuration $Configuration -ConfigurationFile $ConfigurationFile -ConfigurationData $UpdatedConfigurationData -PullServerConfiguration $PullServerConfiguration

New Line:

[PSCustomObject]$Parameters | Update-DSCMPullServer -ConfigurationData $UpdatedConfigurationData

The important thing is: both lines are valid.  As I mature this little module and it’s collection of functions, I may make further tweaks to the build-and-deploy script, but people who want to just call functions directly can continue to do so.  The Build-and-Deploy script is and always will as much reference as anything else.

Part 3 is shorter than the other two … but hopefully we are now in a point where we can do a few key things:

  • Track a Node’s GUID and Certificates
  • Automatically inject passwords from a separate file that wont be part of your check-in/out process.
  • Build a composite configuration that will allow you scale to a very large environment.

cDSCManager is going to continue to be my pet project for awhile.  Those who want to follow can look forward to me maturing the csv file and password repo and maybe even considering scale out options in the future.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s