Business Standard with Exchange Plan 2 NOW only showing 100GB of email space
FOR THE PAST 3 YEARS, we have 15 users with Microsoft Business Standard with 100GB of email storage space and 11 with Microsoft Business Premium with 100GB of email storage. I have 1 Business Standard with Exchange On-line Plan2, and 1 with Exchange On-line Plan2. Both have always jhad 150GB of usable mailbox storage. Both users for several years, leading up to September 18, 2026 had over 100GB of mail in their mailboxes and had no problems sending or receiving email, ever. THEN ALL OF THE SUDDEN on 9/18/2026, these 2 users with Plan 2 are no longer able to receive any email and it now shows their mailbox is full Even though checking active users details about mail for both of these users shows 150GB storage. In investigating further, in the exchange area of the admin portal, checking mailboxes indeed both of these 2 USERS ONLY SHOW 100GB, which is the exact same as all my other users who are not paying for Exchange PLAN 2. HOW DO I REPORT this to Microsoft?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.
IMAP Mail Migration
Hello Microsoft Community, We are currently performing a mailbox migration from Google Workspace (Gmail) to Microsoft 365 Exchange Online using the IMAP migration method. The customer's environment is configured for split routing/coexistence, where both Google Workspace and Microsoft 365 are actively being used during the migration process. Mail flow is functioning as expected; however, we are experiencing extremely slow migration performance. For example, a mailbox containing approximately 10 GB of data is taking nearly two weeks to migrate, which is significantly impacting the overall project timeline. We would appreciate guidance on the following: Is this migration speed expected when using the IMAP migration method from Google Workspace to Exchange Online? Does Exchange Online enforce any throttling limits that can affect IMAP migration throughput? Can split routing or coexistence between Google Workspace and Microsoft 365 impact IMAP migration performance? Is there a recommended number of concurrent mailbox migrations or migration batch size for optimal performance? Are there any Google Workspace-side limitations, API restrictions, or throttling settings that should be reviewed? What Microsoft-recommended configurations or best practices can help improve IMAP migration speed? If higher migration throughput is required, does Microsoft recommend an alternative migration approach instead of IMAP? If split routing/coexistence must remain active throughout the migration project, what is the recommended Microsoft-supported migration method? We are trying to identify whether the bottleneck is on the Exchange Online side, Google Workspace side, or related to the coexistence configuration. Any troubleshooting guidance, performance recommendations, or Microsoft documentation references would be greatly appreciated.
Outlook Desktop users continually prompted for credentials On-Prem Exchange SE
Battling ongoing issues with users being continually prompted for password using Outlook 2024 LTSC with on-prem Exchange 2019 SE. Removed Windows credentials, turned off cache mode, removed shared calendar(s), outlook connection status seems fine. Only (temp) workaround seems to be removing mail profile and recreating it. All other network resources on domain are fine. Any input appreciated. Thanks
IMAP Migration from Google Workspace to Microsoft 365
Hello Team, Greetings!! We have recently been experiencing significant delays during IMAP migrations from Google Workspace to Microsoft 365 and would like to understand if there are any known issues or recent changes affecting IMAP migration performance. We are aware that Microsoft provides the native Google Workspace migration method, which would generally be preferable. However, in our migration scenarios, we have split routing/coexistence configured, with the domain configured as Internal Relay in Exchange Online. Because of this setup, we are currently unable to select/configure the required target delivery domain as expected during the native Google Workspace migration process. Could you please confirm: Whether there are any known issues, throttling, or performance degradation with IMAP migrations from Google Workspace to Microsoft 365 recently? Whether the Internal Relay/split-routing configuration can affect the native Google Workspace migration process or the availability of the target delivery domain option? Is there any recommended configuration or workaround that would allow us to use the native Google Workspace migration while maintaining split routing? Any guidance or recommended approach would be highly appreciated.
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).Outlook Classic Stamps Its Style on the New Outlook
In an attempt to ease the transition to the new Outlook, Microsoft has introduced the classic Outlook style for the new Outlook and OWA. The style essentially redoes the existing GUI for the web clients to make their appearance very close to the win32 client. After using the two clients side by side for a week, sometimes I find it difficult to know what client I’m interacting with. The question is what average users rather than IT people think of a different face for the new Outlook. https://office365itpros.com/2026/09/07/classic-outlook-style/Exchange Server OWA does not display lnline Images after EEMS M2.1.0 mitigation.
Exchange Server can automatically apply applicable mitigations by using the Exchange Emergency Mitigation Service (EEMS) to retrieve mitigation information from Microsoft's Office Config Service (OCS). EEMS can apply several types of mitigations: 1. IIS URL Rewrite Rule Mitigation: Blocks specific malicious HTTP request patterns that could put an Exchange Server at risk. 2. Exchange Service Mitigation: Disables a vulnerable Exchange service. 3. Application Pool Mitigation: Disables a vulnerable application pool on the Exchange Server. In this case, inline images were displayed correctly in Outlook, but the same images were not displayed in OWA. The issue was identified as being related to the IIS URL Rewrite rule deployed by the M2.1.0 mitigation for CVE-2026-42897. Verification Run the following commands in the Exchange Management Shell. 1. Check the installed Exchange Security Update version (Get-Command ExSetup.exe).FileVersionInfo.ProductVersion 2. Check whether the Emergency Mitigation Service is enabled Get-OrganizationConfig | fl MitigationsEnabled 3. Check applied and blocked mitigations Get-ExchangeServer | fl Name,MitigationsApplied,MitigationsBlocked For example, a server affected by this issue may show: MitigationsApplied : {PING1, M2.1.0} MitigationsBlocked : {M2.1.0} 4. Check the IIS URL Rewrite rule Import-Module WebAdministration Get-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site\owa" -Filter "system.webServer/rewrite/outboundRules/rule" -Name "." | Select-Object name The following rule may be present: EEMS M2.1 OWA CSP - outbound Microsoft provides Security Updates (SUs) to address security vulnerabilities in Exchange Server. Exchange Server SE is currently supported, while Exchange Server 2016 and Exchange Server 2019 can continue to receive applicable security updates through the Extended Security Updates (ESU) program. Note: Exchange Server 2016 and Exchange Server 2019 reached end of support in October 2025. ESU must be purchased separately to continue receiving applicable security updates. Resolution 1. Install the July 2026 SU or later Install the July 2026 SU or a later Security Update (preferably the latest available SU), and then restart the server. Installing the update does not automatically remove the previously applied CVE-2026-42897 mitigation. 2. Block M2.1.0 from being reapplied If M2.1.0 is not already listed under MitigationsBlocked, add it: Set-ExchangeServer -Identity EXSE-01 -MitigationsBlocked @{Add="M2.1.0"} Note: Adding M2.1.0 to MitigationsBlocked does not remove the IIS rules that have already been applied. It prevents EEMS from reapplying the M2.1.0 mitigation. 3. Back up the OWA web.config file Copy-Item ` -Path "$env:ExchangeInstallPath\FrontEnd\HttpProxy\owa\web.config" ` -Destination "$env:ExchangeInstallPath\FrontEnd\HttpProxy\owa\web.config.$((Get-Date).ToString('yyyyMMdd-HHmmss')).bak" 4. Remove the M2.1.0 IIS URL Rewrite rule and precondition Remove-WebConfigurationProperty ` -PSPath "IIS:\Sites\Default Web Site\owa" ` -Filter "system.webServer/rewrite/outboundRules" ` -Name "." ` -AtElement @{name="EEMS M2.1 OWA CSP - outbound"} Then remove the associated precondition: Remove-WebConfigurationProperty ` -PSPath "IIS:\Sites\Default Web Site\owa" ` -Filter "system.webServer/rewrite/outboundRules/preConditions" ` -Name "." ` -AtElement @{name="EEMS M2.1 OWA SPA HTML shell - precondition"} Verification After Rollback Without restarting the Exchange Server or running IISReset, reopen the same OWA message that previously failed to display the inline image and verify that the image is now displayed correctly. Test Results I reproduced the issue in an Exchange Server SE June 2026 SU test environment. After EEMS automatically applied the M2.1.0 mitigation, an inline PNG image that was displayed correctly in Outlook was no longer displayed in OWA. After blocking M2.1.0 and removing the M2.1.0 IIS rules according to Microsoft's rollback guidance, the inline image in the same message was displayed correctly again in OWA. No Exchange Server restart or IISReset was required after removing the IIS rules.The Demise of the OWA Light Client
On July 8, Microsoft said that they will retire the OWA Light client for Exchange Server in August 2026. But what happened to the OWA Light client for Exchange Online? It seems like Microsoft announced the retirement of OWA Light for Exchange Online in June 2024, but didn’t really make the fact clear in a blog post about consumer accounts. In any case, you can’t run OWA Light for Exchange Online, even if you wanted to. https://office365itpros.com/2026/07/17/owa-light-retirement/
