Windows

Today’s Read-Only Friday is about retiring/upgrading servers. Don’t worry no changing code today, but with Server 2012R2 going end of support Oct 10, 2023, I want to make sure you are aware and prepared to do it. By no means is this the definitive guide to do it, but hope this helps you create or improve your process for upgrading servers. Right now, I’d put a reminder in your calendar so you don’t forget and that you have enough time to take action on those servers.

I know it will depend greatly on what is on the server, but first thing before doing anything is making sure you have a valid backup. I’m not just talking about that your backup server of choice says it backed it up successfully, but actually restoring the server/files needed from the backup to ensure it works. We are decommissioning it for a reason, but while going through the process we want to make sure we have a backup just in case.

Next, I’d go through the server and make sure all services/software are documented as well as any important files. Even if you have documentation, I’d double check that all of it is correct, and that someone didn’t go out of scope and install something on it without documenting it. The last thing you need is when you shutdown the server or setup the replacement server that a department can’t do their work because the product they need isn’t online anymore.

A PowerShell one liner I’d recommend is “Get-WindowsFeature | Where installed” for one computer or you could run “Get-WindowsFeature -computername serv01,serv02 | Where installed” then you could pipe it to CSV or Excel to make it easier for documentation.

Then to get all programs installed

$InstalledSoftware = Get-ChildItem "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall"

foreach($obj in $InstalledSoftware){write-host $obj.GetValue('DisplayName') -NoNewline; write-host " - " -NoNewline; write-host $obj.GetValue('DisplayVersion')}

This can be exported as well for easier documention as well.

Now that we know we have good back ups, we know what services/applications installed, and we did a once over for any out scope configs, I would ask your team to look over what you have to make sure nothing was missed. The more you do these, the less time it will take, but it’s always good to have a second set of eyes on it.

Great, with it having a second set of eyes on it, we can now build the new machine. Depending on your virtualization platform(Hoping you a test environment, if not look at AutomatedLabs), I’d create a PowerShell script to build the server, or if you have templates already, I’d use PowerShell to make the copy then configure IP and any one off applications and servers, as well as any files that would need to be on it. Make sure all windows updates are done to ensure none of them will break it. Once you have confirmed everything is working on the newer server os, you can now deploy it to production(Make sure to turn off the old one if it will cause issues). Before deploying it to production, I’d send out communication to users in case for some reason there is an issue, they will let you know right away or if there is anything they have to do on their side.

At this point I’d put all of the documentation for the new server together if you haven’t already which should be easy, as most of it is right in scripts. Once the new server has been working for a safe amount of time as it will depend on the importance of server, you can remove the old server and test server from your host(s).

I could definitely go in more depth on this, and if you have any questions on checklists or what to actually keep for documentation, let me know and I’d be glad to help out.

And yes, I know this is a Read-Only Friday topic, but most of the hard work is on the planning/documenting side which you can do on Read-Only Friday.