← Microsoft 365 Collaboration Administration

Teams-Apps: alle für Erlauben, eine für Sperren

Eine beantragte App ist im Admin Center auf Erlaubt gesetzt, und trotzdem sieht sie niemand im Client. Die Erklärung ist eine Regel, die alles in diesem Bereich bestimmt: Um eine App zu erlauben, müssen alle Einstellungen zustimmen — um sie zu sperren, genügt eine einzige. Eine App freizugeben ist damit die Beseitigung eines Hindernisses, nicht die Entscheidung selbst. In diesem Modul lernst du die Ebenen kennen, die zustimmen müssen, und die asymmetrische Diagnose, die daraus folgt. Du lernst, warum Verfügbarkeit und Darstellung im Client zwei verschiedene Richtlinienarten sind, warum App-Berechtigungsrichtlinien als einer von zwei Typen nicht über Gruppen zugewiesen werden können, warum die app-zentrierte Verwaltung umgekehrt sogar verschachtelte Gruppen unterstützt, dabei aber Gastbenutzer ausschließt — und warum eine eigene App drei Einstellungen an drei Orten braucht.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Freigegeben, und trotzdem nicht da

Eine Fachabteilung hat eine App beantragt, die Freigabe ist erteilt, im Admin Center steht die App auf Allowed. Zwei Tage später meldet die Abteilung, die App tauche im Teams-Client niemandem auf. Die Freigabe wurde geprüft und steht unverändert.

Die Erklärung steht als ein Satzpaar in der Dokumentation, und es ist die wichtigste Regel dieses Moduls: Um eine App zu erlauben, müssen alle Einstellungen sie erlauben. Um sie zu sperren, genügt eine einzige. Eine App auf Allowed zu setzen ist damit keine Freigabe, sondern die Beseitigung eines Hindernisses. Wenn organisationsweit die Nutzung von Drittanbieter-Apps aus ist, bleibt sie weg.

LernzielDu kannst eine App-Anfrage entlang aller Ebenen prüfen, die zustimmen müssen, du kennst den Unterschied zwischen der Verfügbarkeit einer App und ihrer Darstellung im Client, und du kannst sagen, welche Stelle bei benutzerdefinierten Apps welchen Teil der Entscheidung trägt.

App-Status auf Organisationsebene — Der Zustand Allowed oder Blocked, den eine einzelne App auf der Seite Apps verwalten trägt. Er gilt für die gesamte Organisation und ist eine von mehreren Bedingungen, nicht die Entscheidung selbst.

Alle für Erlauben, eine für Sperren

Aus der Grundregel folgt eine asymmetrische Diagnose, und sie spart im Alltag viel Zeit.

Eine App ist nicht verfügbar: Es genügt eine sperrende Einstellung. Die Suche ist beendet, sobald die erste gefunden ist — weitere zu prüfen ändert nichts am Ergebnis.
Eine App soll verfügbar werden: Alle Ebenen müssen zustimmen. Hier reicht es nicht, die gefundene Sperre zu lösen; jede weitere Ebene ist einzeln zu prüfen.

Das erklärt ein häufiges Muster in Tickets: Die erste Korrektur wirkt nicht, die zweite auch nicht, die dritte plötzlich schon. Es sind nicht drei Fehler nacheinander aufgetreten — es waren von Anfang an drei Bedingungen, von denen jede einzeln die Verfügbarkeit verhindert.

Und der AusgangszustandSind keine App-Einstellungen durch Administratoren konfiguriert, gelten laut Dokumentation die organisationsweiten Einstellungen als Vorgabe. In einer Umgebung ohne bewusste App-Governance ist das also der Zustand, den man vorfindet — und er ist je nach Cloud unterschiedlich: In den Regierungsumgebungen GCC, GCCH und DoD sind alle Drittanbieter-Apps standardmäßig gesperrt.

Die organisationsweiten Einstellungen

Die organisationsweiten App-Einstellungen erreicht man über die Seite Apps verwalten. Sie sind die gröbste Ebene und die, die am häufigsten übersehen wird, weil sie nicht bei der einzelnen App steht.

