Monday, May 19, 2014

Why Powershell Desired State Configuration?

I am a huge fan of Powershell. I use it where I can to manage my infrastructure and workstations. Powershell remoting is such a wonderful thing. I start to think about my infrastructure as nodes or objects in code. As someone that shifted into IT from development, this becomes a very powerful tool. 

I craft and test my commands on test workstations. I then take those commands and order all of my nodes in AD to go take care of it. I see a job spin off for every one at almost the same time. And I know they are doing exactly what I am telling them to do. It just gives you that feeling of power. It is even better when you can see and hear it happening.

Our largest dental clinic has 50 chars in it. Each cubicle has dividers between them, 2 people could stand up in opposite corners of this large room and they could see each other. There is a central control station that faculty use where I love to issue remote commands. When I send something like Wake On Lan to all the clinics, I can hear every machine in there click on at almost the same time. I can hear the fans spin up and I can see the monitor glow cast a blue shine across the room. There is nothing like seeing your code interact with the real world like that.

This is the perfect fix it now type of remote scripting. This is great for when I want to refresh group policy for flush DNS on every node. I target my Active Directory nodes and say go take care of this. But not every script is a fix it now type of script.

Because I blindly target nodes when I do this, some slip through the cracks. Maybe WOL was miss configured, bios has a low battery warning, the mobile user is out of the office, or it is a spare machine sitting on a shelf. I am left with several machines for whatever reason missed the script. I don't care so much when I flush dns on everything but what about enabling bitlocker? That just has to get taken care of. So I have to decide how to handle this going forward. GPO, SCCM, scheduled task on some random box, or I run this script again when I think about it. 

Personally, I make that call case by case and use whatever I think is best for the change. I have to consider newly deployed machines, returning machines, and how likely those settings will drift. And this is where Desired State Config starts to enter the picture. We have to remember it is just another tool like GPO or SCCM, but it does have a lot to offer.
DSC lets you declare how a system should look, and it will take care of it for you. You once again get to say "make it so" and the system takes action. Not only does this set configurations on nodes, it makes sure they stay configured. With a pull server in place, they never miss a command. You set it and forget it. 

I am just getting started with DSC and I love the idea. Still not sure it is the best match for my current environment, but I think it is important we take notice of it. I felt Powershell was overlooked by a lot of people for the longest time. Step back and see how important Powershell has become already. And when they Jeffery Snover says the reason they created Powershell was so that they could create Desired State Config, you know this is something you should pay attention to.

I don't think we will see this for workstation management yet, it is only a matter of time before we see tools like SCCM switch over to use DSC.

No comments: