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.
Why Migrate?
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.
Conclusion
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!
UC, the article is very good(there was even some info i didn’t knew, like the SIS issue and E13 PF architecture) but there are several points i have to digress based on our experience:
1) Why would an organization still be running 2003 in 2014?: because it just works, and will keep working regardless of support and updates, sure 2003 OWA is god-awful but it’s still serviceable, OWA can be reverse proxied to make it more secure as well.
Also, soft/server age is of no consequence, here servers are used until they croak, until last year~ most users still had XP.
you ask “why migrate?” and in reality there’s no compelling reason for most companies below 50 to 100 seats and i’ll sum it up as follows:
*) functionality:
Internet will keep using SMTP for mail, that will never change, so E2003 will keep sending and receiving mail, that’s the main thing it’s for and for that it works..
Managing E2003 is dead easy everything done from the EMC.
of all the E2003 installs i manage/managed, almost none where troublesome(save for specific problems), mail entered, mail left, and that’s all the exchange needs to do
*) ridiculous costs and annoyance:
Whoever is running 2003 surely does not have an SA agreement, or they are also using SBS 2003 which was wildly popular as SBS was always priced fairly. Let’s take the “discrete” install first:
They’d have to rebuy all their licenses again: Win2012R2 (at least 1), exchange 2013 std, plus windows AND exchange cals.
in SBS case it’s worse as there’s no more SBS, win 2012R2 essentials is a sham designed to make you waste money on that crap O365 infinite money sink OR having to buy a standard E2013 license(which alone costs more than an entire SBS2011 one), costs savings like SBS aren’t there anymore
The HW you used on 2003 will not work for 2013, you could run an entire all-in-one server (dc+sql+fileserver+exchange) on 3~4GB of RAM (SBS2003 runs on that with no issues), for 2013 you need a new expensive server, and if you think about virtualizing even more…
You’d also might have to re-buy office licenses, which are one of the most expensive overpriced things ever (H&B barely cuts it).
and i’m forgetting backup software, unless you chose to use 2012R2 integrated backup(which works very well), but if you wanted to maintain advanced backup functionality provided by backup software, that’s another re-buy (maybe they will offer you a “prior-version upgrade” at discounted price, not like MS that likes to fleece you dry)
so you’re looking at tens of thousands of dollars cost in licenses and HW alone! even for the most basic 1-server/10 user scenario, with all previous investments discarded and no reuse!.
That’s not compelling at all(in fact, it’s so ridiculous it falls under “full retard” and you never go full retard… 😉 ) for any owner that has to pay for that(and if i where the internal IT guy that was there when everything was bought in the past i wouldn’t want to risk my job by saying to the owners “yeah.. you se all we have?, we must throw it all away and buy everything new… just because….”).
As a consultant i couldn’t save face or even know how to propose such ludicrous idea without feeling ashamed myself or ending up as an untrustworthy vulture salesman that’s only after the sale.
*) what are the tangible benefits?
Nicer OWA(VERY nice owa, credit where credit’s due, it’s absolutely gorgeous)
that-is-it.
Managing E2003 with the unified AD/EMC was the easiest exchange to administer ever, ever since the move to PS it’s been a horrible mess. E2013 made great advances but you still need arcane PS commands to do a lot of stuff(basic stuf like mass mailbox addition/management need to be done with PS, that’s retarded product design, 100% of the product should be controllable from the EMC) what was done with a few clicks here and there on 2003 EMC,-EVEN if you didn’t remember a specific setting- you could hunt for it easily, with exchange PS, good luck if you don’t have some TXT stashed with a list of all the commands you used to use.
¿DLP?, sounds nice, it’s painfully impossible to implement without having to probably redesign you entire company way of working(and that won’t happen), with mandatory digital fingerprinting via GPO(if you can do that) etc etc, and it boils down that separating legit from a leak is near impossible as a user could send the same data and be legit depending on the recipient, the criteria for legit/leak is impossible to characterize with a “DLP rule” looking for some string in the emails.
¿Mobile devices?, of all the IT guys i’ve work with in companies, they don’t give a F about them, they don’t care and don’t want to have to manage even more devices, want to have corporate email on your phone?, use OWA and bugger off
*) Support:
so MS support ended, so what?, MS support means practically nothing and i’ve never once used MS support as you need to pay an exorbitant fee for a measly case and when in doubt using forums/publicly available docs solved the issue all the time.
There won’t be security fixes you say, again, largely irrelevant, exchange is isolated via border devices so security bugs are not applicable