Does the new Outlook support mailboxes on your own Exchange?

No. The new Outlook for Windows does not support mailboxes on in-house Exchange Server. Add-ins on your own Exchange run in Outlook classic and Outlook on the web.

Why can a store add-in not be uploaded?

Exchange Server SE only accepts manifests up to API version 1.5. Many store manifests ask for more. On top of that, many add-ins sign in through Entra ID, which is not possible without Microsoft 365.

How do you deploy an add-in with PowerShell?

With New-App and the OrganizationApp parameter in the Exchange Management Shell. The manifest is passed as a file, and the default state for users decides whether the add-in is switched on.

Deploy an Outlook add-in on Exchange Server: limits and paths

Add-ins bring features straight into Outlook: choose encryption, insert signatures, report phishing. With Microsoft 365, deployment is one click in the admin center. On your own Exchange Server the same add-ins often fail at upload. The reasons are clearly technical, and there are ways around them.

Three limits on your own Exchange

The manifest

Exchange Server SE only accepts add-ins with an XML manifest. The unified JSON manifest exists only for Microsoft 365. There is also a ceiling: in our lab, Exchange Server SE accepted manifests up to API version 1.5 and rejected higher versions at upload. Many add-ins from the Microsoft store ask for 1.8 or more.

The version in the manifest only decides acceptance. Which features actually run is up to the client. Microsoft supports compose and send events with your own Exchange in Outlook classic from version 2206.

Most modern add-ins use single sign-on with a token from Entra ID. Without Microsoft 365 there is no such token. The older identity tokens that Exchange issues itself have been switched off by Microsoft in Exchange Online. They are still available on your own Exchange, but hardly any add-in uses them anymore.

The client

The new Outlook for Windows does not support mailboxes on your own Exchange. If you stay in-house, you work with Outlook classic and Outlook on the web. Add-ins have to run there.

Deploying in the Exchange admin center

Open Organization, then Add-ins.
Choose add and select From file as the source.
Upload the manifest.
Enable it for the whole organisation or for selected people.

The From URL source requires the Exchange Server to fetch the address itself. In environments without outbound internet access, the file is the reliable path.

Deploying with PowerShell

New-App -OrganizationApp -FileData ([System.IO.File]::ReadAllBytes("C:\Manifests\addin.xml")) -DefaultStateForUser Enabled -ProvidedTo Everyone
Get-App -OrganizationApp

With -ProvidedTo SpecificUsers and -UserList an add-in can be released to a pilot group first. A tip from the lab: New-App needs a session with a real sign-in. Over a remote session without a delegable ticket the call fails with a message about serializing tokens.

Typical traps

Cache. Outlook classic keeps manifests per ID and version. An updated manifest with the same version number is ignored. Increase the version on every change.
Delay. Newly deployed add-ins do not show up in Outlook classic right away.
Certificate. The addresses in the manifest need HTTPS with a certificate the clients trust.
Runtime without a browser. Event handlers in Outlook classic run in a JavaScript runtime without localStorage and without location. Code that works in the task pane fails there silently.

How Conbool solves it

Conbool generates a dedicated manifest per module for Exchange Server, tuned to the limits of Exchange SE. Instead of single sign-on, the manifest carries a pairing code that the add-in exchanges for its own access on first launch. Nobody types a code. That is how SecureMail, Disclaimer, SecureFiles, Archive and Awareness run on your own Exchange, from the cloud or in your own data centre.

The overview is on Outlook add-ins for Exchange Server, the steps are in the documentation on add-ins on Exchange Server.