In our previous blog post we covered an overview of what migration endpoints are, how to find them and what makes them tick. In this post, we will cover related troubleshooting. Note that this post h...
Updated Mar 30, 2020
Version 5.0
Blog Post
Mirela_Buru
Microsoft
MicrosoftMike, just try to focus on one 401 failure in the move report, the most recent FailureTimestamp in $stats.report.failures |FT failuretimestamp,failuretype where $stats = get-moverequeststatistics <user> -includereport.
These should be timezone of the EXO admin, at least I think so. Then focus on all mrsproxy.svc entries around that HH:MM:SS but UTC timezone in IIS logs. If you only have 200s at that exact failure time, the request didn't reach Exchange. If the request did reach Exchange at that time, then enable FREB with the rule for 401 status code, resume the failed move request, wait to fail with 401 and get again the IIS logs + FREB logs around that exact time.
You can also check $stats.report.Entries | % {[string] $_} > entries.txt and let me know if something odd there.
P.S. The IPs with 174.x are not EXO, at least from my internal tool.
P.S. The IPs with 174.x are not EXO, at least from my internal tool.