Unified Tenant Configuration Management (UTCM) – What It Is and Why It Matters

Seit dem 27.01.2026 ist es soweit. Unified Tenant Configuration Management (UTCM) Graph API ist in der Public Preview angekommen. In diesem Post gehe ich darauf ein was UTCM ist und warum es Relevanz hat. Dabei konzentriere ich micht bezüglich Unified Tenant Configuratoin Management auf die aktuellen Möglichkeiten, die Architektur, die Limitierung, den Vergleich mit Community-Tools, und so weiter.

Was ist UTCM

Das Unified Tenant Configuration Management (UTCM) von Microsoft ist eine neue Reihe von Graph-APIs (Public Preview seit 27.01.2026), mit denen Administratoren die Microsoft 365-Tenantkonfiguration als Code verwalten können, mit integrierten Funktionen zur Snapshot- (Baseline-) und Drift-Überwachung. Im Wesentlichen bietet es eine native Möglichkeit, den Konfigurationsstatus deines Mandanten zu erfassen und Abweichungen kontinuierlich zu erkennen, wodurch die seit langem bestehende Herausforderung der Konfigurationsabweichungen (Drift) in M365-Umgebungen direkt angegangen wird.

Du bist vertraut mit dem Open Source Projekt Microsoft 365 DSC? UTCM ist der offizielle Nachfolger der von der Community entwickelten Microsoft 365 DSC-Lösung und bietet offiziell von Microsoft unterstützte Tools fürs Tenantkonfiguration.

Kernkompetenz: Basislinien und Drift-Analyse

Das Betriebsmodell von UTCM ist einfach, aber leistungsstark: Du erfasst eine Basislinie und überwachst sie anschliessend auf Abweichungen. Der Arbeitsablauf umfasst zwei Hauptschritte:

1. Erstelle einen Konfigurations-Snapshot (Baseline): Erstelle einen Snapshot Job per API-Call als asynchronen Prozess. Heisst der Job wird in Auftrag gegeben mit entsprechenden Parameter wie beispielsweise zu inkludierende Ressourcentypen. Der Job wird dann im Hintergrund von Microsoft ausgeführt. Nach Abschluss erhältst du ein Snapshot der Konfiguration deiner gewählten Ressourcentypen im JSON-Format. Dieser Snapshot kann dir nun als Baseline, bzw. als gewünschter Zustand dienen. Achtung, UTCM ist nicht für die langfristige Speicherung von Konfigurationen vorgesehen. Ein Snapshot wird nur vorübergehend bis maximal 7 Tage gespeichert und sollte zur längeren Verwahrung exportiert werden, wenn benötigt.
2. Monitor für Drift-Analyse bereitstellen: Sobald du über einen JSON-Baseline-Snapshot verfügst (unabhängig davon, ob diese per Snapshot oder manuell erstellt wurde), kannst du einen Konfigurationsmonitor in UTCM erstellen. Ein Monitor ist im Wesentlichen ein geplanter Job in der Microsoft-Cloud, der alle 6 Stunden (festes Intervall in der Vorschau) ausgeführt wird, um die Live-Tenanteinstellungen mit der Baseline zu vergleichen. Der Monitor überprüft jedes in der Baseline definierte Konfigurationselement.
   Jeder Monitor kann mehrere Ressourcen abdecken. Du kannst auch mehrere Monitore verwenden und diese kombinieren, beziehungsweise Separieren. Beispielsweise kannst du einen Monitor für die Überwachung je Service (Exchange, Entra, Teams, …) erstellen und die Konfigurationsüberwachung so auf logischer Ebene voneinander trennen.
   Wenn bei der Prüfung der aktuelle Wert der zu überwachenden Einstellungen im Tenant abweicht, speichert UTCM diese Abweichung als Drift-Datensatz. Dieser Datensatz gibt an, was sich geändert hat (z. B. welche Eigenschaft nun von der Baseline abweicht) und wann dies erstmals bemerkt wurde. Diese Drift-Datensätze bleiben „aktiv”, bis ein Administrator sie behebt. Danach wird die Abweichung als behoben markiert. Während der Vorschau arbeiten die Monitore im Modus „monitor only”. Die automatische Widerherstellung existiert noch nicht.

