Essential Guide

Three essential steps for preparing to migrate to Exchange 2013

A comprehensive collection of articles, videos and more, hand-picked by our editors

Five Exchange 2013 migration gotchas to watch for

An Exchange 2013 migration is no small undertaking. To ensure a successful deployment, avoid these potential mistakes.

Exchange Server 2013 is a bigger, more complex platform that leaves behind some of the legacy Exchange features...

in favor of new ones along with better overall reliability. Before upgrading to the latest version, it's important that you're aware of a few factors that will help ensure a successful migration.

Exchange 2013 migration gotcha #1: Clients

Just as Exchange 2010 removed support for Outlook 2000, Exchange 2013 removes support for Outlook 2003. When it comes to Exchange 2013, you must use Outlook 2007, Outlook 2010 or Outlook 2013. Outlook 2007 must run Service Pack 3 along with the November 2012 update or later, while Outlook 2010 must run Service Pack 1 along with the November 2012 update or later.

When patching clients, consider Windows Server Update Services. You can also use the Microsoft Assessment and Planning toolkit, as well as the Get-LogonStatistics cmdlet in Exchange 2007 and the Exchange Server User Monitor (ExMon) in Exchange 2010.

And it's not just Outlook you need to worry about. With Exchange 2007, users could experience Outlook Web Access in all its glory with a version of Internet Explorer as low as IE6. In Exchange 2010, the minimum version required to experience the Premium Outlook Web App is IE7. Therefore, it shouldn't surprise anyone that IE8 is necessary for Exchange 2013. At the time of writing, however, IE8 suffers from performance issues when running Outlook Web App 2013, so consider IE9 the baseline. It will give users the best OWA 2013 experience on Vista and above.

For Windows XP and other operating systems, third-party browsers like Firefox (v17+), Chrome (v24+) and Safari (v6+ on Mac) also provide great support for Exchange 2013. Check out the table of supported clients on Microsoft's TechNet site for the most up-to-date information.

Exchange 2013 migration gotcha #2: Outlook Web App redirection

This one affects companies migrating from Exchange 2007 that use forms-based authentication (FBA) within Exchange. Previously, when a company migrated from Exchange 2003 or Exchange 2007 to Exchange 2010, legacy coexistence with FBA worked very well. When a user logged into OWA, he was redirected to the legacy server, and the username and password were passed along with the redirection request.

In a coexistence scenario with Exchange 2007 and Exchange 2013 (using FBA) the username and password are not passed when an Exchange 2007 user logs in. The user is redirected to an Exchange 2007 server and is forced to log on a second time. If you're expecting a lengthy coexistence period, look into how you'll work around this issue.

If you already use Forefront TMG 2010 to perform pre-authentication and forms-based authentication, you're free to continue using it. Alternately, various third-party load balancers provide built-in pre-authentication support.

All this said, if you've already implemented Windows Integrated Authentication for Outlook Web App logins, you won't be affected.

Exchange 2013 migration gotcha #3: Outlook Anywhere

All communication for Outlook clients with Exchange 2013 use HTTPS rather than the combination of RPC/MAPI and HTTPS used in previous versions. Specifically, this means that Outlook Anywhere  is used for internal clients as well as external clients. Mailboxes that still reside on Exchange 2007 and/or Exchange 2010 during the coexistence period will continue to connect internally via traditional RPC/MAPI.

If your organization uses Outlook Anywhere externally, ensure that Outlook Anywhere is also enabled on Exchange 2007 and/or Exchange 2010. This is because Exchange 2013 will proxy Outlook Anywhere requests to the version of Outlook Anywhere that corresponds to the version of Exchange Server the mailbox is on.

It's not quite as simple as just enabling Outlook Anywhere or leaving it enabled. You must make sure that NTLM authentication at the IIS level is enabled for both Exchange 2007 and Exchange 2010.

One more thing when it comes to Outlook Anywhere: If the Exchange 2007 servers that run Outlook Anywhere are also running the client access server and mailbox server roles -- and not a Global Catalog server -- you must disable IPv6, as detailed in knowledge base article 2794253

Exchange 2013 migration gotcha #4: Sizing and performance

Performance and sizing can certainly prove a contentious aspect of any Exchange 2013 migration. Deployment guidance was released in May 2013, meaning early deployments that didn't benefit from Microsoft's assistance needn't re-evaluate their specifications. Others have been incorrectly looking at existing Exchange 2010 sizing guidance to provide a high-level view of what hardware they need, with some making the mistake of doubling RAM and CPU.

If you've done this, don't panic, but realize you may need to buy additional hardware. Exchange 2013 sizing is fundamentally different and it's not as easy as giving it a bit more power. Instead, you need to re-think the best way to deploy Exchange 2013.

JBOD (just a bunch of disks) is a great option for many customers, thanks to the auto-reseed features, which allow for massive disk savings. The Exchange Product Group also advocates the use of "building blocks," which are servers that only have local storage. For example, you may have 12 internal four TB disks as your Exchange Server base. Consider using these, rather than expensive add-on arrays. You might end up with a smaller user count per-server, but you'll use fewer disks and benefit from improved reliability.

