Hi all, Float here from the Exchange Online product team.

We're evaluating the future of three long-standing identifier properties in the Exchange Online directory: Guid (the objectGuid schema attribute), SamAccountName, and DistinguishedName. Several properties can identify the same object today, and we're looking at whether a smaller, more consistent set would be better going forward as we continue to modernize our directory.

No decisions have been made. Before picking a direction we want to know how these are actually used, what a change would break, and what notice period and migration help people would need.

The area we're least sure about is the usage of DistinguishedName in filters that rely on group membership conditions (e.g., to define RBAC management scopes based on group membership). If DN weren't accepted there, we don't know yet what you'd want to use instead.

Scope note: This is for the Exchange Online directory only! Not on-prem AD or Exchange Server.

Survey (~5-10 min): Exchange Online Directory: Identifier Properties Survey – Fill out form

Blog post: Tell us how you use ObjectGuid, SamAccountName, and DistinguishedName in Exchange Online | Microsoft Community Hub

Happy to answer any questions here!

Olá a todos,

Gostaria de perceber se alguém enfrentou este cenário em ambiente empresarial e qual foi a solução adotada.

Temos uma Shared Mailbox utilizada para automação através do Power Automate Cloud.

O problema é que alguns emails chegam protegidos por Microsoft Purview Message Encryption (OME) / Rights Management (IRM). Os utilizadores autorizados conseguem abrir e ler normalmente essas mensagens no Outlook, mas quando o Power Automate utiliza ações como:

* When a new email arrives in a shared mailbox (V2) * Get email (V3)

o campo Body não contém o conteúdo real da mensagem.

Como consequência, torna-se impossível processar o corpo do email através de ações como Html to Text, extração de dados, classificação automática, integração com sistemas externos, etc.

O que me deixa com dúvidas é o seguinte:

* Se a conta utilizada na ligação do Power Automate tem permissões sobre a Shared Mailbox; * E se essa mesma conta ou utilizador consegue visualizar o conteúdo da mensagem no Outlook.

Então, porque é que o conector do Exchange Online não consegue disponibilizar esse conteúdo ao Power Automate? Ok, esta foi a pergunta inicial, porque das leituras feitas percebi que os conectores em causa têm problemas/limitações a lidar com a lidar com o corpo destes emails.

Assim deixo, as minhas perguntas para quem já passou por situação similar:

1. Foi necessário alterar políticas Purview/IRM?
2. Criaram exceções para mailboxes técnicas?
3. Acabaram por recorrer a Graph API, Power Automate Desktop ou outras abordagens/alterativas?

O meu objetivo é perceber quais foram as arquiteturas ou boas práticas adotadas nas vossas organizações para automatizar o processamento para emails protegidos.

Obrigado!

Olá a todos,

Gostaria de perceber se alguém enfrentou este cenário em ambiente empresarial e qual foi a solução adotada.

Temos uma Shared Mailbox utilizada para automação através do Power Automate Cloud.

O problema é que alguns emails chegam protegidos por Microsoft Purview Message Encryption (OME) / Rights Management (IRM). Os utilizadores autorizados conseguem abrir e ler normalmente essas mensagens no Outlook, mas quando o Power Automate utiliza ações como:

* When a new email arrives in a shared mailbox (V2) * Get email (V3)

o campo Body não contém o conteúdo real da mensagem.

Como consequência, torna-se impossível processar o corpo do email através de ações como Html to Text, extração de dados, classificação automática, integração com sistemas externos, etc.

O que me deixa com dúvidas é o seguinte:

* Se a conta utilizada na ligação do Power Automate tem permissões sobre a Shared Mailbox; * E se essa mesma conta ou utilizador consegue visualizar o conteúdo da mensagem no Outlook.

Então, porque é que o conector do Exchange Online não consegue disponibilizar esse conteúdo ao Power Automate? Ok, esta foi a pergunta inicial, porque das leituras feitas percebi que os conectores em causa têm problemas/limitações a lidar com a lidar com o corpo destes emails.

Assim deixo, as minhas perguntas para quem já passou por situação similar:

1. Foi necessário alterar políticas Purview/IRM?
2. Criaram exceções para mailboxes técnicas?
3. Acabaram por recorrer a Graph API, Power Automate Desktop ou outras abordagens/alterativas?

