With all co-existence preparations complete we can now cut over the namespaces to Exchange Server 2013.
First, let’s be clear that this is a significant change and should be approached with due care. Although the changes themselves are quite simple (mostly DNS changes), they are best performed during a window of time when they will have the least impact on your end users, with enough time for you to test the outcome and roll back if there is a problem.
On the topic of rolling back, your changes should be well planned and well documented as you go along, so that you can easily reverse them if you need to.
Cut Over External Namespaces
For the Exchange Server Pro organization the external namespaces are:
- autodiscover.exchangeserverpro.net
- mail.exchangeserverpro.net
In a scenario where the external IP addresses are staying the same the cut over would occur on the edge router or firewall that performs NATing for the network. However in this case the internet-facing Exchange 2010 servers are in the Head Office site, while the new internet-facing Exchange 2013 servers are in the Datacenter1 site which has its own internet connection and a new public IP range.
Therefore the change is made in public DNS, updating the records to the new IP addresses. Depending on the TTL (time-to-live) on those DNS records this change may take anywhere from several minutes to several hours to take effect. It is recommended before making planned DNS changes to lower the TTL to a short timespan (eg 5 minutes) at least a day or two in advance of the change so that it will take effect faster, as well as allowing faster roll back.
Note that for the Exchange Server Pro organization this change will impact Client Access services (such as OWA, ActiveSync, Outlook Anywhere), as well as Transport services (ie MX records, mail flow), because the MX record for the domain points to mail.exchangeserverpro.net as well. If the MX record pointed to a different DNS name, or the IP addresses weren’t actually changing, then services on different ports could be cut over at different times.
For more on managing changes to MX records see the following article:
After making the changes to public DNS and/or your firewall NATing repeat the testing and health checks performed earlier to verify that services are working as expected.
The outcome of the external DNS changes is that external access (eg Outlook Anywhere, ActiveSync, OWA, and inbound SMTP) will go via the Exchange 2013 servers and be proxied/routed internally as required.
Cut Over Internal Namespaces
For the Exchange Server Pro organization the external namespaces are:
- autodiscover.exchangeserverpro.net
- mail.exchangeserverpro.net
- imap.exchangeserverpro.net
- pop.exchangeserverpro.net
- smtp.exchangeserverpro.net
High availability for Exchange 2013 Client Access services in Datacenter1 will initially be handled by DNS round robin. So the DNS records for the above namespaces (except SMTP) are updated in the internal DNS zones with two A records, which point to each of the Exchange 2013 IP addresses.
SMTP is a little different. SMTP doesn’t work well with DNS round robin, because many SMTP clients (such as printers) will simply fail a connection if the IP they attempt to connect to doesn’t respond, rather than retry with a different IP as most modern HTTP clients do (including Outlook).
For now the Exchange Server Pro organization is retaining a load balancer for SMTP, so the cut over for SMTP is performed on the load balancer configuration itself. If this cost wasn’t practical or high availability for SMTP wasn’t important then pointing the SMTP namespace at just one Exchange 2013 server IP address would be a reasonable solution.
After making the changes to internal DNS repeat the testing and health checks performed earlier to verify that services are working as expected.
What About Internal Outlook Users?
At this point you may be wondering what are the real impacts to internal Outlook users when you make the internal namespace changes in DNS.
Exchange 2010 mailbox users will continue to connect to the RPCClientAccessServer as before. Their Outlook profiles do not change. However, their connectivity for the namespaces that have been pointed to Exchange 2013 (ie Autodiscover, EWS, etc) will go to the Exchange 2013 CAS where they are then proxied to Exchange 2010 as necessary to fulfil the requests.
It is only after moving mailboxes to Exchange 2013 that Outlook MAPI/RPC connectivity for those users will switch over to the Outlook Anywhere namespace for Exchange 2013 (mail.exchangeserverpro.net in this example scenario).
In the next part of this series we’ll begin looking at the mailbox migration tasks.
For more information see the Exchange Server 2010 to 2013 Migration Guide.
Hi Paul,
We are doing a migration from 2010 to 2013, and are having issues with login prompts. Once a user is moved to a 2013 mailbox, they get a login prompt that cannot be bypassed so outlook never open. If I set my host file to point directly to a 2013 cas server, there are no issues. But when we switch the load balancer instead to point to the 2013 cas servers, there are login prompts. Any suggestions on where to look for configuration problems for login prompts? We are using the same url for 2010 and 2013.
The Real Person!
The Real Person!
If a hosts file entry pointing directly to the CAS works, but going via the load balancer doesn’t work, that suggests to me that there’s a load balancer problem.
Hi Paul,
You are doing great job by publishing this all. Very much helpful.
I have Ex2010 2 cas server 2 mailbox servers, with cas array, no H/W load balancer. Only one name space for all services excluding casarraay.
Just completed the installation and configuration of Ex2013 one cas and one MBX.
Doing the testing for cutover, when I try to auto discover for outlook account, it takes more time and giving certificate error saying “2013CAS” not included in cert. Yes it is not there as recommended. But I hate this error. But I can complete the profile. and mail flow is fine.
And when I open the outlook configuration, server settings, and “server name” is displayed like GUID. Is that related to same certificate error? Pls. advice.
Hi Marcus,
2013 does not use casarray
Hi Paul,
Thanks for the great content! I used your 2003 to 2010 migration guide, and now the 2010 to 2013 🙂
Question: at what point during a 2010 to 2013 migration do we change the casarray A record?
I am doing a 2010 to 2013 migration on single exchange server environment. I have cutover my names spaces and all is well and good.The get-mailboxdatabase | ft name,rpcclientaccessserver command shows my 2013 database is using the casarray FQDN but if I modify the HOSTS file on a workstation to point the casarray FQDN to the IP of the 2013 server, Outlook cannot resolve the mailbox server name.
Thanks,
Marcus.
The Real Person!
The Real Person!
Never. Exchange 2013 mailbox connectivity is via Outlook Anywhere.
Paul –
E14 Environment (Prod)
2x Hub/CAS’s & 4 MBX (1 DAG)
E15 Environment (Co-Existence now, to migrate to fully very soon)
3x CAS/MBX (1 new DAG)
We’re using TMG 2010 to publish our custom sign on page, pass FBA through, and load balance (DNS Round Robin I’m assuming) exchange. Our Exchange DNS entries correspond to TMG ‘owned’ VIP’s.
My question is on the actual DNS/Virtual Directory cutover time…
Do I simply change the ‘server farm’ in TMG to point to my 3 E15 boxes –
I’ve read that I may need to create new Exchange 2013 TMG rules – though I don’t see why I can’t make minor modifications to my existing Exchange 2010 rules – thoughts on this?
Lastly I then set the E15 virtual directories to match the E14 ones? Or do I have to remove any of the E14 directories for the proxy to work?
I will be documenting all changes ahead of time, and performing this during a scheduled maintenance window – I have already notified/warned users about the new look OWA.
…Other than the change to OWA, my goal is for this to be as transparent as possible to end-users – no new web addresses or reconfiguration of Outlook, etc.
Is there anything else I need to be mindful of?
Any response would be greatly appreciated!!
Paul,
Nice work! I have an issue whereby Active Sync is not working for 2010 Users. So Exchange 2013 is not proxing the requests to 2010. Active Sync works fine for 2013 users. OWA works without issue for 2010 and 2013 users. The External URL on the 2010 autodiscover is blank.
Thanks, Carl
The Real Person!
The Real Person!
The URLs on the Autodiscover virtual directory don’t do anything so you can ignore those.
Exchange 2013 CAS proxies the ActiveSync connections to an Exchange 2010 CAS. You could look in the event logs on the 2013 server, or the IIS logs on the 2010 server, and there may be clues as to why the connections are failing. One possibility is that the IIS auth methods on the 2010 server aren’t correct. Another is that there is an SSL trust issue. Looking at your logs should tell you more.
Paul,
Once internal namespaces are cutover, do we need to change the URIs on the the 2010 servers to another namespace, like legacy.domain.com, or just leave them alone? I’m concerned there will be an issue since my namespace on 2010 will be the same as 2013. How will 2013 know how to proxy to 2010?
Thanks.
The Real Person!
The Real Person!
No you don’t need to change the Exchange 2010 URLs. Exchange 2013 is able to determine which server to proxy to.
Hmm this is interesting, so both 2013 and 2010 are lets say mail.company.com only DNS is pointing to 2013 which proxies to 2010.
I remember migration from 2007 to 2010 we had to rename 2007 with legacy.company.com
I know affinity has changed, but I mean when the mailbox still lives on Exchange 2010
/anker
Hi Paul,
how is affinity handled when you change Client Access services namespace to the 2013 servers ?
/anker
The Real Person!
The Real Person!
Affinity for client connections to CAS is handled by whatever load balancer you implement (if you implement one at all). Affinity is no longer required for client connections to Exchange 2013 CAS.
Hey Paul,
I just changed DNS so all traffic hits the 2013 servers and am having an issue with setting out of office. Some people with their mailbox on 2010 can not set out of office, they receive a server error. I believe this error is usually caused by EWS configuration. My server uses mail.company.com internal and external. Should the internal and external URL’s be configured differently on 2010?
Thank you,
Kevin
Hi Paul,
Great Article(s). Ive ready a lot of your work and it has helped me many times in the past. One thing I was wondering if I could pick your brain on, is SMTP traffic. We’re a 2007 shop going to 2013. We dont use the Edge Server (have clustered ironports receiving mail and they are our smart host for outgoing mail) Do we put a VIP on our L4 LB for 25/587 pointing to all Mailbox servers / dag members (going to have 4 MB servers in 1 dag) for internal relay clients (like printers, software etc) or to a VIP towards the CAS servers, and they proxy back to the Mailservers considering the HUB role is now on the Mailbox server? Same question in regards to where to we point the ironports,
Thanks again!
The Real Person!
The Real Person!
The recommended practice is to install multi-role servers, so that should answer your question 🙂
Pingback: Americanrentall.com