Upgrading Windows Server 2003: The procrastinator's guide

Yes, this is something you really need to get going on. Here are some factors to consider in your planning

lifebuoy on wooden wall rescue overboard preserver saver
Thinkstock

Windows Server 2003 support ends on July 15, as you may have heard. For some organizations -- mostly smaller or newer businesses -- this does not have any significance: They are most likely backing up to the cloud, using cloud-based apps and have a cloud-ready NAS on site.

But if you're part of a medium-sized company, especially with custom line-of-business applications, or a larger company with extensive investments in IT infrastructure, you probably have Windows Server 2003 machines all over the place. Although there were around 10 million Windows Server 2003 machines deployed at the beginning of 2015, best guesses from Gartner and Microsoft peg the number that will still run the old OS post-support deadline at between 2 million and 3 million.

Some of you may not be entirely sure what workloads those Windows Server 2003 machines are running, much less how you are going to forklift those applications and services over to a platform that is supported. If that applies to you, how will you cope with the end of support for Windows Server 2003? What are your most realistic options? We will discuss all of that.

Is this important?

Let us tackle the first issue up front: Is the end of support something to care about? From a pure technical-support standpoint, probably not. If you have been invested in Windows Server 2003 for this long, chances are you have institutional memory enough to solve Windows Server 2003 usage and troubleshooting problems, and failing that, the World Wide Web has plenty of historical information on problems and solutions for this platform.

Why you should care: Patches and updates for flaws and security holes will stop coming as of July 15. This means that there could be huge holes in Internet Explorer, or in the TCP/IP stack built into Windows Server 2003, or in the DLLs that Internet Information Services loads -- but none of those features and services will be protected against hackers looking to take advantage of flaws they find.

And find them they will. Most security researchers agree that many flaws have already been found and opportunistic ne'er-do-wellers are holding on, waiting patiently to unleash their attacks exploiting these flaws until Microsoft bids adieu to patch development.

In other words, these bad actors are simply waiting to attack what are fast becoming defenseless systems just sitting out there. While your existing perimeter security and layered defenses may stop some of these attacks, others can slip into your network through the tiniest of holes, with what could be catastrophic consequences.

So yes, the end of support is important.

A nuanced approach

However, if you have critical business applications -- an old production deployment of a content management system, or an inventory and enterprise resource planning package made by a company that has long been out of business -- that function only on Windows Server 2003 and SQL Server 2000, then you do not have the luxury of saying "Damn the torpedoes! We are upgrading!" You must take a more nuanced approach.

An overall migration plan for Windows Server 2003 has many components and should involve a lot of decisions, an anticipated timeline and a lot of checking and rechecking. As you are developing your own plan, some considerations might include the following:

Make sure you are properly licensed for what you are now running and the platforms to which you are migrating. If you are current on your volume license agreement with Microsoft, then this is an easy one: You are already paying for the right to use more current software. If you do not have a volume license agreement, or you have let an existing agreement lapse, you need to check the details, as you may have either permanently purchased that software or perhaps you are only permitted to run the software for the term of your Open subscription. In all cases, make sure you are properly licensed to move to a more current version of Windows (and that is Windows Server 2012 R2, for what it is worth).

Decide on a landing point. This is somewhat specific to the different workloads and applications that you need to deal with, but you are going to need to figure out what you are migrating to once you have decided to move off Windows Server 2003. I see many, many organizations standardizing on Windows Server 2008 R2, which was released in 2009 and will be well supported through 2019. I see many organizations also moving to Windows Server 2012 R2, although (somewhat anecdotally) these companies seem to be more invested in the cloud.

Please do not make the mistake of just jumping up one version, to Windows Server 2008 (not R2), just because you also have a bunch of servers running that release. You will just compound your misery in a couple of years when it comes time to move off this. The oldest release I would consider standardizing on for this migration is Windows Server 2008 R2.

Keep in mind that there is also a new server release coming in 2016, although for most companies I do not think it makes sense to delay the migration off of Windows Server 2003 with the intention of landing on a brand new server release that is more than a couple of months off. For organizations with just a couple of servers running specialized applications that are relatively cordoned off from your network and the wider Internet at large, waiting until 2016 might be a reasonable approach, but there is still risk involved. Exercise due care in making your selections.

Purchase new hardware if necessary. Those machines that are running Windows Server 2003 are most likely in desperate need of replacement, and Windows Server 2008 was the last version of the server operating system to be supported on 32-bit hardware, so you will need to purchase x64-compatible hardware anyway.

