Neues Outlook: Warum COM-Add-Ins nicht mehr laden und welche Web-Add-Ins funktionieren

Architektur: In-Prozess vs. Web-Laufzeit

COM-Add-Ins laufen klassisch als In-Prozess-Erweiterungen in Outlook.exe (oder als VSTO in .NET). Sie werden über die Windows-Registry registriert und durch Outlook beim Start geladen. Das neue Outlook (Monarch) ist eine moderne, webbasierte App und lädt keine In-Prozess-Komponenten mehr. Es unterstützt ausschließlich Office-Web-Add-Ins, die mit HTML/JavaScript in einer isolierten Web-Laufzeit (unter Windows über Edge WebView2, auf anderen Plattformen in der jeweiligen Web-Engine) ausgeführt werden.

Die Kommunikation mit Outlook erfolgt bei Web-Add-Ins über die Office JavaScript API (Office.js) und Add-in Commands (Schaltflächen in der Oberfläche). Die Logik kann lokal im Add-In-Webcontainer oder serverseitig gehostet werden. Dadurch sind Web-Add-Ins plattformübergreifend: dieselbe Erweiterung kann im neuen Outlook für Windows, Outlook im Web, Outlook für Mac und Outlook Mobile (mit unterstützten Szenarien) erscheinen.

Sicherheit: Berechtigungen, Isolation und Compliance

COM-Add-Ins laufen mit weitreichenden Rechten: Zugriff auf Dateisystem, Registrierung und alle Outlook-Objekte. Fehlerhafte oder schlecht programmierte Add-Ins konnten das Startverhalten verlangsamen oder Abstürze auslösen. Härtung erfolgte u. a. über Code-Signaturen, Vertrauensstellungs-Policies und das Blockieren langsamer Add-Ins.

Web-Add-Ins deklarieren Berechtigungen im Manifest. Outlook zeigt nur die erlaubten Operationen an; höhere Berechtigungen wie ReadWriteMailbox bedürfen administrativer Zustimmung und werden auditierbar bereitgestellt. Die Ausführung ist von Outlook isoliert, HTTPs-gesichert und folgt den Mandantenrichtlinien, etwa Modern Authentication und Conditional Access. Datenflüsse zu Anbieterdiensten lassen sich über Firewall/Proxy und Zulassungslisten kontrollieren.

• Geringere Angriffsfläche durch Sandboxing
• Feingranulare Berechtigungen statt Vollzugriff
• Zentrale Kontrolle und Audit durch Administratoren

Bereitstellung und Verwaltung: so wird kompatibel ausgerollt

Web-Add-Ins werden nicht lokal installiert, sondern dem Postfach bzw. Benutzer zugewiesen. Damit erscheinen sie konsistent in allen unterstützten Outlook-Clients, inklusive dem neuen Outlook. Das vermeidet Client-Drift und vereinfacht Updates.

Vorgehensweise für Administratoren:

• Kompatibilität prüfen: In Microsoft AppSource nach dem Add-In suchen und die Produktseite auf „Outlook“ und „Web-Add-In“ prüfen. Alternativ beim Hersteller nach der Office-Web-Add-In-Version fragen.
• Zentrales Deployment: Im Microsoft 365 Admin Center > Einstellungen > Integrierte Apps die gewünschte Lösung hinzufügen (aus AppSource oder per Manifest-Upload) und Benutzer/Gruppen zuweisen.
• Steuerung der Sichtbarkeit: Add-in Commands optional anheften, um Schaltflächen in Lesebereich/Verfassenfenster standardmäßig einzublenden.
• Überwachung: Funktionsumfang, Berechtigungen und Nutzungsberichte regelmäßig kontrollieren; Updates vom Anbieter werden ohne Client-Rollout wirksam.

Folgen für bestehende Lösungen und typische Szenarien

Viele unternehmenskritische COM-Add-Ins – etwa CRM-Integrationen, E-Mail-Archivierung, DLP-Workflows oder Aktenpläne – erscheinen im neuen Outlook nicht, weil die zugrundeliegende COM-Technologie nicht mehr geladen wird. Es existiert kein Kompatibilitätsmodus und keine technische Brücke, die COM-Add-Ins im neuen Outlook aktivieren könnte. Hersteller müssen eine Web-Add-In-Variante bereitstellen.

Praktische Prüfschritte für Fachbereiche:

• Liste der bisher genutzten Add-Ins erstellen (Name, Hersteller, Version, Funktionszweck).
• Auf Herstellerseiten nach „Office Add-in“ bzw. „Outlook Web Add-in“ suchen und Funktionsparität bewerten.
• Im Piloten testen: Add-In zentral zuweisen und in neuen Outlook-Szenarien (Lesen, Verfassen, Termine, Anhänge) nachvollziehen, ob Prozesse abgedeckt sind.
• Fehlende Funktionen dokumentieren und beim Anbieter als Anforderung platzieren; Übergangslösungen nur mit Web-Add-Ins planen.