Dieses Baseline- und Überwachungssystem bietet Administratoren eine kontinuierliche Überprüfung des Konfigurationsstatus ihrer Tenants. Anstatt Dutzende von Admin-Centern manuell zu überprüfen oder sich auf Ad-hoc-Skripte zu verlassen, erhältst du einen zentralisierten Feed aller Einstellungen, die von der genehmigten Baseline abweichen. Auf diese Weise können unbeabsichtigte Änderungen proaktiv erkannt werden, bevor sie zu Sicherheits- oder Compliance-Problemen werden.

Architektur und Funktionsweise hinter den Kulissen

UTCM wird als Teil der Microsoft Graph API (Beta) implementiert, was bedeutet, dass es sich vorerst um eine reine API-Lösung handelt (noch keine GUI im M365 Admin Center). Die Hauptarbeit wird serverseitig von Microsoft erledigt und stellt eine wesentliche Änderung gegenüber früheren Community-Lösungen dar.

1st Party Service Principal

Microsoft stellt erstmals einen 1st-Party integrierten Service Principal für UTCM mit dem Namen «Unified Tenant Configuration Management» und der App ID 03b07b79-c5bc-4b5e-9bfa-13acf4a99998 zur Verfügung.

Wenn du einen Snapshot- oder Überwachungsauftrag ausführst, ist es derjenige, der tatsächlich die Konfiguration deines Tenants liest. Er ist es, dem entsprechende Berechtigungen eingeräumt werden müssen. Diese können nach Least Privilege Prinzip  selektiv gemäss deinen Anforderungen vergeben werden. Durch dieses Design kann die Arbeit in die Cloud von Microsoft ausgelagert werden. Im Gegensatz zu Microsoft365DSC, das die gesamte Datenerfassung lokal über PowerShell-Module ausführte, läuft die Erfassungs- und Vergleichslogik von UTCM in der Infrastruktur von Microsoft als Multi-Tenant-Dienst.

Aufruf der API

Administratoren oder Automatisierungstools rufen die Graph-Endpunkte auf, um UTCM zu verwalten. Es gibt zwei Authentifizierungskontexte:

• Control Plane (Graph): Du als User, dein Skript oder deine App benötigen Graph-Berechtigungen oder eine privilegierte Rolle, um die UTCM-APIs aufzurufen und Snapshot-Jobs, sowie Monitore erstellen und anschauen zu können. Das schöne, neu existieren zwei neue Graph-Berechtigungen, die auch im Applikationskontext vergeben werden können. «ConfigurationMonitoring.Read.All» und «ConfigurationMonitoring.ReadWrite.All». Im Kern sind das die einzigen Berechtigungen, die deine App benötigt. Damit ist der Zugriff auf die neue Graph-API geregelt.
  
  
• Datenebene (Tenant): Der UTCM Service Principal in deinem Tenant hingegen benötigt Rechte zum Lesen (oder gegebenenfalls Schreiben) der spezifischen Konfigurationsdaten. Dies ist die Identität, die tatsächlich den Snapshot-Export und die Drift-Prüfungen durchführt.

Ausführung von Snapshots

Wenn ein Snapshot-Job gestartet wird, wird er asynchron ausgeführt. UTCM listet die angeforderten Ressourcentypen auf (z. B. alle Richtlinien für Conditional Access lesen) und kompiliert die Ergebnisse in einer strukturierten JSON-Datei. Ist der Job abgeschlossen, kannst du die Snapshot-Ergebnisse über einen weiteren API-Aufruf abfragen.

Überwachungszyklus des Monitors

Ein erstellter Monitor wird in einen aktiven Zeitplan aufgenommen und löst automatisch alle 6 Stunden aus. Der Zeitpunkt ist fest vorgegeben und kann in der Public Preview nicht beeinflusst werden. Bei jedem Durchlauf liest der UTCM Service Principal die aktuellen Werte aller in der Baseline aufgeführten Einstellungen und vergleicht sie mit der Baseline. Anschliessend erstellt er einen Datensatz, der protokolliert, ob der Durchlauf erfolgreich war und wie viele Abweichungen (Drifts) gefunden wurden. Dieser Datensatz beinhaltet wiederrum weitere Datensätze für jede Diskrepanz. Administratoren können dann die Graph-API abfragen, um die neuesten Überwachungsergebnisse und Abweichungsdetails abzurufen.

Aktuelle Beschränkungen (Public Preview):

