Microsoft’s deadline has come and gone, and you have all gracefully transitioned your desktops from the now unsupported Windows XP to a better, more secure operating system. Right?
If you haven’t, or have chosen to ignore Microsoft’s warnings, then please click here and here, and come back when you have taken care of business. If you have dutifully moved your users off of XP, then take a breath and get ready, because you have miles to go before you sleep.
It’s been a long, long time…
The new deadline that you face is the end of support for Windows Server 2003. On July 14, 2015, all flavors of Windows XP’s big brother in the data center will cease to receive code updates, meaning bugs will go unpatched and security vulnerabilities will not be addressed. The latter should especially be of major concern, considering that 68% of firms still have Windows 2003 servers in use, according to a 2013 ILTA technology survey. To put it in perspective, when Microsoft rolled out this OS there was a baseball team in Montreal, people read books made of paper, and no one had ever heard of an iPhone.
Cease and desist
The first step to solving this problem is to stop deploying a 12-year-old operating system. Some companies are continuing to roll out Windows 2003 servers, including some for production use. There is no reason to make the problem worse than it is by rolling out a platform that is in need of a refresh before it even goes live.
Consult your application vendors
The grounds for deploying one operating system over another are often rooted in application support and compatibility. Sometimes when an application vendor requires an update to its software it causes headaches related to cost, training, client considerations, and other factors. While it may be tempting to stick with an architecture that is not currently giving you any issues, the benefit of having support when needed will far outweigh the effort of upgrading the application. Another situation to be wary of is an application vendor offering to support the underlying OS. It’s generally a bad idea to depend on this for two reasons. First, when Microsoft stops support they will stop taking engineering change requests from application vendors. Second, regardless of the skillset of the engineer, they will no longer be able to rely on Microsoft for updates and will have to provide workarounds for problems instead of actually fixing them.
In some cases you may also find that application vendors will align end-of-life or end-of-support for a product with that of an operating system because they do not want to be caught in the same position. Never forget that no matter how good your staff may be, vendor support is very important. No one wants to have to explain to a managing partner that their favorite application is down, and that the vendor will not help you get it back up.
The dark side of virtualization
Server virtualization has gone from curiosity to common to crucial in recent years. One downside of this is that it allows legacy applications and operating systems to survive practically indefinitely. For example VMware will support Windows NT 4.0 SP6a on its hypervisors as of ESXi 5.1 U2. As an administrator, it was comforting, in a perverse way, to know that you could depend on hardware to fail. It allowed you to notify an application owner that they had to either adapt or watch their downtime counters go up while their onetime state-of-the-art servers transformed into silicon relics suitable only for propping open data center doors. Instead, virtualization should be utilized wherever possible to allow thorough testing of your new application on your new OS in parallel with the one that is slated for decommissioning.
Embrace the new
There are advantages to upgrading your OS other than retaining support from Microsoft. With each successive release of Windows Server, Microsoft provides a more stable, feature-rich experience across the board, with better security. There is a learning curve when it comes to navigating the interface of a new OS (especially for Server 2012), but, like anything else, once you spend some time with it you will wonder what was so difficult about it in the first place.
Use your POWER
Or, if you don’t want to be subject to fluctuations in the GUI du jour, drop down into PowerShell and take advantage of the most flexible and powerful way to manage a Windows server. If you haven’t learned PowerShell yet, it should be your number one priority as a Windows administrator. You simply do not have access to all available features when working in a GUI that you have in PowerShell.
Make haste but don’t be hasty
So when should you get started on this? The answer is “yesterday.” In many cases, moving an application to a new platform or migrating to a new application altogether is a long process fraught with problems and delays.
These are a few steps that are crucial to a migration of any kind.
Find out which systems you need to retire or update. The larger the network, the more work you need to do in order to find every legacy platform that is still actively providing services or data to users or other applications. Ironically, the most reliable systems (the ones that have been flawlessly running for years without a hiccup) may be forgotten and cause you the biggest trouble. In many cases your monitoring tools, like Systems Center or SolarWinds, can help you inventory your current systems. If not, Microsoft provides the MAP Toolkit, a free, lightweight toolkit that will inventory your network for you and provide a plethora of helpful data.
Once you have figured out what to replace, you need to decide what to put in its place. This may be as simple as migrating to a new Windows file server with a current OS or a much tougher task requiring the upgrade of multiple applications on various servers. Contact your application vendors and use the opportunity to find the best solution for your users. Keep in mind this is not always the fastest, easiest, or cheapest solution.
When you know where you are going, your engineers and project managers should get together and figure out how you are going to get there. At times the most brilliant engineers can be disorganized and have a problem communicating to end users who don’t know an OS kernel from a popcorn kernel. This is why you need project managers to bridge the gap between technical know-how and real world organization and communication to business users.
Make sure that you get all of your planning done with enough time to perform adequate testing. Once you have done all of your testing, do more testing. Although it is usually impossible to recreate every possible scenario or anticipate every technical issue, thorough testing of both the application and the migration path are essential to ensure a secure, stable system and a smooth transition.
Cutovers are rarely stress-free, but as long as you have done your due diligence, and all players from engineer to helpdesk to end user know their parts, your chances of a successful transition are high. More importantly, you will be stepping into a situation where you will be able to rely on your application vendors or on Microsoft when issues arise that your team can not easily resolve.
12 years is a long time in the technology space. Server 2003 has been a dependable platform but there are better more secure alternatives that should be leveraged.