Add-ins bringen Funktionen direkt ins Outlook: Verschlüsselung wählen, Signaturen einfügen, Phishing melden. Mit Microsoft 365 ist die Bereitstellung ein Klick im Admin Center. Am eigenen Exchange Server scheitern dieselben Add-ins oft schon beim Hochladen. Die Gründe sind technisch klar, und es gibt Wege darum herum.
Drei Grenzen am eigenen Exchange
Das Manifest
Exchange Server SE nimmt nur Add-ins mit XML-Manifest an. Das einheitliche Manifest im JSON-Format gibt es nur für Microsoft 365. Dazu kommt eine Obergrenze: Im Labor nahm Exchange Server SE Manifeste bis zur API-Fassung 1.5 an, höhere Fassungen wies es beim Hochladen ab. Viele Add-ins aus dem Microsoft-Store fordern 1.8 oder mehr.
Die Fassung im Manifest entscheidet nur über die Annahme. Welche Funktionen tatsächlich laufen, entscheidet der Client. Ereignisse beim Verfassen und Senden unterstützt Microsoft mit dem eigenen Exchange in Outlook Classic ab Version 2206.
Die Anmeldung
Die meisten modernen Add-ins melden sich per Single Sign-on an, über ein Token aus Entra ID. Ohne Microsoft 365 gibt es dieses Token nicht. Die älteren Identitätsnachweise, die Exchange selbst ausstellt, hat Microsoft in Exchange Online abgeschaltet. Am eigenen Exchange sind sie weiter verfügbar, aber kaum ein Add-in nutzt sie noch.
Der Client
Das neue Outlook für Windows unterstützt Postfächer auf dem eigenen Exchange nicht. Wer im Haus bleibt, arbeitet mit Outlook Classic und Outlook im Web. Add-ins müssen dort laufen.
Bereitstellen im Exchange Admin Center
Organisationöffnen, dannAdd-Ins.Hinzufügenwählen und als QuelleAus Dateiangeben.- Das Manifest hochladen.
- Für die gesamte Organisation oder ausgewählte Personen aktivieren.
Die Quelle Aus URL setzt voraus, dass der Exchange Server die Adresse selbst abrufen kann. In Umgebungen ohne ausgehenden Internetzugang ist die Datei der verlässliche Weg.
Bereitstellen per PowerShell
New-App -OrganizationApp -FileData ([System.IO.File]::ReadAllBytes("C:\Manifeste\addin.xml")) -DefaultStateForUser Enabled -ProvidedTo Everyone
Get-App -OrganizationApp
Mit -ProvidedTo SpecificUsers und -UserList lässt sich ein Add-in zuerst für eine Pilotgruppe freigeben. Ein Tipp aus dem Labor: New-App braucht eine Sitzung mit echter Anmeldung. Über eine Remotesitzung ohne delegierbares Ticket scheitert der Aufruf mit einer Meldung zur Serialisierung von Tokens.
Typische Fallen
- Zwischenspeicher. Outlook Classic hält Manifeste je Kennung und Version vor. Ein aktualisiertes Manifest mit gleicher Versionsnummer wird ignoriert. Die Version gehört bei jeder Änderung erhöht.
- Verzögerung. Neu bereitgestellte Add-ins erscheinen in Outlook Classic nicht sofort.
- Zertifikat. Die Adressen im Manifest brauchen HTTPS mit einem Zertifikat, dem die Clients vertrauen.
- Laufzeit ohne Browser. Ereignishandler in Outlook Classic laufen in einer JavaScript-Laufzeit ohne
localStorageund ohnelocation. Code, der im Aufgabenbereich funktioniert, scheitert dort still.
Wie Conbool das löst
Conbool erzeugt für jedes Modul ein eigenes Manifest für Exchange Server, abgestimmt auf die Grenzen von Exchange SE. Statt Single Sign-on trägt das Manifest einen Kopplungscode, den das Add-in beim ersten Start gegen einen eigenen Zugang tauscht. Niemand tippt einen Code ein. So laufen SecureMail, Disclaimer, SecureFiles, Archiv und Awareness am eigenen Exchange, aus der Cloud oder im eigenen Rechenzentrum.
Den Überblick gibt die Seite Outlook-Add-ins für Exchange Server, die Schritte stehen in der Doku zu Add-ins am Exchange Server.
