The Complete Guide to Windows Server 2003 End of Support

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.

• Related: 5 Reasons Why You Should Upgrade to Windows Server 2012 R2

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)?