As with any Exchange Server 2013 implementation, a critical step is using JetStress to ensure that the storage subsystem is capable of handling the expected load. JetStress has been updated for Exchange 2013 and is available to download -- but watch out. If you're new to JetStress or looking to follow Microsoft best practices, be warned that the updated version of the JetStress Field Guide has not yet been released.

Additionally, LoadGen, the complementary tool that helps test a real-world simulation of activity has not been released either. Therefore, if these tools are essential to your deployment, you may have to hold tight -- at least for the time being.

Exchange 2013 migration gotcha #5: Ambiguous namespaces and Exchange 2010 migrations

What exactly are namespaces? Well, in the context of Exchange Server, they are the names used to connect to Exchange both internally and externally using HTTPS, as well as connect to Outlook clients internally using RPC/MAPI.

During the coexistence period of any Exchange 2010 to Exchange 2013 migration, you'll need to update the DNS entries for your InternalURLs and ExternalURLs to point at your Exchange 2013 infrastructure. Clients with Exchange 2010 mailboxes will have HTTPS services proxied to the Exchange 2010 servers behind the scenes.

An Exchange implementation that follows Microsoft's recommendations will use a single set of names for both internal and external HTTPS URLs (for example, mail.contoso.com) and a separate name for the RPC client access array (for example, outlook.contoso.local). When the HTTPS name is moved to Exchange 2013, the RPC client access array name remains on Exchange 2010.

There's a gotcha here for organizations that have implemented namespaces incorrectly. Some Exchange 2010 implementations use an external HTTPS namespace (again, call it mail.contoso.com) but internally, use the same name for both the internal URLs and RPC client access array (for example, using outlook.contoso.com for RPC/MAPI and services like OWA).

When you move the internal name to Exchange 2013, you'll break existing Outlook client connectivity. The trick here is to update your internal HTTPS URLs to use the external HTTPs URLs. You may want to consider potentially implementing split DNS or pinpoint DNS in the process.

A small number of organizations have implemented a single name, both for internal and external HTTPS URLs and the RPC client access array. If this describes your setup, you likely need to change your RPC client access array name to something unique. Unfortunately, this does not automatically propagate to clients and you may need to either force Outlook clients to update, or do as Microsoft suggests and move internal Outlook clients on Exchange 2010 to Outlook Anywhere.

Final thoughts

Some of these gotchas might sound like serious problems, but don't let them deter you. Armed with the right information, you can easily complete a successful Exchange 2013 deployment.

About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the UK's leading Microsoft Gold partners, Phoenix IT Group. Goodman has worked in the IT industry for 14 years and has worked extensively with Microsoft Exchange since version 5.5.

This was last published in July 2013

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

Three essential steps for preparing to migrate to Exchange 2013

Join the conversation

21 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

When do you plan on migrating to Exchange 2013?
Cancel
We are inside the kickoff project phase. Migration from lotus domino 8.5.2
Cancel
In the next couple weeks.
Cancel
We are migrating very soon to Exchange 2013 CU1 On-Premises :-)
Cancel
When Exchange 2013 is supported on Windows 2012R2 we will look at it.
Cancel
no budget this year. :(
Cancel
Next month because we have been bought by a company that wants us to migrate to there 2013 Exchange servers on there sub domain.
Cancel
We have to complete the migration from Exchange 2003 to Exchange 2010 then we will move to Exchange 2013
Cancel
No hurry since we are already on Exchange 2010 and other projects take priority.
Cancel
We aren't using  at this time testing Microsoft Exchange helps  protect your data and keeps your employees connected with secured, reliable access to email, calendar, and contacts from virtually any device
Cancel
THANKS :-)
We are migrating to Exchange 2013 CU1 On-Premises, and these tips will be helpful.
Cancel
To many issues presently with Exch2013 to make it worthwhile. And little to no Microsoft help in deploying hybrid on-premise with cloud exch2013 as secondary/backup. Extremely disappointing.
Cancel
We may go to the cloud instead. One way or another we will be on exchange 2013. We want the new public folder capabilities.

Mark Magnus
Cancel
we'll upgrade our small system to learn about migration scenarios
Cancel
Waiting for backup products to support Exchange 2013 before we upgrade.
Cancel
We should be migrating to Exchange 2010 then to Exchange 2013 within the next 4 months. That is if nothing slips or breaks
Cancel
looking forward to Exchange Server 2013
Cancel
I just put in an Exchange 2013 solution and have major concerns. No Edge server! You have to use a 2010 Edge server. Lack of backup support. A weird issue where members of a protected group lose all mobile access via ActiveSync - protected groups are administrators, Print Operators etc. You have to alter an individuals AD settings if you are one of these. Took me a day to id and resolve. For a large organisation this could be a disaster.
Cancel
We are now done with migrating to Exchange 2013 CU1 On-Premises with no issues ;-)
Cancel
IBM TSM doesn't offer support for Exchange 2013 yet!
Cancel
With Exchange 2013 CU2 you no longer need to login to 2007 separately after being redirected from Exchange 2013
Cancel

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close