In July 2015, Microsoft’s venerable Windows Server 2003 operating system will reach end-of-life, meaning the company will not provide regular support or updates for the operating system outside of an expensive custom support contract.
Windows Server 2003 remains in widespread use in organizations of all sizes. However, in the decade since its invention, an incredible array of changes has occurred in the IT industry. New forms of attacks, new perspectives on security, new approaches to management and automation, and more are all here. Windows Server 2003 will never be able to take advantage of these advances, or adequately protect itself against these risks.
Organizations need to adopt a repeatable, sustainable pattern for dealing with operating system obsolescence, on both client and server computers. In this paper, we will analyze the components of such a practice, and detail the capabilities that organizations will need to develop or acquire. We will present this process as something that organizations should conduct on a regular basis, and make an argument against treating operating system obsolescence as an interrupt-driven task that is only considered once every several years.
THE WIN2003 EOL DECISION TREE
In dealing with server operating system obsolescence, you have a straightforward chain of questions to ask and decisions to make.
This decision tree should be used to examine each server-based application in your environment. Applications should be prioritized, so that the applications most important to your organization are considered first. Also prioritize applications that face, or are accessed by, the public or by external customers or partners. Public-facing applications face significantly higher security risks, and should be considered primary candidates for server OS upgrades or migrations.
CONSIDERING IN-HOUSE APPLICATIONS
For applications where you have access to the source code, you have the most flexibility. Begin by assessing the applications’ compatibility with a newer server OS, such as Windows Server 2008R2, Windows Server 2012, or later. Ideally, try to evaluate the application against the newest possible OS version, so that the resulting server will have the longest possible life after the upgrade or migration is complete.
Actually testing applications for OS compatibility can be an arduous process. While it is conceptually straightforward to deploy a virtual test environment and run the application through a gauntlet of functional tests, it’s easy to miss specific functional scenarios, or to incompletely test the application. Instead, you should consider acquiring tools and solutions designed specifically for application compatibility testing and packaging needs.
These solutions are designed to statically and dynamically evaluate applications, and rather than simply testing them for functionality, the solution analyzes the applications for known compatibility problems. In some cases, these problems can be automatically mitigated through the use of OS-level compatibility adjustments or “shims;” in other cases, the solution may present an incompatibility report. These reports make it easy to assess the actual effort involved in recoding the application to be upwardly compatible; with such a report, you can make a more informed decision about what to do with the application.
Compatibility testing solutions can also markedly reduce the amount of time needed to evaluate an application. Rather than having to test the entire application’s range of functionality, you can simply use the tool to look at known problem areas for compatibility. Many applications, particularly those developed in recent years, will likely be able to move to a newer OS with few or no problems. In some cases, organizations may simply need to repackage applications into a more modern installer in order to obtain forward compatibility.