After a number of relatively pain-free Exchange transitions, it was only a matter of time before I found an issue during mailbox migration. This one particular client had previously experienced a number of issues with their exiting Exchange deployment and the configuration was absolutely not best practice, so I was very apprehensive about the migration.
Up until the point of switchover, it had been relatively painless, save for the previous consultants using the same FQDN for the CAS Array and virtual directories (See Ambiguous URLs). However, shortly after we moved live mailboxes (test mailboxes worked flawlessly) one issue came to light – once the migration completed (note completed, not just synced) a user would receive the prompt that an Administrator has made a change to the mailbox, and Outlook needs to be restarted. Once restarted, the user would not be able to connect to Exchange 2013. It appeared that the internal clients were still hanging on to the 2010 CAS server and creating a new profile produced the same error.
Whilst spending time researching the problem, I received notification that the mailbox was suddenly working! No changes were made, which made me look at IIS caching. As it turns out, this is a known issue. When a mailbox is migrated to 2013, the mailbox still has a cache entry pointing the client back to Exchange 2010 CAS server. This cache expires supposedly every two and half hours (From CU5).
There is currently no KB article.
As to why this has happened to this one particular client, and not the many others I’ve done, I’ve no idea.
So, we have two options – resetting IIS, or recycle app pools. I’m a fan of trying the least disruptive workaround first.
By recycling an App Pool, a new w3wp process is created which serves subsequent requests, while the previous w3wp process has a configurable amount of time to complete all outstanding requests (by default 90 second). There is a performance impact since the items in memory have to be reloaded, but there is no outage.
Exchange 2013 CAS Server:
Exchange 2013 Mailbox Server:
We could potentially change the interval temporarily by clicking on each app pool, and selecting Advanced Settings. This could be useful during migrations, but given the slight overhead, I would recommend changing this back to 0 after migrating.
Hopefully this assists some of you who run into similar issues.