Tailored apps: Steuert, ob Nutzer mit einer F-Lizenz das auf Frontline-Arbeit zugeschnittene App-Erlebnis erhalten.
Microsoft apps: Ein einzelner Schalter, der Nutzern standardmäßig Installation und Nutzung verfügbarer Apps erlaubt.
Third-party apps: Ein einzelner Schalter für die Verfügbarkeit neuer und bestehender Apps von Drittanbietern.
Custom apps: Steuert, ob Nutzer die bereitgestellten eigenen Apps installieren und nutzen dürfen.

Zwei Eigenheiten gehören dazu. Erstens greifen diese Einstellungen laut Dokumentation nach einigen Stunden — wer unmittelbar nach dem Speichern prüft, misst den alten Zustand. Zweitens sind integrierte Teams-Agenten ausdrücklich nicht mehr über den Schalter für Microsoft-Apps gesteuert; sie werden auf einer eigenen Seite verwaltet und lassen sich dort für alle, für bestimmte Personen und Gruppen oder für niemanden verfügbar machen.

Der Zustand vor der ersten EntscheidungVeröffentlicht ein Entwickler eine App, die eine Konfiguration durch Administratoren braucht, erscheint sie im Admin Center zunächst als Blocked by publisher. Das ist kein Befund über die eigene Konfiguration, sondern ein Hinweis, der Anleitung des Herausgebers zu folgen, bevor man freigibt.

Zwischenstand

Kurzcheck

Eine Drittanbieter-App steht auf der Seite Apps verwalten auf Allowed, und der betroffenen Nutzergruppe ist sie ausdrücklich zugewiesen. Im Client erscheint sie trotzdem nicht. Was prüfst du als Nächstes?

Ob die organisationsweite Einstellung für Drittanbieter-Apps deren Nutzung überhaupt zulässt.
Ob die Zuweisung an die Gruppe wegen der Gruppengröße noch verarbeitet wird.
Ob die App eine Setup-Richtlinie braucht, um im Client überhaupt zu erscheinen.

Treffer. Richtig. Für die Verfügbarkeit müssen alle Ebenen zustimmen; ein einzelner organisationsweiter Schalter genügt, um die App überall zu unterdrücken.

Verfügbarkeit ist nicht Darstellung

Zwei Richtlinienarten werden regelmäßig verwechselt, weil beide „App-Richtlinie“ heißen. Sie beantworten verschiedene Fragen, und nur eine von ihnen entscheidet über Zugang.

Berechtigung: Welche Apps für eine Person verfügbar sind. Das ist die Zugangsfrage und Teil der Kette aus der Grundregel.
Einrichtung (Setup): Wie und wo Apps im Client erscheinen: welche angeheftet werden, in welcher Reihenfolge, und ob sie ohne Zutun der Nutzer installiert werden. Gilt für Web-, Desktop- und Mobilclients.

Die Setup-Seite hat betrieblich mehr Gewicht, als ihr Name vermuten lässt: Über sie lassen sich Apps für Nutzer installieren, ohne dass diese etwas tun müssen. Was in der Berechtigungsebene eine Erlaubnis ist, wird hier zu einer Tatsache — und Einführungsprojekte scheitern regelmäßig nicht an der Erlaubnis, sondern daran, dass niemand die App findet.

Die Setup-Richtlinie reicht dabei weiter als das Anheften einzelner Zusatz-Apps: Auch die Reihenfolge der Core apps — der von Teams selbst mitgebrachten Grundfunktionen — lässt sich darüber für die Nutzer der Organisation ändern. Wer eine Fachanwendung dauerhaft in den Arbeitsfluss bringen will, konkurriert also nicht um freien Platz, sondern um Rangplätze in einer Leiste, die bereits belegt ist. Das ist eine Adoptionsentscheidung mit Nebenwirkungen, keine reine Konfiguration.

Die Ausnahme bei der ZuweisungDie Teams App Permission Policy gehört zu den zwei Richtlinientypen, die nicht über Gruppenzuweisung verteilt werden können — weder im Teams Admin Center noch über das PowerShell-Modul. Wer App-Zugang gruppenbasiert steuern will, kann dafür also nicht den Weg nutzen, der für Besprechungs- und Nachrichtenrichtlinien selbstverständlich ist.

Zwei Modelle auf der Nutzerebene

Für die Frage, wer eine App nutzen darf, gibt es zwei Modelle. Welches gilt, hängt vom Zustand des Tenants ab — und das ist die erste Frage, bevor man irgendetwas konfiguriert.

Berechtigungsrichtlinien: Richtlinienzentriert: Eine Richtlinie erlaubt oder sperrt Apps und wird Personen zugewiesen. Laut Dokumentation gelten sie nicht, wo das andere Modell aktiv ist — die Richtlinienseite weist dann ausdrücklich darauf hin.
App-zentrierte Verwaltung: App-zentriert: Je App wird festgelegt, welche Personen und Gruppen sie hinzufügen dürfen. Die Entscheidung hängt damit an der App, nicht an einer Richtlinie.

Der Unterschied ist nicht nur eine Oberflächenfrage. Er kehrt die Blickrichtung um: Im ersten Modell fragt man „welche Apps darf diese Person?“, im zweiten „wer darf diese App?“. Für Bestandsaufnahmen und Auskünfte ist das zweite deutlich günstiger — die Antwort steht bei der App und muss nicht aus Richtlinienzuweisungen rekonstruiert werden.

Der Gruppenunterschied, der überraschtDie app-zentrierte Zuweisung unterstützt laut Dokumentation Sicherheitsgruppen, Microsoft-365-Gruppen, Gruppen mit dynamischer Mitgliedschaft, verschachtelte Gruppen und Verteilerlisten. Damit kann sie genau das, was die Richtlinien-Gruppenzuweisung ausdrücklich nicht kann. Eine Einschränkung hat sie dafür: Gastbenutzer können die App nicht nutzen, auch wenn sie ihnen zugewiesen ist.

Benutzerdefinierte Apps: drei Stellen für ein Thema

Eigenentwicklungen sind der Fall, an dem sich die Aufteilung der Zuständigkeiten am deutlichsten zeigt. Drei verschiedene Einstellungen an drei verschiedenen Orten tragen je einen Teil der Entscheidung.

Wer hochladen darf: Die App-Setup-Richtlinie (TeamsAppSetupPolicy) steuert, wer in der Organisation benutzerdefinierte Apps hochladen darf.
Ob sie genutzt werden dürfen: Die organisationsweiten App-Einstellungen erlauben Nutzern, die bereitgestellten eigenen Apps zu installieren und zu nutzen.
Welche Personen konkret: Die Berechtigungsebene — TeamsAppPermissionPolicy beziehungsweise app-zentrierte Zuweisung — erlaubt eine bestimmte App nur bestimmten Personen.

Ein Entwicklungsteam, das eine eigene App nicht ausrollen kann, hat deshalb selten ein Problem, sondern meistens zwei oder drei. Und die drei Einstellungen liegen in verschiedenen Oberflächenbereichen mit verschiedenen Zuständigen — die Grundregel aus dem zweiten Abschnitt ist hier keine Theorie, sondern eine Terminplanung.

Nur die eigene VeröffentlichungsstufeVerwalten lassen sich laut Dokumentation nur Apps, die in derselben Veröffentlichungsstufe bereitgestellt sind wie der eigene Tenant. Wer in der allgemeinen Stufe arbeitet, kann Apps aus privaten oder öffentlichen Vorschaustufen nicht verwalten — und sieht sie dort auch nicht.

Anfragen, Nachweise und der Blick von außen

Für den laufenden Betrieb gibt es zwei Wege, die den Aufwand gering halten und beide selten genutzt werden.

Anfragen aus dem Client: Nutzer können aus Teams heraus die Freigabe einer für sie nicht verfügbaren App beantragen. Administratoren erhalten eine Benachrichtigung und können sie erlauben. Das ersetzt den Umweg über ein Ticket und macht den Bedarf sichtbar, statt ihn zu verwalten.
Katalog als CSV exportieren: Der gesamte App-Katalog der Organisation lässt sich aus dem Teams Admin Center exportieren — mit Status, Verfügbarkeit, Herausgeber und Zertifizierung. Das ist die Grundlage für jede Abstimmung mit einem Sicherheitsteam.

