Ask a question


How can we help you today?

Ask Question
Manage notifications
Subscribe to this question
Tony Camas

Some (but not all) users cannot access mailbox through Outlook after migration from Exchange 2010 to 2016

Hello,

Big migration project (from SBS 2011 to Windows Server 2022 / Exchange Server 2019) is proceeding here, and we are slowly moving user mailboxes over from the Exchange Server 2010 system to our temporary Exchange Server 2016 migration "hop."

It's all going relatively well, but I find that certain users (it may be those with particularly large mailboxes, though I'm not certain that's the case) are unable to access their email through desktop Outlook after the move completes. Outlook says it is not connected to the server (though, interestingly, it doesn't pop up a message about that; it just silently refuses to send or receive mail). If I attempt to force it to connect by clicking "update folder" on the Send/Receive bar, it reports that the server is unreachable.

The user has no problem connecting to mail with their mobile device, OWA works, and even the Microsoft Remote Connectivity Analyzer (outlook connectivity test at testconnectivity.microsoft.com) seems to be happy. But desktop outlook cannot connect. I've seen this with Outlook 2016 and 2021, but I imagine it's true of other versions as well. Interestingly, if I manually attempt an https connection to the new server's activesync URL, I get some sort of "bad HTTP request" error (I forget the exact wording, but that is the gist of it). From this and some additional research, I hypothesize that the new exchange server is still proxying requests to the old server, which is complaining because it can't authenticate using more modern methods. That's just an educated guess, though - I could be wrong about that.

Whatever the nature of the underlying failure, it seems that rebooting the Exchange 2016 server solves it. Thankfully, this only takes a minute or so with the new hardware (the old server takes a good 20 minutes to fully restart), but it's obviously not an optimal solution. Nevertheless, it does work -- after the server is restarted, outlook connectivity for migrated users works fine. It also appears that waiting a long time (several hours) eventually clears the problem as well, but this also is not ideal.

So... any idea what this could be? I've spent multiple hours on it, and I'm pretty stumped.

Thanks!

asked09/23/2024 15:24
18 views
Add Comment
Last Activity 09/24/2024 05:08

1 Answer(s)

  • Mariette Knap

    Hello Tony,

    In most cases this is DNS related. Make sure DNS response is correct from that client that has a problem. If all is good and it still does not work remove the Outlook profile, check the folder in %appdata% and delete all content. Autodiscover should do its work if all is configured the way it should.

    If you still have issues open a support ticket and we will connect to fix it for you.

    answered 09/23/2024 16:30
    Add Comment
    Tony Camas

    Thanks once again for your quick response, Mariette.

    DNS was the first thing I thought of as well, but the DNS is all correct as far as I can see, both internally and externally. I also thought at first this might have something to do with people being connected to the server by site-to-site VPN, which is sort of a strange middle ground between external and internal; i.e., the IP address of the client is not on the same local network as the server, but the server is nevertheless being accessed by its private (192.168.xxx) IP, rather than its public IP, because that's what is routed through the VPN. But that turned out to be a diversion and a waste of time, as the problem occurs on people's laptops at home as well as when somewhere within the corporate VPN. Also, the split DNS mapping of mail.domain.com to the local IP actually doesn't happen at most of the VPN-connected sites, owing mostly to an oversight on my part, but it turns out that makes no difference. I tried adding the additional host entry to one of the sites and it didn't matter. And, in any case, it's just as well that people not physically in the same building as the server access it using its public IP; there is no Hairpin NAT issue for them anyway.

    But all that aside, I checked all the DNS stuff, both inside and outside, and it all looks right to me. Also, if it truly is DNS-related, why would rebooting the Exchange Server fix the problem? That seems like a stretch to me.

    I appreciate your offer of assistance via a support ticket, and I may do that, but honestly right now I have a deadline I'm trying to meet, so it might be more expedient for now to just reboot the server occasionally as a workaround, and then perhaps we can seek a "real" answer to this after my deadline has passed.

    If I may ask you to speculate, though -- if rebooting the Exchange Server does indeed solve this, which appears to be the case 100% of the time so far, would it perhaps be worth trying to just restart one (or a few) of the Exchange services, rather than the whole system? If you were to guess at which services would be the ones causing this issue, which would you suggest? I was thinking the RPC Client Access service might be a good candidate for that, but you would probably know better than I.

    Reply
    replied 09/23/2024 21:40
Add an Answer