Exchange Server 2003. Yes, 2003. Why would an organization still be running 2003 in 2014? With an average upgrade cycle between 3 to 6 years, an eleven (11) year old server is quite old. So what would hold back an organization from upgrading their messaging system? Budget issues? Stability of 2003? Lack of technical knowledge or complexity of the new software? In the end the reason is not the issue or even necessarily the main problem.
Because I have customers who are still on Exchange Server 2003 (I have a customer who uses NT 4.0 …), I wanted to write a quick article on some possible pitfalls as well as design considerations when performing this upgrade. I recently had a client wanted to upgrade his aging and troublesome Exchange 2003 servers to 2013, but had to contend with hidden issues from previous migrations as well as contend with Outlook client version issues. The intent of my post is just to give organizations a heads up of the kinds of things that might be found and ways to mitigate issues before they cause significant delays in migrating.
If upgrading to Exchange 2013, do not forget that there is no straight upgrade path nor can the server be upgraded in place. First a migration to Exchange 2010 needs to be performed, Exchange 2003 decommissioned and then Exchange 2013 can be installed and users migrated. In the process Office may need an update as older versions of Office do not support connecting to Exchange 2013. A good reference article on supported versions is available and should be reviewed prior to any upgrade.
Exchange Server 2003 reached the end of its extended support earlier this year. As such, any organization that is still running Exchange 2003 for their messaging environment should consider a move to Exchange 2010 or 2013. Organizations making this move need to plan the migration in advance to prevent any pitfalls that typically come with poorly managed upgrades. This includes namespace considerations, high availability changes in Exchange 2010/2013, reverse proxy, mail flow, client access and so on. Prerequisite reading should include Microsoft’s coexistence guides as well as general Exchange 2010/2013 documentation.
Possible Migration Gotchas
This is not intended on being a complete list of all the possible issues that could occur in a migration from 2003 to a newer version of Exchange, however I will highlight some of the ones that I have either seen or know to be more common.
Before any migration for Exchange a full Active Directory and Exchange health check should be performed. The reasons for doing this are numerous as Active Directory and Exchange may look fine on the surface, but under the hood there could be issues. ‘Hidden’ problems could prevent a successful migration from even getting off the ground. Some of my clients have performed upgrades from 5.5 to 2000 and then finally to 2003 and left the servers as is for 10 years. Then when a migration to Exchange 2010 kicks off we find all sorts of lingering issues/objects that need to be cleaned up. Here are some potential issues you may encounter:
- Computer objects – Exchange 5.5 or 2000 server objects still in Active Directory – usually old Exchange 5.5 or 2000 servers that were not fully decommissioned and are not supported in an Exchange 2010 environment. ADSIEdit may have been used improperly and some leftovers are still present in Active Directory.
- Site Replication Service (SRS)
- Active Directory Connector
- Domain functional level – potentially too low to support an upgrade to a newer version of Exchange
- Exchange Org functional level – Exchange 2003 Native Mode
- Active Directory issues – replication between Domain Controllers, strict replication issues causing data to not replicate, DNS or WINS issues
- Domain Controllers or Global Catalog servers are not the correct version.
How can these issues be found prior to the migration? Free Microsoft tools, events logs and in-depth Active Directory and Exchange knowledge. For tools, the best place to start is Exchange Best Practices Analyzer (ExBPA) and if your Active Directory is new enough there is an Active Directory Best Practices Analyzer that was added with Windows 2008 R2. The Exchange BPA tool will find the more common pain points prior to a migration beginning. Other issues that could put up potential migration roadblocks:
- Backups not working – Active Directory and Exchange should have a good backup copy prior to any upgrade. If at all possible a test should be performed to verify the data as many an engineer has experienced the Good Backups, but Bad Restores scenario. Better to resolve this prior to having to rely on your backups in case of an upgrade disaster. Bad backups are known to be RGE’s (Resume Generating Events).
- Outdated Software – backup, anti-virus and anti-spam software needs to be compatible with your newer Exchange server.
- Any Fax software/hardware cards still being used on Exchange 2003? Will this be upgraded or replaced to be compatible with Exchange 2010 / 2013?
- Unified Messaging considerations – will your old PBX/UM support Exchange 2010 / 2013? Will it need a major overhaul?
- Reverse Proxy – Do you have ISA 2000/2004/2006 – which is not officially supported for Exchange 2013? Or are you lucky enough to have TMG 2010 which is compatible with Exchange 2010 and 2013? If you don’t have those then you have a range of options when you upgrade – no proxy, IIS ARR, WAP, or the reverse proxy included with a hardware load balancer.
Other Design Considerations
Although this section is vastly over-simplified I think it is well worth reviewing some of the changes in 2010/2013 that need to be considered in an upgrade:
- Office version – Outlook 2003 is not supported in Exchange 2013 Organizations
- Clustering – no longer a strict Windows cluster with shared storage, Exchange 2010/2013 utilizes Failover Clustering in Windows 2008/R2 or Windows 2012/R2.
- Storage Considerations – JBOD or local storage is the preferred method of storage with the implementation of DAG replication between Exchange Server nodes. Storing both copies of a database in a DAG on a SAN creates a single point of failure for your Exchange Organization.
- Public Folders – Exchange 2010 and 2003 have similar models when it comes to Public Folders. However, Exchange Server 2013 has a radically different model different model and the migration process is quite involved. Limits in Exchange 2013 Public Folders requires consideration also. Planning for this piece is essential and a decision for either removing Public Folders, moving to SharePoint or keeping Public Folders could be crucial to the migration from Exchange 2013.
- Physical or Virtual – Over the past few years there has been a big push to virtualize any and all servers. Exchange 2003 did not support virtualization, however both Exchange 2010 and 2013 support this as an option. While virtualization works great most of the time this advice should always be taken with a grain of salt. Some considerations for Exchange Server are that it generally requires more resources than a typical server. You could potentially be building servers with 8-16 cores and 64-128 GB of RAM. When virtual servers get to that size the potential benefits are not as great as a virtual server of this size nearly consumes the resources of a lot of good size physical servers. Add that to the fact that local storage can provide the needed I/O and storage quantity, the need for remote, virtual storage is reduced.
- Disk Space – Exchange 2007 was the last version that included Single Instance Storage (SIS). When data is migrated to Exchange 2010 and 2013 the amount of space needed will increase by at least 30%, but the potential exists for this to increase to 50+% depending on your Exchange usage. Plan accordingly.
- Compliance – Exchange 2013 now includes Data Loss Protection (DLP)and Retention Policies which help organizations manage their messaging environments better. Both require planning to be executed properly.
The list above is not meant to be a complete list because many organizations have more complex needs than listed above. Multiple sites, complex SAN replication, etc. It’s best to review what you have now and where you want to be so that plans can be made accordingly. You may also want to integrate newer applications into your Exchange Organization like Lync 2013 or CRM software. Plans for any application integration should be included in the general planning design for an upgraded Exchange Organization.
Simply put, if you are still on Exchange 2003, you should migrate as soon as possible. Support and security concerns should be the highest reasons why, while new features and performance should follow right after. Over the years, I have found that migrations of this sort need an expert to make sure it goes smoothly. This can be an internal employee or a consultant. Make sure that the person migrating has prior experience and a deep understanding of Exchange prior to attempting this. Plan for any outages that may occur and make sure your backups are good for Active Directory and Exchange are verified as good (test restores are the best method) and Good Luck on your migration!