Hello,

Anonymization note: The domain names contoso.com and contoso.local, the server name EXCH-SE-01, and the account name CONTOSO\MigrationAccount used in this post are anonymized placeholders. They do not represent the actual production domain, server, or account names. The Exchange versions, configuration values, HTTP status codes, diagnostic results, and sequence of events are unchanged.

We are experiencing an issue with remote mailbox moves from Exchange Server Subscription Edition to Exchange Online.

The Exchange Online migration endpoint and the following command both fail:

Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer "mail.contoso.com" -Credentials $cred

The error returned by Exchange Online is:

The connection to the server 'mail.contoso.com' could not be completed.

The call to:

https://mail.contoso.com/EWS/mrsproxy.svc

failed with:

The HTTP request is unauthorized with client authentication scheme

'Negotiate'.

The authentication header received from the server was:

'Negotiate, NTLM'.

The remote server returned an error:

(401) Unauthorized.

Environment

Exchange version:

Exchange Server Subscription Edition RTM

 

Installed update:

August 2026 Security Update

KB5121573

 

Binary version:

15.2.2562.46

 

Topology:

Single Exchange server

Mailbox role

Classic Full Hybrid

 

Operating system:

Windows Server 2022

 

Exchange Online migration type:

Remote Move / onboarding

The environment does not have separate frontend and backend Exchange servers. Both the Client Access frontend and mailbox backend services are hosted on the same Exchange server.

All checked MRS binaries have the same version:

Microsoft.Exchange.MailboxReplicationService.dll

Microsoft.Exchange.MailboxReplicationService.Common.dll

Microsoft.Exchange.MailboxReplicationService.ProxyClient.dll

Microsoft.Exchange.MailboxReplicationService.ProxyService.dll

MSExchangeMailboxReplication.exe

File version:

15.2.2562.46

MRSProxy configuration

Get-WebServicesVirtualDirectory | Format-List Identity, MRSProxyEnabled, BasicAuthentication, WindowsAuthentication, WSSecurityAuthentication, OAuthAuthentication, ExternalUrl

Current configuration:

MRSProxyEnabled : True

BasicAuthentication : False

WindowsAuthentication : True

WSSecurityAuthentication : True

OAuthAuthentication : True

ExternalUrl : https://mail.contoso.com/EWS/Exchange.asmx

Extended Protection settings have been validated by the latest Exchange Health Checker:

Default Web Site/EWS:

Extended Protection = Allow

SSL flags = Ssl, Ssl128

Authentication = Windows, Negotiate, NTLM

 

Exchange Back End/EWS:

Extended Protection = Require

SSL flags = Ssl, Ssl128

Authentication = Windows, Negotiate, NTLM

Anonymous authentication = enabled

 

Exchange Health Checker reports:

Exchange SE RTM Aug26SU

Build Number: 15.2.2562.46

MRS Proxy Enabled: True

Extended Protection configured correctly for EWS

Default Web Site: Started

Exchange Back End: Started

MSExchangeServicesAppPool: Started

 

Local MRS health

All local MRS health checks pass:

Get-MailboxServer | Test-MRSHealth | Format-Table Check,Passed,Message -Wrap

Results:

ServiceCheck : Passed

RPCPingCheck : Passed

MRSProxyPingCheck : Passed

QueueScanCheck : Passed

Migration accounts

The test was performed with two different on-premises accounts.

Both accounts return the same HTTP 401 result.

The primary migration account:

Enabled : True

LockedOut : False

PasswordExpired : False

The account is also a direct member of: Organization Management

One of the accounts used for testing also has domain administrative permissions, so the symptom does not appear to be caused by missing Exchange RBAC permissions.

Changing the password and updating the credentials stored in the migration endpoint did not change the result.

Failed Request Tracing results

Failed Request Tracing was enabled temporarily for Default Web Site.

The MRSProxy request is processed in three stages.

Stage 1: anonymous request

The initial anonymous request to:

/EWS/mrsproxy.svc

returns HTTP 401, which appears to be the expected authentication challenge.

Stage 2: NTLM negotiation

The next request shows:

WindowsAuthenticationModule

AUTH_SSPI_CONTINUE_NEEDED

HTTP 401.1

0x8009030e

This also appears to be the normal intermediate NTLM challenge.

Stage 3: authenticated request

The final request shows:

Authentication type : Negotiate

NTLMUsed : true

AUTH_SUCCEEDED : true

RemoteUserName : DOMAIN\MigrationAccount

AuthUserName : DOMAIN\MigrationAccount

The Exchange frontend also calculates the expected backend server.

However, after authentication succeeds, the request ends with:

ModuleName : ManagedPipelineHandler

Notification : EXECUTE_REQUEST_HANDLER

HttpStatus : 401

HttpSubStatus : 0

ErrorCode : 0

Therefore, Windows Authentication appears to complete successfully. The final HTTP 401 is returned later, while the Exchange/WCF MRSProxy handler is executing.

No corresponding failed domain logon events are recorded in the Windows Security log.

No new ASP.NET event stating:

MRS proxy service is disabled

is generated for the current requests.

Additional checks already completed

We have already verified the following:

MRSProxyEnabled=True

Test-MRSHealth passes

Two migration accounts tested

Migration account is in Organization Management

Basic Authentication enabled temporarily for testing

Windows Authentication enabled

Negotiate and NTLM providers present

Frontend Extended Protection set to Allow

Backend Extended Protection set to Require

Frontend TLS certificate valid

Backend port 444 certificate valid

MSExchangeServicesAppPool running

Mailbox Replication Service running

EWS physical paths valid

WCF *.svc handler mapping present

MRS binaries present and version-consistent

Exchange server fully restarted

IIS restarted

MRSProxy disabled and enabled again

Temporarily enabling Basic Authentication did not change the result.

Using another migration account did not change the result.

The dedicated Exchange hybrid application and Microsoft Graph hybrid flow are also configured and Test-OAuthConnectivity succeeds. We understand that this configuration is not used for MRS remote mailbox moves.

August 2026 SU known issue

We reviewed the Exchange Team announcement for the August 2026 Security Update.

The article mentions that MRS migrations can fail if a backend mailbox server has the August 2026 SU while the frontend Exchange server proxying the connection is on an older build.

This does not seem to match our topology because this is a single Exchange server and all MRS components are on version 15.2.2562.46.

The error is also HTTP 401 rather than TooManyTransientFailureRetriesPermanentException.

Questions

Has anyone observed the following behavior after installing Exchange SE August 2026 SU, KB5121573?

MRSProxyEnabled=True

Test-MRSHealth passes

NTLM authentication reaches AUTH_SUCCEEDED

ManagedPipelineHandler returns final HTTP 401.0

Test-MigrationServerAvailability fails

In particular:

1. Is there a known issue in KB5121573 related to MRSProxy authorization after successful NTLM authentication?
2. Does MRSProxy require any additional authorization configuration introduced by the August 2026 security changes?
3. Is there a supported way to validate the MRSProxyAuthorizationManager decision?
4. Are there additional diagnostic logs that show why the WCF MRSProxy handler returns HTTP 401 after AUTH_SUCCEEDED?
5. Is reapplying KB5121573 the recommended repair action in this situation?
6. Has anyone resolved the issue without recreating the EWS virtual directory or disabling Extended Protection?

We have retained the following diagnostic evidence and can provide sanitized excerpts:

Exchange Health Checker TXT/XML

Test-MigrationServerAvailability output

Test-MRSHealth output

Frontend EWS Failed Request Tracing

EWS HttpProxy logs

EWS and backend IIS configuration

MRS binary versions and hashes

Any guidance or confirmation from the Exchange Team or administrators who encountered the same behavior would be appreciated.

Thank you.