Do you know what happens on July 14 ? It’s the day that Windows Server 2003 goes end of life. That’s less than a week from now. And while some of you may scoff at this article and wonder why we’re covering it, far too many of you still have 2003 servers running in your environment, many probably domain controllers, and the clock is running out on you very soon. We have compiled a combined checklist and collection of links to help you get those last lingering 2003 servers sorted out before time runs out!
In this post, given that the end is days away and any server still running 2003 must be ancient, we are not going to discuss any in-place upgrades for anything. Odds are pretty good the servers are well out of warranty anyway, so even if 2008 R2 has drivers for this older hardware, using that ancient iron will still have you in a bad place and we don’t want to encourage that, even inadvertently.
First, don’t panic
Operating systems aren’t like food or medinces… they don’t have an expiration date so they won’t just shut down on the 14th. You’ve waited until the very last minute to get started, but you’re not dealing with a shot clock that, when time runs out, you would have lost.
You are dealing with an ever increasing chance that something bad will happen, including incompatibilities with existing or new applications, bugs, and new vulnerabilities that simply won’t be patched, so don’t sit around expecting to deal with this after Christmas. If you work hard and you work fast, you will be okay. Odds are very good that this month’s patch Tuesday will include patches for 2003, so while you won’t be able to call support if something goes wrong, you’re not likely to have to deal with a zero-day for at least a little while.
o Don’t panic.
P2V or not P2V, that is a question
If you have a robust virtualization platform, you may consider performing a physical to virtual (P2V) transform of your 2003 servers before moving forward with anything else. You should not plan on virtualization enabling you to keep your 2003 servers around, but you can use that as a fallback mechanism should you find anything going completely wrong when you start to take down your 2003 servers.
o P2V for VMware http://www.vmware.com/products/converter/features
o P2V for Hyper-V http://blogs.technet.com/b/enterprise_admin/archive/2010/04/12/hyper-v-p2v-for-windows.aspx
Just remember, you can P2V a domain controller, but Microsoft doesn’t support virtualized FSMO servers, and once you demote a server, you cannot just bring its virtual instance back into AD and expect it to work. P2V is more an option for application servers, or if you want to virtualize DCs as the first step, shutting down the hardware and formatting the drives as soon as you confirm the virtual instance is good to go.
Backup solution
You need to make sure your backup software is compatible with the operating system versions you will use to replace your 2003 servers. That may mean buying more licenses, updating the backup system, or even replacing the system software and even the hardware if need be to ensure that the backup system can maintain your remaining current servers
o Confirm backup solution is ready
Management and monitoring
Whether you are using MOM, SCCM, Tivoli, or any other management system, make sure you’re good to go with the management agents to manage and monitor the new servers you will be deploying to replace the old servers you are shutting down.
o Confirm management and monitoring platform(s)
Antivirus software
Antivirus software is critical for all systems, from the moment they have a network connection. Make sure your AV solution is able to handle the new servers you will be deploying to replace the old 2003 servers.
o Confirm antivirus solution
Patch management solution
As you build your new servers, you will probably hit Windows Update to get them patched ahead of putting them into production. Once they are in production, you will need something a lot more scalable and reliable, and that offers reporting and verification. Check your patch management solution and update if necessary to ensure it can handle your new 2008 R2 or 2012 R2 servers.
o Confirm patch management solution
Management tools and scripts
Server 2003 doesn’t have PowerShell, and has rather limited options for remote management. VBScript was awesome in the early 2000s, and RPC-based management tools were the way to go, but today PowerShell and WinRM have taken over.
o Get training if necessary on PowerShell and WinRM
o Update management tools for 2008 R2 and/or 2012 R2
o Update scripts to use PowerShell instead of legacy methods like VBScript.
Core services
Ensure that all the core services that are provided by legacy 2003 servers are migrated/transitioned to 2008 R2 or 2012 R2 servers
o Migrate DNS to new servers
o Migrate DHCP to new servers
o Migrate WINS to new servers
File Servers
Check the file shares on all file servers, using the Share Folder Management tool, to identify all file shares including their names and permissions. Migrate all shares that you still need to 2008 R2 or 2012 R2 servers.
o (Optional) Check last access/last modified dates on shares and archive any that are no longer in use.
o Migrate file shares to new servers
o Update DFS entries to remove 2003 references
Active Directory
If you still have any Windows Server 2003 servers anywhere, you probably have domain controllers that are running Windows Server 2003. That can be good or bad. You can deploy Windows Server 2008 R2 domain controllers into your environment now, and since AD is multi-master and resilient, core AD functions will be fine and you can just demote the old 2003 servers and shut them down. But that’s bad for a few reasons.
Exchange
o See our recent post on what can happen to Exchange if you rip and replace all your 2003 domain controllers without having a care for the Exchange dependencies. Follow the guidance there to ensure you don’t break Exchange in the process of replacing your old domain controllers.
Dependencies
Odds are pretty good that you have something on your network, be it network gear, VPN concentrators, Linux or Unix systems, third-party apps, or other that use LDAP to leverage Active Directory for authentication, directory services, group memberships for authorization, etc. Odds are really good that if you have anything that does that, it points to either a specific domain controller by name or by ip.addr. When you demote that 2003 box, you’ll break whatever is depending upon it, so plan for that by doing the following.
o Notify all other sysadmins that you will be taking down the 2003 domain controllers, and ask them to check their systems to ensure they have no hard coded settings to either names or ip.addrs of the 2003 DCs.
o (Optional) disable the switch port for each 2003 DC one at a time, for at least a couple of hours, to see if any systems fault or other sysadmins call up frantically asking what happened
o Check DNS for A records and CNAMEs that resolve to domain controllers and changing their target to newer 2008 R2 or 2012 R2 domain controllers
o Check domain controllers from connections to TCP or UDP port 389 from network gear or other servers and getting those admins to update them to point to current DCs
o Consider, after deprecating those old 2003 DCs, assigning their ip.addrs to remaining DCs so anything using a hard coded ip.addr will still have something to hit.
Demoting 2003 domain controllers
o Ensure you have sufficient 2008 R2 or 2012 R2 domain controllers in your environment
o Ensure that these are Global Catalog servers
o Ensure that you have sufficient 2008 R2 or 2012 R2 domain controllers in each AD site
o Transfer any FSMO roles still on 2003 to remaining servers
o One at a time, run DCPROMO to demote the server from domain controller to member server
o Ensure AD replication completes. Use repadmin to confirm no remaining DC is trying to replicate to a 2003 DC.
o Disjoin the former 2003 DCs from the domain.
o Delete their account.
o (Optional) assign the ip.addr from the 2003 server to a 2008 R2 or 2012 R2 DC to cover any hard coded systems.
o Once all 2003 domain controllers are gone, raise your domain and forest functional levels to take advantage of new AD feature that are now available to you. Depending on what the highest FFL you can raise to, you will get
If you raise to 2008 level
- Distributed File System (DFS) replication support for the System Volume (SYSVOL),
- Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for access-based enumeration and increased scalability,
- Advanced Encryption Standard (AES 128 and AES 256) support for the Kerberos protocol
- Last Interactive Logon Information,
- Fine-grained password policies,
- Personal Virtual Desktops.
If you raise to 2008 R2 level, you can also get:
- Authentication mechanism assurance, which packages information about the type of logon method (smart card or user name/password) that is used to authenticate domain users inside each user’s Kerberos token, and
- Automatic SPN management for services running on a particular computer under the context of a Managed Service Account when the name or DNS host name of the machine account changes.
If you can make the jump to 2012, you can really tighten up Kerberos security with:
- The KDC support for claims, compound authentication, and Kerberos armoring KDC administrative template policy has two settings (Always provide claims and Fail unarmored authentication requests) that require Windows Server 2012 domain functional level.
- Finally, if you can make the jump all the way to 2012 R2 you get:
- DC-side protections for Protected Users, which disables legacy authentication protocols for specific privileged or other high-value accounts,
- Authentication Policies, and
- Authentication Policy Silos.
If you take a measured, but purposeful, approach to replacing all of your remaining 2003 servers now, you will be fine. There may be an occasional hiccup, but overall, you should be able to get rid of any remaining legacy servers in the next two weeks or so, and be in good shape.
Get your free 30-day 
trial
Get immediate results. Identify where you’re vulnerable with your first scan on your first day of a 30-day trial. Take the necessary steps to fix all issues.