Windows Server 2003 Mitigation and Migration Options
There are several Windows Server 2003 mitigation options available for clients. For example, one option is to continue running the old servers but to isolate them from other servers or internet traffic. For completeness, let’s take a brief look at mitigation options and then turn our focus to the technical options for migration. Many mitigating options require no technical action and the primary focus for the remaining sections is to help with specific tools, best practices, cost considerations and approaches to migrating.
Much has been written on the topic of Windows Server 2003 end-of-support mitigation options. To summarize, these are the five most prevalent mitigation options available:
1. Purchase a custom support agreement from Microsoft while you continue to migrate away from the platform.
2. Isolate the servers from other servers in your data center (e.g., separate subnets) and set up additional monitoring to watch for potential issues and prevent attacks from reaching other servers.
3. Sunset existing applications and simply retire these servers and applications.
4. Leave the servers running, taking no immediate action. When something happens causing the application to fail or require attention, implement a pre- defined plan at that point in time.
5. Where possible, find replacement applications, roll out replacement applications and then retire the older system.
Each of the above options has significant differences in approach, cost and risk. While performing the necessary inventory, assessment and plan for each of the applications in question, organizations will likely find that a mix of the above mitigation options will be viable as they define prioritization and risk.
There are several options available in terms of migration. Migrations can be performed using either a manual approach or tools to help automate the approach. Additionally, the destination can be one of a variety of locations. These options include the following manual approaches:
Windows Server Installation Upgrade – Uninstall the application from the existing Windows Server 2003, upgrade the OS to a more recent version of Windows Server, install and configure the application on new OS.
• New server migration – Spin up new server infrastructure and install the old application on a more recent version of Windows Server.
• Cloud migration – Leverage Amazon Web Services to spin up an instance on a more recent version of Windows Server and install the application there.
• Physical to virtual – Migrate P2V (physical to virtual) with the assumption that WS2003 may be currently running on physical hardware but virtually after the upgrade. Keep in mind this virtual platform may be in a private data center or in the cloud.
• Virtual to virtual – Migrate V2V (virtual to virtual) by moving your existing virtual Windows Server 2003 to a newer virtual platform. Again, keep in mind that this could be in a private data center or in the cloud.
In each approach above, it will be very important to test the application in detail once it is running on the newer version of Windows Server. This topic will be addressed in more detail in the section on testing later in this paper. However, it is important to consider the numerous security enhancements and changes to the operating system that can impact how well an older application will run with default settings on a new version of Windows Server.
There are some important considerations with Windows Server 2003 in regards to hardware platform. The x64 architecture, which is commonplace today, is not supported by Windows Server 2003. Instead the primary 64-bit option was previously the Intel Itanium architecture which is still sold, but for which Microsoft phased out support for it with Windows Server 2008. When people speak of 64-bit support today, they are referring to the x64 architecture. According to Microsoft, this “is a backwards-compatible extension with x86.
It provides a legacy 32-bit mode, which is identical to x86, and a new 64-bit mode. The term ‘x64’ includes both AMD 64 and Intel64. The instruction sets are close to identical.”6 This means that some Windows Server 2003 machines may be running on Intel Itanium 64-bit processors which have a different instruction set than the x64 bit instructions. Though this is a consideration, most companies continued with the 32-bit versions of the platform and ran 32-bit versions of Windows Server 2003.
Windows Server 2008 supported all of the above7, and many organizations that had existing 32-bit machines moved to Windows Server 2008 32-bit, while others purchasing new hardware typically opted for the x64 platform.
But Windows Server 2012 only supports x64. This means that those looking to upgrade Windows Server 2003 most likely will be moving from x32 to x64-based machines, regardless of whether those machines
are physical boxes in the client’s data center, virtual platforms, or cloud-based infrastructure.
Overview of Automated Approach
Migrating applications using the manual approaches listed previously will have many significant challenges which we’ll discuss in detail. However, there are also a few fully-automated approaches available. Interestingly, there is a huge movement in the open source and Linux world working to solve this problem. Its goal is to make applications easily portable across underlying operating systems by packaging them in a standard way, much like containers are moved in the shipping industry. If you have not heard of Docker8, it is well worth looking into in order to understand how others are working to solve the problem of application portability. Our focus is on Windows machines, and in this arena one company stands out: AppZero9. With AppZero it is possible to:
- Automate the packaging of an existing application for deployment to any server regardless of location, whether on premises or in the cloud
- Extract existing applications, configurations and dependencies even without the original installation program
- Move the application as an application image, called a VAA or Virtual Application Appliance, not as a machine image or virtual machineThe AppZero technology can automate many application migrations that would otherwise only be possible through manual and error-prone steps. We will look at this process in detail in the following sections.