Outlook Login Fails After Exchange Mailbox move (2010 to 2016)

I currently have coexistence setup with Exchange 2010 and 2016.  When I move a mailbox to 2016, existing profiles in outlook (Outlook 2010 SP2 or Outlook 2016) fail to login.  If I create a new profile, I get endless prompts for credentials even though the user/pass is correct and the workstation is joined and logged into the domain.

Per this MS article:

Running this command: Restart-WebAppPool MSExchangeAutodiscoverAppPool  immediate resolves the issue.  The problem is, I have hundreds and hundreds of mailboxes to move and don't want to have to run the command for every move.  I know that I can stage mailbox moves and complete many at once, but I'd like to get to the bottom of the issue if possible to have more flexibility.

In addition, as an alternative to running that command, I can build a new profile and make the user a domain admin.  This resolves the continuous prompting and I can remove domain admin privileges immediately after the first login in.  While this is not a viable option, it does lead me to believe that there is some form of permissions issue.

Is anyone aware of the root cause of this issue?  I've reviewed countless articles regarding coexistence, failed mailbox moves, and checked, double checked and triple checked all of my DNS records, URLs, and virtual directory permissions.  That said, I would be happy to check them again if anyone can zone in the best places to look.

Thanks a lot
Aaron EcclesAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jose Gabriel Ortega CEE Solution Guide - CEO Faru Bonon ITCommented:
The bottom of the issue is quite simple.

Your autodiscover records should always be on the NEWER version of the exchange server, from the reading it looks like it's looking by default on exchange 2010, so, since the mailbox is not there, PROMPT IT ... forever
Michael B. SmithExchange & Active Directory ExpertCommented:
It's a caching issue and "works as intended". Depending on your CU, the cache is either 2 hours or 4 hours. Domain admins are not cached, because they are not supposed to have mailboxes (no highly privileged account should have a mailbox).

You already know the answer - move users in batches and restart the app pool after you've completed the batch. This is easier if you are doing everything in PowerShell, and not switching back-and-forth between the GUI and PowerShell.
Aaron EcclesAuthor Commented:
In regard to it working as intended, I'm curious then about the prompt that the user receives saying that a restart of Outlook is needed.  When they follow these instructions they would then be locked out of email until that 2 or 4 hour period.  It's surprising that this is "as intended" and there is no work around.  Am I correct in assuming that the "caching" is on the Exchange 2016 server, and that is why a restart of the pool resolves the issue?

Many thanks
Michael B. SmithExchange & Active Directory ExpertCommented:
So Outlook receives an ECMOVED message about the user's mailbox - and then updates the user's profile. It tries to connect - and can't. It heuristically expects that connecting to a fresh CAFE (Client Access Front End - CAS) server will give it a new connection path and tells the user to restart Outlook. In an on-premises environment - it'll probably connect to the same place and won't work because the CAFE will tell it to connect to the old location. And thus we travel the merry-go-round...

In Office 365, with thousands of CAS (front-end) servers, the chance of connecting to the same one is pretty small. In on-premises, the chance is very high. This was one of the first examples of Microsoft programming for what works best in the cloud and works poorly on-premises. The cache is an autodiscover cache - in MSExchangeAutodiscoverAppPool. Microsoft's compromise was to lower the cache from 4 hours to 2 hours in later CUs. But I honestly don't remember which CU it was, it's still so large that unless you do your migrations in the middle of the night, you need to recycle the app pool.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Aaron EcclesAuthor Commented:
Thanks for the incredibly knowledgeable responses - greatly appreciated.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.