When the grim reaper comes for an operating system we all know what that means; no more security updates, software vendors stop supporting it and essentially it's a forgotten soul in the Microsoft ecosystem.

It's obviously important to keep your server infrastructure current not only to continue getting security updates but for all the reliability improvements and features that new operating systems can get you. This is the most obvious benefit but sometimes the biggest benefit for getting servers current is standardization.

Ahh, beautiful standardization. Standardization nirvana is that moment when all your servers are running exactly the hardware with the same firmware, the same OS, have exactly the same configuration and you're using Powershell DSC to ensure they all stay that way. When you make a change to one you know with 100% certainty that the change will behave in exactly the same way on all your other ones. Just take it all in for a moment.....

OK, back to reality. No one lives in standardization nirvana but we all strive to get there. What some people don't understand is that not prioritizing server upgrades and focusing more on standardization not only affects security but also makes you pull your hair out when you try to roll out a change to all your servers. I love examples and I've got just the one for you.

Today I am planning to deploy an application to a few hundred servers. This application requires some registry tweaks, files copied and a Windows feature installed; perfect for a Powershell script, right? Yes; a 20 line script maybe, but this script, when fully tested across the 7 different Windows OSes and different architectures turned into a 100 line beast! Why? Read on...

First, it needed a Windows feature installed. If I had Server 2012 across the board it'd just be a simple matter of:

Add-WindowsFeature FEATUREHERE

However, I have Server 2008 RTM which requires:

Import-Module ServerManager Add-WindowsFeature FEATUREHERE

A small change yes, but nonetheless a difference. I then have Server 2003 which is completely different:

Start-Process 'sysocmgr.exe' -ArgumentList "/i:$($env:SystemRoot)\inf\sysoc.inf /u:$WorkingDir\SCCM_SNMP_Install.txt /r /q" -NoNewWindow -Wait 

Now I've turned my 1 line script into something like this:

## Find the chassis architecture to decide which MSI to install
$Architecture = (Get-WmiObject -Class Win32_ComputerSystem).SystemType

## Configure SNMP
$OperatingSystem = (Get-WmiObject -Class Win32_OperatingSystem).Caption
if (($OperatingSystem -like '*2008*') -or ($OperatingSystem -like '*2012*')) {
    if (Get-WindowsFeature SNMP-Service | where { !$_.Installed }) {
        ## Do something
    } else {
        ## Do something else
    }
} elseif ($OperatingSystem -like '*2003*') {
    if ($Architecture -eq 'x86') {
        ## Do Something
    } elseif ($Architecture -eq 'x64') {
        ## Do something else
    }
} else {
    ## Do something else again
 } 

This is just for a single function like installing the SNMP service! Imagine if this script had to do all kinds of other stuff that depended on the OS and architecture. It would (and did) greatly increase testing time, is more error-prone due to more moving parts and is frustrating as hell because you tweak one thing on one OS which breaks on another.

I don't write this post just to gripe (really!) but to bring to light the importance of standardization. Standardization (and simplification) are sometimes looked over because their benefits are "gooey". It's easy to say "Less stuff is better if you get the same thing done" because it makes sense but proving that is another story. The same goes for standardization. It makes so much sense when you say it'd be tons easier to manage 1,000 of the same servers rather than 200 different ones but quantifying that may not come so easy.

Develop a standardization mantra and question any "required" exception to this incessantly. Remember me the next time you're making a bulk change across your server environment and that single, super-critical Windows 2000 server in the janitor closet that no one remembers goes belly up because it just so happened that the service your bouncing had some crazy dependency on another service that killed that LOB application running on it!

Join the Jar Tippers on Patreon

It takes a lot of time to write detailed blog posts like this one. In a single-income family, this blog is one way I depend on to keep the lights on. I'd be eternally grateful if you could become a Patreon patron today!

Become a Patron!