Hybrid moves fail since Oct 2026: MRSProxy 401, Event 4625 shows "Administrator" with empty domain (endpoint credentials ignored)

We are seeing the same behavior in our environment, so this does not look tenant-specific or limited to Exchange 2019.

Environment

• Exchange Server 2016 CU23 (on-premises) in hybrid with Exchange Online
• Onboarding moves (on-premises to Exchange Online) via MRSProxy

Symptoms

• Moves started failing between 12 and 13 Oct 2026, with no changes on our side beforehand
• Test-MigrationServerAvailability succeeds, but the actual mailbox move fails after connecting to the target mailbox.
• IIS log: POST /EWS/mrsproxy.svc returns 401 1 ...
• Security log: Event 4625 for the local account Administrator, Sub Status 0xC000006A (user name correct, password wrong), matching the pattern described in the original post

Workaround We renamed the local Administrator account on the Exchange server(s). After that, no more 4625 events appear for this account, the 401 responses are gone, and our migration batches complete normally again.

Same conclusion as the original poster: the credentials configured on the migration endpoint seem not to be used for these logons, and the failed attempts appear to come from the Exchange Online side. This looks like a service-side change rather than a local MRSProxy configuration issue, but only Microsoft can confirm that.

@Dario Steck, thanks for documenting this and the workaround. Please update the thread if Microsoft confirms a root cause or fix. We have also opened a support case and will share anything we learn.We are seeing the same behavior in our environment, so this does not look tenant-specific or limited to Exchange 2019.

Environment

• Exchange Server 2016 CU23 (on-premises, DAG) in hybrid with Exchange Online
• Onboarding moves (on-premises to Exchange Online) via MRSProxy

Symptoms

• Moves started failing between 12 and 13 Oct 2026, with no changes on our side beforehand
• IIS log: POST /EWS/mrsproxy.svc returns 401 1 ...
• Security log: Event 4625 for the local account Administrator, Sub Status 0xC000006A (user name correct, password wrong), matching the pattern described in the original post

Workaround
We renamed the local Administrator account on the Exchange server(s). After that, no more 4625 events appear for this account, the 401 responses are gone, and our migration batches complete normally again.

Same conclusion as the original poster: the credentials configured on the migration endpoint seem not to be used for these logons, and the failed attempts appear to come from the Exchange Online side. This looks like a service-side change rather than a local MRSProxy configuration issue, but only Microsoft can confirm that.

Came here to say thank you - I was in the middle of migration efforts and that ish has been broken since last week and thought for sure it was something I broke, but nope, MIcrosoft at it again. Renamed the local admin account to something else as suggested by OP, reset the Exchange Rep Service just to be sure, and then Migration finally worked right away.

Same issue here, confirming the pattern on another tenant.

Environment - Exchange Server 2019 CU15 (15.2.1748.39), single server, hybrid with Exchange Online - Onboarding moves via MRSProxy, endpoint credentials in DOMAIN\user format (domain administrator) Symptoms - Moves worked on 14 Oct 2026 (EXO MRS build 15.21.522.12) and copied several GB. - Since then every move/resume fails right after "Connected to target mailbox" (EXO MRS builds 15.21.522.17 and 15.21.546.12 seen in the move reports). -

Report.Failures: CommunicationErrorTransientException, FailureSide Source, WorkItem MakeConnections, "unauthorized with client authentication scheme 'Negotiate'". - IIS: POST /EWS/mrsproxy.svc -> 401 1 2148074252. - Event 4625: "administrator", empty domain, SubStatus 0xC000006A, NTLM, logon type 3. - RemoteCredentialUsername on the move requests is correct; no changes on our side. - Test-MigrationServerAvailability succeeds.

Opening a support case as well and will post any update from Microsoft.

Thanks Dario for documenting this and the workaround.

Identical issue here and the workaround worked. Thanks Dario!

Hi Dario Steck (dplan AG)

Based on the information provided, I am not aware of any publicly documented Microsoft incident or service health advisory at this time that describes Exchange Online MRS suddenly authenticating as the local Administrator account instead of the credentials configured on the migration endpoint. I was also unable to find an official incident ID associated with this behavior.

The symptoms you described are certainly unusual:

• Test-MigrationServerAvailability succeeds, but the actual mailbox move fails after connecting to the target mailbox.
• IIS logs show POST /EWS/mrsproxy.svc returning 401 Unauthorized.
• Security Event 4625 records logon attempts using Administrator with an empty domain and NTLM authentication, while the migration endpoint is configured with a different service account.
• Renaming the local Administrator account appears to eliminate the failed logons and allows mailbox moves to proceed.

Given that the behavior started around the time the Exchange Online MRS servers changed builds, and considering that the configured migration credentials continue to appear correctly in the move request properties, the evidence suggests a potential service-side regression or authentication handling issue rather than a typical MRSProxy configuration problem. However, only Microsoft engineering would be able to confirm whether this is an emerging issue or an unintended change in Exchange Online.

If you have not already done so, I would recommend opening a support case with Microsoft and providing:

• Correlation timestamps
• MRSProxy IIS logs showing the 401 responses
• Event 4625 entries showing Administrator with a blank domain
• Exchange build information
• The observation that renaming the local Administrator account consistently restores migration functionality

That workaround is particularly valuable because it provides a reproducible scenario that Microsoft can investigate further.

If Microsoft confirms this as a product issue, please consider posting an update here, as it may help other administrators experiencing similar hybrid migration failures.

This keeps the response neutral, avoids claiming a issue that Microsoft has not yet confirmed, and acknowledges the customer's findings.

I hope this information helps.