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.
gotcha #1: Clients
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.
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.
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.
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.
gotcha #2: Outlook Web App redirection
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.
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
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.
already implemented Windows Integrated Authentication for Outlook Web App logins,
you won’t be affected.
gotcha #3: Outlook Anywhere
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.
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.
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
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
gotcha #4: Sizing and performance
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.
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.
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.
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.
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.
gotcha #5: Ambiguous namespaces and Exchange 2010 migrations
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.
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.
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.
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).
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.
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.
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