This article is part of a series on migrating from Exchange Server 2010 to 2013.
Before the Exchange 2013 migration project moves into the co-existence phase, where production services are provided from both the Exchange 2010 and 2013 servers, there are some final checks and configurations that should be performed.
General Health Check
Before any migration or cutover of services it pays to verify that the current Exchange Server 2010 environment is in good health. This avoids potential support confusion if a service is cutover to Exchange 2013, is found to be not working, and then it is unknown whether the service was already faulty or whether it was the cutover that caused the fault to occur.
Here are a few suggestions:
- Run Test-ExchangeServerHealth.ps1 to perform a health check of the servers
- Use the ExRCA tools to test external access
- Note that the ActiveSync test may fail on the final step if your ActiveSync mailbox policy does not allow non-provisionable devices. Either use a different mailbox policy for the test user you use for ExRCA, or use a mobile device to perform the testing instead.
- Confirm that backups for Exchange 2010 are functioning correctly
- Review the Exchange 2010 server event logs for any unusual errors
- Launch Outlook for a new test user and verify that Autodiscover works correctly
- Test Exchange Web Services by doing free/busy lookups
- Verify that mail flow between existing servers is healthy. If you have a large/complex environment you can use my mail flow heat map script for this.
Configure Outlook Anywhere
During co-existence all Outlook connections to mailboxes are via the Exchange 2013 Client Access servers using RPC-over-HTTPS (Outlook Anywhere), even internal connections.
If Outlook Anywhere was not previously used in your Exchange 2010 organization it needs to be enabled and configured.
If Outlook Anywhere was already enabled and configured, it needs to be checked to confirm that the correct authentication settings are in place to allow Exchange 2013 to proxy connections to Exchange 2010 for users who have not yet been moved to Exchange 2013.
For the Exchange Server Pro organization the servers are configured as follows:
[PS] C:\>Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "*14.*" -and $_.IsClientAccessServer} | Get-OutlookAnywhere | fl servername,externalhostname,*auth*
ServerName : HO-EX2010-MB1
ExternalHostname : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods : {Basic}
ServerName : HO-EX2010-MB2
ExternalHostname : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods : {Basic}
ServerName : BR-EX2010-MB
ExternalHostname : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods : {Basic}
The IISAuthenticationMethods need to be updated to include NTLM.
[PS] C:\>Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "*14.*" -and $_.IsClientAccessServer} | %{Set-OutlookAnywhere "$_\RPC (Default Web Site)" -IISAuthenticationMethods Basic,NTLM}
Configure Virtual Directories
The Exchange 2013 Client Access server virtual directories should be checked to ensure they are configured correctly for your environment.
The Exchange Server Pro organization has OWA and ECP virtual directories configured for Basic and Integrated authentication, and uses Forefront TMG to publish them to the internet with Forms-based Authentication. Therefore, the OWA/ECP virtual directories for Exchange 2013 also need to be configured the same way so that the TMG publishing can continue to work.
This is particularly important for TMG authentication delegation to continue working. Using a different authentication type for Exchange 2013 potentially means the TMG configuration also needs to be re-assessed.
For more information on publishing Exchange 2013 with TMG see the following article:
For organizations that are simply NATing port TCP 443 (HTTPS) to the Client Access servers then this is less of an issue and changing authentication types likely has no other significant technical considerations.
Communicate Changes to Users
This may seem obvious but communicating the upcoming changes to end users is important. Particularly for OWA, which will present the Exchange 2013 OWA logon to Exchange 2010 users once the OWA namespace is pointed at the Exchange 2013 CAS and it is pre-authenticating and proxying connections to Exchange 2010. Naturally the OWA interface itself is new in Exchange 2013, so some training or documentation updates for end users may be wise.
Other than that, as long as you’re re-using the same namespaces as the existing Exchange organization there is not likely to be any other user-visible changes that need communicating.
In the next part of this series we’ll begin cutting over the Client Access namespaces to Exchange 2013.
Return to the Exchange 2010 to 2013 migration series index page.
This article Exchange Server 2010 to 2013 Migration – Preparing for Co-Existence is © 2014 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