Mindestens während der aktuellen Vorschau hat UTCM einige festgelegte Beschränkungen, die du berücksichtigen musst.

Engpässe

Diese Kontingente unterstreichen, dass UTCM für die gezielte Überwachung kritischer Konfigurationen und nicht für die umfassende, hochfrequente Überprüfung aller Elemente in deinem Tenant konzipiert ist. Das Monitor-Limit von 200 Ressourcen pro Tenant bedeutet beispielsweise, dass du bei einer halbwegs grossen Anzahl von Objekten Prioritäten setzen musst, welche davon für die Überwachung am wichtigsten sind. Das Limit von 20’000 Elementen pro Monat für Snapshots ist dagegen für die regelmässige Basisbewertung in den meisten Tenants ausreichend, auch weil die Ressourcentypen auf verschiedene Snapshot-Jobs verteilt werden können, die sich dann aber wiederrum auf die 200 Snapshot-Limite pro Monat auswirkt. Denkt man an den Ressourcentyp «User» (microsoft.entra.user) oder «Gruppen» (microsoft.entra.group), so wird schnell klar, dass eine passende Filterung von Ressourcentypen schnell notwendig sein wird.

Umfang der Abdeckung

Derzeit unterstützt UTCM über 250 offiziell dokumentierte Ressourcentypen für die sechs oben aufgeführten Workloads. Dazu gehören beispielsweise Exchange-Transportregeln, Aufbewahrungsrichtlinien in Purview, Gerätekonformitätsrichtlinien in Intune, verschiedene Teams- und Entra ID-Einstellungen auf Tenantebene.

Highlight: Das vollständige Schema der unterstützten Ressourcentypen ist öffentlich dokumentiert und als JSON-Schema für die Konfigurationsvorlage auf Schemastore veröffentlicht.

Ein bemerkenswerter und nicht zu vernachlässigender Wermutstropfen ist, dass SharePoint Online und einige andere Service fehlen. Das Fehlen dieser Services dürfte auf die fehlende oder mangelhafte Integration in Microsoft Graph zurückzuführen sein. Die Unterstützung ist in Planung, eine Roadmap ist aber offiziell nicht bekannt. Ausserdem ist der Abdeckungsgrad innerhalb eines unterstützten Ressourcentypen möglicherweise noch nicht 100 %.

Im Zuge der Weiterentwicklung der Public Preview erwarte ich, dass Microsoft sowohl die Breite (mehr Services) als auch die Tiefe (mehr Ressourcentypen und Konfigurationen pro Dienst) von UTCM erweitern wird.

UTCM vs Microsoft 365 DSC

UTCM ist ein moderner, vollständig unterstützter Ersatz für Microsoft 365 DSC (Desired State Configuration), das bisher als Community-/Open-Source-Tool für ähnliche Zwecke verwendet wurde. Auf der Homepage von Microsoft 365 DSC wird UTCM gar offiziell als Nachfolgelösung genannt und eine Transition von M365DSC nach UTCM beschrieben.

Beide Tools zielen darauf ab, die Konfiguration als Code und das Drift-Management für Microsoft 365 zu realisieren, unterscheiden sich jedoch erheblich in Bezug auf Ansatz und Funktionen:

	Microsoft 365 DSC (M365 DSC)	Unified Tenant Config Mgmt (UTCM)
