Exchange 2016 Hybrid. No on-prem mailboxes. All Business Standard M365 subscriptions.

Just brought up Exchange SE. Has a 180 day trial showing.

Am I correct that we don't have to pay if all of our mailboxes are M365? Do I just let the trial expire and carry on? Or do I need to insert a key from somewhere?

Microsoft Exchange Server Auth Certificate is expiring in 30 days. Are Ali's guide and Microsoft's MonitorExchangeAuthCertificate.ps1 still applicable now that we are using the Dedicated Exchange Hybrid App? Anything additional which needs to be done/run?

I am in a situation where I need to rotate the "Exchange Server Auth Certificate" on an Exchange Server 2016 that is configured in Hybrid.

• I do not have any information / documentation about how the Hybrid was initially configured.
• we do not have any mailboxes in EXO yet.
• We do however already route our MX to EXO and then have emails coming down via a connector to EXCH
• We do have our on-prem Calendars in Teams visible (so I assume it’s a full-classic Hybrid..)

I'm trying to figure out what to choose in the attached image and I’m very concerned about choosing the wrong settings in the rerun and I’m looking for guidance / experience and tips from the community.

PSA: Starting the second week of September 2026, Microsoft will raise the minimum allowed version of Exchange 2016/2019 servers that connect to Exchange Online over an inbound connector type of OnPremises to the October 2025 SU.

I’m unable to permanently untick My Marketplace Apps from the Default Role Assignment Policy from user roles in exchange online
I can uncheck it and successfully save the changes, but when I go back into the policy, My Marketplace Apps is checked again.
Has anyone seen this behavior before? Any idea what could be causing the setting to revert?
I’m trying to prevent users from installing Marketplace/Outlook add-ins themselves.

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!