Depreciation of Custom Controls in favor of External MFA
Deprecation of Custom controls Custom controls are being deprecated in favor of External MFA. Existing configurations keep working during the transition, but you should begin migration planning now. Custom controls retire September 30, 2026, and reach end of life in May 2027. When will you see this change? Custom controls will be retired on September 30, 2026, and the service will reach end of life in May 2027. Who will be affected by this change? This update affects organizations currently using Custom controls to integrate third-party MFA providers with Conditional Access. How will this affect your organization? Organizations relying on Custom controls will need to transition to External MFA to maintain support and continue using third-party MFA solutions within Microsoft Entra ID. Moving to External MFA also enables more consistent Conditional Access enforcement and improved integration with Microsoft Entra security capabilities. What do you need to do to prepare? Organizations should: Review existing Custom controls integrations Evaluate External MFA migration requirements Test Conditional Access policies and user experiences before migration Begin migration planning ahead of the retirement date Read more in the External MFA General Availability announcement and migration guidance.
Exchange SE 15.2.2562.46: MRSProxy returns HTTP 401 after successful NTLM authentication
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: Is there a known issue in KB5121573 related to MRSProxy authorization after successful NTLM authentication? Does MRSProxy require any additional authorization configuration introduced by the August 2026 security changes? Is there a supported way to validate the MRSProxyAuthorizationManager decision? Are there additional diagnostic logs that show why the WCF MRSProxy handler returns HTTP 401 after AUTH_SUCCEEDED? Is reapplying KB5121573 the recommended repair action in this situation? 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.
