„Dieses Add-in ist erlaubt, alle anderen nicht.“ Als Sicherheitsziel klingt das eindeutig. In der technischen Umsetzung fehlen dann oft entscheidende Angaben: Welche Anwendung ist gemeint? Wie wird die Erweiterung identifiziert? Welche Version ist geprüft? Und was passiert, wenn Office sie wegen Stabilitätsproblemen deaktiviert? Ich empfehle, zentrale Add-in-Regeln als kleines Betriebsmodell aufzubauen. Eine einzelne Richtlinie ersetzt weder ein sauberes Inventar noch eine fachliche Freigabe. Sie ist erst dann belastbar, wenn ihre Wirkung auf dem tatsächlichen Client nachgewiesen wurde.
Zuerst die technische Grenze ziehen
Dieser Ansatz betrifft klassische COM-Erweiterungen und die dafür geeigneten Richtlinien. Webbasierte Office-Add-ins folgen einem anderen Integrationsmodell. Ebenso sollte man ActiveX-Steuerelemente in Dokumenten nicht mit einer zentral installierten COM-Erweiterung gleichsetzen. Die gemeinsame Bezeichnung „Office-Erweiterung“ reicht für eine technische Entscheidung nicht aus.
Prüfen Sie daher Anwendung, Integrationsmodell und Clientvariante. Bei Outlook muss beispielsweise klar sein, welcher Client eingesetzt wird. Ein Steuerungskonzept für den klassischen Windows-Client darf nicht unverändert auf jede andere Variante übertragen werden. Ich würde diese Abgrenzung direkt in die Freigabedokumentation schreiben, damit später keine falschen Erwartungen entstehen.
Eindeutige Identifikation vorbereiten
Microsoft dokumentiert für die Verwaltung klassischer Outlook-Add-ins unter anderem die ProgID als Identifikator. Der Anzeigename in einem Dialog ist dafür kein zuverlässiger Ersatz. Bei verschiedenen Produkten können sich Namen ähneln, während die technischen Kennungen unterschiedlich sind. Auch eine neue Produktgeneration kann eine andere Integration mitbringen.
Für Sie heißt das konkret: Ermitteln Sie den Wert auf einem repräsentativen, korrekt installierten Testsystem. Stimmen Sie ihn bei Bedarf mit dem Hersteller ab und dokumentieren Sie die dazugehörige Anwendung. Übernehmen Sie keine ungeprüften Werte aus einem fremden Beispiel. Eine Freigabeliste funktioniert nur, wenn sie tatsächlich die Komponente adressiert, die Sie steuern möchten.
Installation und Ladeverhalten getrennt betrachten
Ein Add-in kann installiert sein, ohne aktiv geladen zu werden. Umgekehrt ist die Steuerung des Ladeverhaltens keine vollständige Softwareverteilung. Paketierung, Aktualisierung und Entfernung bleiben eigene Aufgaben. Diese Trennung ist wichtig, wenn eine Richtlinie scheinbar nicht wirkt: Vielleicht fehlt die Erweiterung, vielleicht startet sie nicht oder vielleicht greift eine andere Regel.
Ich empfehle deshalb getrennte Prüfpunkte für Installation, Registrierung und Nutzung. Öffnen Sie die betroffene Anwendung mit einem normalen Benutzerkonto und testen Sie den konkreten Geschäftsablauf. Eine erfolgreiche Installation im Softwareportal beweist noch nicht, dass die Funktion in Office verfügbar und korrekt eingerichtet ist.
Sicherheitsentscheidung und Stabilität nicht verwechseln
Ein fachlich erlaubtes Add-in ist nicht automatisch technisch stabil. Ebenso macht eine Stabilitätswarnung die Erweiterung nicht automatisch zu Schadsoftware. Gerade bei Outlook sollten die Mechanismen zur Behandlung problematischer Erweiterungen und die administrativen Vorgaben gemeinsam bewertet werden. Ein pauschales Erzwingen kann die Ursachenanalyse erschweren.
Unterstützung bei AI Governance, KI-Code-Prüfung und sicherer Automatisierung
Ich unterstütze Unternehmen bei der sicheren Einführung von ChatGPT, Copilot, KI-Agenten und moderner Enterprise-Automatisierung. Mein Fokus liegt auf AI Governance, Compliance, sicherer KI-Nutzung und der strukturierten Kontrolle von KI-generiertem Code.
Zusätzlich verfüge ich über eigene Softwarelösungen zur automatisierten Analyse von Code, Skripten und KI-generierten Automatisierungen, um Risiken, unsichere Muster und Governance-Themen frühzeitig sichtbar zu machen.
Gerne tausche ich mich mit Ihnen in einem unverbindlichen virtuellen Kaffee über AI Governance, sichere KI-Einführung und Governance-Strategien im Enterprise-Umfeld aus.
Virtuellen Kaffee vereinbarenMein Tipp: Dokumentieren Sie, welche Regel aus welchem Grund gesetzt wird. Geht es um einen Sicherheitsstandard, um eine fachlich notwendige Integration oder um die Behandlung eines konkreten Fehlers? Diese Begründungen brauchen unterschiedliche Nachweise. Herstellerunterstützung, Performanceprüfung und fachliche Abnahme sollten dort zusammenkommen, wo die Erweiterung dauerhaft benötigt wird.
Änderungen zunächst eng ausrollen
Beginnen Sie mit einer Pilotgruppe, die typische Aufgaben tatsächlich ausführt. Dazu gehören nicht nur IT-Mitarbeiter, sondern auch die Fachanwender der Erweiterung. Testen Sie einen normalen Arbeitstag: Start, Anmeldung, Datenabruf, Bearbeitung und Abschluss. Berücksichtigen Sie außerdem die Kombination mit anderen freigegebenen Add-ins.
Ein Beispiel: Eine Dokumentenmanagement-Erweiterung funktioniert allein problemlos, gemeinsam mit einer weiteren Integration entsteht aber ein Fehler beim Versand. Das lässt sich nicht aus einer Freigabeliste ablesen. Halten Sie den getesteten Bestand fest, damit spätere Änderungen vergleichbar bleiben. Ein Pilot ohne dokumentierte Ausgangskonfiguration liefert nur begrenzt verwertbare Ergebnisse.
Den Ausnahmeprozess vor dem ersten Ticket definieren
Eine neue Sperre erzeugt Rückfragen. Der Service Desk braucht deshalb einen klaren Weg, statt eigenständig Ladeeinstellungen zu verändern. Legen Sie fest, welche Informationen für einen Antrag erforderlich sind: Anwendung, Erweiterung, fachlicher Zweck, Fehlermeldung und zuständiger Prozesseigentümer. Ergänzen Sie einen Ansprechpartner für die technische Prüfung.
Befristete Ausnahmen sollten einen Endtermin und eine konkrete Weiterbearbeitung erhalten. Vermeiden Sie pauschale Gruppen, deren Mitgliedschaft niemand mehr kontrolliert. Für mich ist eine Ausnahme nur dann beherrschbar, wenn sich später erklären lässt, warum genau diese Person genau diese Erweiterung benötigt. Das schützt die Regel vor schleichender Aufweichung.
Als konkrete Entscheidungsunterlage würde ich einen freigegebenen Referenzzustand festhalten: Office-Client, installierte Erweiterung, technische Kennung, Richtlinienzuordnung und getesteter Geschäftsablauf. Damit lässt sich eine spätere Störung gegen einen bekannten Zustand vergleichen. Nach einem Herstellerupdate muss nicht die gesamte Diskussion neu beginnen; geprüft wird gezielt, was sich geändert hat. Diese Übersicht erleichtert zugleich die Übergabe an den Betrieb und verhindert widersprüchliche lokale Reparaturversuche.
Fazit: Steuerung braucht einen überprüfbaren Zusammenhang
COM-Add-ins lassen sich nur verlässlich verwalten, wenn technische Kennung, Installation, Richtlinie und Geschäftsprozess zusammenpassen. Ich würde deshalb zuerst den Bestand klären und erst danach Freigaben erzwingen. Prüfen Sie jede Regel im vorgesehenen Client und mit realistischen Aufgaben. So entsteht aus einer Liste von Produktnamen ein nachvollziehbares Verfahren, das Sicherheit und Arbeitsfähigkeit gemeinsam berücksichtigt.
Quelle: Microsoft: Verwaltung und Ladeverhalten von Outlook-Add-ins.
Image: OpenAI
Ich blogge über den Einfluss der Digitalisierung auf unsere Arbeitswelt. Hierzu gebe ich Inhalte aus der Wissenschaft praxisnah wieder und zeige hilfreiche Tipps aus meinen Berufsalltag. Ich bin selbst Führungskraft in einem KMU und Ich habe berufsgeleitend an der Universität Erlangen-Nürnberg am Lehrstuhl für IT-Management meine Doktorarbeit geschrieben.
