The Exchange 2016 migration for Not Real University is at the stage where they are ready to cut over their client access namespaces to point to Exchange 2016. The cutover itself is just a DNS change for internal namespaces, and a firewall change for external namespaces, but it is a high impact change as it will result in all of your clients connecting to Exchange 2016 for HTTPS services. Any Exchange 2010 mailbox users will continue making RPC connections to the Exchange 2010 CAS array (RPCClientAccessServer). If public folders are still hosted on Exchange 2010 the Outlook clients for Exchange 2013/2016 mailbox users will be proxied to Exchange 2010 for public folder access.
As with any DNS change, rolling the change back is as simple as pointing the DNS record back to its previous value. To ensure a quick change and, if necessary, a quick rollback, you should lower the TTL of your DNS records to less than 5 minutes. A very low value of 1 minute is often recommended. When the change has been proven successful after a few days or weeks, you can increase that TTL value to something higher.
For the external namespace cutover, rolling back the change is usually as simple as reversing the firewall rule changes.
If the external namespace being used, for example mail.notrealuniversity.com, is also the name used for the MX record for inbound mail flow from the internet, then any DNS or firewall changes will also impact inbound mail flow. That is unless your firewall is able to NAT the SMTP port (TCP 25) separately to the HTTPS port (TCP 443), which most firewalls can.
Before the change is made, Not Real University has the following client access flow:
- Inbound HTTPS connections are NATed to the Exchange 2013 server. Internal HTTPS connections also resolve to the Exchange 2013 server. Exchange 2013 proxies HTTPS connections to Exchange 2010 and 2016 (there are no 2016 mailboxes at this time, but 2013 is capable of “up proxying” to 2016).
- SMTP mail flow is unaffected by the changes planned for client access namespaces.
After the DNS and firewall changes, the client access protocol flow for Not Real University is as follows:
- Inbound HTTPS connections are NATed to the Exchange 2016 server. Internal HTTPS connections also resolve to the Exchange 2016 server. Exchange 2016 proxies HTTPS connections to Exchange 2010 and 2013, and public folder connections to Exchange 2010.
- RPC connections for Exchange 2010 mailbox users resolve to the Exchange 2010 server.
As an example, here is the Outlook connection status dialog box for an Exchange 2013 mailbox user after the client access cutover has been performed.
When the client access cutover has been completed and successfully tested, the mail flow cut over can also be performed, which is what we’ll look at next.
Thank you for share your experience, I am facing an issue, I’m migration 2010 -> 2016, everithing looks fine, just following your steps, but, in this point, I have outlook 2016 in win 10 machines, those clients are not able to connect to the exchange 2016 server, It just keep asking password and never connect, what do you think im doing wrong?
Have you rolled the ASA across all the servers? I came across this when doing an upgrade a couple of years back and outlook was failing kerberos because the ASA hadn’t been configured.
We are in the process of migrating exchange 2010 to 2016. Exchange 2010 was using Windows NLB and published using TMG. For exchange 2016 we are planning to use F5. Our network team has configured F5 to load balance internal outlook connections . I can connect to exchange 2016 test mailboxes and exchange 2010 mailboxes by changing local host entry pointing to F5 VIP.. But I am facing issue in publishing exchange 2016 for external access using F5. As per the team responsible F5 for external access, they are not using APM. they directly published the internal f5 vip to the external(internet). OWA is working for new and old exchange. but outlook is working only for exchange 2016. we are facing problem in connecting old exchange 2010 mailboxes from external using this scenario.
We are using different name for exchange 2010 cas array name and it was found that CAS Array shows 2016 servers also as array members and exchange 2016 DBs shows cas array name as RPC client access proxy.
While connecting to exchange 2010 mailbox, it keep asking password and if we look at connect status, it shows car array in the server name from external network..
For exchange 2010 mailbox to work in co-existence scenario do i have to modify any setting in F5 or exchange ?
Any help would be appreciated
After migrating client access to new server testing owa access is successful for most of 2010 mailboxes (redirection to 2010 mailbox is successful)but one mailbox server doesn’t redirect and encounter “The page isn’t redirecting properly” with too many /owa/owa/owa… in address bar .Chrome report “ERR_TOO_MANY_REDIRECTS”
Could you please help me on that?
Perhaps someone has tried to manually set up a redirect on that IIS virtual directory? You’ll need to go back over all the configuration changes that were made to the server, or compare to working server, to get an answer.
I changed IIS http to https redirection based on this link:
and it works fine for all other users.
we have exchange 2013 currently and we wanted to migrate to 2016. i just wanted to know for creating coexistence environment external traffic where should i point. currently its pointing to 2013 cas, when we migrating mailbox from 2013 to 2016 will 2013 exchange proxy the request to the Exchange 2016.?
As I wrote in the article, 2013 is capable of “up proxying” to 2016.
Hello Paul Thank you for you reply.
in coexistence scenario(2013-2016) external DNS, should I point to 2016 exchange or 2013 ?. also I wanted to know for configuring 2013 -2016 coexistence environment do we required two External DNS record(like mail.abc.com and legacy.abc.com)?. I heard that for 2013 – 2016 coexistence setup we required only one External DNS record? is that true?
What guidance are you following for this migration? This is all widely documented so I’m concerned you’re not following a good resource.
Your articles are always extremely helpful.
I am facing a wiered issue, we are at stage of migrating to exchange 2016 with 2010 co-existence.
I have have mailbox on the Exchange 2016 database, the URL are currently pointing to Exchange 2010 server. When this user tries to login using OWA I receive the error
“A server configuration change is temporarily preventing access to your account. Please close all Web browser windows and try again in a few minutes. If the problem continues, contact your helpdesk.”
I will highly your appreciate your valuable advise on this issue
You’ll need to migrate your OWA namespace to the 2016 server before you can login to OWA for a 2016 mailbox. If you don’t want to make the DNS change yet you can do it as a hosts file entry on a test PC.
Anybody that can share more information about how Exchange 2016 Picks a Target Legacy Exchange 2010 Server?
“It’s important to understand that when MBX2016 proxies to a legacy Exchange Client Access server, it constructs a URL based on the server FQDN, not a load balanced namespace or the InternalURL value. But how does MBX2016 choose which legacy Client Access server to proxy the connection?”
“When a MBX2016 starts up, it connects to Active Directory and enumerates a topology map to understand all the Client Access servers that exist within the environment. Every 50 seconds, MBX2016 will send a lightweight request to each protocol end point to all the Client Access servers in the topology map; these requests have a user agent string of HttpProxy.ClientAccessServer2010Ping. MBX2016 expects a response – a 200/300/400 response series indicates the target server is up for the protocol in question; a 502, 503, or 504 response indicates a failure. If a failure response occurs, MBX2016 immediately retries to determine if the error was a transient error. If this second attempt fails, MBX2016 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), MBX2016 will attempt to determine the health state of the down CAS to determine if it is available.”
So this proxy function is using round robin then?
Today, Exchange 2010,Outlook 2010, 10000 users, hardware loadbalancer.
When we install Exchange 2016 and move current namespace to Exchange 2016, http/https traffic will go to the Exchange 2016 servers, (OWA, Active Sync, Outlook Anywhere, ECP)
Outlook 2010 RPC/MAPI access will still go through the (CASARRAY), HW loadbalancer. (until the mailbox is moved to 2016)
But don’t want to have 10000 users hitting just one Exchange CAS server for http/http services.
Is this proxy funtion is using round roben then?, no possibility to use HW loadbalcer for this?
If you are going to use different namespaces for 2016 (in a new AD site, new data center, don’t want the current location-centric namespaces used by 2010) that you will migrate 2010 over to (except Outlook Anywhere), can 2016 still proxy to 2010?
I.e. current 2010 namespaces:
OWA – abcowa.domain.com (needs to be unique as it’s sent through pre-auth before allowing in OWA)
ECP – abcowa.domain.com
EWS – abcmail.domain.com
OAB – abcmail.domain.com
AS – abcmail.domain.com
AutoDiscover – abcmail.domain.com
OA – exchmail.domain.com
Desired 2016 namespaces
OWA – owa.domain.com (needs to be unique as it’s sent through pre-auth before allowing in OWA)
ECP – owa.domain.com
EWS – mail.domain.com
OAB – mail.domain.com
AS – mail.domain.com
AutoDiscover – mail.domain.com
OA – exchmail.domain.com
So, with differing namespaces like this (except keeping the same namespace for Outlook Anywhere), can the 2016 still proxy connections to the 2010 if all clients are pointed to 2016? Outlook Anywhere makes sense, since it will keep the same namespace and the DNS record would be changed to point to the 2016 side, but I’m not sure if having the other URLs as different presents an issue?
Sorry, I forgot to mention that the 2010 EWS URLs match the 2010 OA External host name, so exchmail.domain.com, and the external EWS in 2016 would be exchmail.domain.com as well. Trying to keep it simple, but fit needs, and still work correctly during migration.
There’s different proxy vs redirect behavior depending on whether the 2010 site has an external URL configured or not (which yours currently does).
Microsoft walks through the different scenarios here:
You Sir/Madam are the enemy of confusion everewhyre!
On the different VDIR (owa,ecp,ews etc) there is an Internal and an External authentication method. Can you tell more when which is used? Does Exchange somehow check where traffic comes from?
The recommended practice is to use the same URL for both internal and external on each vdir/service. However, in case such as Outlook Anywhere, where different auth is required for external access vs internal access (e.g. if external access comes via a reverse proxy that needs specific auth configured), then different namespaces can be configures so that Exchange and the client can tell whether the access being attempted is internal or external.
OK but what if we use same namespace on internal & external URL and then use different authentication method for internal and external authentication, what authentication is when used and how does Exchange know of the auth is external or internal? Or are internal and external auth are used in conjunction with internal and external namespace?
If you need different auth, then you must use different namespaces.
Maybe if that little nergo that was killed in rwanda opps imean Chicago had a gun and beeglond to the NRA he would have been able to defend himself instead of being a dead negro.