Schritt 1: Verfügbarkeit im Office Store/AppSource prüfen

Nur Web-Add-Ins werden im neuen Outlook geladen. Die erste Prüfung ist daher die Store-Liste: Gibt es das gewünschte Add-In als Office-Web-Add-In und ist der Client „Outlook“ (einschließlich neues Outlook für Windows) explizit unterstützt?

• Öffnen Sie in Outlook die Schaltfläche „Add-Ins abrufen“ (Start-Menüband) oder rufen Sie appsource.microsoft.com auf.
• Suchen Sie das Add-In nach Namen oder Hersteller.
• Öffnen Sie den Eintrag und prüfen Sie den Bereich „Works with“ bzw. „Unterstützte Produkte/Clients“. Erwartet: „Outlook“ inklusive „Outlook im Web“ und „neues Outlook für Windows“.
• Prüfen Sie in der Beschreibung die „Client and platform requirements“ bzw. „Erforderliche Berechtigungssätze/Requirement Sets“ und „Exchange Online“ als Ziel. Web-Add-Ins, die nur lokale Exchange-Server adressieren, erscheinen nicht im neuen Outlook.
• Fehlt der Client „Outlook“ oder steht dort kein Hinweis auf das neue Outlook/Outlook im Web, ist das Add-In nicht kompatibel.

Viele Hersteller hinterlegen zusätzlich einen Link zu ihrer Roadmap oder einem Hinweis „Supported in new Outlook“. Fehlt ein solcher Hinweis, sollte die Kompatibilität beim Hersteller verifiziert werden.

Schritt 2: Zentrale Bereitstellung im Microsoft 365 Admin Center prüfen

Die zentrale Bereitstellung zeigt zuverlässig, ob ein Add-In als Web-Add-In für Outlook mandantenweit verfügbar ist. COM/VSTO-Add-Ins tauchen hier nicht auf.

• Öffnen Sie admin.microsoft.com > Einstellungen > Integrierte Apps.
• Wählen Sie „Add-Ins“ und suchen Sie das gewünschte Add-In.
• Öffnen Sie den Eintrag. Erwartet: Typ „Office-Add-In“, verfügbare App „Outlook“ und Bereitstellungsoptionen für Benutzer/Gruppen.
• Führen Sie einen Pilot aus: „Bereitstellen“ > Zielgruppe (z. B. Sicherheitsgruppe „Outlook-Addin-Pilot“) > Bestätigen.
• Kontrollieren Sie nach der Bereitstellung unter „Integrierte Apps“ den Status. Der Eintrag muss aktiv sein und der Zielgruppe zugeordnet.

Hinweis: Zentrale Bereitstellung setzt Exchange Online-Postfächer voraus. Für lokale Exchange-Postfächer erscheint das Add-In im neuen Outlook nicht.

Schnellcheck: Kriterien und Erwartungswerte

Schritt 3: Funktion im neuen Outlook testen

Nach der zentralen Zuweisung lässt sich die tatsächliche Sichtbarkeit und Funktionsfähigkeit direkt im Client prüfen.

• Starten Sie das neue Outlook und melden Sie sich mit einem betroffenen Pilotkonto an.
• Öffnen Sie „Add-Ins abrufen“ und wählen Sie „Meine Add-Ins“. Das zentral bereitgestellte Add-In muss hier gelistet sein.
• Öffnen Sie eine Nachricht. Je nach Add-In erscheint eine Schaltfläche im Lesebereich, im Kontextmenü oder in der Multifunktionsleiste.
• Testen Sie Kernfunktionen (z. B. CRM-Verknüpfung, Ticketanlage, Archivierung) in einer realen Nachricht.
• Falls das Add-In in Outlook nicht erscheint, öffnen Sie parallel Outlook im Web. Funktioniert es dort, aber nicht im neuen Outlook, fehlt häufig die Client-Freigabe des Herstellers für das neue Outlook.

Zwischen Bereitstellung und Sichtbarkeit kann es zu Verzögerungen kommen. Ein Neustart von Outlook oder erneutes Anmelden beschleunigt die Aktualisierung der Add-In-Liste.

Typische Ursachen, wenn das Add-In nicht erscheint

