Testing a DSC configuration with Invoke-DscResource

Let’s imagine that you’re working on a fairly complex DSC configuration and you made a small change to the section shown below which you’d like to test.

001 002 003 004 005 006 007

File 'ConfigFile' {     Type = 'File'     Ensure = 'Present'     SourcePath = '\\dc1\ConfigFiles\config.txt'     DestinationPath = 'C:\configs\config.txt' }

For the sake of this imaginary scenario, let’s assume you’re using a pull server.  One way you could test your change is to do the following:

1. Generate the mof file
2. Copy it to the pull server
3. Create the checksum
4. Run the DSC configuration on your target node to test

While this test will certainly work, you’re now reapplying the whole configuration just to test that one small section which you changed.  If you got something wrong and it fails, you have to repeat the whole process again to test it a second time.  In many cases, I have found this to be overkill and a major time waster when all I’m trying to do is verify that my change works as expected.  For scenarios like this there’s a much easier way thanks to the little-known Invoke-DscResource cmdlet.  Let’s take a look at how it works.

The code below shows the same configuration as above but instead of being part of a larger configuration that has to be applied via your pull server, it’s now a standalone piece of code that you can test anywhere.

001 002 003 004 005 006

Invoke-DscResource -ModuleName PsDesiredStateConfiguration -Name File -Method Set -Property @{     Type = 'File';     Ensure = 'Present'     SourcePath = '\\dc1\ConfigFiles\config.txt';     DestinationPath = 'C:\configs\config.txt';     } -Verbose

Notice that we’ve taken our configuration from above and simply placed it in a hash table which we pass to the Property parameter.  The screenshot below shows the output after running the command – exactly the same as if we’d gone through the lengthy process of creating the mof and pulling it from our pull server!

Another powerful use for Invoke-DscResource is that you can use it to verify whether a server is in the desired state for a given configuration.  All you need to do is change the Method parameter from Set to Test.

PowerShell Calculated Properties

A little-known but very powerful feature in PowerShell is the ability to create your own properties and then use them as if they were built-in properties of whatever object you’re working with.  Let’s take a look at a real-world example where this feature came in handy for me.

I recently needed to find out in which OU each member of a group was.  You can get part of the way there by using the distinguishedName property for each user in the group but that also includes the user’s name at the beginning, for example:

CN=Mary McAfee,OU=Finance,OU=Accounts,dc=mydomain,dc=corp

Not too difficult to get just the OU from that – with a bit of string manipulation we can get rid of the CN= part and we’ll have just the OU.  The great thing about calculated properties is that we can make this calculated OU attribute a property of each user.  Let’s see how we do that in the script below.

001 002 003 004 005 006 007

param (     $GroupName ) $ou = @{Name = 'OU';Expression = {$($_.DistinguishedName).Substring(($($_.DistinguishedName).IndexOf(",") + 1))}} Get-ADGroupMember $groupName -Recursive | select SamAccountName, $ou

 

On line 6 we create the OU property, give it a name and then tell Powershell how to calculate it in the “Expression” section.  To calculate our OU property, we’re simply taking the DistinguishedName property of the user and getting all the text after the first comma.  Then, on line 7 the magic happens.  All we have to do is tell PowerShell to the select the $ou variable we created in line 6 and our calculated property will be returned as if it was retrieved directly from AD as shown below.

 

There you have it – an easy way to retrieve the OU of each account in a group using a very powerful PowerShell feature, calculated properties.