Have you already heard about PowerShell Desired State Configuration?


What?! PowerShell, isn’t that for IT pro’s? I thought this was a blog by a developer. Well, it’s true that I am a software developer at heart. But that doesn’t mean you should ignore what’s going on in the IT pro world.

Why should you care: meet Bob and Joe

Meet Bob the Developer. Bob works on a great new application: project Unicorn. He uses cool techniques like Angular, ASP.NET MVC, WebAPI and Entity Framework to build a stunning SPA. But in essence his application is a web based app with a SQL Server database.

Bob has a great team of developers and they are producing quite some code. After a couple of weeks, a tester joins the team and asks if there is a testing environment available. So Bob goes of to the IT guys and asks them for a new machine. Fortunate as Bob is, it only takes a couple of days before his machine is ready! He gets the credentials to remotely access his Windows Server. Now as a true developer, Bob knows how to install IIS and SQL Server by clicking next –> next –> finish. After doing this, he copies his website and database to the machine, fiddles with some configuration settings and he’s good to go.

All of this is done through a set of GUIs like the Control Panel and Microsoft Management Console. Now that’s not a big problem for Bob. He knows how to do this. And while doing this, he installs his favorite tools and plugins for Windows. Who likes that new start menu on Windows Server? And having Visual Studio locally on the test environment is much easier to debug some stuff.
Meet Joe, the IT pro. Joe is given the job to prepare a production environment for  Unicorn. He looks at Bobs test environment, shudders and starts working on a production environment with all the bells and whistles that are required to get a stable and secure environment that’s up to his standards.
Joe uses PowerShell. He needs to configure a lot of machines and he doesn’t want to do it by hand. Instead he has collected a great amount of scripts over time that he stores on his hard drive and shares with some of his colleagues.

Things start breaking down

Until now, this doesn’t sound to bad. Maybe you have been a Bob or a Joe in a situation like this. But then, Joe calls Bob.

Joe: Your application doesn’t work
Bob: Yes it does. It not only works on my machine but also on the test environment
Joe: But it doesn’t work in production and that’s the only thing that matters

Bob who clicked through all his GUIs has no idea what changes he made. And so the search begins. After a long and heated search, Bob and Joe decide they really don’t like each other. Eventually the problem is found: a permission setting is required for a logs folder.

So what does this have to do with PowerShell Desired State Configuration

Can you explain what the following scripts does?

Configuration ContosoWebsite  
  param ($MachineName)  
  Node $MachineName  
    #Install the IIS Role  
    WindowsFeature IIS  
      Ensure = “Present”  
      Name = “Web-Server”  

    #Install ASP.NET 4.5  
    WindowsFeature ASP  
      Ensure = “Present”  
      Name = “Web-Asp-Net45”  

It’s not too hard is it? This is a PowerShell DSC script. It instructs a server to make sure that IIS and ASP.NET are installed.

This script is plain text. It can be read by a developer and an IT pro. Now imagine that Bob would have set down with Joe when he started preparing a test environment. Instead of clicking through a GUI, Bob asked Joe to help him create a DSC script. This script describes exactly what state the server should be in.

Since it’s just a script, it can be added to version control. Now that it is in version control, it can be added to the package that Continuous Integration build creates.

Release Management Update 3 has support for DSC. This means that after your build finishes, Release Management takes your DSC files and applies them to the set of servers you have in your environment. At the start, these machines can be completely clean. Everything is configured automatically when the DSC script gets applied. Whenever someone makes a manual change to a machine, the script reruns and the machine autocorrects itself.

Now that the script is finished, can you imagine how Joe setups the new production environment?

If you want to know more about PowerShell DSC, have a look at http://powershell.org. They have some great resources on DSC.

Feedback? Questions? Please leave a comment