Neues Outlook: Warum Add-Ins fehlen – und wie Sie die Unterstützung prüfen

Warum klassische COM-Add-Ins im neuen Outlook nicht mehr erscheinen

Das neue Outlook (Monarch) lädt keine COM-/VSTO-Add-Ins mehr. Die Anwendung basiert auf der gleichen Webplattform wie Outlook im Web und Outlook für Mac und unterstützt ausschließlich Outlook-Web-Add-Ins auf Basis von Office JavaScript (Office.js). Add-Ins, die in der klassischen Windows-Variante über COM registriert wurden (Registry, MSI, ClickOnce), werden im neuen Outlook nicht erkannt, auch wenn sie korrekt installiert sind.

Unterstützt werden Web-Add-Ins, die über den Microsoft AppSource Store oder per zentraler Bereitstellung im Microsoft 365 Admin Center zugewiesen werden. Diese Add-Ins funktionieren plattformübergreifend (Web, Windows, Mac) und werden in einer isolierten WebView2/Browser-Laufzeit ausgeführt.

Technische Unterschiede im Überblick

So prüfen Admins die Kompatibilität eines Add-Ins

• Herstellerseite/AppSource prüfen: Existiert ein Eintrag als „Outlook-Add-In“ in Microsoft AppSource, handelt es sich um ein Web-Add-In. COM-Add-Ins tauchen dort nicht auf.
• Microsoft 365 Admin Center: Einstellungen > Integrierte Apps. Über „Apps suchen“ nach dem Add-In suchen oder über „Benutzerdefinierte Apps hochladen“ ein Manifest testen. Integrierte Apps listen ausschließlich Web-Add-Ins.
• Praxischeck im Browser: Add-In in Outlook im Web installieren und testen. Läuft es dort, läuft es in der Regel auch im neuen Outlook (gleicher Laufzeitpfad und API-Verhalten).
• Anforderungen und Berechtigungen validieren: Benötigte Office.js-Funktionen (Requirement Sets), SSO/Graph-Aufrufe, Domains/URLs und ggf. Conditional Access prüfen. Netzwerk-Freigaben (Allowlist) für die Add-In-Domains sicherstellen.
• Zuweisung verifizieren: Zielgruppe (Alle, Benutzer, Gruppen) in der zentralen Bereitstellung korrekt zuweisen und Synchronisationszeit beachten.

Hinweis: Es gibt keinen Loader, Shim oder Kompatibilitätsmodus, der COM-/VSTO-Erweiterungen im neuen Outlook aktiviert. Wenn ein benötigtes Add-In nicht als Web-Add-In verfügbar ist, muss der Hersteller eine Office.js-Version bereitstellen.

Typische Auswirkungen in der Praxis

• CRM-Add-Ins, die sich in den Inspector einhängen (z. B. Aktenzeichen, Kontaktanlage), fehlen im neuen Outlook, sofern keine Web-Add-In-Version existiert.
• Archiv-/DMS-Integrationen über COM-Schaltflächen (Ablage, E-Mail-Klassifizierung) erscheinen nicht mehr; stattdessen sind Web-Add-Ins mit Ribbons/Taskpane erforderlich.
• Sicherheits-/Compliance-Add-Ins (z. B. Verschlüsselung, Sensitivity, Disclaimer), die lokal eingreifen, müssen auf serverseitige oder Office.js-basierte Mechanismen umgestellt werden (z. B. On-Send-Events, Exchange-Transportregeln, MIP-Labels).
• Eigenentwicklungen auf VSTO-Basis benötigen eine Neuentwicklung als Office-Add-In mit manifestbasiertem Deployment.

Empfohlene Alternativen und Migrationspfade

• Web-Add-In des Herstellers einsetzen: AppSource-Eintrag oder Manifest vom Anbieter anfordern und zentral bereitstellen.
• Funktionale Lücken über serverseitige Funktionen überbrücken: Exchange-Transportregeln, Journaling, Microsoft Purview (MIP/IRM), DLP und Add-In-Events (z. B. On-Send) nutzen.
• Interne Add-Ins neu implementieren: Office.js nutzen, SSO mit Microsoft Entra ID planen, Backend-APIs über Microsoft Graph anbinden, klare Domänen- und CORS-Strategie definieren.
• Übergangsphase steuern: Für betroffene Arbeitsplätze die Nutzung des klassischen Outlook für Windows weiterhin zulassen, bis Web-Alternativen verfügbar sind. Rollout- und Change-Management entsprechend staffeln.

Schnellcheck in AppSource/Office Store

Web-Add-Ins für Outlook werden über Microsoft AppSource (auch als Office Store sichtbar) bereitgestellt. Die Store-Seite eines Add-Ins zeigt, ob es im neuen Outlook für Windows unterstützt wird.