O meu objetivo é perceber quais foram as arquiteturas ou boas práticas adotadas nas vossas organizações para automatizar o processamento para emails protegidos.

Obrigado!

We're working through a CIS Benchmark remediation and one of the findings is:

We're planning to set this to "Authenticated" (not "Authenticated without exceptions" — we're aware that level is much riskier and more likely to break things) on our Exchange Server SE environment.

Before we push this via GPO, I'd like to hear from anyone who has actually applied this in a production Exchange SE (or 2019) environment:

• Did it break Outlook Anywhere / RPC over HTTP for any legacy clients?
• Any issues with MAPI/RPC connections from older Outlook versions?
• Any impact on DAG replication or Active Manager?
• Did it cause problems with Exchange Management Shell / EAC functionality?
• Any unexpected issues with AD communication (since Exchange talks to DCs heavily over RPC)?
• Did you apply it to Domain Controllers as well, or keep DCs and Exchange servers on separate rollout schedules?
• Since Exchange SE is fairly new, has anyone tested this specifically against SE's RPC dependencies, or is it safe to assume behavior is the same as 2019?

Our environment: Exchange Server SE, mostly modern Outlook clients on MAPI/HTTP, not fully certain if any legacy RPC/TCP clients remain in the environment.

Any war stories, gotchas, or "wish I'd known this before enabling it" experiences would be really helpful before we roll this out.

Thanks in advance.

We've migrated an email domain from one M365 tenant to another but an old exists on the 'old' tenant. This app sends messages via a mailbox in the tenant using EXO and M365 mail routing. However, the mailbox sends as a temporary domain (given the real domain is in the new tenant). How can we rewrite the domain on the way out with M365 or relay through an external SaaS solution that would send on the email and rewrite back to the old domain

Suite à la mise en place du SU Exchange KB5121573, que deviennent les boîtes en OWA Light ? Passent-elles automatiquement en OWA normal ?

Merci

I have a client still running Exchange Server 2019 CU12 on-premises.

The server is now flagged as vulnerable to CVE-2026-62911.

I see two options:

1. Upgrade the existing Exchange 2019 CU12 server to the latest CU, then migrate to Exchange SE. This is probably the quickest way to patch Exchange.
2. Build a new Windows Server 2025 VM with Exchange SE and migrate to it.
3. Another option is to move to Exchange Online, but mailbox migration is required too.

I’m leaning toward a new server because the existing Exchange installation is quite old, and we had CU upgrade problems in the past due to AD replication issues.

My main questions are:

• Would you upgrade the existing CU12 server or build a new Exchange SE server?
• How serious do you consider CVE-2026-62911?
• Are there any known real-world incidents or active exploitation so far?

Interested to hear what other on-prem Exchange admins would do.

New m365 & created new distributed group. Group can receive mail within organization but not outside. Any leads pls
Thx

Spent some time trying digging around in MFCMAPI trying to rename the folder. That didn't work, but persistence did eventually pay off.

Have anyone dealt with Power Bi Data Refresh first party apps? I’ve added the appID to the EWS allow list but I need to locate the owner of these connections to have them move to Graph. Interesting that Microsoft is not able to help. They weren’t even familiar with this deprecation.

Is there are way through the power BI portal to find these connections and the owners?

Anyone managed to fix the Exclaimer signature de-dupe/clobbering issue in Outlook?

Example:
We have a signature in Exclaimer that says "mycompany.com - Senior IT Engineer".

Our end-user has copied the full signature from an email they sent and have set a custom signature in Outlook to say "mycompany.com - Master of the Universe".

When that end-user sends an email, the ONLY signature that is being applied is the "mycompany.com - Master of the Universe".

We are not getting a duplicate where both the "mycompany.com - Master of the Universe" AND the "mycompany.com - Senior IT Process Engineer" signature is being applied. The end-user's custom Outlook signature is clobbering the Exclaimer signature entirely.

The solution we need:
-Signature IS NOT clobbered. User's email shows a double-signature. The Exclaimer one and their custom one. We are aware that this will look silly but we've accepted that risk.
-Signature IS clobbered but instead of the custom Outlook signature winning the conflict, the Exclaimer signature wins the conflict.

Question for other IT admins. who actually owns email signatures where you work? IT? Marketing HR? Nobody?

We keep bouncing between departments because everyone has a reason why it belongs somewhere else. curious how other companies deal with ownership.

Hi All,

