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 2012update or later, while Outlook 2010 must run Service Pack
1 along with the November 2012update 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 runningOutlook 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.