• AppSource öffnen: appsource.microsoft.com (oder in Outlook auf „Apps“/„Add-Ins abrufen“ klicken).
• Add-In suchen und öffnen.
• Im Abschnitt „Works with“ bzw. „Funktioniert mit“ nachsehen: Es muss explizit „Outlook (Web)“ und „Outlook für Windows (neu)“ bzw. „Outlook on the web“ und „new Outlook for Windows“ enthalten sein.
• Unter „Zusätzliche Informationen“ auf „Anforderungen“/„Requirements“ achten: Outlook-JavaScript-API/Requirement Sets (z. B. Mailbox 1.10+) sollten gelistet sein.
• Wenn ausschließlich „VSTO“/„COM“ oder gar keine Outlook-Web-Unterstützung angegeben ist, ist das Add-In im neuen Outlook nicht lauffähig.

Prüfung und Pilotierung im Microsoft 365 Admin Center

Die zentrale Bereitstellung bestätigt, ob ein Web-Add-In mandantenweit dem neuen Outlook bereitgestellt werden kann und sichtbar wird.

• Als Administrator anmelden unter admin.microsoft.com.
• Zu Einstellungen > Integrierte Apps wechseln.
• „Apps abrufen“ wählen und das gewünschte Add-In aus AppSource hinzufügen, oder „Benutzerdefinierte App hochladen“, wenn ein Manifest (XML) vom Hersteller vorliegt.
• Pilotgruppe zuweisen (Sicherheitsgruppe/M365-Gruppe) und Bereitstellung starten.
• Status überwachen: In der Liste „Integrierte Apps“ muss das Add-In mit „Bereitgestellt“/„Erfolgreich“ erscheinen.
• Überprüfung am Client: Im neuen Outlook für Windows den Store („Apps“), die Symbolleiste oder die Kontextaktionen öffnen. Das Add-In muss dort erscheinen und sich aktivieren lassen.

Fehlt das Add-In trotz erfolgreicher Zuweisung, ist es nicht für Web-Add-Ins bzw. das neue Outlook ausgelegt. Ein weiterer Indikator: Funktioniert das Add-In in Outlook im Web (OWA), funktioniert es in der Regel auch im neuen Outlook, da beide dieselbe Web-Add-In-Plattform nutzen.

Erkennen, ob ein vorhandenes Add-In ein COM-Add-In ist

Viele unternehmenskritische Add-Ins (z. B. CRM-Buttons, Archivierung, DMS-Integration) waren früher als COM/VSTO-Add-Ins implementiert. Die folgende Übersicht hilft, die Technologie eindeutig zu identifizieren.

Wenn ein Add-In ausschließlich als COM-Add-In vorliegt, erscheint es im neuen Outlook nicht. Ein technischer Workaround existiert nicht; nötig ist eine Web-Add-In-Version des Herstellers.

Hersteller-Roadmaps und Nachweise einholen

Ob und wann ein Anbieter eine Web-Add-In-Version liefert, ergibt sich aus dessen Veröffentlichungen. Für die Umstellung sind belastbare Aussagen wichtig.

• Produktseite/Release Notes prüfen: Schlagworte wie „Outlook Web Add-in“, „Supports new Outlook for Windows“, „Office JavaScript API“.
• AppSource-Eintrag des Herstellers vergleichen: „Works with: Outlook on the web, new Outlook for Windows“ muss genannt sein.
• Support-Tickets eröffnen: Konkrete Fragen stellen zu „Unterstützung im neuen Outlook (Monarch)“, Zielversion, Funktionsparität, benötigten Berechtigungen.
• Proof-of-Concept anfordern: Test-Manifest/Preview-Version in einer Pilotgruppe ausrollen und funktional prüfen (Senden/Empfangen, Kontextaktionen, Terminfenster, OWA-Parität).
• Abhängigkeiten klären: Erforderliche Requirement Sets (z. B. Mailbox 1.10/1.12), Berechtigungsumfang („ReadItem“, „ReadWriteMailbox“) und notwendige Exchange Online/Graph-Endpunkte.

Für Archivierungs-, Signatur- oder CRM-Integrationen, die bisher tief in MAPI und lokale Prozesse eingriffen, erfragen, welche Funktionslücken im Web-Add-In bestehen und welche Alternativen der Hersteller nennt (z. B. serverseitige Transportregeln für Signaturen, Graph-basierte Archivierung).

Praktische Prüfpfade im Alltag

• Store-Indikator: Store-Seite zeigt „new Outlook for Windows“ → Kandidat ist kompatibel.
• OWA-Test: Funktioniert das Add-In in Outlook im Web identisch? Dann ist die Chance hoch, dass es im neuen Outlook läuft.
• Admin-Pilot: Zentrale Bereitstellung auf Testgruppe, Sichtprüfung in neuem Outlook, Funktionsfälle abarbeiten.
• Fallback-Erkennung: Erfordert das Add-In lokale Treiber/Dateizugriffe? Das deutet auf COM-Technik hin → nicht kompatibel.

Zwischenlösungen, um Geschäftsprozesse stabil zu halten

