Summary: Windows PowerShell MVP, Will Anderson, begins a series of posts about using Desired State Configuration in Windows PowerShell.
Ed Wilson, the Microsoft Scripting Guy is here. Today we begin a series of posts about using Desired State Configuration (DSC) in Windows PowerShell by Microsoft MVP, Will Anderson. In fact, the series is so good that it is going to run all week. Take it away Will…
The best way to learn DSC
I’ve been meaning to blog about this for some time. I get a lot of questions from colleagues about the “best way to learn DSC.” The truth of the matter is that everyone learns differently. Although there are plenty of amazing resources available for learning about Desired State Configuration, I decided to write a series about how you can use your own scripts to learn by converting them to DSC.
This isn’t intended to be a bible about how to use DSC. There are plenty of other resources that are better. This is intended to be more of a walkthrough of how to get your first configuration working, to understand the concepts of building a configuration, and to get you on your way towards configuration management in a DevOps world.
What is DSC?
For the uninitiated, Desired State Configuration is a declarative language that leverages Windows PowerShell to provide a configuration management solution. It is capable of configuring a system, deploying software, measuring drift, and enforcing compliance where necessary.
Introduced in Windows PowerShell 4.0, DSC can apply these set configurations on systems that are on or off a domain, giving you reach where traditional tools, such as Group Policy, cannot. It can also be used in place of traditional “gold image” models, where base configurations are baked in to a standard image.
The obvious problem with the gold image solution is that if you need to update the image, you often have to rebuild the entire thing. This involves taking the time to rebuild the image, test and validate, and redeploy to your environment. Furthermore, if the change to your base image is a change that you also want to make in your existing environment, you have to create a separate workflow and solution to implement to your systems.
With DSC, you can make a change to your configuration and deploy it to new and existing systems. This reduces the amount of time you need to update and deploy your solution. Furthermore, your configuration serves as a document, which you can validate your systems against for auditing requirements.
“Configuration, security, auditing, compliance enforcement, and documentation in one configuration?” you say, “Tell me more!”
Along with the obvious ability to perform the aforementioned tasks in a Windows environment, DSC resources also have been created for Linux. Not only that, but the configurations you create can be utilized in automation frameworks such as Chef, Puppet, System Center SMA, and in Azure (we’ll get more into that later).
Now on to the fun! I’ll be using a portion of a configuration script that I wrote to deploy SCCM distribution points to servers, but I highly encourage you to try to follow along with some of your own configuration scripts. After all, what better way to learn than with the things we’re already familiar with? Time to get started. Tomorrow, we’ll dive in.
Thank you, Will. This is great.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. Also check out my Microsoft Operations Management Suite Blog. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy