Winding Down Windows Server 2003 in Your Organization

If you go to the Windows Server 2003 end of support web page, you'll see a clock that counts down the days, hours, minutes, and seconds until Server 2003 reaches its end of support on July 14, 2015. At time of this writing, that's only eight months away. Given that the average migration takes between 8 to 12 months, if you haven't already started your migration from Server 2003, you better start today. When July 14, 2015, hits, Server 2003 becomes completely unsupported. There will be no security fixes, no support, and no chance of passing any kind of audit, which could lead to fines or even litigation.

But how big is the problem? Estimates vary, but many studies show around a third of all Windows Server deployments are still running Server 2003. Given the number of Windows servers deployed worldwide, this means a lot of Server 2003 deployments.

Why are there so many Server 2003 deployments? It might be due to the "if it ain't broke, don't fix it" mindset, but I suspect another reason is that many organizations simply aren't aware of those deployments. If you use an 11-year-old phone every day, it'll be obvious that it's outdated. However, a service running on an outdated server is far less obvious. There are many systems still using IIS 6.0 and other applications on older OSs. Because organizations don't see or touch them directly, they aren't aware of the specifics of the host providing the service. This brings us to the first order of business: discovering Server 2003 deployments in an organization.

Discovery

For large companies, it's common to see old infrastructure at branch locations, at manufacturing plants, and on oil rigs, where there's little hands-on IT. Most estimates show the Server 2003 deployments are split evenly between physical deployments and virtualized deployments. So, the first step in migrating from Server 2003 is to determine how many physical and virtual Server 2003 deployments are present, where they're located, how they're being utilized, and what software is running on them. If an organization has a large percentage of Server 2003 deployments (more than 20 percent), it should concentrate on modernizing its data center. If an organization has a low percentage of Server 2003 deployments, it can concentrate on migrating targeted workloads.

Some organizations already have a solution in place for their server management and have detailed knowledge of every server. For example, they might be using Microsoft System Center Configuration Manager and System Center Operations Manager to manage their physical servers and System Center Virtual Machine Manager to manage their virtual servers. Using their enterprise management tools, these organizations can create reports of the OSs deployed in the environment and the server architecture (which is likely 32-bit for Server 2003). They can even gather performance data, which is important when planning a migration because the migration will likely be to a virtual environment, where the amount of resources (e.g., memory, CPU, I/O operations per second—IOPS) can be customized based on actual needs rather than simply what the environment currently has.

It's important to understand which OS roles (e.g., DNS, file, print, IIS) and non-native OS applications (e.g., Microsoft Exchange Server, Microsoft SQL Server) are running on each server. Enterprise management tools should be able to provide this information. However, if an older application consists of an executable that's copied to a folder and launched by a logged-on user, it's not going to be reported. So, although enterprise management tools are great because they automate the inventory process, the human element is still needed, especially for older systems that likely are ignored.

If your organization doesn't have an enterprise management tool that provides a comprehensive inventory of all Windows Server OS instances, their utilization, and their applications, you can download the free Microsoft Assessment and Planning (MAP) Toolkit. This toolkit lets you assess an organization's current IT infrastructure in preparation for desktop, server, and cloud migrations. For example, you can assess OS readiness for a migration to Windows Server 2012, check OS readiness for virtualization, and determine SQL Server deployment utilization. The MAP Toolkit doesn't deploy any agents to the environment. Instead, it's installed in a central location. It then remotely queries the environment and can even periodically gather performance data. After the MAP Toolkit has been collecting data for a sufficient period of time, you can create two reports that can provide some insight into the true scope of your Server 2003 migration:

Previously, I mentioned that the human element is needed to manually check systems. The human element is also required to assess the criticality of each deployment and its application. This assessment will not only dictate the resiliency required on the target platform but also help determine how and when the migration should be performed. For example, this assessment can help determine the maintenance window for when a migration can occur.

One of the most time-consuming aspects of a Server 2003 migration will be ascertaining if the applications will even run on 64-bit Server 2012 or Windows Server 2012 R2. If the application is a 32-bit application without any 16-bit code or any drivers, there's a good chance it will run on Server 2012 or Server 2012 R2, but is it supported by the vendor? If so, do you still have the install files and knowledge to perform a re-installation of the application on a modern OS? Or will you need to use a third-party tool such as AppZero, which can grab the application and its dependencies from Server 2003, put the application in a "bubble," then run it on a modern OS? If running the 32-bit application on Server 2012 or Server 2012 R2 isn't supported by the vendor, are you able to upgrade the application to a newer version and what does that upgrade entail?

Planning and Justification

Organizations should know which direction they want their technology to be headed (e.g., want to deploy a private cloud or public cloud). As part of their migration planning, they need to ensure the desired end state of the migration fits with their technical direction. If your organization doesn't have a technical direction, now would be a good time to set one. You should take time to reassess the actual requirements of your environment and design a solution using all the capabilities available. With the desired end state known, you can map out how to migrate from what you have to that final architecture.

In order to design a solution that takes advantage of the capabilities available in Server 2012 or Server 2012 R2, you first need to know about them. Evaluating the full set of capabilities can also lead to far simpler deployments.

Most of the Windows OS changes since Server 2003 aren't refinements of existing functionality but rather major overhauls and completely new functional areas. Key features new since Server 2003 include x86 virtualization (Hyper-V), desktop virtualization (including session virtualization), virtual desktop infrastructure (VDI), and application publishing (Remote Desktop Services). There have also been huge changes to Active Directory (AD), including granular security policies based on group membership, the ability to undelete objects, federation with other organizations, the ability to publish services to the Internet while enabling single-sign on and pre-authentication for users (Web Application Proxy), and centralized network management (IP address management—IPAM).

An in-depth discussion of all the Windows OS capabilities new since Server 2003 is beyond the scope of this article, but there are many articles that discuss the new features in Windows Server 2008, Windows Server 2008 R2, Server 2012, and Server 2012 R2. The key point is to make sure this research is done.

This research is helpful in another respect. If you don't have Windows Server Software Assurance (in which case you have the right to the newest version), you'll be getting out the corporate checkbook to pay for the new version, in which case, you'll likely need to justify the purchase and show the ROI. Taking the time to identify the new capabilities in Server 2012 or Server 2012 R2 can help identify the additional value the new OS will bring to the organization. For example, you might be able to eliminate some third-party solutions because their capabilities are now provided natively by Server 2012 or Server 2012 R2.

Migration

There's no direct upgrade path from Server 2003 to Server 2012 or Server 2012 R2. Even if such an upgrade existed, nearly every Server 2003 deployment is 32-bit, whereas Server 2008 R2 and later is 64-bit only—and it's not possible to upgrade between architectures. This means any type of direct upgrade (or even a multi-hop upgrade) is likely out of the question. Instead, you should concentrate on migrating services. Ideally, there's some spare resources in your organization, so you can migrate services from the source OS to the new target while both are available. The alternative would be backing up the application and role states to a file, performing a clean installation of Server 2012 or Server 2012 R2, then restoring the application and role states, but this might not even work in all scenarios. For detailed information about the upgrade paths, see Evaluation Versions and Upgrade Options for Windows Server 2012 or Upgrade Options for Windows Server 2012 R2.

There's no single migration solution that will migrate all the services. Instead, each service has its own migration approach. Let's walk through the approaches to migrate six major services often found in Server 2003: AD, DNS, DHCP, file services, print services, and IIS. (For information on how to migrate other types of services, see Migrate Roles and Features to Windows Server 2012.)

AD. Providing you have followed best practices, your domain controllers (DCs) don't run any other software, which means the existing domain and forest will be prepared for Server 2012 or Server 2012 R2. In this case, you need to create new DCs running Server 2012 or Server 2012 R2, migrate the Flexible Single-Master Operation (FSMO) roles, migrate any certificates or other items, then decommission the Server 2003 DCs. To introduce Server 2012 DCs, the forest (and therefore the domains) must be Windows Server 2003 mode. For detailed guidance on migrating DCs, see Upgrade Domain Controllers to Windows Server 2012 R2 and Windows Server 2012.

DNS. If you're hosting DNS on Windows, you're likely integrating it with AD and your DNS servers are DCs. Therefore, when you migrate AD, the DNS configuration will move as well. It's important to remember to migrate any DNS server configurations, such as forwarding. If the DNS servers will be hosted on new IP addresses, you need to make sure that you update any static IP configurations and all DHCP configurations. To avoid this time-consuming task, most organizations will change the IP addresses of the new servers to that of the old servers once the old servers are retired.

DHCP. DHCP scopes provide the IP addresses given to clients, along with their IP configuration (e.g., gateway, DNS server). To migrate DHCP scopes, the best option is to export the scopes from the Server 2003 instance, then import them to the Server 2012 or Server 2012 R2 instance. Full details on this approach are available in the TechNet Networking Blog post "Steps to move a DHCP database from a Windows Server 2003 or 2008 to another Windows Server 2008 machine." If there is any delay in the DHCP scope export and import and a risk of IP address reuse, you can configure the DHCP server to check if an IP address is being used before it's allocated by enabling address conflict detection.

File services. There are two parts to a file services migration: moving the storage and shares, then updating all the references to the data stored in the shares. If you intend to reuse server names, there's no change in reference. However, this practice isn't common because it can be difficult and time-consuming to identify every location where paths are used. The best solution for a migration and for longer term management is to leverage DFS namespaces. These abstracted logical namespaces provide redirection to specific file shares, which is invisible to the end user. With DFS namespaces, a new logical namespace is created, which initially has links to the Server 2003 file servers. The task of updating references is then undertaken, which can take months. Once the DFS namespace is used by all clients, data and shares can be migrated to the target and the DFS link updated to point to the new Server 2012 or Server 2012 R2 file server. Also required is the actual data and share migration. Microsoft has a complete toolkit for the migration of file services, which includes the integration with DFS. For more information about migrating file services, see Migrate File and Storage Services to Windows Server 2012.

Print services. Like file services, printer configurations and shares must be migrated from the source server to the target server. In addition, you'll need new printer drivers that are 64-bit and compatible with Server 2012 or Server 2012 R2 as well as with modern clients. Microsoft has a print migration wizard and command-line tool you can use for migrating printer services. You can download these tools from the Migrate Print and Document Services to Windows Server 2012 web page.

IIS. If all you have running on IIS 6 are basic HTML pages or Active Server Pages (ASP), you can copy the content to the IIS version running on Server 2012 or Server 2012 R2, then update the DNS records to point to the new IIS server. However, organizations typically have more complex configurations. The good news is that you can use a migration toolkit named Web Deploy 3.5. If you need to migrate websites to Microsoft Azure websites, there's a separate tool available named Azure Websites.

Besides migrating the core OS roles, you might have to migrate applications such as SQL Server and Exchange Server. The exact process to migrate applications is application-specific but here are some good references to start with:

Continued Action

After you have completed your migration from Server 2003 to Server 2012 or Server 2012 R2, you can sit back and relax. Once you're relaxed, though, you should take steps to ensure that your organization never faces a rushed migration again. You should stay current on new technologies and constantly re-evaluate the organization's requirements, consider new capabilities, and architect new solutions as required.