DSC: Be careful what you test for

When it comes to testing the state of our environment with Desired State Configuration it’s important to remember to keep it as lightweight as possible.

Take the following scenario:

You’ve built a custom DSC Module that installs, uninstalls or updates versions of a custom in-house piece of Software.

A new version of the Software is available and you want your test nodes to automatically install it without you having to do anything.

What options do you have if you want to do an upgrade of the version? Well let’s take a look:

Here we have what I think some people would end up making. A simple CIM query to check whether or not the specific product is installed and if so return its version.

Here is how long it takes to run a Query like this on my machine with not tons of Software Installed:

Not only did it take 18 seconds to return version information it also filled my whole application log up with tons of MSIInstaller ‘reconfigure’ messages.

Each time you run a query like the one above you’re going to get a fair bit more than you asked for. This can be problematic if you are using centralized logging for your servers and they all send this data off for processing and analytics.

Now imagine this query was part of your Test method which executed every 30 minutes on 300 machines. Now that’s a lot of spam events and wasted CPU cycles.

So how can we come up with a better solution to testing something so simple as version information?

Try and think of as lightweight approach as possible. An example would be a simple registry query to see if the item is held in HKLM. Using PowerShell we can simply navigate the registry with the registry PSprovider.

 

These examples will return within 1-2 milliseconds and will be able to tell you if a piece of software is a certain state or version.

Motto of the story:  Write your DSC test methods as if they were being executed on 100’s of Servers every 30 minutes.