When in doubt, size up, because you might also use this opportunity to continue virtualizing some applications, and bigger and better hypervisor hosts are never unwelcome in these situations. For some companies, this is less of a problem, as you may have already virtualized your instances of Windows Server 2003 on a later version of the OS's hypervisor, or have moved to an alternative platform like VMware or XEN, so all you have to deal with is the software problem and not the silicon underneath.

Find the solution to your application incompatibilities. This whole migration may well hang on more than one "which came first, the chicken or the egg?" sort of conundrum -- you want to move off Windows Server 2003, but your application cannot run on Windows Server 2012; it can only run on Windows Server 2008, but to do that requires you to downgrade SQL Server which you cannot do because you do not have the right licenses and so on.

That is why I always advise companies to focus on the end game: The applications. After all, your users do not need to interact with a certain version of Windows Server. You do not get customers or fulfill orders with Windows Server 2008; you do so with a line-of-business application. So step one is to figure out how to get the applications where they need to be and the rest of the puzzle will fill itself in.

What if you simply cannot migrate off Windows Server 2003 because you have something that just cannot exist in any other state? This is that space between a rock and a hard place that many companies running heavy-duty industrial equipment find themselves in. Often the hardware that controls big equipment like CNC machines, lathes and other specialized devices runs a specially customized installation of Windows Server 2003 (customized by the manufacturer, not by Microsoft itself) that is supported only in that special state.

Touch it, change it, and things stop working and then the vendor will not talk to you. In this case, the primary threat for these machines that you need to mitigate is the connection to the Internet. In most cases, you can look into deploying an air gap -- either physically or virtually -- between the system that is frozen in time and the perimeter of your network.

(Air-gapping means partitioning older, unsupported machines off the network, and specifically off the Internet, so they are not likely to get hurt or infected.)

This technique ought to mitigate 90% or more of the potential surface for attack for Windows Server 2003, as it will make it nearly impossible for the machine to have malware downloaded directly onto it. The air gap should also assist in making the machine far less susceptible to internal malware running rampant on your corporate network.

On the downside, this air gapping technique does involve more sneaker-netting-style administration activities since network access is significantly reduced -- on balance, though, this technique is definitely the recipe for success here. But now is the time to figure out what your plan is for when these machines break.

Come up with the timeline. You can expect one last Patch Tuesday in July, when the final payload of Windows Server 2003 patches in the queue at Microsoft will be released. Then, there will be silence.

You will want to establish a timeline after this last Patch Tuesday where you have half of your remaining machines moved by X date -- I suggest no more than three months after this last Patch Tuesday -- and all remaining machines that do not have "showstopper" type incompatibilities moved by the end of the year. This will leave only the machines that you need a long-term plan to migrate (hopefully, in 2016).

Immediately after this last Patch Tuesday event next month, however, I recommend putting into place both the air gap discussed in the last bullet point for those systems with migration-preventing incompatibilities and also have a plan by August 30 on how those systems will be maintained and scanned via manual methods.

Why so aggressive a timeline for any of these components? For one, you can expect a hacker field day. Second, these types of migrations tend to consume a lot of your IT resources. When you are planning migrations, you are not adding value to your business or driving it forward, either, so it makes sense to go ahead and actually move what you can now and get it over with. Do it carefully, but get it done, in other words. This way you can get back to actually creating business value and not spend time in the weeds of operating system maintenance.

It's time to move

Regardless, you are going to have to develop a plan of some sort. While Microsoft has released emergency patches and updates for Windows XP even beyond the date they committed to stopping servicing that operating system, it has been months since those out-of-band updates were released.

This is generally because the Windows XP Embedded release, which operates in a "sealed" environment inside ATMs, point of sale systems and other dedicated use devices, was still supported and much of the codebase was similar; the company lost little by deploying those emergency updates since they had to work on them and test them against a decent swath of devices.

However, that situation may well change: Even the embedded versions of Windows XP end their supported lifecycle soon. And with Windows Server 2003 sharing much of the same base of code with these operating systems, there will be little reason for Microsoft to continue to develop updates when there are no active operating systems sharing that code remaining in a supported part of their lifecycle.

Even corporations with support contracts may find updates are farther in between and fewer -- and those updates will generally not be widely deployable because they will be tested against a large company's known application and installed base, not against the millions of variations of configurations for computers the general public owns worldwide.

The time to migrate is here. How do you plan to move off Windows Server 2003?

This story, "Upgrading Windows Server 2003: The procrastinator's guide" was originally published by Computerworld.

Copyright © 2015 IDG Communications, Inc.