This article is an excerpt from the Exchange Server 2010 to 2013 Migration Guide.
After installing the first Exchange 2013 server into an existing Exchange 2010 organization we are effectively in a co-existence state. During this phase of the Exchange 2013 migration project there are some management considerations to be aware of.
Exchange Server 2013 Management Tools
On the Exchange 2013 servers there are three parts to the Exchange management tools:
- The Exchange Admin Center, a web-based administration console
- The Exchange Management Shell, a PowerShell interface for Exchange 2013
- The Exchange Toolbox, which contains a few MMC-based tools for Exchange 2013
For a migration scenario you will primarily be using the Exchange Admin Center and the Exchange Management Shell.
Accessing the Exchange Admin Center During Co-Existence
The Exchange Admin Center can be accessed using a web browser. It is available on any Exchange 2013 server with the Mailbox server role installed. Because this is a web-based console you do not need to log on directly to the server to use it, nor do you need to install any management tools on your admin workstation to access it.
The URL for the Exchange Admin Center is https://serverFQDN/ecp, for example https://ex2013srv1.exchangeserverpro.net/ecp, or https://mail.exchangeserverpro.net/ecp if you have already configured and migrated your Client Access namespaces.
It is likely you will see an SSL certificate warning in your browser when you first access the EAC, due to the default self-signed certificate on the server. Later when you have configured the correct namespaces and SSL certificates this warning will not appear.
Exchange Admin Center Redirects to Exchange Server 2010 OWA
If you log on to the Exchange Admin Center with a user account that has an Exchange 2010 mailbox then you may be redirected to the Exchange 2010 OWA page instead.
To avoid this you can append the ?ExchClientVer=15 string to the end of the URL, for example https://ex2013srv1.exchangeserverpro.net/ecp?ExchClientVer=15.
However, in some cases such as when the new Exchange 2013 servers are located in a different AD site to the Exchange 2010 servers, this workaround may not be successful.
In such cases it is often simpler to create a new admin account specifically for use during the co-existence period. In this example scenario I’ve created an account called “E15Admin” and added it to the Organization Management group.
Managing Exchange Objects During Co-Existence
There are some general rules for managing Exchange objects during co-existence. From TechNet:
You can’t use the Exchange 2010 EMC to manage Exchange 2013 objects and servers. While customers upgrade to Exchange 2013, we encourage them to use the EAC to:
- Manage Exchange 2013 mailboxes, servers, and corresponding services.
- View and update Exchange 2010 mailboxes and properties.
- View and update Exchange 2007 mailboxes and properties.
We encourage customers to use Exchange 2010 EMC to create Exchange 2010 mailboxes.
We encourage customers to use Exchange 2007 EMC to create Exchange 2007 mailboxes.
Customers can continue to perform management tasks using the Exchange Management Shell and script tasks.
Transport rules are a slightly different situation. From TechNet:
When you coexist with Exchange 2010 or Exchange 2007, all transport rules are stored in Active Directory and replicated across your organization regardless of the Exchange Server version you used to create the rules. However, all transport rules are associated with the Exchange server version that was used to create them and are stored in a version-specific container in Active Directory. When you first deploy Exchange 2013 in your organization, any existing rules are imported to Exchange 2013 as part of the setup process. However, any changes afterwards would need to be made with both versions. For example, if you change an existing rule using the Exchange 2013 EAC, you need to make the same change using the Exchange 2010 or Exchange 2007 EMC.
In the next article in this series we’ll look at configuring SSL certificates for Exchange Server 2013.
For more information see the Exchange Server 2010 to 2013 Migration Guide.
Hi Paul, regarding transport rules… As you said them are AD based objects and are imported during the setup. But my concern is: are them applied twice if a message goes through the “categorizer” of the transport server component of both of my servers? Let’s say that a rule applies to two users, one is on the xch2010 DB, the other is on the xch2013 DB. What happens? Since transport rules are “Organization wide” objects, them should be applied once, I suppose, ain’t it? Thank you very much.
Given that Exchange 2016 is so similar to Exchange 2013. Do you think a scenario containing Exchange 2010, 2013 and 2016 servers would be viable. For example if you were upgrading to Exchange 2016 from a previous co-existent environment.
I don’t know what your criteria for “viable” are, but Exchange 2010, 2013, and 2016 are supported for co-existence.
Thanks so much! Was stuck for a few days trying to figure out why I couldn’t connect to the new console.
I have Exchange 2010 is running, i want to migrate it to Exchange 2013 with 20000 Mailboxes… I don’t want new URL in Exchange 2013 and do not want to disturb Exchange 2010 Users…. Simply, i want OWA redirection … What i understand after reading different Forums and article is :
1. Export Exchange 2010 certificate.
2. Import to Exchange 2013 server and SET for IIS, SMTP etc
3. Set External & internal URL in Exchange 2013 same as Exchange 2010 (mail.abc.com).
Is this enough or i am missing anything ..
You are great man. I was stuck for a week and that fixed my issue