Welcome to another in our series entitled “Modernizing Your Infrastructure with Hybrid Cloud”. As you may be aware, this week the theme is “Management and Automation”. As a part of that theme I’m sharing with you an introduction to Desired State Configuration (DSC); more completely called Windows PowerShell Desired State Configuration.
DSC is a relatively new (less-than-a-year-old) technology, introduced with PowerShell v4.0, that lets IT define what the configuration of a server will be, apply that configuration, and then verify (and remediate) so that the configuration is still in place and as-desired.
“So, it’s like System Center Configuration Manager?”
No. It’s built-in as a part of Windows, and is configured and implemented using PowerShell. Sound interesting?
“I’m listening.”
Good. In the context of one blog article naturally I won’t be able to go into every detail, but I hope that this article, some simple examples, and some additional resources at the end will get you excited for trying this out. And ultimately that you’ll see the immense value that this will give your IT and, of course, you’re business.
A Simple Example
For our quick example let’s assume a couple of things. I’ve enabled the Windows PowerShell DSC feature on a server named “Server1”. Server1 is a member server in my domain. I’ll be using an administrative account from another server (called Admin) to apply configuration to Server1.
I open up the PowerShell ISE and enter the following text. Can you tell what it’s doing from what the text says?
“It looks like it’s defining something that’s a ‘Configuration’ and calling it ‘IISWebsite’. And for your server named Server1, it’s laying out what Windows Features should be installed!”
Exactly! And in this PowerShell session, when I execute the configuration, I end up with a .MOF file, which is a definition on behalf of how Server1 should have the Web Server and ASP.NET 4.5 installed and running. All I need to do is run the Start-DSCConfiguration PowerShell cmdlet with the proper parameters referring to the .MOF file and pointing to Server1, and DSC configures the features and enforces that they always be there as I desired In fact, even if I or another administrator were to manually remove the ASP.NET 4.5 feature from the server, after a period of time the state would be re-evaluated and the configuration would be fixed!
What if, like those “WindowsFeature” sections, I were to add a “File” section like this:
Basically what I’m saying is, “Here’s the source folder of content that I want you to make sure is always found under this destination.” Ah.. and doesn’t the path look like it might be a web site folder? Yes! This configuration not only enforces that IIS be installed and running, but that the contents of a web application be always there and that the destination code always matches what is coming from the source! Someone could go in there and, say, delete some of the web content, but DSC would fix it automatically!
“Hey Kevin… What’s a .MOF file?”
Yeah.. this was a very quick, very simple example. Let me go through and briefly describe the parts that make up DSC…
The Parts – Configuration
The configuration is what we built in my earlier example. It’s a PowerShell definition that, using “Resources” (defined next) specify how things should be configured; our “desired state” for the configuration of a target server.
The Parts - Resources
In our example above, you notice that I’m defining what Windows Features are to be installed. I can do this because there is a built-in DSC “Resource” called “WindowsFeature”. From the TechNet Documentation, “Resources are building blocks that you can use to write a Windows PowerShell Desired State Configuration (DSC) script.” Windows comes with a number of these built-in resources that know how to specifically work with, configure, and enforce various aspects of the operating system. Resources for working with the registry, the file system, Windows Features, services… and many more, are included in the list of built-in DSC resources.
But it gets even better. These resources are just PowerShell modules. And just as you have the ability to create your own modules to extend PowerShell, you also have the ability to create your own custom resources!
The Parts - The .MOF file
This is the file that contains the configuration to be applied. It’s the result of executing the configuration definition in PowerShell, and is in a standard format as defined by the DTMF.
“Hey Kevin - Why do we even really need a .MOF file? Can’t Microsoft just do what it needs to do directly from PowerShell?”
I’m sure they could. But the beauty of using the .MOF is that because it’s a DTMF standard, it is formatted in a way can be applied to different machine types and for various purposes. In fact, at TechEd in Houston earlier this year I saw Jeffrey Snover actually use DSC to create a .MOF that then configured a Linux server running an Apache web server. (Yeah.. we’re “open” like that these days!)
The Parts - How It’s Deployed
The full name, “Windows PowerShell Desired State Configuration” is a hint about how you enable the DSC capability. It is a feature of Windows Server 2012 R2, found here in the Add Roles and FeaturesWizard:
When you check the box, you’ll notice that it will also install some Web components to your server…
This is because one of the ways DSC configurations are securely pulled is to use IIS.
The Parts - Push-me-Pull-You?
One important aspect of DSC is that it becomes even more powerful when you can distribute configurations, or maintain consistent configurations among many machines, all from a smaller number of source locations. DSC allows either a simple “push” distribution, which is simple and more manual, and a “pull” distribution where not only do you apply a configuration to a machine but you also tell it where it should be looking for its configuration and any changes going forward. Pulling can take place over HTTP (not recommended), HTTPS (recommended), or SMB Share permissions (okay because it’s authenticated access).
“Why isn’t HTTP recommended?”
Think about the damage someone could do if they hijacked DNS and then pointed to and automatically applied someone else’s version of a server configuration to your servers. Scary prospect, indeed.
The Parts – The Local Configuration Manager
The Local Configuration Manager is “the Windows PowerShell Desired State Configuration (DSC) engine. It runs on all target nodes, and it is responsible for calling the configuration resources that are included in a DSC configuration script.” So basically when you’ve enabled the DSC feature on a server, this is the service that either takes the pushed configuration, or pulls the configuration, and then applies it as defined in the most recent .MOF file.
For More Information…
Like many of you, I find that I learn best by looking at other people’s examples. And thankfully in the case of PowerShell and DSC there is a really big community already formed and willing to share what they have done with the rest of us. Here are some of the places I recommend you check out and save to your favorites if you’re really going to get serious about using Desired State Configuration:
- PowerShell.org, and specifically the DSC Forum found there.
- Recording of Don Jones’ TechEd North America 2014 session – A Practical Overview of Desired State Configuration
- Windows PowerShell Desired State Configuration Overview– The Official Documentation
If you want to try it out in a virtualized lab environment:
And finally, don’t forget to check in frequently at our “Modernizing Your Infrastructure” series landing page, to see all the great articles our team has created and resources we’ve shared.