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!!!
Exchange Online Mailbox cannot see Unsynchronized On-Premises mailbox Free/Busy info and vice versa
Hello Everyone! I originally posted an issue on Microsoft Learn https://learn.microsoft.com/en-us/answers/questions/5651848/free-busy-not-viewable-from-on-premises-mailbox-to?comment=answer-12418292&page=1#comment-2404594 regarding Free/Busy issues with our On Premises Exchange Server which is running the latest version of Exchange SE and Exchange Online which is on our Microsoft 365 Tenant. At first, it would fail the Test-OAuthConnectivity, but that now seems to be fixed with renewing the OAuth Certificate and in addition, enabling the Dedicated Exchange Hybrid App as per https://learn.microsoft.com/en-us/exchange/hybrid-deployment/deploy-dedicated-hybrid-app . On initial deployment, we could not see Free/Busy between EXO and On-Prem Exchange but after 2 hours, it started working but only between On-Premises Synchronized to Microsoft 365 Mailboxes and EXO Mailboxes Our final problem is the viewing of Free/Busy information of On-Premises 'NON-Synchronized to Microsoft 365' mailboxes and EXO Mailboxes. Running the Free/Busy Troubleshooter on ExRCA just gives me a warning during the Determining where the target mailbox is hosted. Also using 'Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/EWS/Exchange.asmx -Mailbox<onpremnonsynchedmailbox>@domain.com -verbose | fl ' on our On-Prem EMS leads to the following error System.Net.WebException: The remote server returned an error: (500) Internal Server Error. at System.Net.HttpWebRequest.GetResponse() at Microsoft.Exchange.Monitoring.TestOAuthConnectivityHelper.SendExchangeOAuthRequest(ADUser user, String orgDomain, Uri targetUri, String& diagnosticMessage, Boolean appOnly, Boolean useCachedToken, Boolean reloadConfig) ResultType : Error Identity : Microsoft.Exchange.Security.OAuth.ValidationResultNodeId IsValid : True ObjectState : New Please advise on how we can fix this error.Removing Retention Holds from Exchange Mailboxes
A new Exchange Online feature allows administrators to remove multiple types of holds from mailboxes (usually inactive mailboxes). It’s a great way to release holds that might be keeping inactive mailboxes lingering in a tenant. The feature doesn’t remove holds used to retain items required for eDiscovery or other compliance purposes. Even so, this is definitely a feature that needs to be carefully tested. https://office365itpros.com/2025/12/18/remove-retention-holds/Older Versions of Exchange ActiveSync Clients Get the Bullet
Exchange Online will require email clients to use Exchange ActiveSync (EAS) V16.1 to connect from March 1, 2026. Email clients that use older versions of EAS won’t be able to synchronize with Exchange Online to upload outbound messages or download messages, attachments, and calendar items. There should be relatively few clients using an old version of EAS, but it’s wise to check. https://office365itpros.com/2025/12/16/exchange-activesync-161/
o365 public folder migration
Hi All, I have began a migration from on-prem exchange 2010 to o365 using minimal hybrid method I need to consider how i'm going to migrate public folders. I refer to two MS docs links below The first article suggests this method should be used when using a cutover or staged method https://docs.microsoft.com/en-us/exchange/collaboration-exo/public-folders/batch-migration-of-legacy-public-folders The second article references a hybrid setup but fails to mention if this includes the minimal hybrid option https://docs.microsoft.com/en-us/exchange/collaboration-exo/public-folders/set-up-legacy-hybrid-public-folders Can anyone clarify? Kind regards
Re-locate ost-files
Hi everybody, we have a customer with a default ost-file location to the Homedrive of the user because they used Citrix in the past and now using AVD. They now want to migrate to OneDrive and disable the homedrive. In that case we want to move the ost-files back to the default location within the profile because now the profile is re-located by fslogix. As far as I know a re-location of existing ost-files is not possible and the only way to change this is to create a new Outlook profile. https://learn.microsoft.com/en-us/outlook/troubleshoot/data-files/cannot-change-the-location-of-ost-file Does anyone have a better idea to solve that issue without less effort? Thanks in advance GuidoExchange 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!
I 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.Scoping application Crestron to access only room mailboxes of resourcetype Workspace
We got a requirement for to enable application Crestron to be able to access Workspace resourcetype Room mailboxes only. So, we thought of directly tieing the application to these mailboxes over the usual way of assigning it to a group because we had to create a group just for to maintain this delegation. Below are the steps we performed: #Create management scope Connect-ExchangeOnline New-ManagementScope -Name "Workspace Mailboxes" ` -RecipientRestrictionFilter "((RecipientTypeDetails -eq 'RoomMailbox') -and (ResourceType -eq 'Workspace'))" #Assign the management scope to Roles New-ManagementRoleAssignment ` -App "<AppID>" ` -Role "Application Calendars.ReadWrite" ` -CustomResourceScope "Workspace Mailboxes" ` -Name "MyApp-WorkspaceOnly" New-ManagementRoleAssignment ` -App "<AppID>" ` -Role "Application MailboxSettings.Read" ` -CustomResourceScope "Workspace Mailboxes" ` -Name "MyApp-WorkspaceOnly-Settings" #Verified the assignment via: Get-ManagementRoleAssignment -App "<AppID>" | ft Name, Role, CustomResourceScope Name Role CustomResourceScope ---- ---- ------------------- MyApp-WorkspaceOnly Application Calendars.ReadWrite Workspace Mailboxes MyApp-WorkspaceOnly-Settings Application MailboxSettings.Read Workspace Mailboxes Tested the scope of the assignment with a non-workspace mailbox and a workspace mailbox, the scope resulted false for non-workspace mailbox and true for a workspace mailbox. Later, admin consented for API permissions Calendars.ReadWrite, Mailboxsettings.Read & User.Read.All and generated an application secret with validity of 180 days to the application team and shared the secret key. ISSUE: When application team tested the access from Crestron application for a workspace mailbox it is resulting in Authentication Failed. This is the actual issue. In order to test whether this is happening because of scope , performed the below steps: $TenantId = "<TenantID>" $AppId = "<AppID>" $ClientSecret = "<ClientSecret>" $Body = @{ grant_type = "client_credentials" client_id = $AppId client_secret = $ClientSecret scope = "https://graph.microsoft.com/.default" } $TokenRequest = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" ` -Method POST -Body $Body $AccessToken = $TokenRequest.access_token $WorkspaceMailbox = "<email address removed for privacy reasons>" Invoke-RestMethod ` -Uri "https://graph.microsoft.com/v1.0/users/$WorkspaceMailbox/events" ` -Headers @{Authorization = "Bearer $AccessToken"} The expected results for this test was to receive Workspace mailbox → Returns events. Non-Workspace mailbox → Should return 403 Forbidden. However, it resulted events in both the cases, when dug further I realised that Graph API will override the management scopes created at Exchange level, so need guidance on how we can take this further.
