After a mailbox move from Exchange 2010 to 2013, there seems to be an hour or so delay before ActiveSync starts working again for that mailbox. External and internal DNS is pointing to the Exchange 2013 CAS, which proxies everything just fine for mailboxes still on the Ex2010 server. After a mailbox move from Ex2010 to Ex2013, Outlook and OWA work perfectly fine and get proxied to the proper mailbox by the Ex2013 CAS immediately, but activesync does not for about an hour or so.

Running the ExRCA for Activesync with the credentials of the mailbox that just moved it fails at the Attempting to send the OPTIONS command to the server, with a HTTP 403: forbidden. Interestingly, even though the mailbox is fully on the Ex2013 server, it seems that the Ex2013 CAS is still trying to proxy the activesync session to the Ex2010 mailbox (in the ExRCA error, the X-CalculatedBETarget is still pointing to the Ex2010 server), and since the user is no longer on that mailbox you get the permission error. If you wait an hour or so after the mailbox has moved everything starts working properly and X-CalculatedBETarget points to the proper server when you run the ExRCA. 

So my question is: is it normal for there to be a delay in ActiveSync after moving the mailbox? Is there some kind of cache on the Ex2013 CAS for proxies that just takes a while to time out before it starts proxying activesync to the proper mailbox? is there any way to change this behavior if it is normal? Both Ex2010 and Ex2013 servers are in the same AD site, so there isn't any cross-site AD replication lag, and I'm not seeing any ActiveSync related errors in any of the logs. Thanks!

(Also I should note, the accounts I've tested moving are just normal AD accounts that have the 'Inherit permissions' checked in AD. I'm aware of the issue with privileged AD accounts sometimes not getting the proper Exchange permissions inherited causing ActiveSync to fail, but that is not the case here)

• Edited by JordanLoehr Thursday, August 08, 2013 3:20 PM

We validated on CU1, that the Exchange 2013 CAS/IIS caches the 2010 CAS server as the X-CalculatedBETarget instead of the 2013 mailbox server FQDN.  You can validate this with testexchangeconnectivity.com or turn on EAS logging for the mailbox you're testing from.

When we migrated to CU2 it didn't resolve anything but to date we are able to restart IIS to clear out the caching in order for the mailbox to work.  A few test required a phone restart (not having to wipe any profile data).  We've escalated the issue to MSFT Premier but since we migrate users in batches, we can suspend the migration until a safe time to complete cut over and then bounce web services.  If you have a load balancer then just do one at a time and you'll have no issues.

It will be either be confirmed as a bug and then fixed in the next available CU cycle or there may be some "KB" on how to change IIS caching for this type of behavior.  At least that's my theory.

• Proposed as answer by El Veracruz Friday, October 04, 2013 4:56 PM
• Unproposed as answer by El Veracruz Tuesday, April 15, 2014 6:12 PM

Ben;

Sorry for the delayed thread update.  I did get this submitted as a bug with verification by escalation engineering.  I don't know if the fix will make it into the planned SP1, but the workaround is to recycle the Microsoft-Server-ActiveSync application pool on all CAS servers responsible for those services.

Obviously this isn't very helpful when doing one-off moves, but if you're batch migrating hundreds of users then I can schedule completion of the migration along with a powershell script to recycle those pools remotely.

IIS App Pool Recycle Script

That script allowed me to batch migrate a few hundred users and complete each night at midnight.  I then buffered out around 1 hour to allow completions and then run the powershell app pool recycle at 1AM via task manager so I don't have to be "on-call" to manage the process.

Hope this help.

• Proposed as answer by El Veracruz Monday, December 16, 2013 6:24 PM
• Unproposed as answer by El Veracruz Tuesday, April 15, 2014 6:12 PM

I wanted to add that we are currently in the same situation. We're running the same release and distribution and having to manually restart application pools each time is just not a great way for us to be working.

I haven't seen any kind of update on this or a patch that fixes it. Has anyone had something shared from Microsoft or seen something I haven't in regards to a fix?

• Proposed as answer by McGr Wednesday, April 09, 2014 3:26 PM
• Unproposed as answer by McGr Wednesday, April 09, 2014 3:26 PM

The Premier ticket is closed with "Accepted as Bug".  They don't give out CU number to expect the fix in the same way they did, I can only wait to see if the next CU does include this fix (post SP1).  What the escalation engineer did note is the time to clear cache against the application pool did go down in SP1 from a variable of 6 to 8 hours to a hour or so, still annoying but interesting something did change this behavior.

• Proposed as answer by Brandon Shanks Friday, April 11, 2014 9:28 PM

Has anyone tried CU9?  We're encountering the similar issue with CU8.  Before migrating the mailbox from 2010 to 2013, the iPhone could send/receive the emails normally by accessing CAS 2013, but, after migrating, the iPhone started failing in accessing CAS 2013.  To avoid the issue, if CU9 might work, we'd like to try it, but, the KB article (https://support.microsoft.com/en-us/kb/3049849) doesn't mention the issue as of now...

I have CU9 and experiencing this issue first hand after my first mailbox move yesterday.