Exchange 2007/2013 CoExistence URLs

 

Introducing Exchange 2013 into an Exchange 2007 environment can be a challenging task.  One of the most overlooked, and least documented topics I see is the proper configuration of URLs for Proxy and Redirection.

A good article to start with is Exchange 2013 interoperability with legacy Exchange Versions by Michael Van Horenbeeck.  This article points out when Exchange 2013 will proxy connections to 2007 vs. when it will redirect the connection.

 

Setup:

Exchange 2007

  • Ex2007.domain.com
  • Exchange 2007 SP3 RU10
  • 192.168.100.10

Exchange 2013

  • Ex2013.domain.com
  • Exchange 2013 RU3
  • 192.168.100.20

In this scenario we have a very simple setup.  A single Exchange 2007 server and a single Exchange 2013 server.  Both servers are installed in the same Active Directory Site.

Prior to Exchange 2013 being introduced, our 2007 URLs were configured as follows:

Virtual Directory Current 2007 Values (Prior to Exchange 2013)
OWA internalURL: https://webmail.domain.com/owaexternalURL: https://webmail.domain.com/owa
ECP N/A
ActiveSync internalURL: https://webmail.domain.com/Microsoft-Server-ActiveSync

externalURL:
https://webmail.domain.com/Microsoft-Server-ActiveSync
Outlook Anywhere externalHostName: webmail.domain.comIISAuthenticationMethods: Basic

ClientAuthenticationMethods: Basic

Exchange Web Services internalURL: https://webmail.domain.com/EWS/Exchange.asmxexternalURL: https://webmail.domain.com/EWS/Exchange.asmx
AutoDiscover AutoDiscoverServiceInternalURI: https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

…and DNS was configured as follows:

A Record IP Address
webmail.domain.com 192.168.100.10
autodiscover.domain.com 192.168.100.10

 

The default internalURL and AutoDiscoverServiceInternalURI values are derived from the server FQDN, but as you can see these have been changed.  Your configuration may be different depending on how it was setup.

Likewise, when Exchange 2013 is introduced into the environment, the default values are derived from the server FQDN.

For Coexistence and interoperability between Exchange 2013 and 2007, these values all need to be changed.  The first step in the migration process is to update these values so that all users connect to OWA, EAS, and OA via Exchange 2013.   Again, I won’t go into the details of why, but essentially Exchange 2013 can proxy and redirect back to 2007, but 2007 cannot proxy forward to Exchange 2013.

“Now, Rabbit, a good cop does what… before using his equipment in the field? – Uh, they test it? – They test it. Exactly. How are you shootin’ today, Thorn? – Dead on all morning. – How about that little fella? Oh, that little guy? I wouldn’t worry about that little guy.”

Yes, I personally like to test everything prior to making any change to the existing 2007 environment.  So I usually setup some dummy URLs on the 2013 side and test all the connections (OWA, EAS, OA).  This way I know all proxying and redirecting is working prior to making any user impacting changes.  This also usually takes some host file manipulation to fully test.

After all testing is complete…it’s time to update the Exchange 2012/2007 URLs.  The configurations that we will make should look something like this:

 

Virtual Directory 2007 2013
OWA internalURL: https://legacy.domain.
com/owa

externalURL: https://legacy.domain.
com/owa
internalURL:
https://webmail.domain.com/owa
externalURL:
https://webmail.domain.com/owa
ECP N/A internalURL:
https://webmail.domain.com/ecp
externalURL:
https://webmail.domain.com/ecp
ActiveSync internalURL:
https://legacy.domain.com/Microsoft-
Server-ActiveSync

externalURL: $null
internalURL:
https://webmail.domain.com/Microsoft-Server-ActiveSync
externalURL:
https://webmail.domain.com/Microsoft-Server-ActiveSync
Outlook Anywhere externalHostName:
webmail.domain.com
IISAuthenticationMethods:
Basic,NTML
ExternalClientAuthenticationMethods:
Basic
externalHostName:
webmail.domain.com
IISAuthenticationMethods:
Basic,NTML
ExternalClientAuthenticationMethods:
Basic
Exchange Web Services internalURL:
https://legacy.domain.com/EWS/Exchange.asmx
externalURL:
https://legacy.domain.com/EWS/Exchange.asmx
internalURL:
https://webmail.domain.com/EWS/
Exchange.asmx

externalURL:
https://webmail.domain.com/EWS/
Exchange.asmx
AutoDiscover AutoDiscoverServiceInternalURI:
https://autodiscover.domain.com/
Autodiscover/Autodiscover.xml
AutoDiscoverServiceInternalURI:
https://autodiscover.domain.com/
Autodiscover/Autodiscover.xml

 

…and DNS will look like this:

A Record IP Address
legacy.domain.com 192.168.100.10
webmail.domain.com 192.168.100.20
autodiscover.domain.com 192.168.100.20

 

Now, let’s look at some of the configuration.

 

NOTE: It should go without saying, but the certificate on the Exchange 2007 server should have been replaced by this time with a certificate that contains legacy.domain.com.

 

OWA – (Redirect) Should be pretty straight forward.  When a user whose mailbox still resides on 2007, accesses OWA via the 2013 CAS, they will be redirected back to 2007 via externalURL value: https://legacy.domain.com/owa

Set-OwaVirtualDirectory –Identity “ex2013\owa (Default Web Site)” –InternalUrl https://webmail.domain.com/owa –ExternalURL https://webmail.domain.com/owa

Set-OwaVirtualDirectory –Identity “ex2007\owa (Default Web Site)” –InternalUrl https://legacy.domain.com/owa –ExternalURL https://legacy.domain.com/owa

 

 

ActiveSync – (Proxy) I prefer to force ActiveSync to proxy from 2013 to 2007 as some ActiveSync devices don’t handle the redirect correctly.  In order to force a proxy scenario, the externalURL value for 2007 is set to $null.  The internalURL on 2007 should be configured with https://legacy.domain.com/Microsoft-Server-ActiveSync

Set-ActiveSyncVirtualDirectory –Identity “Ex2013\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://webmail.domain.com/Microsoft-Server-ActiveSync –ExternalURL https://webmail.domain.com/Microsoft-Server-ActiveSync

Set-ActiveSyncVirtualDirectory –Identity “Ex2007\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://legacy.domain.com/Microsoft-Server-ActiveSync –ExternalURL $null

 

 

Outlook Anywhere – (Proxy) All OA connections, both 2007 mailboxes and 2013 mailboxes will now connect via the 2013 CAS.  2013 will proxy connections back to 2007 for legacy mailboxes.  The externalHostName for both 2013 and 2007 should be the same, (webmail.domain.com).  Exchange 2007 does not support “Negotiate” authentication (See image below).  Therefore the externalClientAuthenticationMethods should be configured to match whatever is configured for 2007, either Basic or NTLM.  For OA to proxy from 2013 to 2007, the IISAuthenticationMethods on 2007 must be reconfigured to support both Basic and NTLM.  By default, Exchange 2007 IISAuthenticationMethods is set to just Basic.  NTLM must be added for the proxy to work.

image

Set-OutlookAnywhere –Identity “Ex2013\Rpc (Default Web Site)” –InternalHostname webmail.domain.com –ExternalHostName webmail.domain.com –ExternalClientAuthenticationMethod Basic –IISAuthenticationMethods Basic,NTLM

Set-OutlookAnywhere –Identity “Ex2007\Rpc (Default Web Site)”  –IISAuthenticationMethods Basic,NTLM

 

Exchange Web Services – (AutoDiscover) Autodiscover is used to retrieve the EWS configuration for the 2007 users.

Set-WebServicesVirtualDirectory –Identity “Ex2013\EWS (Default Web Site)” –InternalURL https://webmail.domain.com/EWS/Exchange.asmx –ExternalURL https://webmail.domain.com/EWS/Exchange.asmx

Set-WebServicesVirtualDirectory –Identity “Ex2007\EWS (Default Web Site)” –InternalURL https://legacy.domain.com/EWS/Exchange.asmx –ExternalURL https://legacy.domain.com/EWS/Exchange.asmx

 

AutoDiscover – Both the 2007 and 2013 SCP locator can be configured to point to the Autodiscover URL https://autodiscover.domain.com/Autodiscover/Autodiscover.xml.  DNS must be updated however so that the A record for Autodiscover.domain.com resolves to the 2013 CAS.

Set-ClientAccessServer –Identity Ex2013 –AutoDiscoverServiceInternalUri https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

ECP –  Exchange 2007 did not have an ECP virtual directory.  Therefore, only the 2013 ECP virtual directory needs to be configured.

Set-EcpVirtualDirectory –Identity “Ex2013\ecp (Default Web Site)” –InternalURL https://webmail.domain.com/ecp –ExternalURL https://webmail.domain.com/ecp

 

As usual…ymmv…

92 Replies to “Exchange 2007/2013 CoExistence URLs

  1. Thanks for the article. I had to adjust the EMS command for IIS authentication methods slightly. Exchange 2013 SP1 was prompting me for some additional parameters:
    -ExternalClientsRequireSsl $True -InternalClientsRequireSsl $True

    Aside from that, I used the ECP for changing the URLs instead of ESM, but everything is working for us so far in a co-existence environment with 2010 and 2013, except for a weird cert error that I’m getting for legacy.domain.com when autodiscover kicks in when I’m configuring or opening Outlook. We don’t plan on keeping both environments up as we’re just migrating to the new environment, so the legacy cert error doesn’t bother me too much, but it would be nice to figure that out as well.

    Thanks again.

    1. Yes, the legacy domain name should be available externally. Yes, this should be a SAN certificate, and should be issued by a trusted 3rd party CA for external services.

  2. Hi Jeremy, Thanks for your wonderful article. Please In hybrid scenario; what impact on users/production should i expect when importing exchange2013 SAN certs into Exchange 2007? Thanking you for a quick response.

    1. Hi Tobs, When importing new certificates into 2007, as long as the new certificate contains all the appropriate SAN entries and the server has the CA hierarchy in its trusted computer store, you should not expect any impact. The certificate should be imported using the enable-exchangecertificate cmdlet.

  3. Hi,

    Such a wonderful and simple article you have wrote which makes each and every Exchange admins to have a good understanding on co-existence environments.

    Regards
    S.Nithyanandham

  4. Hello

    We are having some issues where some users are not being notified when their mailbox is being migrated to E2013.

    Before 2013, we never had a load balanced solution for CAS in Exchange Server 2007 or a single name space.

    Below is our current config

    AutoDiscoverServiceCN : Server2K7ASpd
    AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
    AutoDiscoverServiceInternalUri : https://legacy.domain.int/Autodiscover/Autodiscover.xml
    AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
    AutoDiscoverSiteScope : {USChicago, UKLondon, SGSingapore}

    AutoDiscoverServiceCN : Server2k7cASdr
    AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
    AutoDiscoverServiceInternalUri : https://legacy.domain.int/Autodiscover/Autodiscover.xml
    AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
    AutoDiscoverSiteScope : {USChicago, UKLondon, SGSingapore}

    AutoDiscoverServiceCN : Server2013CASPD01
    AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
    AutoDiscoverServiceInternalUri : https://autodiscover.domain.int/autodiscover/autodiscover.xml
    AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
    AutoDiscoverSiteScope : {UKLondon}

    AutoDiscoverServiceCN : Server2013CASPD02
    AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
    AutoDiscoverServiceInternalUri : https://autodiscover.domain.int/autodiscover/autodiscover.xml
    AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
    AutoDiscoverSiteScope : {UKLondon}

    AutoDiscoverServiceCN : Server2013CASDR02
    AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
    AutoDiscoverServiceInternalUri : https://autodiscover.domain.int/autodiscover/autodiscover.xml
    AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
    AutoDiscoverSiteScope : {UKLondon}

    AutoDiscoverServiceCN : Server2013CASDR01
    AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
    AutoDiscoverServiceInternalUri : https://autodiscover.domain.int/autodiscover/autodiscover.xml
    AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
    AutoDiscoverSiteScope : {UKLondon}

    I believe that we should change the AutoDiscoverServiceInternalUri on the two 2007 CAS to ALSO be the same as our 2013 CAS.

    We know that when Outlook is opened, Autodiscover will respond with any of the 6 available CAS, and we think that those Outlook clients that are misconfigured, are those that are not getting notified when their Mailbox is moved to E2013.

    Thanks

    1. Rob,

      AutoDiscoverServiceInternalUri is the Active Directory SCP used by domain joined Outlook clients connected to the internal network for Auto Discover. When the mailbox is moved from 2007 to 2013, Outlook receives a notification from the mailbox server on which the mailbox was formerly located. The referral response is in the format ecWrongServer. This notifies the Outlook client to updates its profile and connect to the new server, then prompts the user with the notification to restart Outlook. If you are not receiving the notification immediately, I’ve seen leaving the Outlook client connected for a certain amount of time, 30 minutes or so, will typically result in the prompt and subsequent connection to the new server. Make sure that the Outlook client is running the latest updates. You can always try a repair on the mailbox profile to force it to update and connect to the new 2013 server. In regards to updating the AutoDiscoverServiceInternalUri, it should not be required to change this to point to 2013 on your legacy servers, however it won’t hurt either.

      Jeremy

  5. Hi, Jeremy
    Good and straight forward – nice article.
    One question though.
    Will it effect anything if I use fqdn for all the internal and external urs (that were created during the installation of Exchange 2007)?
    I have included the fqdn of the exchange 2007 in the SAN cert and imported the same cert on Exchange 2007 server.

    1. Hary,

      You do not have to use the URL namespace “Legacy.domain.com”. This is used only as an example, although I do see it used for most customers. If you use the actual FQDN, just make sure it is included properly in the certificates, and you have the public DNS records setup appropriately. For all intents and purposes, you would simply replace FQDN everywhere you would have used legacy.

      Jeremy

  6. Jeremy, a great article, and 100% pertinent to our current project. Why can’t Microsoft produce such simple, easy-to-follow instructions.
    Thank you!
    Andy.

  7. He Jeremy

    I am in the process of migrating Exchange 2007 to 2013. I will be installing Exch 2013 next week to get a certificate ruquest from our agency. This will take a week. Does the initial Exch 2013 changes any of my OWA or URL (internal and external) before I manually configure them. In other words, my intent is to only install Exchange 2013 (without any additional configuration) so I can do a certificate request. Once I get my certificate back from my agency, I will then go through the hoops of pointing my URL to my legacy name, DNS cname, and configuring my virtual directories. I understand when you first install Exchange 2013, it creates a self-signing certificate. Does it also redirects my webmail URL to my 2013 Exchange or will it default to Exchange 2007 OWA until I change this manually in 2013?

    In a nutshell, will my webmail from 2007 be affected by installing exchange 2013 without any url configurations? Do I need a certificate readily available or can it wait a week before redirecting my URL from 2013 to 2007?

    1. Jack,

      The initial install of Exchange 2013 will not modify or impact users ability to get to webmail. This will only be impacted when you configure 2013 and update DNS to point to 2013.

      What you should be careful of though, is the AutoDiscover SCP. When you install Exchange 2013, it will automatically register a SCP in Active Directory for AutoDiscover. This entry will be based on the FQDN of the Ex2013 server. Since Ex2013 will be using a self-signed certificate, users may start getting pop ups indicating a certificate trust issue. You can check your configuration and see how the SCP’s are set. Get-ClientAccessServer | fl server,AutoDiscoverServiceInternalUri. You can either change the new Ex2013 to point to the same DNS entry as 2007, or you can modify the security ACL on the 2013 SCP and remove authenticated users as an interim step.

      Jeremy

  8. Jeremy, Thank you for this detailed blog. I have a question and hope you will find some time to reply me.

    I currently have 2013 and 2007 running together – but haven’t swapped over the names yet (legacy.domainname.com / outlookanywhere.domainname.com).

    Nor any user is moved to 2013 yet. Our OWA and mobile devices use “email.domain.com” SSL certificate. Our Autodiscover is registered with the ISP.

    My question is

    If we simply move the public certificate “email.domain.com” from 2007 to 2013. Do we still need any public certificate ex legacy.domain.com for 2007 for the time users being migrated from 2007?

    If yes, does a simple SSL or a SAN certificate would be required? Thanks

    1. If you plan on having users co-exist in 2013 and 2007, you will need the namespace legacy.domain.com. This is because 2013 will perform a redirect, not a proxy, for users still homed on 2007.

      In this scenario, you will need to migrate email.domain.com to 2013, prior to moving any users to 2013. Once this occurs, all users (2007 and 2013) will start hitting the 2013 CAS. When a 2007 user goes to sign in to OWA via the 2013 CAS, the 2013 CAS will detect that the user is located on a 2007 mailbox server, and redirect the user to the ExternalURL value that is populated on the 2007 OWA Virtual Directory. In this case “legacy.domain.com”.

      The SSL cert can be a multi-SAN certificate, or UC cert, that has all the names listed. You would then load this certificate on both servers.

      1. Thanks for your quick response.
        A SAN cert is expensive compare to single name cert and if UC Cert can do the job and only needed for OWA, then we would rather purchase that.
        Does Mobile devices will get any error/notification for a single time, when we move the cert to 2013? Thanks

        1. A SAN cert is the same as a UC Cert. These can be fairly inexpensive for a 5 SAN cert from GoDaddy.

          Mobile devices will behave differently than OWA. ActiveSync will always proxy from 2013 to 2007. “For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2013 no longer supports the 451 redirect response – Exchange 2013 will always proxy ActiveSync requests.”

  9. JeremyM :Instructions are very clear and well written. However, when we made the change in our 2007/2013 environment Outlook Anywhere will not function/connect. Client Authentication in 2007 was using NTLM so 2013 has been changed to match. Additionally, 2007 and 2013 are both configured for IISAuthentication to use NTLM and Basic. OWA, Activesync, and Autodiscover all seem to work fine after the change. A test with Microsoft Remote Connectivity Analyzer showed an RPC unavailable error when trying to connect and listed the internal 2007 database server:6001 as its connection point. I am able to telnet to that server:port from the 2013 CA server. Any ideas?

    UPDATE: RPC error can be ignored as I get that error message in the MRCA even before I make my changes. Also, I have already moved autodiscover DNS to the new server and Outlook Anywhere still works as expected. However, once I switch over my webmail DNS entry, autodiscover no longer connects. Thoughts??

  10. Jeremy,
    We’re not even at the same company anymore and I still get to tap into your knowledge! I’m doing a 2007 to O365 and this visual representation of the URL’s was exactly what I needed to remember the proxy/vs redirects for co-existence.

    Scott Jaworski

  11. Jeremy,
    In Migrating from SBS 2008 with Exchange 2007, “remote.domain.com” is typically used. Would this be substituted for “legacy.domain.com”? In our initial testing we continually get prompted for credentials, after moving the mailbox. Outlook clients are both 2010 and 2013. Any ideas would be appreciated. Thanks

    1. Hi Mark,

      “Legacy.domain.com” is simply a place holder. You can chose whatever actual value you’d like, but yes, you will need to use something. The ExternalURL values need to be something different on 2007 than they are on 2013. This allows 2013 to redirect requests to the legacy version. After migrating the mailbox to 2013, does Outlook connect to Exchange and then prompt you for a password, or does it stay in a disconnected state? I would suggest running a connection status check, by holding the Control Key and right-clicking on the Outlook icon in the system tray. Most of the time, the repeated authentication prompts are caused by Outlook trying to connect back to 2007. You will see this in the Connection Status page. If this is the case, you probably have an authentication mismatch between virtual directories on 2013 and 2007. Also make a note that the default Negotiate setting on 2013 is not supported on 2007. This has to be changed.

  12. Hi Jeremy,

    We are doing the transition from 2007 (one server) to 2013 (2 CAS and 2 Mailbox in DAG)
    On 2007 box the SSL certificate is *.domain.com
    So does this mean we don’t have to add any thing for 2007 like legacy.domain.com right?

    Does wildcard certificate will cause any issue?

    Many thanks

    Vicky

    1. You can continue to use a wildcard certificate on both 2007 and 2013. You will however still have to modify your URL’s with the legacy namespace for the redirection.

  13. Hi Jeremy,

    I want to install Exchange Server 2013 alongside with 2007, but use 2007 as main mail server and 2013 as test platform. Exchange 2013 will be accessable only internal.
    1. When I move one mailbox to 2013, will I have access to this mailbox?
    2. Will then CAS 2007 redirect to CAS 2013?
    3. Will this mailbox fully functional?

    Thanks in advance
    Andy

    1. Hi Andy,

      It’s no issue bringing up 2013 in coexistence side-by-side with 2007. There are a couple things to watch out for. First is the SCP registration when you install the new CAS role. You’ll want to take this into consideration so that end users don’t start getting security warnings when they fire up Outlook. Second, is that Exchange is not designed/supported to proxy from an older Exchange version to a new Exchange version. Which means if you have a mailbox on an Exchange 2013 database, and your DNS records are still pointing to 2007, you’ll have issues accessing the mailbox via Outlook, OWA, and EAS. During a coexistence and cut-over, the first step is to point DNS to the newer version, as the newer version is designed to proxy/redirect back to the legacy version. Third, if you want to set it up to test only without impacting current users or changing any DNS, you would consider using local host files on a test machine to simply point the necessary records to the 2013 machine. this way you can test with a single device. Fourth is that Exchange 2013 no longer supports MAPI over RPC. So you’ll need Outlook Anywhere setup and AutoDiscover working appropriately in order to setup the profile in the Outlook client.

      Jeremy

  14. Jeremy,
    Thanks for the articles, i followed it and made change to the URLs.

    I assume you have to make the same DNS change on the public records.
    i did change mail and autodiscover to point to the hybrid server(ex2013) and legacy.domain.com is pointed to the old exchange 2007.

    after I made this change, I cannot receive external email, but i can sent externally without problem and email flow is working fine internally.

    i then change the pointer for mail and autodiscover to exchange 2007 on the public DNS, and mail starts to work again,but owa wouldn’t work properly.

    1. Hi Sai,

      As part of the migration, yes, you should be planning public DNS changes accordingly. I’m assuming you use mail.domain.com as both the OWA address as well as your SMTP address used for your MX records. I typically recommend splitting these to avoid potential conflicts such as this. For example, use mail.domain.com for owa, and smtp.domain.com for mail flow.

      If my assumption is accurate and you have mail setup for both, I’d suggest checking the ports you have open. You may not have 25 open to the new 2013 CAS. You may also want to validate your receive connectors are setup appropriately in 2013. To test prior to changing this again, you can simply use telnet from an external source and telnet on port 25 to the new public IP address of your hybrid server and validate you can send mail. https://support.microsoft.com/en-us/kb/153119

      Thanks,

      Jeremy

      1. So in this instance you would keep the MX record pointing to the legacy 2007 server? Would you keep it pointed to the legacy server until all the mailboxes have been migrated?

        1. You could do it either way. Leave it on 2007 until over 50% of the users are migrated, cut it over at the beginning, or cut it over at the end. It typically depends on the length of the migration or just personal preference.

          1. OK so it looks like external mail will flow into your environment through either system? This part wasn’t clear in a lot of other tutorials I’ve looked at.

          2. Correct. Mail can come in via either 2007 or 2013. Exchange will manage the routing internally without any configuration on your part. As long as you didn’t screw up the connectors between 2007/2013.

  15. If I bring up exchange 2013 server but not configure for co-existence, as long as I fix the SCP entry, can I migrate all of the mailboxes without worrying about using a redirect like legacy?

    great article and comments.

    Thanks

    1. Hi,

      Not knowing the details of your plan, I would think his depends on the timing of your cut-over. If you are migrating every mailbox in a bing-bang fashion in a single night, and then updating DNS to point to 2013 at the same time, you could get away without doing any legacy redirects.

      The only purpose of the legacy redirect is if you will have users in both environments at the same time. If you are planning on having mailboxes in both 2007 and 2013 at the same time, you should plan for legacy redirects and proxying.

      Jeremy

  16. and also Can i leave the exchange 2007 OWA to it’s original configuration and Configure exchange 2013 only to its new OWA address?? so that the users in 2007 will still use the exchange 2007 OWA address and the users in 2013 will use exchange 2013 new OWA address??

    thanks again…

    1. In regards to OWA, if you want 2013 users to use a net new URL to access OWA, this comes down to end user communication. “Typically”, end users have the URLs stored in memory and book marked in browsers, so moving the URL to 2013 is a more seamless transition for users. Although it is not required. If you want users to use a new URL for 2013, then you can leave 2007 as it currently is, and simply create a new URL for 2013. When you migrate your user from 2007 to 2013, you’ll simply need to build the new URL into your communication plan, and ensure they are aware of the new address, so they can update their bookmarks, and possibly their Mobile Devices, if these use the same URL.

  17. Thanks for the good article. Which address do activesync users on exchange 2007 point to. if they have webmail.domain.com must it be manually changed?

    1. As part of the migration, I typically configure the Ex2013 EAS Virtual Directory with the public facing URL for OWA (webmail.domain.com), and configure Ex2007 EAS Virtual Directory as $Null. This forces 2013 to proxy all connections from 2013 CAS back to 2007 CAS, instead of re-configuring the EAS device. So if the 2007 users are all pointing to webmail.domain.com, you shouldn’t have to reconfigure the devices . Once DNS is updated and webmail.domain.com is pointing at 2013, all devices will start connecting to the 2013 CAS, regardless of whether their mailbox is on 2007 or 2013.

  18. Great article. Seems to add a few steps the Exchange deployment wizard misses. We do have some weirdness though – Outlook Anywhere users with 2007 mailboxes get an 0x8004011D in Outlook. Works ok if we manually change the Exchange proxy settings on the client to point to legacy.domain.com but webmail.domain.com should proxy shouldn’t it? We’re behind TMG so have put a workaround in place for the time being.

  19. We are going into coexistence between exchange 2007 and exchange 2013.

    Exchange 2013 Server Internal IP – 10.3.42.81

    Exchange 2007 Server Internal IP – 10.3.42.51

    We have assigned a public IP 86.76.156.56 on external DNS and a firewall rule that NATS

    86.76.156.56 to 10.3.42.51 (Exchange 2007 Server)

    Now for coexistence we need to introduce a legacy exchange host name

    1. Do we need to assigne a public IP for legacy.domain.com

    2. do we need to create a firewall NATing for legacy.platcorp.com where the public IP assignd above will be routed to 10.3.42.51

    or

    3. do we need to just modify the current firewall routing to NAT

    86.76.156.56 to 10.3.42.81 (Exchange 2013 Server)

    Internal DNS

    Record Type Internal IP
    ————————————————————

    mail.domain.com A 10.3.42.81

    autodiscover.domain.com CNAME 10.3.42.81

    legacy.platcorp.com A 10.3.42.51

    ———————————————————————————-

    External DNS

    Record Type Public IP
    ————————————————————

    mail.domain.com A 86.76.156.56

    autodiscover.domain.com CNAME 86.76.156.56

    legacy.platcorp.com A Shoud we assign a new Public IP or can we use the same public IP as 86.76.156.56

    ————————————————————————————

    1. Hi Philip,

      If you plan on having co-existence between the two systems, you will have to introduce the new “legacy” namespace. You will also need a new IP address. I would suggest to associate the new IP address and NAT rule to your Exchange 2013 server, as opposed to your 2007 server. This allows you to perform some basic testing of the 2013 server prior to making any production changes.

      Then once tested, you can simply swap the names in DNS, assigning “legacy” to the current IP, and assigning mail and autodiscover to the new IP.

      Jeremy

  20. Unfortunately none of this is working for me. I assume I have to have two separate external IP addresses for this to work. When 2013 redirects the web browser to legacy, I get a redirected loop error.

    Also, no mail in but mail out is fine.

    Phones no longer working as well.

    1. Yes, you will need to have two separate external IP addresses for the redirects to work properly. You will also need to make sure that the ExternalURL’s are configured properly to facilitate the redirect. After updating the Virtual Directories with new URL’s, restart IIS on both 2007 and 2013.

  21. I was successful in the migration except for ActiveSync. Outlook clients OK, autodiscover working, OWA works fine. moble phones via ActiveSync cannot connect to server for anyone with Mailboxes on 2013. I have tried everything I can think of. Can you think of what I may be missing? As soon as I clear this up, I can move all the remaining mailboxes (only 300).

    1. I would check by validating the URL configured for the ExternalURl for ActiveSync is pointing to the 2013 CAS. 2013 can proxy back to 2007, but 2007 cannot proxy to 2013. Remember to use the Remote Connectivity Analyzer, as this can provide a lot of assistance with troubleshooting specific connection types. Also have a look at the IIS logs on the 2013 CAS to see ensure that the connection attempt is occurring, and to see if there is a specific error code being thrown.

      1. The URL is configured correctly. The RCA. If I type the URLthat was tried, which is the URI referred to above, this is what I get:




        6000
        Invalid Request

        I found a log entry with 17:38:04 timestamp, but it did not refer to any errors.

      2. I have tracked the issue to the mobile device manager (MDM) we are using. It is not an Exchange issue at all, or at least a MobileIron/Exchange 2013 issue. Unfortunately I still have to sort it out.

  22. Great article Jeremy!. I used these steps on my 2007 to 2013 coexistence and everything worked like a champ! I was able to use a wildcard cert that was already in place on our 2007 system on the 2013 CAS, this made all of the “Legacy” name changes easier IMO. We had everything switched over in coexistence and our external DNS changes done in under 45 minutes, tested everything, mobile, OWA, autodiscover, setup a new outlook client, OAB, everything working and managers happy.. Now we move our mailboxes.

  23. Hi Jeremy

    If I may ask I am in process of introducing exchange 2013 server ta network running exchange 2007 regarding
    Cert for exchange 2013 can i use the existing wild cert on exchange 2007 by just e porting cert from exch2007 and then importing into exchange 2013

    1. Hi,

      If you imported your wildcard cert on your 2007 server allowing the private key to be exported, then yes. You will need to export the wildcard certificate from your 2007 server with the private key, then import it into the 2013 server. You may also need to copy over any intermediate or root certificates as well.

      Jeremy

  24. Hi Jeremy,

    In our Exchange 2007 environment we have SAN certificate that includes following two names only

    1. webmail.domain.com
    2. Autodiscover.domain.com

    and we do not want to include legacy name during coexistence with Exchange 2013. please advise how this coexistence is going to work during mailboxes migration from Exchange 2007 to Exchange 2013?

    or is this approach not going to work for us?

    Thanks in advance.

    Sheeraz

    1. Hi Sheeraz,

      If you do not want to include a legacy namespace, then legacy (2007) users will loose certain access to Exchange (OWA). The purpose of the legacy namespace is to facilitate coexistence during the time when users exist on both 2007 and 2013.

      Before you migrate your first user to Exchange 2013, you will need to cut your namespaces over. Meaning point your DNS records at 2013. When a 2007 user attempts to sign in to the 2013 OWA page, the Ex2013 CAS will discover that the users mailbox is on 2007, and “redirect” the user to the Legacy URL. If a legacy URL does not exist, then the user will not be able to access OWA.

      Hope this helps.

      Jeremy

  25. We have a 2007 environment, 2 CAS/HUBS 4CCR mailbox clusters and recently we added in 4 2013 servers each holding the CAS & Mailbox roles, we currently use an F5 and have a VIP created that includes the 2 2007 CAS servers. My question is do I need to create a new VIP in the F5 that includes all the 2013 servers, or do I point at just one server or can I just add in these new 2013 servers to my existing vip? This is our webmail.***.com address btw. We already have a legacy dns entry created pointing to the 2007 servers, it’s not doing anything at the moment of course cause we haven’t changed the Exchange urls yet.

    1. If you want the 2013 CAS Role to be highly available for your end users, you will need to create a new VIP on the F5, which will include only the 2013 servers. You should not include your 2007 and 2013 servers in the same VIP.

      You will have the legacy namespace pointing to the 2007 VIP, and all other production namespaces (webmail, etc…) pointing to the 2013 VIP.

      1. Thanks Jeremy, performed cutover pretty quickly thanks to your instructions, running into 2 weird issues though, prob something I have configured wrong with authentication. Users can’t connect to webmail (both server versions) however if going strait to Legacy it works. Receive a 403 error, same with autodiscover, not working, 403 in exchange connectivity tests. Activessync, Outlook Anywhere, etc. work fine. Any idea?

  26. Hi,
    Thanks for the tips.
    I have set my 2007 and 2013 in co-existence, all seems well, but I get a funny thing with OWA.
    All mailboxes still on 2007 while we iron out some issues.
    Logged in as user1 onto pc, user 1 logs into OWA, this works without hitch, redirect and everything takes place as expected.
    Log user 1 out of OWA. Log user 2 into OWA, enter right credentials etc, when OWA opens it is still logged in as User1. Log out again, try again with totally incorrect credentials and password for User2 (into OWA), OWA opens with User1 showing and user1 emails.
    In exchange 2007, OWA would log in with whomever’s login credentials were entered.
    Any idea what is happening here?

  27. Very interesting and helpful article.I am writing the documentation for the migration from Ex 2007 to Ex 2013 and you have done a very good job summarizing Dns and certificates changes,
    Thank you very much

  28. Hi Jeremy,

    I read your article and it is great and simple to understand. We had been following this article http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part1.html to work on our Migration/Coexistence and have run into a stumble block, I am hoping that you can shed some light/provide some assistance.

    Just a bit of a background:
    Our SSL Cert does not include Autodiscover and we did not have an autodiscover record in our Internal or external DNS while we are on Exchange 2007. Also, we did not have a Legacy namespace on our SSL certificate but did have a mobile.domain.com namespace which to my knowledge we were not using for Exchange 2007. So we decided to use the mobile namespace for our Exchange 2007 and our webmail.domain.com namespace for Exchange 2013. It seems like everything was going pretty good (PS: we did not modify the external DNS yet) was only working internally.

    1. We created a test mailbox on Exchange 2013 and tried connecting to it via OWA – Result was successful but get like a light weight Outlook Web App instead of full Outlook Web access, is that normal? Also, instead of getting a web form to login, get a Windows Authentication box to login into.

    2. When we try to use MS outlook and configure the user that has the mailbox on 2013 we kept getting prompted with a Login Prompt

    3. All existing users that have mailbox on Exchange 2007 started getting Login Prompt when in outlook

    4. When a user that has mailbox on Exchange 2007 tries to login to OWA, gets a Windows Login prompt instead of Web Form login. Once they login they get redirected to mobile.domain.com the page.

    From your description above, it seems pretty straight forward, however we seem to have managed to screw up somewhere and not sure where. For now we have reverted everything back (changed all the URLs back where webmail namespace is back on the Exchange 2007 just so production can work).

    We would like to make another attempt at this, hopefully equipped with exact information so we can move to the next step. Any feedback/assistance will be greatly appreciated.

    Also, if we have to get a wildcard cert for our Exchange 2007 so that we have Autodiscover namespace configured, I am willing to do that. Currently our SSL cert only allows 3 or 4 names and they are all in use).

    Thank you so much and if there is anything that I am not clear about, I am sorry.

    Awaiting your response.

    1. 1) Are you using a web browser that is supported for use with the premium version of OWA? https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx

      2) Are there Public Folders involved? This is often an issue as the connection to Public Folders will be proxied back to the legacy server hosting PF. This could be were the authentication prompts are coming from. I’d suggest launching Connection Status to see what connections have established and which are connecting at the time of the prompt. This could be an authentication mismatch between Virtual Directories.

      3) I’d suspect this to likely be a virtual directory authentication mismatch

      4) OWA is a redirect from 2013 to 2007. Since mobile.domain.com is now the 2007 externalurl, i would expect this behavior.

      I would suggest getting a UCC or multi-SAN cert with the correct names, to ease confusion.

  29. Hey jereme,
    i am migrated users and password but while migrating mailbox i am facing following issue:

    We couldn’t detect your server settings. Please enter them. AutoDiscover failed with a configuration error: The migration service failed to detect the migration endpoint using the Autodiscover service. Please enter the migration endpoint settings or go back to the first step and retry using the Autodiscover service. Consider using the Exchange Remote Connectivity Analyzer ‎(https://testexchangeconnectivity.com)‎ to diagnose the connectivity issues.
    Remote MRS proxy server:
    The FQDN of the Exchange server that the Mailbox Replication Service (MRS) Proxy is on.

    please provide solution,
    Thanks

  30. Hi Jeremy,

    We have 3 exchange servers 2010 in our environment. We recently installed 2 exchange server 2016.
    We want to run 2016 in coexistence with 2010.

    All the 3 exchange 2010 servers have different autodiscover names, xcg12010.domain.com, xcg22010.domain.com and xcg32010.domain.com

    I am a bit confused about the autodiscover names for my xcg12016 and xcg22016 servers.

    Can you please share your thoughts on this.

    Thanks.

    1. By saying you have 3 AutoDiscover names in 2010, can I assume you’re referring to SCP addresses? The Outlook client uses built-in logic for determining AutoDiscover location: SCP, https://domain.com/autodiscover, https://autodiscover.domain.com, …

      The SCP by default is the FQDN of the server. So i’m assuming by your notes that you’ve left the SCP (aka AutoDiscoverServiceInternalUri) defaulted to the FQDN in 2010. Now that you’ve deployed 2016, you have 2 new SCP addresses which match the FQDN of the 2016 servers.

      I personally don’t like leaving the AutoDiscoverServiceInternalUri defaulted to the FQDN. This requires the FQDN be added as a SAN on the certificate to avoid security prompts by the Outlook client. It also limits your control on which CAS the client connects to as SCPs are handed out in random fashion.

      My suggestion would be to set all AutoDiscoverServiceInternalUri to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml. You would then point autodiscover.domain.com to your load balancer and have the LB manage which servers you send SCP based autodiscover requests to. In this case, i’d point it to the new 2016 servers once they are in “production”.

      1. Thanks for your quick response.

        Yes, you got it right.

        We have a wild card certificate so we don’t have to worry about the SAN certificate part.

        If we update the SCP of our current exchange servers to autodiscover.domain.com, what would be the impact on the users?
        If a user’s outlook is using xcg12010.domain.com to connect to the exchange server, on updating the SCP, will the user have to manually update to the new SCP or restarting outlook should do it automatically?

        Thanks.

    1. One more question. I have set all and: OWA, autodiscover, OA work perfect, but from Outlook client connected (internally or externally) to Exchange 2007 (legacy) have problem with OOF (inaccessible server). I just found problem – can not access externally https://legacy.domain.com/ews/exchange.asmx and internally too.
      Outlook connected to Exchange 2013 + OOF works OK.
      Thanks in advance for your help.

  31. Friends, are these “legacy” records created for users to be redirected from Exchange 2013 to Exchange 2007? So, all users who are in Exchange 2007, after installing Exchange 2013 will connect in Exchange 2013 first and then be redirected to Exchange 2013? Does this apply to the CAS service as well? Thank you.

  32. These settings need to be performed outside of business hours, as soon as you install Exchange 2013 users who are logged on in Exchange 2007 will be affected, right? Or is it initially transparent to users until URL changes are made? I do not want to impact my local users.

  33. Hi jeremy great article it helped me so much!
    A question i have if we have Exchange 2007 and build a hybrid Exchange 2013 server. Do we need to move a mailbox first to Exchange 2013 before we can move it to Office 365?

  34. I’m part way through 2007-2013 coexistence. I applied cert to 2013 and ready to begin setting urls. I’ve read many of the comments and your post has cleared up several of my issues. My question relates to autodiscover. My current autodiscover URL points to https://fqdn.domain.com/autodiscover/autodiscover.xml. By what I’ve read here, it would be best to first change the 2007 URL to https://autodiscover.domain.com/auto…etc, set the same on 2013 then set 2013 as the lead scp? Is this correct? The cert contains autodiscover entry so I’m good there. Any guidance would be much appreciated.

  35. Good Afternoon Jeremy,
    First, as its been said, GREAT Article- Thanks a ton for this!!

    Second, and my reason for posting. I’ve read the article and all 75 comments, Some are relevant and some aren’t so i though that i’d see if i could get a more direct response. Here goes..

    Currently in a 2007 environment, we are NOT staying with OnPrem but have to migrate front end services to 2013 in order to facilitate O365 federation. I’ve opened tickets with Both the OnPrem and O365 folks and i’ve made limited progress. Here’s what i need to know if you wouldn’t mind:

    1- I’d like to install Exchange 2013 and run it Side-By-Side to test without impacting current production- you sorta covered this in comment 30- i was hoping you could go into a little more detail. Specifically around the use of Local Host Files. Are you referring to local as in local to my machine or local to the Exchange 2013 server- also what entries?

    You also mentioned in your reply that we’d need Outlook Anywhere setup- On the 2007 or 2013? we’re set up on 2007 and it works great. Same thing for Auto-discover- its obviously working fine as it stands.

    2- Public DNS – At the moment we do not have legacy.”mydomain”.com but that’s an easy step. When we add that we’re going to point that back to our Netscalers and handle the NAT’ng there – is that correct or did i miss something- you mentioned it earlier in another comment about needing a 2nd External IP..

    3- SCP registration, im assuming that this is able to be modified- again assuming that and assuming im able to do so, when would we change it back? And when we do, what should it be changed to?

    At the end of the day i want to be able to install Exchange 2013 on 3 server, while not affecting the current Production 2007 environment and understand what it is im doing in the process.

    Sorry for the lengthy post.
    Thanks!!

  36. Hello,

    I am planning to do the migration from 2007 to 2013 Exchange. I am installing the 2013 server, do I need to do the migration right away or can I do it slowly, in other words will the exchange 2013 installation create problems to my existing 2007 exchange environment.

    Thanks.

    1. Hi Bobby, I’m sure you’re well on your way or even complete with this migration by now, but I figured I’d respond anyways. No, you will not need to migrate immediately. The two versions can co-exist side-by-side which can provide you ample time for migrating to the new platform, and decommissioning the legacy 2007 environment. I personally would not recommend a long term coexistence period. Plan the project…execute the plan. The sooner you get off the aging, unsupported 2007 environment, the better.

      Jeremy

  37. First off, this is an amazing walkthrough regarding the migration from 2007 to 2013.
    I have inherited an 2007 Exchange environment that unfortunately has the server named “webmail.domian.com”. Of course the owa, ews, etc URL’s are webmail.domain……
    How can I go about making the DNS changes with the server being called webmail. Arrgh.

    1. Hi Greg,

      Not sure if you’re still working through this scenario, but this is indeed a challenging situation.

      Unfortunately, I don’t have any good answers for you. Since the actual name of the server is webmail.domain.com, there’s not much you can do about redirecting this existing namespace until the legacy 2007 server is removed from the environment. The FQDN of an Exchange server is embedded deep within Active Directory, and it is not supported to change the name of an Exchange server.

      My only advice would be to pick a new namespace for 2013, and don’t tie it to the server FQDN this time around. Once you get everything cut over to 2013, and you decommission 2007, you could re-introduce the webmail namespace if you’d like, but this involves impacting the end user several times. Not something I’m a fan of doing.

      Thanks,

      Jeremy

  38. Used this guidance when migrating from 2007 to 2013 back in late 2013. About to migrate from 2013 to 2016, does the same guidance apply?? Or do you have an updated document for 2016?

    1. I do not have guidance published. 2013 to 2016 is typically not as challenging as namespace will proxy back and forth.

      A couple of good places to start:

      Exchange 2016 Namespace Planning
      https://blogs.technet.microsoft.com/exchange/2015/10/06/namespace-planning-in-exchange-2016/

      Exchange 2016 Preferred Architecture
      https://blogs.technet.microsoft.com/exchange/2015/10/12/the-exchange-2016-preferred-architecture/

      Load Balancing in Exchange 2016
      https://blogs.technet.microsoft.com/exchange/2015/10/08/load-balancing-in-exchange-2016/

  39. Jeremy, thanks for that great document.
    I’m at the beggining of a 2007 to 2013 migration where there are no split-dns and the 2007 namespace is the same as name of the server, so this record is used internal and externally and is the FQDN also: exchange.domain.com. As I have read in other comments I have no other choice than to use another namespace for 2013 not tied to the new nameserver. My questions are: 1.- Does the installation of the new 2013 with new namespaces affect in any matter to the existing 2007 production environment?. 2.- As I don’t have configured autodisvover in 2007 instalation nor dns or clients, this implementation will affect the outlook clients? Now they are configured to connect to exchange.domain.com.
    For you to know, OA is configured in 2007 with NTLM activated.
    3.- How this will affect to smartphones email connections with Active Sync as they are pointing to exchange.domain.com?
    I gess that when changing namespaces in a migration there is no impact in clients as far as notify them to connect to a different OWA or Active Sync urls when their mailbox has been migrated, but I don’t know how autodiscover will work when configured and will point the new namespace in 2013. Maybe I have to install ssl certificates for exchange.domain.com, newnamespace.domain.com and autodiscover.domain.com in the new 2013 server?
    Thanks in advance and hope you respond to this questions. Regards

Leave a Reply

Your email address will not be published. Required fields are marked *