Does anyone know how we update the routing address in Exchange Hybrid?

We have added a new onmicrosoft address to Office 365 as part of a rebrand and we now want to use this as our routing address but I can't get it to work.

I have tried running the HCW again but doesn't help.

If I do set the new address as the routing address for a user the new address never syncs as alias via cloud sync to Office 365.

Thanks

migrations to 365 failing with timeout to mrsproxy.svc

This obviously has worked for years, but recently has stopped. The strange thing is that test-migrationserverability passes.

I've re-run HCW, verified everything I can think of including making sure both servers in this DAG are up to date as of last night, and rebooting both.

Also, when I run:

Invoke-WebRequest -Uri "https://localhost/EWS/mrsproxy.svc" -UseBasicParsing

I get:

Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

However, the certs are all valid, everything else seems normal on that front. proper tls versions are enabled, I've verified everything I can think of there and not sure what I'm missing.

I'm sorry I can't list off everything I've tried. I've worked on this for about 20 hours so far and honestly can't remember it all.

Any help would be super appreciated.

have an exchange 2016 environment, cu23. when i run the HCW, it fails both using classic and modern with HCW8125 set-authserver failed. i've checked all of the settings for EWS, OAB, autodiscover and everything comes up correct. if i try and run the set-authserver command via powershell, it fails with an LDAP error. An Active Directory error 0x51 occurred when trying to check the suitability of server 'xxx.com'. Error: 'Active directory response: The LDAP server is unavailable.' if I try an LDAP query to the domain, it works on both 389 and 3268.

Any ideas? This is baffling me.

Thanks!

Hi everyone,

I’m reviewing an Active Directory environment where Exchange Trusted Subsystem appears to have the Reanimate-Tombstones extended right.

I understand that this permission allows a principal to reanimate deleted/tombstoned AD objects, so I’m trying to understand whether this permission is expected for Exchange.

• Is it normal for Exchange Trusted Subsystem to have this permission?
• Is it required for any Exchange functionality?
• If it is not required, is removing the permission considered safe?
• Are there any Exchange operations or features that could break if this permission is removed?
• Has anyone encountered this permission on Exchange environments before?

I’m mainly looking for guidance on whether this is legitimate Exchange delegation or an unnecessary permission that should be removed.

Exchange like all email mail transfer agents, depends on solid DNS lookups. It can be scotched with the AD domain controller DNS server being setup with problems.

And one of the bigger problems out there with setting up nameservers is setting them up on Internet connections to ISP's that transparently intercept DNS. This completely screws over resolving nameservers that are expecting to be able to query the actual root nameservers not have their queries transparently intercepted and returned by an unknown possibly rogue DNS proxy their ISP has setup.

Run my dns-proxy test script located here:

tmittelstaedt/DNS-Testing-Tools: DNS Testing tools for Windows 10/11 etc.

it is a test harness for the ISC's "dig" program. (dig for Windows is available from the ISC) It runs 10 different tests designed to discover if your ISP is messing about with your DNS queries. It can also run these on a remote Linux server outside of the blast zone if you are lucky enough to have ssh credentials on one so you can see what "normal" untampered output is supposed to look like. There are also some other scripts there of interest including a few that build the raw DNS query packet and send it out via raw sockets because Microsoft does not support all DNS queries in the powershell DNS library. Enjoy!

This week a user did notify me that their published calendar via ICS link can't get synchronized to their Google calendar for a while. Looking at the logs I can see that it didn't worked since mid May, around the time when the mitigations for CVE-2026-42897 were applied.

After some debugging I could pin the problem to the User Agent when opening the ICS link. When I open the link with a browser every thing works just fine. When Google tries to use the ICS link it triggers a HTTP 500 error and an ASP.NET Event that OWA is not supported for the browser. I can also replicate the problem with curl and submitting different User Agents with the -A parameter.

curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:154.0) Gecko/20100101 Firefox/154.0" https://exchangeserver.com/owa/calendar/..../calendar.ics

works fine and returns the ICS file. While...

curl -A "Google-Calendar-Importer" https://exchangeserver.com/owa/calendar/..../calendar.ics 

gets redirected to the HTTP 500 error page. The reachcalendar.ics alternative also fails with the same error. I also tried to add the ICS link as a calendar to an Exchange Online mailbox and even the User Agent of the Exchange server fails with a HTTP 500 error.