Unterstützt durch	Community & MVPs (Open Source auf GitHub), kein offizielles MS-Produkt.	Microsoft (integrierte Graph-API, offiziell von Microsoft unterstützt).
Schnittstelle & Format	PowerShell-Modul (Microsoft365DSC). Konfiguration definiert in PowerShell DSC-Syntax (.ps1), die zu MOF-Dateien kompiliert und über PS-Befehle betrieben wird. Keine native Benutzeroberfläche.	REST-API (Graph) – Konfiguration in JSON-Vorlagen definiert Sprachunabhängig (Graph SDK/REST, PowerShell, .NET, Python usw.). Derzeit keine Benutzeroberfläche.
Ausführung	Clientseitige Ausführung (auf einem Computer, Azure Automation, VM). Abrufen von Einstellungen und Drift-Analyse erfolgt auf diesem Host mittels API-Aufrufen. Für die kontinuierliche Überwachung ist die Planung von DSC-Ausführungen oder die Verwendung des LCM (Local Configuration Manager) von DSC auf einer VM erforderlich.	Cloud-Ausführung: Snapshots und Drift-Analyse werden von Microsoft UTCM als automatisierter Job ausgeführt. Es sind keine dedizierte VM oder geplante Jobs erforderlich, Microsoft übernimmt die 6-Stunden-Planung und -Verarbeitung.
Funktionsumfang	Exportieren (Snapshot) der Konfiguration und Testen (Überwachen) auf Abweichungen. Unterstützt auch das Anwenden (Importieren) von Konfigurationsänderungen mithilfe der DSC-Mechanismen. Keine integrierte Abweichungswarnung.	Snapshot und Monitor zur Drift-Erkennung (gleiche Kernfunktionen). Noch keine Push-/Korrekturfunktion in der Preview. Microsoft hat jedoch angekündigt, dass zukünftige Updates die Bereitstellung von Konfigurationen und die automatische Korrektur von Abweichungen hinzufügen werden.
Workload Abdeckung	Umfasst Kerndienste wie Entra, Exchange Online, SharePoint Online, OneDrive, Teams usw. Die Qualität der Abdeckung war jedoch unterschiedlich und erforderte ständige Community-Updates für neue Funktionen.	Derzeit beschränkte Abdeckung (Entra, Exchange, Teams, Intune, Defender, Purview) Bspw. SharePoint und OneDrive fehlt gänzlich, wohl zurückzuführen auf die fehlende / unzureichende Graph-Integration jener.
Skalierbarkeit und Mandantenfähigkeit	Keine native Multi-Tenant-Verwaltung. Um das System für mehrere Mandanten zu nutzen, müssen Sie für jeden Mandanten separate Instanzen von DSC oder Skripten ausführen.	(Derzeit) keine native Multi-Tenant-Unterstützung.
Erweiterbarkeit	Erweiterbar durch das Schreiben neuer PowerShell-DSC-Ressourcen (Community-gesteuerte Entwicklung).	Erweiterbar nur durch Aktualisierung der API durch Microsoft mit neuen Ressourcentypen.

Zusammenfassend lässt sich sagen, dass UTCM das Konfigurationsmanagement von Tenants von einem selbstständigen, skriptlastigen Ansatz zu einem cloudnativen, API-gesteuerten Ansatz verlagert. Es beseitigt die Abhängigkeit von der Ausführung von PowerShell-Skripten nach einem Zeitplan und verspricht eine bessere Skalierbarkeit und offiziellen Support. UTCM wird im Laufe der Zeit Microsoft365DSC vollständig ablösen, sobald es ausgereift ist, insbesondere dann, wenn die Funktionen für die Konfigurationsbereitstellung und -korrektur verfügbar sind.

Grenzen & Ausblick

So vielversprechend UTCM auch scheint, als Public Preview bringt es naturgemäss noch einige Einschränkungen mit sich. Diese zu kennen ist entscheidend, um das Tool realistisch einzuschätzen und sinnvoll einzusetzen.

Nur definierte Ressourcen werden überwacht: UTCM erkennt ausschliesslich Änderungen an Ressourcen, die explizit in der Baseline definiert wurden. Das bedeutet:

• Wird eine bestehende Richtlinie (z. B. eine Conditional Access Policy) verändert, erkennt UTCM die Abweichung zuverlässig.
• Wird jedoch eine neue Richtlinie hinzugefügt, die nicht Teil der ursprünglichen Baseline war, bleibt dies unbemerkt.
• Ebenso werden neue Parameter, die durch Feature-Updates von Microsoft eingeführt werden, nicht automatisch erkannt, sofern sie nicht in der Baseline enthalten sind.

Diese Einschränkung kann zu blinden Flecken führen und schmerzt insbesondere dann, wenn Microsoft einen Default-Wert anpasst, bei neuen Features, oder in dynamischen Umgebungen mit häufigen Änderungen.

Kein Abgleich mit Best Practices oder Standards: UTCM bietet derzeit keine Möglichkeit, Konfigurationen mit etablierten Sicherheitsstandards wie den CIS-Benchmarks oder Microsoft Security Baselines zu vergleichen. Eine solche Funktion wäre ein wertvoller Baustein für Compliance- und Governance-Szenarien.

