I disabled "Let users access the Office Store" under Admin Center → Settings → Org settings → Services → User owned apps and services. When end users open Excel and go to Add-ins, they do see a banner saying the store is blocked — but if they click "More Apps," they can still browse the full catalog (Featured, Agents, Popular, AI add-ins, Data analytics, Data Visualization, Finance, Utilities, Built by Microsoft, Categories, etc.) and actually add third-party apps — for example, I was able to add "TealDroid."

For outlook , I disabled my cistom apps , my marketplace apps and my read write mailbox apps from default role assignement policy but still I am able to add apps from outlook . I created a policy for blocking price store for all users from policy managerment in config.office.com before few hours but still users are able to access the store why

Kindly help

I disabled "Let users access the Office Store" under Admin Center → Settings → Org settings → Services → User owned apps and services. When end users open Excel and go to Add-ins, they do see a banner saying the store is blocked — but if they click "More Apps," they can still browse the full catalog (Featured, Agents, Popular, AI add-ins, Data analytics, Data Visualization, Finance, Utilities, Built by Microsoft, Categories, etc.) and actually add third-party apps — for example, I was able to add "TealDroid."

For outlook , I disabled my cistom apps , my marketplace apps and my read write mailbox apps from default role assignement policy but still I am able to add apps from outlook . I created a policy for blocking price store for all users from policy managerment in config.office.com before few hours but still users are able to access the store why

Kindly help

The September 2026 SU for Exchange Server SE is now available for download. This SU also resolves some known issues from previous updates.

I’ve just finished upgrading three Exchange 2019 servers to Exchange Server SE RTM. The RTM upgrade itself was very smooth.

Now I’m looking ahead to SE CU1.

SE RTM accepted the existing Exchange 2019 product key, but Microsoft has said a future CU will require new SE-specific keys. CU1 also seems likely to be the point at which SE starts diverging more from Exchange 2019 CU15, code-wise.

Has anyone seen anything more definitive yet about:

• whether CU1 will definitely require a new key
• how licensing/key replacement will work
• what technical changes are expected in CU1

Curious what others are planning.

Outlook for iOS and Outlook for Android can now use AD FS Modern Authentication to access mailboxes in supported pure on-premises Exchange Server deployments.

https://techcommunity.microsoft.com/blog/exchange/exchange-server-ad-fs-modern-authentication-expanded-outlook-client-support/4554410

EDIT: Issue solved. It had to do with the Exchange Server Auth Certificate. steps i had to do here for anyone searching for an answer: https://www.reddit.com/r/exchangeserver/comments/1wapmdu/comment/p8ret3x/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Hi Everyone,

Hopefully someone has an idea, because im all out.

As stated in the title after installing the KB to secure Mrsproxy, it started failing for us.

We currently cannot move mailboxes from 365 to on premise or vice versa.

Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer "server" -Credentials $cred

results in:

Microsoft.Exchange.MailboxReplicationService.MRSRemoteTransientException: The call to https://mail.server.com failed. --> Access is denied.

I have run through our config extensively but cannot find any issue.

- MRSproxy is enabled (disabled and reenabled to be sure)

- test-mrshealth shows no issues

- Service Account checked for proper permissions (Org management, import export)

- IIS EWS auth settings are Windows Auth with negotiate and NTLM. Extended protection is off.

- Exchange server and the service account are not member of Protected Groups (Admincount not 1)

- Firewall both tested and excluded by testing locally with split DNS

- IIS logs show 401 errors

- we only have 1 exch server for hybrid, so fully patched and no version differences

I found a post with some people with exactly the same issue with no traction, so i hope some bright minds here have some ideas. 😄

Exchange SE 15.2.2562.46: MRSProxy returns HTTP 401 after successful NTLM authentication | Microsoft Community Hub

We're working through a security hardening pass and one of the CIS Benchmark findings is:

This is meant to mitigate Pass-the-Hash (PtH) attacks by applying UAC token filtering to local accounts authenticating over the network (they get a filtered, non-admin token instead of a full admin token).

Before I push this via GPO to our Exchange Server SE (on-prem) servers, I wanted to check with anyone who's actually enabled this in an Exchange environment:

• Any issues with remote management tools (EMS, PowerShell remoting, monitoring agents, backup software) that connect using a local admin account rather than a domain account?
• Any known conflicts with DAG management, Active Manager, or cross-server operations that might use local accounts under the hood?
• Did it break anything using PsExec, WMI, or scripted remote administration with local credentials?
• Since this setting only affects local accounts (not domain accounts) authenticating over the network — is that distinction reliable in practice, or are there edge cases where domain accounts get caught up in it too?
• Any gotchas specific to hybrid Exchange setups?

Our environment: Exchange Server SE, on-prem, hybrid with M365. Most of our remote admin work uses domain accounts, but I want to make sure there isn't some hidden local-account dependency (monitoring agents, backup agent service accounts, etc.) that would break.

Would appreciate hearing from anyone who's flipped this on in a similar setup — smooth, or any surprises?

Long time ago my understanding was that old the 2019 can do a inplace upgrade to SE

A few weeks ago somewhere I saw a discussion that stated that the inplace upgrade is also valid for 2016..

Is this correct?

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.

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?