Organisationsprofil

Gruppendesigns erlauben es, verschiedenen Nutzergruppen unterschiedliche Designs zuzuweisen. Das ist sinnvoll, wenn deine Organisation mehrere Marken oder Abteilungen mit eigener visueller Identität betreibt. Technisch funktioniert das über Entra-ID-Gruppen: Ein Design wird einer Gruppe zugewiesen, alle Gruppenmitglieder sehen es nach Anmeldung.

Aus Datenschutzsicht gilt:

• Logos und Grafiken dürfen keine personenbezogenen Daten enthalten
• Verwendete Bildelemente müssen urheberrechtlich unbedenklich sein
• Änderungen am Standarddesign sollten einem Freigabeprozess unterliegen

Willst du Organisationsdesigns vollständig entfernen, musst du zuerst alle Gruppendesigns löschen, bevor das Standarddesign gelöscht werden kann. Microsoft erzwingt diese Reihenfolge technisch.

Das klingt praktisch, birgt aber ein unterschätztes Risiko: Jede Kachel ist ein Vertrauenssignal. Nutzende gehen davon aus, dass alles im App-Launcher vom Unternehmen geprüft und freigegeben wurde. Unkontrollierte Kacheln auf nicht datenschutzkonforme Dienste untergraben dieses Vertrauen, ohne dass es jemand bemerkt.

Vor dem Hinzufügen einer Kachel solltest du prüfen:

• Ist die verlinkte App oder das Portal datenschutzkonform und DSGVO-tauglich?
• Gibt es einen Auftragsverarbeitungsvertrag (AVV) mit dem Anbieter?
• Wird die App tatsächlich von der Zielgruppe benötigt?

Veraltete oder nicht mehr genutzte Kacheln sollten aktiv entfernt werden. Ein ungepflegter App-Launcher ist kein kosmetisches Problem, er zeigt, dass kein Prozess dahinter steckt.

Wo Microsoft deine Kundendaten tatsächlich speichert, ist keine Selbstverständlichkeit. Die Datenspeicherortkarte im Admin Center zeigt dir je Workload, welche Geografie aktuell genutzt wird und welche Microsoft vertraglich zugesichert hat. Beides kann voneinander abweichen.

Im Screenshot ist das gut sichtbar: Exchange Online und Teams liegen auf "Germany", Exchange Online Protection und Viva Connections dagegen auf "European Union\EFTA". Wer DSGVO-konform argumentieren muss, sollte diese Unterschiede kennen und dokumentieren.

Das Advanced Data Residency Add-On (ADR) geht einen Schritt weiter. Es stellt Datenresidenz-Verpflichtungen bereit und ermöglicht die Migration ruhender Daten in eine definierte regionale Geografie. ADR ist lizenzpflichtig und wird über den Microsoft 365 Marketplace, ein Enterprise Agreement oder einen CSP-Partner bezogen.

Was du regelmäßig prüfen solltest:

• Aktuelle Geografie vs. zugesicherte Geografie je Dienst
• Ob neue Workloads (z. B. Copilot) bereits einer Region zugewiesen sind
• Ob sich Datenschutzanforderungen in deiner Organisation geändert haben

Ohne ADR bleibt die zugesicherte Geografie ein Richtwert, kein Versprechen. Die Datenspeicherortkarte ist der einzige Ort im Admin Center, der dir diese Transparenz ohne zusätzliche Tools gibt.

Standardmäßig versendet Microsoft system­generierte Benachrichtigungen aus M365 von einer microsoft.com-Absenderadresse. Für Nutzende sieht das aus wie eine externe Mail, was Verwirrung erzeugt und Phishing-Trainings konterkariert: Wer soll misstrauisch gegenüber externen Absendern sein, wenn legitime System-Mails selbst von außen kommen?

Die Einstellung ist schnell gemacht. Du aktivierst "Benutzerdefinierte Absenderdomänenadresse verwenden", trägst ein Präfix ein (z. B. noreply) und wählst eine deiner verifizierten Domänen. Microsoft nutzt dann die Exchange Online-Instanz deines Tenants für den Versand. Damit das funktioniert, muss E-Mail-Routing für die gewählte Adresse eingerichtet sein, also entweder ein Postfach oder eine Weiterleitung hinter noreply@deinedomain.de.

Was du vor der Aktivierung klären solltest:

• Existiert die Absenderadresse als gültiges Postfach oder Shared Mailbox?
• Sind SPF, DKIM und DMARC für die gewählte Domäne konfiguriert?
• Landen Bounce-Mails an diese Adresse irgendwo, wo sie jemand sieht?

Eine noreply-Adresse, die Bounces ins Leere schickt, ist kein Sicherheitsproblem, aber ein Betriebsproblem. Wer den Absender sauber aufsetzen will, legt eine Shared Mailbox an, deaktiviert den Empfang eingehender Mails und richtet eine Weiterleitung für Bounces an den zuständigen Admin ein.

Wenn Nutzende im Microsoft 365-Hilfebereich auf Probleme stoßen, sehen sie standardmäßig nur Microsofts eigene Supportoptionen. Mit den Helpdeskinformationen schaltest du eigene Kontaktdaten darunter, sodass Nutzende direkt den internen IT-Support erreichen, bevor sie ein Microsoft-Ticket eröffnen.

Die Konfiguration ist minimal: ein Titel, und mindestens eine Kontaktoption aus Telefon, E-Mail oder URL. Mehr braucht es nicht. Der Eintrag erscheint dann unterhalb der Standardhilfethemen für alle Nutzenden im Tenant.

Worauf du bei der Befüllung achten solltest:

• Nur offizielle Geschäftskontakte eintragen, keine privaten Mobilnummern oder persönlichen Mailadressen
• Die Helpdesk-URL sollte intern erreichbar sein, also kein öffentliches Ticketsystem ohne Authentifizierung
• Den Titel so wählen, dass Nutzende sofort verstehen, wen sie kontaktieren: "IT-Support Intern" ist klarer als "Helpdesk"

Das ist eine kleine Einstellung mit großem Effekt. Ohne sie landen Supportanfragen bei Microsoft statt beim eigenen Team.

Wenn eine Organisation mehrere Entra-ID-Mandanten betreibt, etwa durch Fusionen, Tochtergesellschaften oder getrennte Produktiv- und Entwicklungsumgebungen, entsteht schnell das Problem fehlender Transparenz: Wer hat in welchem Tenant Zugriff auf was? Die mehrinstanzenfähige Organisation (Multi-Tenant Organization, MTO) löst das, indem sie gegenseitiges Vertrauen zwischen definierten Mandanten herstellt.

Technisch basiert das auf Entra-ID-Cross-Tenant-Synchronisation. Nutzende aus Mandant A werden in Mandant B als externe Mitglieder synchronisiert und können dort auf Teams, SharePoint und andere Ressourcen zugreifen, ohne Gastzugang oder manuelle Einladungen. Der Einstieg erfolgt über "Erste Schritte" im Admin Center, wo du entweder eine neue MTO einrichtest oder einem bestehenden Verbund beitrittst.

Was vor der Einrichtung geklärt sein muss:

• Welche Mandanten sind tatsächlich vertrauenswürdig und auf welcher vertraglichen Grundlage?
• Welche Ressourcen sollen mandantenübergreifend zugänglich sein und welche explizit nicht?
• Wie werden Zugriffe protokolliert und bei Bedarf widerrufen?

Der Vertrauensstatus zwischen Mandanten ist keine technische Selbstverständlichkeit, sondern eine bewusste administrative Entscheidung. Wer pauschal alle Mandanten einer Unternehmensgruppe zusammenschaltet, ohne Berechtigungskonzept, schafft eine große

Die Organisationsinformationen sind das administrative Grundgerüst deines Tenants. Was hier eingetragen ist, erscheint auf Rechnungen, Anmeldeseiten und in der Kommunikation mit Microsoft.

Drei Felder verdienen besondere Aufmerksamkeit:

