Forum Widgets
Latest Discussions
EWS Autodiscover Process in Hybrid with "internal" Exchange Servers
Hi everyone, i really need help about the EWS Autodiscover process in a specific hybrid Environment. Customer is starting to use Exchange Online. For Full Hybrid configuration there is a seperate new Exchange SE with a valid certificate, NAT for IP Ranges from M365 and public available URLs for Autodiscover,EWS,... There are internal Exchange Servers which are used only for internal access. Those are the servers with all mailboxes. All URLs are configured for internal use (mail.contoso.internal) Migration is working, access to own calender is working, mailfllow is working. But there are problems to access other users calender. If a user which is migrated to Exchange Online (or via Teams) try to access another calender which is onPrem, there is no access. So i tried to use connectivity analyzer for teams integration to find out whats the problem. Result: Autodiscover resolves, connects to Hybrid and gets EWS URL as answer. But it gets the internal EWS URL from the internal Exchange Servers, not from the public available URLs which are configured at the hybrid server. I visualised the two scenarios. Number1: Thats how i thought it would work Autodiscover to autodiscover.contoso.com Hybrid answers with EWS URL: hybrid.contoso.com Connect from EXO to hybrid EWS URL Proxy to Internal Exchange Number2 : Thats what really happens Autodiscover to autodiscover.contoso.com Hybrid relays request to internal Exchange (Mailbox Server) Server answers with internal EWS URL: mail.contoso.internal Connect from EXO to internal EWS URL (which is obviously not working) So as you can see, the autodiscover process asks the internal Exchange for its EWS URLs and not as i expected the hybrid server's URLs. I always thought, the hybrid server works as a sort of proxy for every external connection from EXO. But it seems that the hybrid just relays the autodiscover request to the server which holds the mailbox. And this servers in this scenario cannot change their EWS URLs to a public resolvable FQDN. So my question is: Is this correct? Does the process always works like this or did i do anything wrong in the configuration? I hope you understand my explanation. Thanks in advance!!!
Remove Classic EAC Organization Add-ins?
Hello, Does anyone know how to remove the organization add-ins that were deployed with the Classic Exchange Admin Center? Now that the "classic view" is no longer accessible, our tenant shows a 400 Bad Request error when trying to go to "https://outlook.office.com/ecp/". This org add-in is pushed to all mailboxes by "organization administrators", and as far as I can tell, there isn't a way to remove the add-in. This legacy add-ins are not visible in the new "Integrated Apps" in O365. I contacted Microsoft Support but the support agent got to the point where he was having me run PowerShell commands to check the registry to see if it was "installed as a program on my computer", and that's when I knew he had exhausted his support resources. I can see the app if I execute: Connect-ExchangeOnline as a Global Admin & Tenant Admin (Exchange Online Role) and then run the Get-App | select DisplayName, AppID cmdlet. If I try to remove it Remove-App -Identity <AppID>, then I see a: Write-ErrorMessage : |Microsoft.Exchange.Data.ApplicationLogic.Extension.OwaExtensionOperationException|The app "Alert" is managed by organization administrators and can't be uninstalled by end users. If I check the Exchange Online roles, I am in the TenantAdmins_3744d role, which states that "it will be a member of the Organization Management role group and will inherit the capabilities of that role group". So far I have no way to remove this old add-in which normally was installed/uninstalled through Organization > Add-Ins in the Classic (Legacy) Exchange Admin Center.
Exchange 2016 Mail Flow is Not Working
We had issues with updating to a latest Cumulative Update and messed up our EMS and some Web Config. It seems our Exchange Server is totally bricked. So, we decided to boot our Exchange Server from backup. The backup was dated September 2025. Unfortunately, after booting up the September 2025 backup, we noticed that the internal and external mail flow is not working (our Exchange 2016 is Exchange hybrid configured). The outgoing emails are stuck in Draft folder. The following troubleshooting steps have been done to no avail: -Checked if the port 25 is open -> This port is opened -Check the network settings if the Preferred DNS Address points to the correct DNS Server --> It points to the correct DNS Server -Modified the DNS lookup under Exchange Admin Center > Servers > DNS Lookups > Internal DNS Lookups --> Added the IP Address of the DNS Server -Modified the hosts file under System32 > drivers > etc --> Pointed the IP Address of the Exchange Server to the FQDN of the Exchange Server Currently, are not sure of the next steps to do in order to fix the issue. Any advice?
Exchange SE and Domain / Forest Functional Level 2025 Support
Does anyone have any general idea on when they may test support for Domain / Forest Functional Level 2025? We're still rocking hybrid with Exchange SE and ExO and as such we're waiting on the supportability matrix (https://learn.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix#supported-active-directory-environments) to get updated so we can raise the DFL/FFL. Currently Exchange SE supports 2025 AD servers so they've verified the schema update from 88 to 91 is good to go but our Exchange team doesn't want us to raise the functional level until this matrix shows that it's supported for our current Exchange version. Thanks for any insight. Supported Active Directory environments The following table lists the supported Active Directory environments for Exchange Server. Version Active Directory servers Forest Functional Levels Exchange Server SE Windows Server 2025 Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2016 Windows SI am receiving DMARC errors
Hello Please i need your help on this issue. Last night I started receiving DMARC and other errors when trying to send emails. I dont believe my business email is receiving messages either. Please help me 'fix' resolve these bounce back errors. I did try to find the solution on my own,, but its just out of my wheelhouse. Please help as my business is being affected by these errors and bounce backs.
Configure Dedicated Exchange Server Application
Currently our product ranning exchange 2019 CU15 with Exchange hybrid, so what else need configure other task for configuration of the dedicated application for Exchange Server. HCW8126 - Admin consent was not granted during the configuration of the dedicated application for Exchange Server. The application will be created but will not function until consent is provided. Please re-run the Hybrid Configuration Wizard (HCW) or grant consent via the Entra ID portal before using the application.We have set RejectDirectSend to true
Hello Please i need your help on this issue. We have set RejectDirectSend to true, but it is still possible to send mail anonymously through tenant Last Friday 3 oct 2025 we configured the tenant not to allow DirectSend from anonymous sources by setting the RejectDirectSend value to true using Powershell command. When we check the status with the Get-command it looks like it is set but it is not working - it is still possible to spoof emails by sending through the mx record as anonymous.Exchange database dismounted due to NTFS file extent limit reached – unexpected outage
Hi everyone, We experienced a serious outage on our Exchange 2016 server recently, and I wanted to share what we found during the root cause analysis – in case it helps someone else avoid the same scenario. Summary: After digging deep, we discovered that the issue was caused by the NTFS file system hitting its internal file extent limit on the .edb file. Once this threshold was reached, the database could no longer grow, and the system dismounted the database unexpectedly. No prior warning, just service interruption. Details: The .edb was around 1.2 TB in size. This isn’t a limit on database size itself — it’s about how fragmented the file is on disk. Once NTFS couldn’t track any more extents, the database stopped working. Microsoft doesn’t publish a clear fix for this; only scattered references to similar behavior in past cases. What we did: Created a fresh, clean database. Manually moved user mailboxes into the new DB. The old database couldn't be mounted anymore, so we brought the system live without historical mail – just to maintain continuity. We're now working on extracting data from the unmounted .edb using third-party tools. Looking for thoughts: Has anyone else hit the NTFS extent wall with Exchange? How do you monitor extent growth proactively? Did switching to ReFS solve this for you long-term? Open to any input or similar experiences – appreciate it in advance. Thanks!
