Access old Exchage after migration to 365
Hi all So I have migrated from Exchange OnPrem to Exchange Online. Before migration I have taken a snapshot from the Exchange server, just in case. Now, there is a user who claims that some of her contacts vanished during the migration. So I booted up the backup Exchange and tried logging into the OWA to see if I can find some cantacts there. However, when trying the OWA, using the localhost url I get redirected to the online Outlook. Obviously the Exchange server recognizes soemwhere in the AD that we have migrated. So my question: How do I access the old information on the OnPrem Exchange Server if I did not think of keeping a backup of the DC?Why do Apple macOS and Ubuntu clients display Exchange meeting times one hour earlier than scheduled
If a meeting is generated from Apple macOS and Ubuntu clients showing the meeting time as one hour earlier than the actual scheduled time email solution is exchange server 2019, what will be the issue.
Teams calendar for exchange on prem users not working
Hello I am having issues to make Exchange On prem users use Calendar on teams. Initially Client autodiscover was blocked externally but they added a cname and open flows but I am still having issues to makecalendar on teams work HCW as passed and new hybrid dedicated app was used any help is welcomeRetirement of Azure Communication Services
Microsoft has announced several retirement and breaking changes in September 2026. One notable change is the retirement of Azure Communication Services as a standalone offering, scheduled to take effect on September 30, 2028. Organizations currently using Azure Communication Services should review the announcement, assess the potential impact on their environments, and begin planning accordingly. https://learn.microsoft.com/en-us/azure/communication-services/acs-retirement-and-breaking-changes-guide
Exchange SE Published Calendar URLs giving HTTP 500 error (both html and ics)
I'm getting an http 500 error when trying to browse any published calendar url. I already recreated the owa virtual directories and just updated to the latest patch level of Exchange Server SE. I did a failed request tracing for error 500 and I see the following info: When I got to that section of the web.config I see the following under rewrite: I tried using AI to "fix" this but it didn't fix anything. Can anyone offer any insite as to what's wrong here? Thanks! p.s. this was getting listed as spam so I will paste the text from the pictures in a reply below
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.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.Microsoft Entra Connect 2.x Version Retirement Reminder
Microsoft is retiring older versions of Microsoft Entra Connect Sync 2.x as part of its version lifecycle policy. Version 2.5.79.0 Retirement date: 23 October 2026 This version will retire 12 months after the release of version 2.5.190.0. Important to know Microsoft Entra Connect Sync 2.x versions retire 12 months after a newer version is released. This retirement policy has been in effect since 15 March 2023. For new installations: Always install the latest available version. For existing environments: Plan your upgrade to the latest version before your currently installed version reaches its retirement date.Outlook - Online mode address book search fails with "Operation failed" when Name only is ticked.
I hope you had this issue and managed to solve 😂 pulling my hair already. Symptom: In classic Outlook for Windows, open the Address Book → set Search to Name only → type any single character → "The address book operation failed." Switch to More columns and the exact same search works fine. Ctrl+K resolution in the To: field works. OWA people search works. Mail flow is fine. It's only the Name-only ANR seek in the dialog. Environment: Exchange hybrid, mailbox in Exchange Online, dir-syncedfrom on-prem AD via Entra Connect Classic Outlook for Windows, online mode (Cached Mode is not permitted here — this is the constraint, I can't just flip it) Affects all users, all machines What I've already ruled out: Test Result Other address lists (Contacts, All Users) Same failure Ctrl+K in To: field Works Safe mode (outlook.exe /safe) Same failure — not add-ins Multiple accounts / multiple machines Same failure Brand-new mail profile Same failure — not profile corruption Addressing order (Tools > Options) GAL set first, not "Choose automatically" Off corporate network (5G) Same failure AddressBookPolicy / OfflineAddressBook on mailbox Both blank (inherit defaults) Get-OfflineAddressBook Default OAB, IsDefault: True, web dist enabled Get-GlobalAddressList Default GAL, IsDefaultGlobalAddressList: True, stock default RecipientFilter
