After more than 11 years in production, Windows Server 2003 is nearing its last gasp. On July 14th, 2015, extended support for this workhorse will expire. The argument that a legacy app running on a Windows Server 2003 server “just works” because it’s paid for is no longer valid.
It’s not that the app and OS have changed — it’s due to the fact that the world has moved far, far past them, especially in the criminal world. After July 14th, there’ll be no more patches and no more support. No support from Microsoft also means that the application will also fail most regulatory requirements.
Looking at the positive side of this situation, getting rid of your remaining Windows Server 2003 systems also provides you with the opportunity to give a portion of your compute environment a big step forward. By migrating to the latest Microsoft OS — Windows Server 2012 R2 — you’ll have enabled a lot of new capabilities that were unheard of when Windows Server 2003 was released. There’s the latest version of Hyper-V, Storage Spaces, SMB 3.0… it’s a long list.
It really is time to move on.
Phase I: Identify Windows Server 2003 Workloads
Before you can work on migrating your workloads off Windows Server 2003, you need to take inventory of those workloads by finding them. If you have a large number of Windows Server 2003 systems or a large server environment, I strongly recommend the Microsoft Assessment & Planning Toolkit (MAP). MAP is an agentless inventory, assessment, and reporting tool that can securely assess IT environments.
Figure 1 shows the MAP toolkit main menu with the sample database loaded. It supports a wide range of planning capabilities, as you can see from the left-hand menu. For the purpose of discovering your Windows Server 2003 servers, you need to choose the Server scenario:
Under Legacy Server Discovery, we can see that there are 67 Windows Server 2003 servers of various editions and architectures on the network.
You can drill further into this analysis by clicking on the panel. This brings up more detail on what kind of legacy servers you have, as shown in Figure 2:
To get this in an actionable form, click on the Generate Legacy Windows Server Report to get an Excel workbook of the data. You can then use Excel’s auto-filter function to select the OS type that interests you, which you can see in Figure 3 below:
In addition to tracking servers, you also need to keep track of more soft information about the server and its workload. This type of tracking will most likely be a complicated project, as every server and application has its administrators, owner, and customers. And you’re going to need to communicate with all of them for this migration.
The following list is information that you will likely need to obtain:
Note: This list is also available in worksheet form at http://1drv.ms/1CiJbog.
- Name: The server name
- Location: The physical location of the system
- Type: Standard server or an embedded system
- Base hardware: The base server model (“HP DL380 G4”)
- Workload(s): Workloads running on this system (“File & Print, SQL Server, IIS, AD domain controller”)
- Business purpose: The business purpose of this system (“manufacturing system”, “DC for flybynightsoftware.com domain”)
- Owner Name: The hardware’s owner
- Owner Email
- Owner Phone
- Criticality: How mission-critical the system is
- Stakeholders: The business owners and high-level users who have a stake in the system’s functionality and need to be involved in the migration planning.
- User Locations: Onsite, offsite, distributed
- Access method: Desktop rich app, browser-based, mobile app
- Workload Support Status: Unsupported / Supported on Windows Server 2003 / Upgrade available
- Hardware Support Status: Contract details
- Footprint: Physical or virtual?
- Utilization: Heavily used? Mostly idle?
- Storage requirements: Is a SAN or other specific storage type required? Unusually large databases?
- Network requirements: Fibre Channel, unusual bandwidth requirements. Does it require special firewall rules? Does it need to be on an isolated network?
- Availability requirements: High availability requirements. Does it need to be part of a cluster?
- Security requirements: Does the system require smart cards or certificates?
- Regulatory requirements: What regulatory or compliance requirements is this system subject to that may influence its migration requirements?
- Remote access requirements:
- Other dependencies: Is the system part of a workflow or multi-tier application that may be affected by its migration?
- Other installed software: What other software is installed on the system (e.g. backup, management, security)?
Phase II: Planning
Now that you’ve identifed your Windows Server 2003 systems and collected pertinent information about them, you can more accurately plan how to migrate them. If you have many systems that need to be migrated, the process can become quickly complicated. I’ve provided a checklist below to help you organize the planning phase. You may not need all of these checklist items for your own Windows Server 2003 migration, but you’ll have at least examined all the major facets of a migration by looking through this list and crossing off items that aren’t relevant. And just maybe you’ll encounter some items you haven’t thought about.
Hardware upgrade planning
Next, review new hardware technologies. In all likelihood, your Windows Server 2003 systems are physical, and you should be migrating to virtual machines (VMs). If you don’t have an existing virtualization environment to host the VMs, then this is the time to start one. Even if you have an existing virtualization infrastructure, it’s still important to examine what Windows Server 2012 / R2 capabilities require new hardware technologies (for example, RDMA). By going through this process, the hardware will be there to support new technologies when you’re ready to turn on new features.
Be sure to include hardware deployment lead time into your project plan. Remember that hardware is unlike software, where it requires significant lead time for spec’ing out, purchasing, shipping, powering, networking, and more.
Base operating system upgrade planning
This part of the planning phase is where you’ll determine migration paths. The single most important rule to keep in mind for this migration is that Windows Server 2003 is Microsoft’s last 32-bit server operating system. Upgrades from Windows Server 2003 to Windows Server 2008 and 2008 R2 are supported, but upgrades to Windows Server 2012 / R2 are not. If you’re contemplating upgrading from 2003 to 2008 because it’s easier, keep this in mind: Windows Server 2008 R2 has already exited mainstream support in January of this year. If you’re going to the trouble of moving forward, go all the way forward and take advantage of what the latest technology has to offer. If you take my recommendation and migrate to Windows Server 2012 R2, then you must reinstall applications on the target system.
A couple of useful TechNet articles on this are:
Evaluation downloads of the currently offered Windows Server versions are also available.
Workloads are the roles a server is performing; we use “workloads” instead of “roles” to distinguish it from Microsoft’s technical description of a role as a function that can be installed from Server Manager. For example, a server running a SharePoint workload may have several roles installed in addition to platforms, such as SQL Server.
Determine workload end of lifecycle. First, try to simplify the migration by eliminating systems that don’t need to be migrated in the first place. Perform an impact analysis of the system and workload. How much of an impact would decommissioning the system have versus the cost of migrating and maintaining it? Can this workload simply be retired and its functions moved to another system?
Workload configurations. This is an opportunity to standardize and reduce the number of configurations you must support. Group the remaining Windows Server 2003 workload types together as much as possible into what we’ll call workload configurations. You’ll end up with several configurations, each with multiple instances, and a random collection of one-off systems.
Consider the following for each workload configuration:
Physical vs. Virtual
- Does the workload reside on a physical server? If yes, plan for P2V (physical to virtual) conversion unless there is strong technical or security data otherwise. And there probably isn’t a technical reason.
- Using the utilization data you collected in Phase I, scope the target VM for the usage the workload is getting — not the hardware it’s on now.
- There are a number of good P2V utilities available, depending on your virtualization vendor. VMware has its free vCenter Converter, and Microsoft the free Disk2VHD utility or P2V capability in System Center Virtual Machine Manager.
On premises vs. Cloud
- Should the virtualized workload remain on premises or might it be moved to the public cloud as a SaaS app? For example, there may be a good business case to move an Exchange Server 2003 installation to Exchange Online.
- Could the virtualized workload be moved to an infrastructure as a service (IaaS) offering, such as Amazon Web Services or Microsoft Azure? For the workload to continue to interact with on-premises applications, this strategy requires a VPN link to tie on premises and cloud networks together.
- If the workload was built in house, can it be re-architected as a web service running on a platform as a service (PaaS) offering, such as Microsoft Azure? This is probably a very long-term strategy.
Workload Migration Paths
Every workload or application has its own upgrade or migration path, which Figure 4 shows in more detail. Many workloads or applications are dependent on each other, so you must always keep dependencies in mind. For example, Exchange upgrades depending on Active Directory domain and forest-functional levels.
Active Directory / DNS
Although migrating your Active Directory from a domain and forest-functional level of Windows Server 2003 to 2012 R2 may not be strictly necessary if your current applications won’t take advantage of its expanded capabilities, you should do it anyway. Why? Because Active Directory protects the keys to the kingdom — your company’s identities and therefore access to all its resources — and its 2012 R2 version is significantly more secure than its decade-plus predecessor.
This upgrade can take several different paths. You can upgrade your domain controllers to Windows Server 2008 R2 and upgrade them again to Windows Server 2012, but this is neither the simplest, nor the cleanest way to move your AD environment forward. The best method is to introduce a Windows Server 2012 R2 server into your network and promote it to domain controller. In doing this, your Active Directory schema will automatically be upgraded to the Windows Server 2012 R2 version, running ADPREP /FORESTPREP, then /DOMAINPREP via the Server Manager interface.
The Petri IT Knowledgebase has a handful of articles on how to do this:
Migrating Active Directory from Windows Server 2003 to Server 2012 R2 Article Series
- Part 1: Preparing Windows Server and Active Directory
- Part 2: Install AD and Transfer FSMO Roles
- Part 3: Migrate DHCP, Remove Windows Server 2003, and Raise Functional Levels
Nonetheless, be sure that you review Active Directory changes beforehand. I strongly recommend you test the upgrade procedure by adding a Windows Server 2003 DC to your existing domain, then remove it to a test lab where you can add a Windows Server 2012 R2 DC to upgrade. This thread on Experts Exchange gives a high-level overview of the procedure. Microsoft technical evangelist Blain Barton also has an article on upgrading Active Directory, with a link that lists a variety of issues.
The tighter security in Windows Server 2008 R2 and Windows Server 2012 R2 is good, but it may impact your existing environment. What’s New In Active Directory Domain Services reviews the major changes to look at from a Windows Server 2003 upgrade viewpoint.
Once you’ve upgraded one DC to 2012 R2, it’s time to get your Active Directory forest to an all-2012 R2 environment as soon as possible. As the Microsoft Directory Service team notes, “It turns out that weird things can happen when you mix Windows Server 2003 and Windows Server 2012 R2 domain controllers.”
DHCP has seen very few updates of any kind over the years. The single most significant update came in Windows Server 2012 when it gained true failover capabilities. Petri IT Knowledgebase’s Russell Smith has also written a good step-by-step procedure to migrate your Windows Server 2003 DHCP server(s) to Windows Server 2012 or R2.
File and print
The Windows Server Migration Tools are an installable feature in Windows Server 2012 and R2. These tools help you migrate a variety of roles from previous OS versions to Windows Server 2012 R2. Many of the migration tools only migrate from Windows Server 2008 and later, but you can use these tools to migrate File and Storage Services, and Print Services from Windows Server 2003. Microsoft technical evangelist Matt Hester has an overview article on the Migration Tools.
- Look here for information on File and Storage Services migration with the Windows Server Migration Tools.
- Look here for information on Print and Document Services migration with the Windows Server Migration Tools.
Microsoft recommends the following migration paths for SQL Server:
- SQL Server 2000: Migrate to SQL Server 2014 via SQL Server 2008
- SQL Server 2005: Upgrade to SP4 and then migrate to SQL Server 2014
- SQL Server 2008: Upgrade to SP3 or later and then migrate to SQL Server 2014
- SQL Server 2008 R2: Upgrade to SP1 or later and then migrate to SQL Server 2014
The first steps I would suggest is to use the Microsoft SQL Server 2014 Upgrade Advisor. The Upgrade Advisor “analyzes instances of SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 in preparation for upgrading to SQL Server 2014. Upgrade Advisor identifies feature and configuration changes that might affect your upgrade, and it provides links to documentation that describes each identified issue and how to resolve it.”
The SQL Server 2014 Upgrade Advisor is available as part of the SQL Server 2014 Feature Pack.
If you have a database other than SQL Server that you want to migrate to SQL Server, then the SQL Server Migration assistant is your best bet, and the price is right.
Starting with IIS 6.0, IIS upgrades and migration have been made easier with the Web Deploy tool. Web Deploy simplifies deployment of web applications and websites to IIS servers, but it also can be used to migrate to newer versions of IIS. This article by Microsoft provides more information on how to use Web Deploy for migration.
For applications purchased from a non-Microsoft third party, key questions include:
- Is there an updated version supported on Windows Server 2008+?
- Failing that, is the existing application version supported on Windows Server 2008+?
You can also explore third-party applications like AppZero to extract the application from Windows Server 2003 and migrate it to Windows Server 2012 R2 or Azure.
Very few systems may reside at an intersection where they can’t be migrated or they are absolutely essential for business operations. This is a bad situation. The best you can do is to create a security mitigation plan using network isolation and draconian firewall rules, along with having a formal sign off of risk acceptance by management. This sign off is important. The decision to leave a vulnerable system online is generally made by management, and those making the decision should sign off on the risk.
Applications developed in-house face a similar decision tree:
- Can the application be migrated to Windows Server 2012 R2 as is?
- If not, do you have development resources to port the application to R2?
- Can the app’s function be replaced by a SaaS app? Use a SaaS marketplace site like SaaSMax to search for a possible replacement.
- If you don’t and you must continue to use this application, you may need to invest in an application migration solution like AppZero, Racemi, RiverMeadow, or Cloud Velocity.
If none of these solutions work, you may need to isolate the app as a dead-end system.
- Test “to be” architecture. Azure or AWS is perfect for this.
- Finalize high-level “to be” architecture
- Build upgrade and migration deployment plan
Security considerations: Security is tighter with both Windows Server 2012 R2 and modern applications (ownership changes, some read/write permissions are taken away)
Licensing considerations: Consider what has changed with licensing. For example, Windows Server 2008 and 2012 have updated licenses that including some number of virtual instances, depending on what edition you purchase. Your virtualization architecture will impact what edition you need to purchase.
Business function and functionality reviews. Your stakeholders need to be involved in these planning decisions, which include the following:
- New capability planning: Consider low-hanging fruit or easy wins that can be implemented as part of the migration
- Attractive capabilities to be evaluated and deployed after migration
- Overall project sequence dependencies, especially hardware purchase and datacenter installation
- Create plans
- Engineering test
- Customer acceptance test
- Back out
Phase III: Execution
Relatively speaking, execution is the most straightforward of these three migration phases. That’s because the actual migration process is not that different than any other production maintenance or upgrade process: You develop a plan to execute, you perform engineering tests, you package it up perhaps in a simply a documented procedure, and you have customers do acceptance tests of the end result in a pre-production environment. Next, you schedule and roll out the change.
The time has finally come to move away from Windows Server 2003. There’s lots of documentation on how to do it, along with a variety of existing applications that will get it done if you have a really tough situation. Get planning today; break this big project down into separate workstreams so much of the work can be delegated and worked on simultaneously. And get yourself a project manager; in a project like this, the technical professional needs to work on the technical aspects and leave the project work to a project professional.