Automating Windows Series – Chef on Windows

This is the first of a series of posts on automating Windows and deploying systems in the real world of enterprise operations. I’ve focused the series on the those nuances and problems that I’ve hit trying to deploy the various software stacks found in a typical Windows centric enterprise company.

To understand the nuances of running Chef on Windows you need to keep in mind that it evolved in the Linux\Open Source world. It’s a bit like humans trying to live on Mars, it can be done but you need to provide a special habitat and it takes longer to get things done sometimes.

Core to Chef is Ruby as the base programming layer that it defines its DSL in. Ruby’s performance and efficiency isn’t great in the Windows world. It’s a port from Linux and it isn’t optimised for Windows. What you’ll see is consistently high CPU usage during a Chef run, generally on a single cpu core. (I’ve found single core virtual machines suffer significantly during a Chef run in terms of other operations happening in parallel)

It also manifests in longer Chef runs especially with deploying a large number of Windows features for example.

The approach I’m taking more and more now is to utilise DSC resources within the Chef recipe which effectively hands off processing of the Windows specific configurations from Chef to the native DSC engine. A further post will go into the detail of how I’m implementing DSC in Chef.

Updating the Chef client is also a bit tricky, it ships as an MSI (A well built MSI that actually adheres to the MSI best practices) but you can’t update it during a Chef run for obvious reasons… Ultimately you’ll need to update it out of band to the Chef run, either with a different tool or by using a Chef recipe which sets up a scheduled task to run to do the update.

You will also need to make a decision on how the Chef client will run, will you trigger it on demand or run it as a service and have it automatically trigger chef runs. The good news is that the Chef client operates properly within a Powershell environment both locally and via remoting so there are plenty of options depending on your deployment processes.

The other key point to note is that Chef has ensured that Powershell is an option within recipes, both as a resource and as a guard interpreter (More on this later as well).

Advertisement

Automating Windows Series – Why Chef

This is part of a series of posts on automating Windows and deploying systems in the real world of enterprise operations. I’ve focused the series on the those nuances and problems that I’ve hit trying to deploy the various software stacks found in a typical Windows centric enterprise company.

The first question is why I chose Chef, especially considering it’s roots are definitely not in the Windows space!

Ultimately a choice had to be made and at the time it was made because of the following points.

• A large and vibrant community (Helped by the fact that Steve Murawski, an ardent fan and early DSC adopter, joined the Chef team).
• Chef identified early that it needed to embrace Windows and demonstrated a clear path to incorporating DSC into it’s DSL.
• Templates! Oh how templates makes deploying configuration files, where one or two settings need to be dynamic, so simple. I can’t highlight this enough, being able to drop text files and then dynamically modify a single field based on environment or node specific variables is a godsend.
• All the core functionality is open source and provides a complete system for managing and deploying configurations.
• The Chef server and in built search tools give operations the ability to do some simple but dynamic service discovery and configuration. Not as good as doing service discovery native within the applications but better than static configuration files.

Of course the big question is why not straight Powershell DSC? I spent a fair bit of time with DSC before I adopted Chef and I found there were some fairly large hurdles to overcome. Some of them are still relevant today and some have been remediated or will be in the not to distant future.

The really painful problem relates back to managing text based configuration files which have some dynamic content within them. There’s no native functionality within DSC that will allow you to handle config files in the same manner as say Chef, so you have to implement your own logic. I went right down a rabbit hole writing a custom DSC resource to manage nodes in a XML file for one POC before I realised I was going to have to do something similar for every text based file format.

There’s a basic framework around DSC configuration deployment that requires you to write a lot of Powershell to assemble a deployment system from base DSC to deployed configuration. It can be done but it takes a lot of work to maintain that sort of system and I’d rather spend my time writing configurations than the plumbing to keep deployments working. DSC being primarily a DSL means you can use it different deployment and configuration scenarios but ultimately it’s not a singular tool for the end user. Microsoft and others (like Chef) are going to wrap their own deployment methodologies around the DSC DSL.

So Chef got chosen as the platform for attempting to automate the Windows beast. Stay tuned for the follow up articles where I discover it isn’t all roses in the automation world.

To get started with Chef hit the root of their official documentation at https://docs.chef.io/ or for a guided set of tutorials https://learn.chef.io/tutorials/

SCCM 2007’s dirty little secret

I’m going to get this out the way first: Yes, I know SCCM 2012 has been out for a little while (and SP1 got launched too). Yes, I know it supports Windows 7 and 8 and has awesome new features for targeting applications at users.

But here’s the rub, there’s probably lots of companies with SCCM 2007 and XP who just want to get their company done and dusted with the Windows 7 upgrade, before they go and make life a bit more difficult by trying to do a SCCM upgrade, right in the middle of it.

I sure as hell do.

SCCM 2007 R3 was supposed to give us full support for Windows 7 and Windows 2008 R2 so that we can quickly migrate to Windows 7 and reap all the benefits of a new OS (Yes I know Windows 8 is out now, too).

So why in all that is holy was Fast User Switching not supported in SCCM 2007? Yes you heard me it isn’t supported, in fact what you will get is that the second user who logs on to a Windows 7 computer won’t see anything in “Run Advertised Programs” and no user targeted advertisements will run until the first person logs out. The split second that happens the SCCM client kicks in and RAP populates and all those wonderful app-v applications deploy.

You’ll find the support statement on this page on the TechNet site. No hotfix or update is available as far as I can see (if anyone can correct me I will be indebted to you!) and that’s just that. I’m partially placated by the fact that we’ll do a SCCM 2012 upgrade and get this sorted, but when you consider all the hoopla about Windows 7 and all the Teched sessions about deploying it, how did this slip by? (I must have missed the Teched session where someone mentioned FSU, probably the day after Techfest 😉 ).

It seems to be a constant frustration with the System Center suite, where core functionality gets ignored (Just see the twitter verse every time someone wonders allowed why Hyper-V replication can’t be managed by SCVMM)  and sends us back into the wild swing that is the love/hate relationship of SCCM.