• Es handelt sich um ein klassisches COM/VSTO-Add-In; diese werden im neuen Outlook nicht geladen.
• Keine zentrale Bereitstellung oder falsche Zielgruppe im Admin Center.
• Mailbox liegt nicht in Exchange Online; zentrale Web-Add-Ins greifen nicht.
• AppSource-Eintrag unterstützt das neue Outlook noch nicht oder der Hersteller hat die Client-Freigabe nicht veröffentlicht.
• Erforderliche Berechtigungen/Scopes wurden abgelehnt oder benötigen Admin-Consent (bei Add-Ins mit verbundenem Dienst).

Steuerbarer Übergang: Klassisches Outlook weiter nutzen

Solange geschäftskritische COM-/VSTO-Add-Ins gebraucht werden, bleibt das klassische Outlook für Windows die stabile Option. Microsoft unterstützt es weiterhin im Rahmen von Microsoft 365 Apps; das neue Outlook lädt keine COM-Add-Ins. Die Umschaltmöglichkeit zum neuen Outlook lässt sich zentral steuern.

• Add-Ins inventarisieren: Welche COM-Add-Ins sind produktionskritisch (CRM, DMS, Archiv, Signaturen, Verschlüsselung)?
• Risikogruppen definieren: Benutzergruppen mit kritischen Add-Ins vom Wechsel ausnehmen.
• Umschalten unterbinden: Per Cloud Policy Service oder Gruppenrichtlinien die Option zum neuen Outlook ausblenden und den Wechsel blockieren.
• Update-Kanal wählen: Semi-Annual Enterprise Channel für betroffene Geräte nutzen, um Planbarkeit zu sichern.
• Pilotgruppen: Kleine Pilotkohorten ohne kritische COM-Add-Ins schrittweise ins neue Outlook migrieren.

Vendor-Roadmaps systematisch prüfen

Nur Web-Add-Ins (Office Add-ins auf Basis von Office.js) sind im neuen Outlook kompatibel. Für jeden Hersteller sollte eine belastbare Aussage vorliegen, ab welcher Version ein Outlook-Web-Add-In verfügbar ist und welche Funktionen abgedeckt werden.

• Produktname und Technologie: Gibt es ein „Outlook Web-Add-In“/„Office Add-in“ (Office.js), nicht nur „Outlook COM/VSTO“?
• Bereitstellung: Unterstützung der Zentralisierten Bereitstellung über den Microsoft 365 Admin Center (Integrated Apps).
• Funktionsabdeckung: Unterstützung für Ereignisse (z. B. OnSend), Lesemodus/Erstellen, Kategorien, Anhänge, Klassifizierungen.
• Einschränkungen: Kein Zugriff auf PST/OST/MAPI, keine tiefen UI-Injektionen, Online-Abhängigkeit berücksichtigen.
• Roadmap/Termine: GA-/Preview-Daten, Feature-Gaps, Migrationspfade (Daten, Konfigurationen).
• Support-Matrix: Unterstützte Outlook-Varianten (neues Outlook für Windows, Outlook im Web, Mac, Mobile).

Funktionsfolgen für CRM, DMS und Archiv

Alternativen ohne Client-Add-In

Viele frühere Client-Funktionen lassen sich heute server- oder cloudseitig abbilden, was Unabhängigkeit vom Outlook-Client schafft.

• Archivierung/Compliance: Exchange Online-Archivpostfach, Journaling, Microsoft Purview-Retention, eDiscovery statt Client-Stubbing.
• CRM-Synchronisation: Serverseitige Synchronisation (z. B. Dynamics 365, Salesforce) statt Client-Sync.
• Ablage: Versandregeln, DLP und Sensitivity Labels erzwingen Metadaten/Schutz ohne Client-Hooks.
• Automatisierung: Microsoft Graph, Power Automate und Webhooks für serverseitige Verarbeitung eingehender/ausgehender Nachrichten.

Pragmatischer Migrationsplan

Ein kontrollierter Ablauf reduziert Ausfallrisiken und hält Compliance-Anforderungen ein.

• Bestandsaufnahme: Liste aller Add-Ins, Funktionen, betroffenen Benutzer, Compliance-Bezug.
• Klassifizierung: Kritisch/Erheblich/Nett; Zuordnung zu Abteilungen.
• Policy-Set: Wechsel zum neuen Outlook für kritische Gruppen blockieren; Pilotgruppen freigeben.
• Hersteller-Validierung: Web-Add-In-Versionen, OnSend-Unterstützung, Deployment-Methoden prüfen.
• Proof of Concept: Web-Add-Ins zentral bereitstellen und gegen Use-Cases testen (Tracking, Ablage, Archivierung).
• Betriebsentscheid: Entweder Web-Add-In produktiv nehmen oder klassisches Outlook vorerst beibehalten; Meilensteine festlegen.
• Kommunikation/Schulung: Geänderte Bedienung, Offline-Verhalten und Grenzen der Web-Add-Ins transparent machen.