Da das neue Outlook für Windows keine COM-/VSTO-Add-Ins lädt, müssen kritische Workloads (CRM-Erfassung, Archivzugriff) kurzfristig abgesichert werden. Folgende Optionen sind sofort umsetzbar:

• Outlook (klassisch) gezielt beibehalten: In verwundbaren Bereichen die Umschaltung verhindern (Cloud Policy oder Registry: UseNewOutlook=0, HideNewOutlookToggle=1) und nur für getestete Pilotgruppen das neue Outlook zulassen.
• Outlook im Web nutzen: Alle Web-Add-Ins funktionieren identisch in Outlook im Web und im neuen Outlook; dort lassen sich CRM- und Archiv-Add-Ins sofort testen.
• Serverseitige Erfassung statt Client-Add-In: Viele CRMs bieten eine persönliche BCC-/Dropbox-Adresse. Per Exchange-Transportregel lässt sich für definierte Absender „Blind copy (Bcc) the message to…“ aktivieren (EAC: Mail flow → Rules), sofern die Compliance dies zulässt.
• Direktzugriff über Webportale: Archiv- oder CRM-Web-UI per PWA (Edge → App installieren) bereitstellen, bis das Web-Add-In des Herstellers vorliegt.

Schritt-für-Schritt: Web‑Add‑In zentral bereitstellen

Die zentrale Bereitstellung funktioniert identisch für Outlook im Web, neues Outlook und weitere unterstützte Clients.

• Kompatibilität prüfen: Hersteller muss ein Outlook Web‑Add‑In (Manifest) für Exchange Online liefern. Ankündigungen wie „Monarch unterstützt“ oder „Outlook on the web kompatibel“ sind gute Indikatoren.
• Pilot auswählen: Kleine Benutzergruppe mit repräsentativen Postfächern (Shared Mailbox, Delegationen, MIP-Labels) definieren.
• Bereitstellen: Microsoft 365 Admin Center → Einstellungen → Integrierte Apps → Apps abrufen (Office Store) oder „Eigene App hochladen“ (Manifest-XML). Nutzer-/Gruppenzuordnung festlegen.
• Berechtigungen bestätigen: Falls das Add‑In Graph/EWS-Berechtigungen anfordert, Freigabe mit Compliance abstimmen.
• Funktionsprüfung: Lesen/Erstellen, Kontextbefehle, eventbasierte Aktionen (z. B. OnSend), SSO und Mobil-Clients testen.
• Rollout staffeln: In Wellen ausrollen, Telemetrie und Supporttickets monitoren.

CRM-spezifische Pfade

Für Dynamics 365 ist die „Dynamics 365 App for Outlook“ das unterstützte Web‑Add‑In. Voraussetzung: Serverseitige Synchronisierung und Aktivierung der App in der Power Platform-Administration. Bei Salesforce ersetzt die Outlook-Integration (Lightning) das alte COM‑Plug‑in; ähnliche Web‑Add‑Ins existieren für HubSpot, Zendesk und andere Anbieter.

Wenn noch kein Web‑Add‑In verfügbar ist, lassen sich E-Mails über folgende Wege ins CRM bringen: serverseitige Regeln im CRM, zentrale Transportregeln für definierte Absender, oder dedizierte BCC-/Dropbox-Adressen. Sensible Datenflüsse sollten vorab datenschutzrechtlich bewertet werden.

Archivierung und Journaling ohne Client‑Add‑In

Outlook‑Add‑Ins sind für rechtssichere Aufbewahrung nicht erforderlich. In Exchange Online stehen serverseitige Mechanismen zur Verfügung:

• Journaling: Weiterhin möglich, um Kopien an ein externes Archiv zu senden.
• Exchange Online Archiving: In-Place-Archiv, inkl. auto-erweiterndem Speicher.
• Aufbewahrungs- und Löschrichtlinien in Microsoft Purview: Steuerung von Lifecycle, eDiscovery und Legal Hold ohne Client‑Komponenten.
• Zugriff: Archivsysteme bieten typischerweise Web‑UIs oder ein eigenes Outlook Web‑Add‑In für Recherche.

Entscheidungsmatrix: Wege aus der Add‑In‑Lücke

Checkliste für Anbietergespräche

• Gibt es ein Outlook Web‑Add‑In mit Manifest für Exchange Online und Unterstützung im neuen Outlook?
• Welche Funktionen werden clientseitig abgebildet (Lesen/Erstellen, Kontextbefehle, Termin‑Integration, OnSend‑Events)?
• Welche Identitäts- und Datenpfade nutzt das Add‑In (SSO, Microsoft Graph, eigene APIs)?
• Wie werden mobile Clients (iOS/Android) unterstützt?
• Welche Migrationswerkzeuge existieren (Datenmapping, Kategorien/Tags, alte Stub‑Objekte)?
• Roadmap und Termine für Funktionsparität zum alten COM‑Add‑In?