Für die fachliche Beurteilung einer App liefert die Plattform eigene Angaben. Auf der Detailseite einer App stehen ihr Zertifizierungsstatus, die Zusicherung des Herausgebers und weitere Sicherheitsmerkmale. Die Dokumentation weist ausdrücklich darauf hin, dass Microsoft für Teams-Apps keinen direkten Kundensupport leistet — der Support kommt vom Entwickler, dessen Kontaktweg auf derselben Seite steht.

Zwei Oberflächen, ein ZustandApps lassen sich sowohl im Teams Admin Center als auch unter Integrated apps im Microsoft 365 Admin Center verwalten. Solange ein Tenant nicht auf die vereinheitlichte App-Verwaltung umgestellt ist, müssen die Einstellungen in beiden Oberflächen laut Dokumentation synchron gehalten werden — sonst drohen unerwartete Störungen. Eine Prüfung, die nur eine Seite ansieht, ist in diesem Zustand unvollständig.

Apps bei externen Beteiligten

Sobald Besprechungen und Chats über die Organisationsgrenze gehen, verschiebt sich die Zuständigkeit für Apps — und zwar in eine Richtung, die viele Governance-Konzepte nicht vorsehen.

Nutzer können laut Dokumentation Apps hinzufügen, wenn sie Besprechungen oder Chats mit Gästen ausrichten. Sie können außerdem Apps nutzen, die von Gästen geteilt werden, wenn sie extern ausgerichteten Besprechungen oder Chats beitreten. Für diesen zweiten Fall gilt: Es greifen die Datenrichtlinien der ausrichtenden Organisation und die Datenpraktiken der Drittanbieter-Apps, die diese Organisation teilt.

Die eigenen App-Entscheidungen schützen damit die eigenen Besprechungen, nicht die Teilnahme an fremden.
Gesteuert wird das nicht über die App-Verwaltung, sondern über externen Zugriff und Gastzugriff in den organisationsweiten Einstellungen.
Eine Aussage wie „bei uns sind Drittanbieter-Apps gesperrt“ ist damit über die Organisationsgrenze hinweg nicht haltbar, wenn Beschäftigte extern ausgerichteten Besprechungen beitreten.

Was das für eine Risikobetrachtung heißtDie Frage „welche Apps sehen unsere Daten?“ zerfällt in zwei: Welche Apps erlauben wir in unseren Besprechungen, und an welchen fremden Besprechungen nehmen unsere Leute teil? Die zweite lässt sich mit den Mitteln der App-Verwaltung nicht beantworten — sie ist eine Frage der Einstellungen für externe Kommunikation.

Den Ist-Zustand feststellen

Bevor eine Organisation App-Governance entwirft, braucht sie den Bestand. Die Plattform liefert dafür mehrere Quellen, die sich in Genauigkeit und Aufwand deutlich unterscheiden.

Katalogexport als CSV: Der gesamte App-Katalog der Organisation mit Name, Status, Verfügbarkeit, Herausgeber und Zertifizierung. Die Grundlage für jede Abstimmung mit Sicherheit und Datenschutz.
Detailseite je App: Registerkarte Security and Compliance mit Zertifizierungsstatus, Herausgeberzusicherung und weiteren Sicherheitsmerkmalen — dazu die Kontaktwege zum Entwickler.
Kachel für Kandidaten: Zählt auf der Seite Apps verwalten die Microsoft 365-zertifizierten und die vom Herausgeber bestätigten Apps und filtert die Liste darauf.
Nutzungsbericht: Welche Apps tatsächlich genutzt werden, mit aktiven Nutzern — die einzige Quelle, die Erlaubnis von Nutzung unterscheidet.

Die letzte Zeile ist die wertvollste und wird am seltensten herangezogen. Eine Liste erlaubter Apps beschreibt den Möglichkeitsraum, nicht die Wirklichkeit. Erst der Abgleich mit der tatsächlichen Nutzung zeigt, welche Freigaben je gebraucht wurden — und das ist die Liste, mit der sich eine Verschärfung begründen lässt, ohne jemandem etwas wegzunehmen, das er benutzt.

