Skip to content

Windows 2016 and DSC – Like Peanut Butter and Chocolate

We’ve all heard about DSC, right? Sure you have. Maybe you’ve been playing around a bit in labs or using for test environments. Why haven’t we all taken the plunge to Infrastructure as Code ( or more accurately Infrastructure from Code)? Because it’s hard, and we’re busy?

Likely, it’s because we don’t have the opportunity to go all ‘greenfield‘ in our daily jobs. Most of us live in the depressingly named ‘brownfields.’ We have servers already, we have workloads on them that are of different importance to our companies. We can’t just rip everything out and replace it! Oh but wait! Most of those machines are running older versions of Window Server or have old hardware. We’re going to need to do an upgrade/replacement plan anyway.

I know a lot of us have those old servers that run some important job. Maybe we virtualized when the hardware broke, but otherwise, they are still on 2008 or god forbid 2003. We can’t manage them with the latest tools because they have an old version of PowerShell ( if at all). We want to get rid of them, but what a daunting task!

Why not combine these two tasks? Two birds one stone and all that. Build out a pull server, and rebuild your infrastructure the “Modern” way. Don’t upgrade those VM,s construct new ones and shift the workload over. That ensures the cleanest installation and configuration. Since you’re configuring them from scratch, why not do it with DSC?

Here’s what I’m in the middle of right now: I have several physical servers at or near the end of life. I have a few 2008 servers still lingering. I want to get all my servers on 2016 to take advantage of several newer technologies. To make our Hyper-V hosts more efficient, I want to move as much as possible to Server Core.  I had used DSC for several small servers but not in a truly ” production ” manner. Time to upgrade!

Here’s my plan in broad terms:

  1. Build out a pair of new load balanced secure Pull Servers – using DSC Push Mode.
  2. From there, make a BASE configuration shared by all servers and inject that MOF into the image I’m using to build new VMs. This base config contains things like domain join, setting up the LCM with where to look for the pull server, network set up, etc.
  3. Create configurations for the server Archetypes – File Server – Web Server – App Server – Backup Server – Domain Controller – etc.
  4. Write some basic Pester tests to verify that the configurations are doing what I expect.
  5. Start standing up servers, pushing configs and testing. Once tests pass…..
  6. Move to production mode!

At some point, I plan to move the whole shooting match from Github to Visual Studios Team Services for source control and test beds. It would be nice to be able to apply a MOF file to a VM in Azure, run pester tests, and upon a full pass, have it deploy that new MOF to the on-site pull servers. But that’s a learning curve for another day!

Leave a Reply

%d bloggers like this:
Verified by MonsterInsights