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

Hi Twad,

I saw this issue with SP1 and struggled with it.  If it has still not resolved with CU8 I am not sure if it would have been resolved with CU9.  It seems like some more architecture level issue.

Anyways, during our migration I created batch jobs using .xls file where I put all the user mailboxes emailaddresses I wanted to move and when create a move job select "manual" option before it completes.  Then you can start the move batch once it finishes it will ask you to "complete" the job.  So you will be ready to refresh "MSExchangeSynAppPool" on CAS servers.  Refresh it once you click finish and wait depending upon how many users are in the batch.  So you may need to wait for 5 to 10mins let all those connection comes to Exchange 2013 CAS and fail.  Then refresh the pool in this way I have noticed it starts working for most of the users with just 1 refresh but in some cases some users connections come late and again fails then you may need to refresh it again may be after 30mins.  

Look for eventids 1052 on Exchange 2010 CAS servers.  This will also tell you that which particular moved Exchagne 2013 users are still not able to use ActiveSync.  Otherwise IIS logs are difficult to read.  So you can refresh the "MSExchangeSyncAppPool" again.  

"The Exchange ActiveSync user DOMAIN.Com\userid has a mailbox on a Client Access server running a newer version of Exchange. Exchange ActiveSync doesn't support proxying users to Client Access servers running a newer version of Exchange. The user needs to connect to a newer Client Access server".