• Technischer Kontakt: Die E-Mail-Adresse, an die Microsoft Dienststatus-Meldungen, Sicherheitswarnungen und administrative Hinweise schickt. Hier gehört keine persönliche Mailadresse eines einzelnen Admins rein, sondern eine Funktionsadresse wie it-admin@deinedomain.de, die auch bei Personalwechsel erreichbar bleibt.
• Standarddomäne: Die primäre Domäne des Tenants, sichtbar in der Mandanten-ID-Zuordnung und relevant für externe Kommunikation.
• Käuferadresse: Wird auf Rechnungen und in Vertragsunterlagen verwendet. Änderungen laufen über die Abrechnungskonten, nicht direkt über diese Seite.

Die Mandanten-ID ist unveränderlich und identifiziert deinen Tenant eindeutig gegenüber Microsoft und verbundenen Diensten. Sie ist kein Geheimnis, sollte aber nicht ungeprüft in externe Dokumentationen wandern. Die bevorzugte Sprache steuert, in welcher Sprache Microsoft administrative Kommunikation und Dienststatus-Meldungen ausliefert. Für DACH-Organisationen ist Deutsch sinnvoll, sofern das Admin-Team damit arbeitet.

Microsoft rollt neue Features und Dienstupdates nicht für alle Tenants gleichzeitig aus. Die Releaseeinstellungen bestimmen, wann deine Organisation in diesen Rollout einbezogen wird. Die Wahl hat direkte Auswirkungen auf Planbarkeit, Testaufwand und Datenschutz-Bewertung neuer Funktionen.

Drei Optionen stehen zur Verfügung:

• Standardrelease für alle: Updates kommen, wenn Microsoft sie allgemein veröffentlicht. Kein Vorlauf, aber maximale Stabilität.
• Gezieltes Release für alle: Die gesamte Organisation erhält Updates frühzeitig. Sinnvoll für kleine, technisch versierte Teams, riskant für größere Umgebungen ohne Testprozess.
• Gezieltes Release für ausgewählte Benutzer: Definierte Pilotnutzer erhalten Updates zuerst. Das ist der empfohlene Weg für produktive Umgebungen: Neue Funktionen werden intern bewertet, bevor sie für alle ausgerollt werden.

Wichtig: Diese Einstellung steuert ausschließlich den Dienst-Rollout, also Änderungen in Teams, SharePoint, Exchange Online und ähnlichen Workloads. Den Update-Kanal für Microsoft 365 Apps (Word, Excel, Outlook) steuerst du separat über die Installationsoptionen.

Aus Datenschutzsicht lohnt es sich, neue Features im Gezielten Release zu prüfen, bevor sie flächendeckend aktiv werden. Microsoft führt regelmäßig Funktionen ein, die standardmäßig aktiviert sind und Daten verarbeiten, ohne dass Nutzende es bemerken. Wer das Standardrelease wählt, verzichtet auf dieses Zeitfenster.

Wer ein internes Ticketsystem wie ServiceNow oder Jira Service Management betreibt, kann es über die Support-Integration direkt mit Microsoft 365 verbinden. Das Ergebnis: Supportanfragen aus dem M365-Hilfebereich landen automatisch im internen Tool, ohne dass Nutzende zwischen Systemen wechseln müssen.

Technisch läuft das über einen Dienstprinzipal in Entra ID. Microsoft stellt diesen beim Einrichten der Integration bereit. Die Verbindung selbst wird über OAuth-Token autorisiert: Du trägst die Anwendungs-ID deines Supporttools ein, die zum Ausstellen dieser Token berechtigt ist. Zusätzliche Anwendungs-IDs lassen sich ergänzen, wenn mehrere Systeme angebunden werden sollen.

Aus Sicherheitssicht gilt hier das Prinzip der minimalen Berechtigung.

Was du vor der Einrichtung klären solltest:

• Welche Daten überträgt das Supporttool an M365 und umgekehrt?
• Hat der Dienstprinzipal nur die Berechtigungen, die er tatsächlich braucht?
• Sind die OAuth-App-Registrierungen im Entra Admin Center dokumentiert und werden sie regelmäßig auf ungenutzte Grants geprüft?

Integrationstests vor dem Produktivbetrieb sind kein optionaler Schritt. Eine falsch konfigurierte OAuth-Verbindung kann dazu führen, dass Supportdaten in falschen Systemen landen oder Zugriffe unkontrolliert weitergegeben werden.