Die Grenze der eigenen SichtVerwaltbar sind laut Dokumentation nur Apps aus derselben Veröffentlichungsstufe, in der der eigene Tenant läuft. Ein Bestand ist damit immer ein Bestand dieser Stufe. Für Apps aus Vorschaustufen gilt: Wer sie nicht sieht, hat sie nicht zwangsläufig nicht — er kann sie nur nicht verwalten.

Durchgerechnet: eine App, die ankommen soll

Von der Genehmigung bis zur Sichtbarkeit

Szenario

Eine Fachabteilung hat eine Drittanbieter-App zur Terminplanung beantragt. Die fachliche Prüfung ist positiv, die App soll für die 60 Personen dieser Abteilung nutzbar sein, für den Rest der Organisation nicht. Der Tenant hat bislang keine bewusste App-Governance.

Anforderungen

Die App wird für die Abteilung nutzbar und findet sich im Client
Für alle anderen bleibt sie unverfügbar
Die Entscheidung ist später nachvollziehbar

Schritte

Vor allem anderen klären, welches Modell auf der Nutzerebene gilt — Berechtigungsrichtlinien oder app-zentrierte Verwaltung. Davon hängt jeder weitere Schritt ab.
Die fachliche Grundlage von der Detailseite der App holen: Zertifizierungsstatus, Herausgeberzusicherung, Datenschutzangaben. Das ist der Teil, den ein Sicherheitsteam braucht.
Die organisationsweite Einstellung für Drittanbieter-Apps prüfen. Steht sie auf aus, ist jede weitere Konfiguration wirkungslos — und ihre Änderung ist eine organisationsweite Entscheidung, nicht eine für diese eine App.
Den Status der App auf Organisationsebene auf Allowed setzen. Das beseitigt eine Bedingung; es erteilt keine Nutzung.
Auf der Nutzerebene die 60 Personen adressieren. In der app-zentrierten Verwaltung geht das über eine Gruppe — auch über eine verschachtelte; über Berechtigungsrichtlinien geht es nicht über Gruppenzuweisung, sondern nur über Direkt- oder Stapelzuweisung.
Prüfen, ob Gäste betroffen sind: Bei app-zentrierter Zuweisung können Gastbenutzer die App nicht nutzen, selbst wenn sie ihnen zugewiesen ist.
Über eine Setup-Richtlinie das Anheften regeln, damit die App auffindbar ist — Verfügbarkeit allein führt niemanden hin.
Nach einigen Stunden prüfen, nicht sofort: Die organisationsweiten Einstellungen greifen mit Verzögerung.

Merksatz: Vier Ebenen mussten zustimmen, und keine von ihnen war die, die im Ticket stand. Die Genehmigung war der Anfang des Vorgangs, nicht sein Ergebnis.

Der Preis und die Route

Eine restriktive App-Governance ist begründbar: Jede App ist Code Dritter, der auf Unternehmensdaten zugreift, und die Plattform liefert für die Beurteilung Zertifizierungs- und Herausgeberangaben mit. Der Preis ist, dass jede einzelne Freigabe einen mehrstufigen Vorgang auslöst — und dass Nutzer in der Zwischenzeit andere Wege finden, die niemand sieht.

Die Gegenrichtung ist ebenso benennbar. Ein Tenant, in dem Drittanbieter-Apps organisationsweit erlaubt sind, hat keine Freigabepraxis, sondern eine Voreinstellung — und die Frage, welche Apps Zugriff auf Unternehmensdaten haben, ist dann nur über den Katalogexport zu beantworten, nicht über eine Genehmigungsliste. Beides ist vertretbar; nur unbemerkt sollte es nicht sein.

Modell klären: Berechtigungsrichtlinien oder app-zentrierte Verwaltung→Bei Nichtverfügbarkeit die erste sperrende Ebene suchen — dann aufhören→Bei Freigabe alle Ebenen einzeln durchgehen→Zugang und Darstellung trennen: Berechtigung gegen Setup→Nach Stunden prüfen, nicht nach Minuten

Alle für Erlauben, eine für Sperren

Das nächste Modul wechselt vom Zugang zu den Inhalten selbst: Vertraulichkeitsbezeichnungen, Datenverlustvermeidung und die Frage, was eine Kennzeichnung tatsächlich durchsetzt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität4 Primärquellen · zuletzt geprüft: 2026-09-12