I’ve request Samir Marwaha (MS PFE Xchange) who is also one of the co-host for NEW JERSEY UNIFIED COMMUNICATION USER GROUP to write a paragraph which can be helpful to avoid common mistakes migrating to Exchange 2013. Here you go with a precise information which can save you hours.
Things to watch out for Exchange 2013 Migration
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.
#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.
#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
#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.
#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.