I already double checked the web.config for the CVE-2026-42897 mitigations and also made sure that no IIS URL Rewrite rules are present. Also the Exchange server did get rebooted a couple of times since the mitigations got removed.

Anybody else can replicate that problem on a Exchange SE with the latest August SU? Or does anybody know another place where to look to allow the User Agents again?

Edit: It's now an official know issue but also has a workaround:

After the August 2026 SU is installed, subscriptions to an anonymously published Exchange calendar stop refreshing. The subscribing application reports a server error, and the URL returns HTTP 500. Opening the same published calendar URL in a web browser works normally and returns the calendar. As a workaround, you can add “?layout=premium” to the .ics link when subscribing (so the end of the URL would look like “calendar.ics?layout=premium”).

https://techcommunity.microsoft.com/blog/exchange/released-august-2026-exchange-server-security-updates/4543951

Chrome is forcing changes to public certs, so they can only be used for ServerAuth, not ClientAuth:

https://www.reddit.com/r/selfhosted/comments/1mt9ovs/lets_encrypt_certificates_will_no_longer_be/

https://www.actalis.com/news/ssl-communications/client-authentication-public-ssl-certificates-what-changes-in-2026

https://www.godaddy.com/help/why-is-godaddy-removing-clientauth-eku-and-transitioning-to-the-r1-root-hierarchy-for-dv-tls-issuance-42783

Does this impact mailflow from local EX to cloud EXO? I just replaced a cert, and now local-to-cloud email is stalling with 454 4.7.5 The certificate specified in TlsCertificateName of the SendConnector could not be found

The blogpost here doesn't directly address how this works, but when discussing inbound STARTTLS, it says that the cert is selected automatically, so presumably it's checking for a cert with ClientAuth. In the comments of that blogpost, someone asked about this issue, but got no response.

Everyone's answer to removing ClientAuth is so far "you should have been using a private CA anyway, just do that", but surely MS actually validates the cert chain, since I can't tell them what CA or cert thumbprint to trust?

Do we have to fallback to having the cloud connector check by IP address? I can't find anyone else addressing this issue, so maybe I'm barking up the wrong tree.

Edit: As commenters suggested, my issue was because the outbound connector is looking for a specific Issuer and Subject. My CA changed their intermediate issuer for the first time in a long time, and I've never run into this before. I was able to check this with Get-SendConnector Outbound* | fl, and after some careful string editing, set it with Get-SendConnector Outbound* | Set-SendConnector -TlsCertificateName $certstring (note I only have one matching connector, so a wildcard was fine). So, apparently the answer is no, Hybrid mailflow does not need the ClientAuth part of the cert. (But then how the heck is it doing some kind of client auth? Do EX and EXO collaborate to break the rules of TLS somehow? Maybe it's a special STARTTLS thing? Oh well...)

OOF not working internally but working externally, have hybrid setup but mailbox on cloud only. Wondering if someone can help.

No oof msg template corruption, already checked.

Tia.

Got a bit of a weird Exchange Online archiving issue and wondering if anyone has seen similar. This is a hybrid Exchange environment with on-prem AD/Exchange and the mailbox hosted in Exchange Online.
 
User has a pretty large primary mailbox around 85GB and Online Archive is enabled, but the archive is basically empty.
 
Things I've checked:
 
ArchiveStatus = Active
 
Default MRM Policy assigned
 
Default 2 year move to archive enabled
 
RetentionAction = MoveToArchive
 
AgeLimitForRetention = 730 days
 
RetentionHoldEnabled = False
 
ElcProcessingDisabled = False
 
No obvious holds
 
No folder-level archive policy overrides
 
I pulled the mailbox diagnostics as well. MFA/ELC seems to be running successfully, but the latest run shows:
 
ElcLastRunArchivedFromRootItemCount = 0
 
ElcLastRunTaggedWithArchiveItemCount = 0
 
For comparison, I checked another mailbox in the same tenant using the exact same Default MRM Policy. MFA is actively moving eligible items into that user's Online Archive, so the policy itself seems to be working.
 
Manual moves from the affected mailbox into Online Archive also work fine.
 
It looks like MFA is processing the affected mailbox but, for whatever reason, isn't finding anything eligible for the 2-year archive rule.
 
Anyone come across this before?
 
Is there anything else worth checking to understand why the items aren't being considered eligible?