Working with the Desired State Configuration Feature (Part 5)

If you would like to read the other parts in this article series please go to:

In the previous article, I showed you how to run a script in order to make sure that a server adheres to the required state. In this article, I want to continue the discussion by showing you what it looks like when you run the script on a server that does not adhere to the required configuration. From there I am going to show you some ways to automate the execution of the script in the next article. Later, I will explore some other things that you can do with a Desired State Configuration script.

As you may recall, our original script that we have been using was designed to test for the presence of the Hyper-V role on a Windows Server. Unfortunately, I don’t really have a way of demonstrating what happens if you run that script on a server that doesn’t have Hyper-V installed because I don’t have the any available hardware that isn’t already running Hyper-V. So with that said, I made a few modifications to the script. You can see these modifications in Figure A.

Figure A: The script now checks for the presence of the Web Server feature.

As you look at the figure above, you can see that I am using the same basic script as before, but I have made two changes. The first change is the Node name. I am using a node called Web. Web was the NetBIOS name of a Windows Server 2012 R2 Web server that I used in another article series that I wrote for this site. The other change that I made was that I am checking to make sure that the Web-Server role is installed on the server instead of checking for the Hyper-V role. After all, a Web server can’t do its job if the Web Server role isn’t installed.

As before, I executed the script by entering the ./PoseyConfig.ps1 command. This causes the MOF file to be created.

So the first thing that I am going to do is to manually check for the presence of the Web Server role. I can do this without a script by entering the Get-WindowsFeature Web-Server command. As you can see in Figure B, PowerShell confirms that the role is installed.

Figure B: PowerShell confirms that the Web Server role is installed.

Of course this raises the question of why we even need a Desired State Configuration script if we can use a simple PowerShell command to test for the presence of a server role. Well, there are two main reasons.

First, a Desired State Configuration script can do more than just check to see if a role is installed. I have just been using that particular function for demonstration purposes because it is easy to follow.

The second reason why you would need to use the Desired State Configuration tool is because the tool can perform remediation. Sure, you could write PowerShell code to test for the existence of a server role and install the role if necessary, but it would be a lot easier to just use the Desired State Configuration tool rather than write all that code.

So with that said, Figure C shows what happens when we run our script with verbose output. As you can see in the figure, the operation succeeded. As you may recall from the previous article, running the script without the –Verbose switch produces no visible output.

Figure C: Here is what happens when we run our script.

As you can see in the figure above, our script has essentially confirmed the presence of the Web Server role. So what happens if we remove that role from the server? Let’s go ahead and try it! As you can see in Figure D, I am removing the Web Server role from the server. In Figure E, you can see that I have used PowerShell to confirm the role’s absence.

Figure D: The Web Server role is being removed from the server.

Figure E: PowerShell confirms that the Web Server role is no longer installed.

So now that the Web Server role is no longer installed, let’s go ahead and run our Desired State Configuration script. When I run the script, the script immediately detects the absence of the Web Server role and begins installing it, as shown in Figure F.

Figure F: The Desired State Configuration tool begins installing the Web Server role.

If I run the Get-WindowsFeature Web-Server command one more time, you can see in Figure G that the role’s status has changed from Available to Installed.

Figure G: The Web Server role’s status changes from Available to Installed after running the Desired State Configuration script.

One thing that I want to quickly mention before I move on is that depending on the type of operation you are performing with your Desired State Configuration script, it may be necessary to reboot the server after the operation is complete. For instance, removing the Web Server role usually requires a reboot.

As you can see, the script worked flawlessly. It automatically installed the missing server role. There is just one thing that you really have to think about.

We have been working with a really simple script. There is almost no danger of the script doing something unexpected because the script is so short. However, real world desired state scripts can be much longer. They may evaluate dozens of configuration options across multiple servers. So with that in mind, how can you make sure that your script isn’t going to do something crazy when you run it?

My advice is to test the script prior to executing it. To show you what I mean, I have gone back and manually removed the Web Server role from the server shown in the previous screen capture. So with that said, let’s pretend that we suspect that a server is suffering from configuration drift and we want to use the Desired State Configuration tool to verify the problem and fix it. Let’s also assume however, that our script has never been tested and that we need to make sure that it works before running it.

The best thing to do is to test the script. As you will recall, we ran our script by using the Start-DscConfiguration command. Instead, we can use Test-DscConfiguration. You don’t need to use any parameters with this command.

When you run this command, Windows will automatically look at your MOF file even though you aren’t actually telling it to do so. It will use the .MOF file to determine whether or not the computer adheres to the desired state. If the computer does not adhere to the desired state, a status of False will be returned. If the computer does adhere to the desired state, the status will be True.

To show you what I mean, check out Figure H. I removed the Web Server role and ran the TestDscConfiguration command. The status was shown as False because the required role was missing. From there, I installed the required role (that part isn’t shown in the screen capture) and then re-ran the Test-DscConfiguration command. This time I got a status of True because the required feature was installed.

Figure H: Test-DscConfiguration tells you whether or not the system adheres to the desired configuration.

Unfortunately, this test doesn’t give you a granular report, but you can run the test against servers that are in a known state in an effort to determine whether or not your script is working correctly.

Conclusion

In this article, I have shown you how to test for configuration drift and how to use the Desired State Configuration Tool to perform automatic remediation. In the next article in this series, I am going to show you some options for making the script run automatically.

If you would like to read the other parts in this article series please go to: