Skip to content

April 18, 2013

21

Exchange 2010/2013 Co-Existence Experience

Now that Exchange 2010 SP3 and Exchange 2013 CU1 have both been released, co-existence between Exchange 2010 and Exchange 2013 can now be completed using a supported method.  Unfortunately, there are some scenario’s that can cause this migration to have a few problems.  I wanted to take a few minutes to post a few experiences I have had in this process; hopefully what we have learned will be helpful to others.

To give a little background of our environment, we have 3 Exchange 2010 servers (2 CAS/DAG collated servers, and 1 UM server), and 4 Exchange 2013 servers (2 CAS servers and 2 DAG servers).

Our main issue stemmed from a namespace issue that can occur with Exchange 2010 and Exchange 2013 co-existence.  Because we have multiple CAS servers in Exchange 2010, we have a CAS array defined.   We ran into a conflict, where our Outlook Anywhere name (in Exchange 2010 and 2013) and our CAS Array Name (Exchange 2010) are the same (outlook.domain.com).  In this configuration, when we attempted to move our Exchange 2013 CAS servers to internet facing, we began to counter a loopback issue for all users with Exchange 2010 mailboxes.  The loopback issue occurred because of the namespace conflict.

After talking with MS Support, it was determined that this conflict has to resolved by changing the RPC name for Exchange 2010 Mailbox Databases to something unique (for example, the real server name of one of the members of Exchange 2010) and configuring all Exchange 2010 communication (internal and external) to occur over HTTPS instead of RPC (since this is how Exchange 2013 talked to Outlook clients).  We also had to make a few changes to Exchange 2013 Outlook anywhere configurations methods.  Below, in Appendix A, I will post the commands we ran to enable this configuration.

Unfortunately, at this point, we loose the seamless migration experience, in relation to the end-user.  Changing this setting results in end-users getting pop-ups in Outlook stating that an Exchange Administration has changed settings and that Outlook must be closed in re-opened.  This would not have been a huge deal if this is where the problem stopped, however, this is only the beginning of the user impact.  From what we can tell, older version of Outlook (such as 2007 in our case, I think 2010 can be affected as well), can’t properly switch to the new namespace without holding on to connections to the old CAS array.  This causes Outlook to hold a connection to the Exchange 2010 RPC service, and to the new Exchange 2013 Outlook Anywhere service at the same time.  Even though Outlook states that it either needs password, or is trying to connect, it does appear that mail flow in Outlook does usually continue to function.  However, the end-user is endlessly plagued with password prompts while in this state (and passwords are typically rejected by the server).  Best we can tell, Outlook 2013 handles these changes smoothly and without issue (the user just has to restart Outlook a couple of times).  It also appears that some Outlook 2007 clients do successfully make the change, but a high percentage do not.  The only way to fix these clients is to completely delete their Outlook Profile and let it re-create using AutoDiscover (repairing the account does not appear to fix the issue). Once the account gets added back, all is well (however if you have a large number of clients, this can be very problematic).

The issue also continues to plague as we move into the actual Exchange 2013 mailbox migration.  We have found that when a user, once again, is using Outlook 2007, and their mailbox is moved from Exchange 2010 to Exchange 2013 the Outlook issue can reoccur.  When this happens, the profile must once again be removed and re-created.  (The server name does successfully change to the mailbox GUID, as expected in Exchange 2013, but a connection tends to stick to the old Exchange 2010 server.  Closing and re-opening, or rebooting the system, makes no difference in cleaning up this problem.)  Outlook 2013 clients do appear to work flawlessly.  As you can see, this provides a large amount of IT overhead and end-user interruption.  Unfortunately, when asking Microsoft support about the Outlook 2007 behavior (in both migration stages), all we got back was that it is “expected results.”

One other, completely separate issue, is in relation to Mailbox transfer speeds.  Even after talking to Microsoft Support, have no real answer for this. From our experience, you should expect this mailbox migration process to take not hour, not days, but weeks (or months in large organizations) to complete.  We are only looking at about 300 GB of mailboxes to move, and based on the extremely slow rate of move, we expect this to take anywhere from 10-14 days to complete.  At this point, the most we can do is just to be patient and just wait.  This was not expected results, as moves from Exchange 2007 to Exchange 2010 were no where near this slow (we moved all boxes in 24-48 hours).  This is important to note as a possibility if mailbox migration speed matters in your environment.

That is the highlights of our co-existence so far, hopefully our mailbox moves will complete soon and we can be on the way to wrapping up this migration.  We are eager to be fully on Exchange 2013, as there are some great features in this new version. The good news is, the fact that the Exchange team now maps the mailbox GUID as the server name in Outlook (instead of any server name of Outlook Anywhere name), it would seem that this issue should not be present going forward with future versions of Exchange.  If you have found, like we have, that the documentation is extremely lacking for this co-existence processes, hopefully you can find some of this information useful.

 

Appendix A:

When moving Exchange 2013 to Internet Facing, in addition to modifying your Load Balancer, Firewalls, DNS, Send/Receive Connectors, we had to make the following changes to resolve the namespace problem:

Using Exchange 2010 Management Shell:
Change RPCClientAccessServer Attribute to be FQDN of Exchange 2010 Mailbox Databases (repeat for all Databases on Exchange 2010)
Set-MailboxDatabase –Identity “<Database Name>” –RPCClientAccessServer “<servername>.<internaldomain>.local

Using Exchange 2010 or 2013 Management Shell:
Change SCP Object for Exchange 2010 to Point to Exchange 2013 (repeat for all Exchange 2010 CAS Servers); set this to whatever your internal AutoDiscover namespace is.
Set-ClientAccessServer –Identity “servername” –AutoDiscoverServiceInternalURI https://outlook.domain.com/autodiscover/autodiscover.xml

Using Exchange 2010 Management Console:
Set Exchange 2010 Outlook Anywhere to NTLM (repeat for all Exchange 2010 CAS servers)
EMC-Server Configuration-<servername>-Right Click-Properties-Outlook Anywhere Tab- Change Authentication method to “NTLM”

Using Exchange 2013 Management Shell:
Temporarily adjust Authentication Method on Exchange 2013 Outlook Anywhere to be NTLM (required for users on Exchange 2010)
Set-OutlookAnywhere -Identity “<exchange2013cas>\rpc (Default Web Site)” -InternalClientAuthenticationMethod:Ntlm -IISAuthenticationMethods Basic,Ntlm,Negotiate  -SSLOffloading $false

Once Exchange 2010 has been removed and uninstalled, run the following command to reset authentication.
Using Exchange 2013 Management Shell:
Adjust Authentication Method on Exchange 2013 back to Negotiate
Set-OutlookAnywhere -Identity “<exchange2013cas>\rpc (Default Web Site)” -InternalClientAuthenticationMethod:Negotiate -InternalClientAuthenticationMethod:Ntlm -IISAuthenticationMethods Negotiate -SSLOffloading $false

21 Comments Post a comment
  1. Sai Prasad
    Aug 7 2013

    I am hoping that your mailboxes have moved and migration is smooth now ?

    1 thing I am interested in is about UM during your co-existence. Did you have any issues for 2010 mailboxes enabled for UM. I mean, were VM’s correctly forwarded to users mailbox irresepective of which server they were in.
    Did you also add the 2013 server to the UM Dial Plan ?

    Reply
    • Brent
      Aug 8 2013

      Yes, we finally got things smoothed out and are running solely on Exchange 2013 now.

      Yes, it did have some level of intelligence in regards to UM, but also required some config. I am trying to remember the exact situations, its been a little while. We did end up configuring UM on our Exchange 2013 servers and adding them to the dial plan. I would suggest moving one mailbox that has UM enabled and testing it. If it fails, then go ahead and configure UM on your Exchange 2013 servers and then it should work.

      Reply
  2. sameboat
    Jan 21 2014

    I have the same issue, as I deployed exchange 2010 into production in June of 2010, they didnt have the documentation finished for configuring cas array’s, so I ended up using the same name as it was kind of confusing.

    Due to issues like the ones you reported, I am seriously thinking of just rolling out 2013 with a new name, though i hate to do that since it means activesync profiles will need to be updated for every user to reflect a different server name. What would you say, based on your experience?

    Reply
    • Brent
      Jan 23 2014

      Yeah, you may find a new name safer/easier; depending on how many devices that you will have to fix manually. But, if its a large number, it would probably be worth trying to make the existing name work (but this did cause a lot of headache for both IT and the end-user when we did). However, there is better documentation out there now to deal with this situation. Regardless, I would recommend testing as much as possible during off hours and attempting any scenario you can think of, so that you can rollback if its not seamless. I have seen many situations where Office 2007 behaves very differently than Office 2013, and problems sometimes only manifest depending which server the users mailbox is present on.

      Reply
  3. Frans Rampen
    Jan 29 2014

    Hello,

    We have a problem with outlook anywhere of 2013 not connecting to the 2010 environment; we get the following error in microsoft connectivity analyzer running on external client connecting to 2013 CAS:

    RPC Proxy can’t be pinged.

    Additional Details

    Additional Details: An HTTP 500 response was returned from Unknown.
    Headers received:
    request-id: 074e5643-3205-4fc2-ab6b-f13eface515e
    X-CalculatedBETarget: 2010cashost.domain.local
    Persistent-Auth: true
    X-FEServer: 2013CASHOST
    Content-Length: 102
    Cache-Control: private
    Content-Type: text/html; charset=utf-8
    Date: Wed, 29 Jan 2014 14:48:07 GMT
    Server: Microsoft-IIS/8.0
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET

    2014-01-29 14:48:07 RPC_IN_DATA /Rpc/RpcProxy.dll 2010cashost.domain.local:6001&RequestId=24d560c6-a841-42aa-a526-c74fdd230b1b&cafeReqId=24d560c6-a841-42aa-a526-c74fdd230b1b; 443 – MSRPC – 401 1 2148074254 0
    2014-01-29 14:48:07 RPC_IN_DATA /Rpc/RpcProxy.dll 2010cashost.domain.local:6001&RequestId=074e5643-3205-4fc2-ab6b-f13eface515e&cafeReqId=074e5643-3205-4fc2-ab6b-f13eface515e; 443 DOMAIN\test00000 MSRPC – 500 0 0 15
    2014-01-29 14:48:07 RPC_IN_DATA /Rpc/RpcProxy.dll 2010cashost.domain.local:6001&RequestId=1d03621f-a81e-4b5a-899a-227d67f2e334&cafeReqId=1d03621f-a81e-4b5a-899a-227d67f2e334; 443 – MSRPC – 401 2 5 187
    2014-01-29 14:48:07 RPC_IN_DATA /rpc/rpcproxy.dll 2010cashost.domain.local:6001&RequestId=2979411a-f6db-4eeb-a37a-4d3bd1bdb76f&cafeReqId=2979411a-f6db-4eeb-a37a-4d3bd1bdb76f; 443 – MSRPC – 401 1 2148074254 0
    2014-01-29 14:48:07 RPC_IN_DATA /rpc/rpcproxy.dll 2010cashost.domain.local:6001&RequestId=c51c8944-0e73-4c69-afec-2798ccfff90d&cafeReqId=c51c8944-0e73-4c69-afec-2798ccfff90d; 443 DOMAIN\test00000 MSRPC – 500 0 0 15

    We can successfully connect from 2013CASHost to 2010CASHost on ports 6001, 6002 and 6004 using telnet.

    Any idea what the problem is? All other services run without problems from 2013CAS to 2010 environment.

    Also, you write:
    Set-MailboxDatabase –Identity “” –RPCClientAccessServer “..local

    Suggesting to add 2010mbxhost.domain.local (the mailbox server) but i cannot change this, only cas serverobject is accepted.

    When using a migrated mailbox running on 2013 mailboxserver i can successfully connect but only the public folder connection remains on 2010MBXHost which gives the following error:

    2014-01-29 11:07:26 RPC_IN_DATA /rpc/rpcproxy.dll 2010MBXHOST.domain.local:6001&RequestId=e343fc6f-6123-41dd-8da0-e56d2a5449a5&cafeReqId=e343fc6f-6123-41dd-8da0-e56d2a5449a5; 443 DOMAIN\info00009 MSRPC – 500 0 64 15

    Before this works we cannot switch completely (DNS updates etc) as currently all RPC/HTTPS is running still on 2010CAS server.

    Hopefully someone knows why we get the 500 Internal Server Error messages on RPC traffic.

    Reply
    • Brent
      Feb 19 2014

      For the Set-MailboxDatabase you should be able to apply to the Exchange 2010 database, pointing directly to the Exchange 2010 CAS server (in our Exchange 2010 environment CAS and MBX were on same servers for Exchange 2010). This is only required if you have a shared namespace issue (CAS Array and Outlook anywhere are the same). Also, if I understand correctly from the last section, if you have a user on Exchange 2013, then your DNS, etc. must point to the Exchange 2013 CAS. Also, make sure that your Outlook anywhere configs on both versions match authentication methods.

      Reply
  4. Leng
    Feb 7 2014

    Really nice article!
    We are experiencing same problem as described in the article,only difference is that we only have problem with outlook 2013 users(latest patch installed).When migrating user from 2010 to 2013, 90% of Outlook 2013 users wont connect to exchange server.Only solution is to create new profile and let autodiscover fix the rest.(we have tried to repare/change current profile,reboot,change to offline mode and back to online mode,with no result)
    Since Exchange 2013 no longer need casarray it is still added to exchange 2010 cas array (strangely new servers are added automatically to 2010 casarray).20 % of users also have problem to get active sync to work,even when creating new profile.Solution is to go in users ad object and remove and set back inheritpermission.Then it takes almost 1 day before user can create new profile and sync their phone again.Seems like this issue can be stated back to Exchange 2003 (google for active sync error 500 or error 403).
    Will on monday check if your tip in Appendix A will work!

    Reply
    • Brent
      Feb 19 2014

      We saw issues with a few users profiling getting “stuck”, removing the profile and letting autodiscover recreate did fix it; but we didn’t see anything like the percentage you saw.

      Yeah, I have seen that issue with the inheritance before, but never nailed down what causes it. Resetting inheritance did fix it in my scenarios. In my case, it solved the issue instantly, but time might depend on Active Directory replication topology (forcing replication could speed this up).

      Reply
  5. Andrew
    May 7 2014

    Hi – thank you for this excellent fix for my identical issue.

    So I am about to perform the commands and fix the ambiguous database url issue, but just need some clarification.

    When changing the database will this break currently connected Outlook clients? and I have 2 2010 cas servers in an array, so do I still only choose one of the 2010 database names? Or could I create a new dns name for the array and use that?

    Set-MailboxDatabase –Identity “” –RPCClientAccessServer “..local

    thank you again.
    Andrew

    Reply
    • Brent
      May 8 2014

      Hello, I would definitely recommend making changes after-hours/in a maintenance window so that you can test the results. You definitely could create a new shared namespace (if you need to keep your Exchange 2010 CAS redundancy during the migration). We didn’t for simplicity sake because we were migrating very quickly and could live pointing directly to a single CAS for a week. Yes, this change will definitely affect Outlook clients. If it works smoothly, users will just have to close and reopen Outlook. If it does not happen smoothly, we had many cases where we had to delete and recreate their Outlook profiles for Auto Discover to properly pick up the correct names. Once you make the change I would recommend testing with users on both Exchange 2010 and 2013 with any version of a mail client a user might use, as well as test what happens after a user is migrated from Exchange to Exchange 2013. (That is the main reason for making change during a maintenance window so you can troubleshoot if any issues arise). In theory the popup prompting users to close and reopen Outlook is all that should happen both times, but I found it didn’t always work that smoothly. Does that answer your question?

      Reply
  6. Andrew
    May 7 2014

    I have create a new mailbox in 2010 and set the RPCClientAccessServer to a 2010 CAS server, and moved a 2010 mailbox into this database.

    I will test this now.

    Reply
  7. Nice post. I was checking continuously this blog and I’m impressed!
    Extremely helpful info specifically the last part 🙂
    I care for such info a lot. I was looking for this particular information for a long
    time. Thank you and best of luck.

    Reply
  8. Sep 25 2014

    Thanks for your personal marvelous posting! I definitely enjoyed reading it, you’re
    a great author. I will be sure to bookmark your blog and definitely will
    come back sometime soon. I want to encourage
    yoursxelf to continue your great writing, have a nice evening!

    Reply
  9. Kman
    Oct 20 2014

    Hi

    When all the URIs are the same;:

    Do you need to change the RPCClientAccessServer value for the databases to something unique
    OR
    Just force all outlook clients to go through HTTPS?

    Thanks

    Reply
    • Brent
      Oct 24 2014

      Yeah, in Exchange 2013 all clients should be connecting via HTTPS (RPC over HTTPS). If you are in co-existence, RPCClientAccessServer will need to be unique (from CAS array); as Exchange 2010 still uses traditional RPC. Once not in co-existence (only Exchange 2013), my RPCClientAccessServer setting matches Outlook Anywhere FQDN.

      Reply
      • Marcel
        Apr 26 2017

        Kman
        Did this change from forcing the clients to use RPC over HTTPS
        fix a lot of issues ? did you have a lot of outlook clients profiles to reconfigure?

        Reply
  10. Jul 19 2016

    Thanks for the solution. I found that I have the same issue with Exchange 2016 and Exchange 2010. I found a similar solution here: http://www.admin-enclave.com/en/articles/exchange/254-resolved-exchange-2010-2016-co-existence-issues-with-rpc.html which also mentioned your website. However in my case the solution 1 in the link above solved my issue. However your blog points me to the RPCClient issue … So thank you 😀

    Reply
    • Brent
      Jul 20 2016

      Thanks for pointing out that still affects Exchange 2016. Glad this information helped solve your problems 🙂

      Reply
  11. KISHORE R
    Sep 16 2016

    Your solution is very helpful. I have faced the same issue. From your document i have resolved our organization issue.

    Reply
  12. Leo Borges
    Jan 19 2017

    This post is perfect. I did a lot of research to find out my problem, and only here I was able to solve my case. I was not minding to change the RpcClientAccessServer property of Databases. Thank you for taking the time to publish this.

    Reply

Trackbacks & Pingbacks

  1. Exchange 2013 coexistence environment and Outlook infrastructure | Part 2/2 - o365info.com

Share your thoughts, post a comment.

(required)
(required)

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments