Exchange online - shared personal calendar dissapear
User A has been given full delegate access to User B mailbox - set in exchange admin backend When user A open OWA (or outlook app) - the calendar of User B does not show up. Manually when adding User B calendar the calendar shows up - but only with limited view (details of meeting not shown) If User A do a F5/refresh in OWA (or close and open outloo app) - the calendar of User B is gone again Have tried to reset the rights on calendar of user B - so to remove all access for user A. And wait 24 hours - and then set the rights again. But issue on calendar keep going on Running exchange online
Cross-tenant Migration
Hi all, I will be doing migration from existing tenant to a new one soon. I've recently completed IMAP migration to Exchange online, and also Google Workspace Migration to Exchange online.... So I thought that cross-tenant will be the easiest one as it is all under MS.... Looks that I was wrong, and seems to be quite the most challenging one 🙂 Few details first - there is a COMPANY-A tenant. There is also COMPANY-B domain created in that tenant . Now, COMPANY-B is going to move to a new tenant and keep the name. It will be only 15 users, so not a huge amount. So, I can see that there is a Cross-Tenant migration option available in EAC, so I want to use it. It does look a bit complicated anyway. What I'm trying to confirm/clarify is: Is the Cross-Tenant Migraiton option in EAC the one that I can use for my scenario? Checking https://docs.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide . It seems to be however a bit of work in powershell etc (I'm not expert with powershell). Is this the only and easiest way to do the migration? 🙂 Anyone has any guide on "step-by-step" that I could have a look? Would help me a lot. Are there any "tricky" parts that I should be aware of during migration? Ppl that already used this way to migrate PS: For SharePoint migration, I will use Migration and Mover that is abailable for via SharePoint... which seems to be quite straight forward. Any info that will help me to prepare for the move would be much appreciated.Microsoft Bumps Auto-Expanding Archive Limit Past 1.5 TB
First revealed in 2015, the history of auto-expanding archives in Exchange Online has been spotty with several false starts. Now the limit will go past 1.5 TB, but only for eligible E5 licenses. Although the roadmap item has roll-out scheduled for October 2026, Microsoft hasn’t revealed details of what the new upper limit will be or how the new limit will be managed. Having a massive archive mailbox will never concern me, but there must be some who need such a monster archive. https://office365itpros.com/2026/09/10/auto-expanding-archive-larger/
Own domain flagged as harmful by Safe Links — submissions return "Unknown"
Our organization's own domain is being flagged as "This message contains a link that might be harmful" in Outlook and Teams. We submitted the URL for review via Submissions → URLs twice (over several days apart), and both came back as "Unknown - We checked but can't make a decision right now." We also tried adding the domain to the Tenant Allow/Block List, but the warning in Teams still persists. Per the portal notice, tenant allow entries only override bulk/spam/regular phishing verdicts, not malware/high-confidence phishing — so we suspect the domain may be misclassified at a higher severity level. Has anyone experienced this before, or know how to escalate when submissions repeatedly return "Unknown"? Submission IDs for reference: 5483d45c-405e-46c8-97e3-08df0cc793fb (Sep 7) and dcaab607-4ead-4791-4996-08df0a6ab25a (Sep 4).
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.
