How to Test Configuration drifts at target Nodes – part 7

This is seventh part of 10 series blog on LCM APIs and Internals. In last part, we saw “How to Send and Apply Configuration to target Nodes” using three different methods, namely WMI, CIM and DSC Cmdlet.

In this post, we will continue our journey and would see “How to Test Configuration drifts at target Nodes” using the same three methods.

Last few posts discussed and described the process of sending and applying configurations to the target nodes. In this post, we will look at testing the configuration for their validity and check their drifts from their expected configuration. If there is a configuration drift then either we can re-apply the configuration using ApplyConfiguration method shown before or leave it as is.

Testing the validity of existing configuration on target nodes is responsibility of LCM. This method return true or false as “InDesiredState” depending on whether the target node is matching the expected configuration or not. It is to be noted that testing of configuration only checks the current configuration with expected configuration. It does not apply the configuration to remove the gap or drift in configuration. There is a DSC cmdlet names Test-dscconfiguration that tests the configuration together.

Using DSC Cmdlet

Test-DSCConfiguration cmdlet is used to test a target node for its validity against expected configuration. It need not be send any parameters and it would check the validity of the node on which it runs. To check the validity of a remote server on network, it accepts a CIMSession which can be configured for a remote server. The execution and syntax is shown here.


Windows Management Instrumentation (WMI)

We can use WMI Cmdlet to test the Configuration. We can see in Image below that we are invoking a WMI method named “TestConfiguration” on class “MSFT_DSCLocalConfigurationManager” available in WMI namespace “ROOT\Microsoft\Windows\DesiredConfigurationManager”. This method has two output parameters. “InDesiredState” results into true or false depending whether there is a configuration drift. “ResourceID” does not return any value and is empty.


The result is shown here.


Common Information Model (CIM)

All the steps remain same with that of WMI however the only difference is using a CIM cmdlet instead of WMI cmdlet and parameters are sent as hashtable.


The result is shown here.


Hope this Post helps!



Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s