Eingebaute Drift-Erkennung nur gegenüber der eigenen Definition: Die Drift-Erkennung erfolgt ausschliesslich im Vergleich zur selbst definierten Baseline. Es gibt keine „intelligente“ Erkennung von sicherheitskritischen Änderungen oder potenziellen Fehlkonfigurationen ausserhalb dieser Definition. UTCM weiss nicht, ob eine Änderung „gut“ oder „schlecht“ ist. Es erkennt nur, dass sie vom Soll-Zustand abweicht.

Noch am Anfang, der Weg ist weit: UTCM ist ein junges Produkt mit viel Potenzial, aber auch mit klaren Limitierungen:

• Die Service-Abdeckung ist noch nicht vollständig. Besonders auffällig: SharePoint Online wird derzeit nicht unterstützt. Ein Bereich, in dem ein Konfigurationsdrift besonders kritisch sein kann.
• Die maximale Anzahl an überwachten Ressourcen (800 pro Tag) und Snapshots (20’000 Ressourcen pro Monat) ist für viele Szenarien ausreichend, kann aber bei grossen Tenants oder ambitionierten Governance-Zielen schnell an Grenzen stossen.
• Die automatische Korrektur von Drifts ist noch nicht verfügbar. Aktuell ist UTCM ein reines Monitoring-Tool.

Was bereits möglich ist: Trotz dieser Einschränkungen ist UTCM es wert, es sich anzuschauen. Bereits heute ist es für alle Microsoft 365 Tenants verfügbar und anders als in der private Preview kein Whitelisting mehr erforderlich. Voraussetzung ist eine Microsoft 365 E3- oder Microsoft Entra ID P1 Lizenz.

Fazit

Unified Tenant Configuration Management (UTCM) ist ein bedeutender Schritt in Richtung eines modernen, deklarativen Konfigurationsmanagements für Microsoft 365. Zum ersten Mal überhaupt direkt aus erster Hand von Microsoft. Es bringt zentrale Funktionen wie Snapshot-Erstellung und Drift-Überwachung erstmals als offiziell unterstützte Graph-API direkt in die Microsoft-Welt, ohne Umwege über Dritttools oder Community-Projekte.

Trotz seiner Stärken ist UTCM aktuell noch ein Tool mit klaren und markanten Grenzen. Die fehlende Abdeckung wichtiger Dienste wie SharePoint Online dürfte dabei wohl die markanteste sein. Aber auch die Limitierung auf definierte Ressourcen sowie die fehlende Integration von Best Practices zeigen, dass UTCM noch am Anfang steht. Dennoch: Die Richtung stimmt. Microsoft adressiert mit UTCM endlich ein lang bestehendes Problem.

Wer heute bereits mit Microsoft 365 DSC gearbeitet hat, wird sich schnell zurechtfinden. Wer neu einsteigt, erhält mit UTCM ein zukunftsfähiges Fundament.

In den nächsten Teilen dieser Serie werfen wir einen Blick auf die praktische Umsetzung und strategische Relevanz: Wie du UTCM einrichtest, Snapshots erstellst, welche Best Practices sich bereits jetzt abzeichnen und welche Bedeutung einer Drift-Analyse beizusetzen ist.

Quellen

https://learn.microsoft.com/graph/api/resources/unified-tenant-configuration-management-api-overview?view=graph-rest-beta&WT.mc_id=AZ-MVP-5004129

https://learn.microsoft.com/en-us/graph/api/resources/configurationmonitor?view=graph-rest-beta&preserve-view=true&WT.mc_id=AZ-MVP-5004129

https://learn.microsoft.com/graph/utcm-entra-resources?WT.mc_id=AZ-MVP-5004129

https://learn.microsoft.com/graph/utcm-exchange-resources?WT.mc_id=AZ-MVP-5004129

https://learn.microsoft.com/graph/utcm-intune-resources?WT.mc_id=AZ-MVP-5004129

https://learn.microsoft.com/graph/utcm-securityandcompliance-resources?WT.mc_id=AZ-MVP-5004129

https://learn.microsoft.com/graph/utcm-teams-resources?WT.mc_id=AZ-MVP-5004129

https://nik-charlebois.com/blog/posts/2026/introducing-tcm-apis/index.html

https://microsoft365dsc.com/blog/2026/utcm-transition/utcm-transition/index.html

https://ourcloudnetwork.com/microsoft-to-introduce-native-tenant-configuration-drift-monitoring/

https://petri.com/microsoft-graph-utcm-apis-configuration-drift