Microsoft365DSC: Tenant exportieren, Vorlage im Testtenant einspielen

Test-Tenant als Code

Export statt Handarbeit

Foto: Haer_breizh / Pixabay

Ein Bauplan ersetzt kein Haus, aber er lässt dich ein zweites bauen, ohne das erste anzufassen. Genau das verspricht Microsoft365DSC für einen Microsoft-365-Tenant: Du exportierst die Konfiguration einmal und spielst sie in einen Test-Tenant ein.

Das Wichtigste in Kürze

• Microsoft365DSC beschreibt einen Tenant als PowerShell-Code. Das Modul ist Open Source, steht unter MIT-Lizenz und deckt laut PowerShell Gallery über 600 DSC-Ressourcen ab, von Entra ID über Exchange und SharePoint bis Teams und Intune.
• Ein Export enthält keine Werte der Quelle. Tenantspezifische Angaben landen in einer Datei ConfigurationData.psd1. Für das Ziel änderst du nur diese Datei und kompilierst neu.
• Die Voraussetzungen haben sich verschoben. Die aktuelle Dokumentation verlangt PowerShell 7.6. Windows PowerShell 5.1 braucht es nur noch für den Local Configuration Manager.
• Das Werkzeug kann Schaden anrichten. Die Dokumentation sagt selbst, dass falsche Anwendung ernste Folgen haben kann. Teste deshalb nie zuerst im Produktiv-Tenant.

Warum ein Test-Tenant als Code

Änderungen an Richtlinien, Gruppen oder Freigaben gehören zuerst in eine Umgebung, in der ein Fehler nichts kostet. Dasselbe gilt für KI-Szenarien, etwa einen Agenten, der auf SharePoint-Inhalte und Gruppen zugreift. Ein leerer Test-Tenant hilft dabei kaum, weil ihm die Struktur fehlt, die im Betrieb den Unterschied macht.

Dazu kommt ein Zeitproblem. Microsoft schreibt zum Entwickler-Tenant im Developer Program, ein Abonnement laufe bis zu 90 Tage und Tenants könnten alle 90 Tage neu erstellt werden müssen. Wer dort testet, baut seine Umgebung regelmässig neu auf. Von Hand dauert das jedes Mal Stunden. Ein Export als Code verkürzt es auf einen Befehl und macht den Stand nachvollziehbar.

Was Microsoft365DSC ist

Microsoft365DSC ist ein PowerShell-Modul von Microsoft-Entwicklern, gepflegt von der Community. Die Einführung der Dokumentation nennt es die deklarative Form einer Tenant-Konfiguration und vergleicht es mit ARM-Vorlagen für Azure. Das Modul liest einen Tenant aus (Snapshot), wendet eine Konfiguration an, überwacht auf Abweichungen, klont einen Tenant auf einen anderen und vergleicht Konfigurationen. Dazu erzeugt es Berichte als CSV, HTML, Excel, Markdown oder JSON.

Der Stand zum Redaktionsschluss: Version 2.26.1021.1 erschien am 21. Oktober 2026 in der PowerShell Gallery, die Seite zeigt rund 3,3 Millionen Downloads. Ein Hinweis zur Einordnung steht ebenfalls in der Dokumentation: Das Projekt ist Open Source und nicht über die regulären Microsoft-Supportkanäle abgedeckt. Fehler meldest du im GitHub-Repository.

Voraussetzungen, ehrlich genannt

Die Voraussetzungen sind der Teil, an dem die meisten Versuche scheitern. Deshalb hier der Stand aus der Dokumentation vom Oktober 2026, nicht aus älteren Anleitungen.

Ein Wort zum Widerspruch in der Tabelle: Das Modulmanifest der aktuellen Version nennt PowerShellVersion = '5.1' und schränkt die Edition nicht ein, die Dokumentation verlangt dagegen 7.6. Wo beide abweichen, folgt dieser Artikel der Dokumentation. Prüfe vor dem Start die Seiten „Prerequisites“ und „PowerShell 7+ support“, denn sie ändern sich mit den Versionen.

Installieren und Abhängigkeiten holen

Das Modul kommt aus der PowerShell Gallery. Die Anleitung verlangt eine erhöhte Windows-PowerShell-5.1-Sitzung, weil sonst nur der Benutzerbereich entsteht, den der LCM nicht findet. Danach holst du die Abhängigkeiten, in beiden Editionen.

# Erhöhte Windows-PowerShell-5.1-Sitzung
Install-Module Microsoft365DSC -Force
Update-M365DSCDependencies

# Danach in einer erhöhten PowerShell-7-Konsole
Update-M365DSCDependencies
Enable-PSRemoting -Force -SkipNetworkProfileCheck

Update-M365DSCDependencies liest die Liste aus Dependencies/Manifest.psd1 im Modul und installiert die festgelegten Versionen. Führe den Befehl nach jedem Update aus. Ein Update des Moduls selbst erledigt Update-M365DSCModule, es entfernt auch ältere Versionen.

Berechtigungen vergeben

Der Export liest, das Einspielen schreibt. Das Modul trennt beides sauber: Get-M365DSCCompiledPermissionList liefert zu einer Liste von Ressourcen die minimalen Lese- und Schreibrechte. Dazu nimmt es für jede Graph-Ressource Organization.Read.All auf, ohne das jede Graph-Komponente mit „Failed to initialize Graph HTTP client“ scheitert.

# Welche Rechte brauchen diese beiden Ressourcen für den Export?
Get-M365DSCCompiledPermissionList `
  -ResourceNameList @('AADGroup','AADGroupsNamingPolicy') `
  -PermissionType 'Application' -AccessType 'Read'

# Delegierte Rechte der "Microsoft Graph PowerShell"-App einwilligen (Lesen im Quell-Tenant)
Update-M365DSCAllowedGraphScopes `
  -ResourceNameList @('AADGroup','AADGroupsNamingPolicy') -Type Read

# Vor dem Einspielen im Ziel-Tenant: Schreibrechte
Update-M365DSCAllowedGraphScopes `
  -ResourceNameList @('AADGroup','AADGroupsNamingPolicy') -Type Update

Die Dokumentation empfiehlt den Dienstprinzipal, weil er die feinsten Rechte erlaubt und keine hoch privilegierten Anmeldedaten über die Leitung schickt. Eine App-Registrierung mit Zertifikat legt Update-M365DSCAzureAdApplication an, samt Admin-Zustimmung und selbstsigniertem Zertifikat. Die Beispiele der Dokumentation zeigen dort Rechte für SharePoint. Die Graph-Rechte deiner Ressourcen holst du aus der Liste oben und trägst sie in der App ein.

Zu beachten: Hochprivilegierte Apps gehören überwacht. Die Dokumentation rät dazu, sie mit Conditional Access auf bestimmte Quellen oder Konten zu beschränken.

Export: gezielt nach Komponenten

Export-M365DSCConfiguration ist der Snapshot-Befehl. Ohne Parameter fragt er nach Anmeldedaten und exportiert die Standardkomponenten. Gezielter geht es mit -Components oder -Workloads. Der Parameter -Mode unterscheidet Default (nur Konfigurationsobjekte) und Full (zusätzlich Datenobjekte). Standardmässig fehlt, was sehr lange dauert oder eher Daten als Einstellungen sind, etwa Planner-Aufgaben oder SPOUserProfileProperty.

Export-M365DSCConfiguration `
  -Components @('AADGroup','AADGroupsNamingPolicy') `
  -ApplicationId $appId -TenantId 'quelle.onmicrosoft.com' `
  -CertificateThumbprint $thumb -Path C:\Dsc\Quelle

# Nur Gruppen, deren Name mit TST beginnt
$Filters = @{ AADGroup = "startsWith(displayName, 'TST')" }

Der Export läuft nach dem Muster: erst die Komponenten sammeln, dann je Workload anmelden, dann auslesen. Wer die Befehle nicht zusammenbauen will, startet mit -LaunchWebUI die Oberfläche unter export.microsoft365dsc.com. Dort wählst du Komponenten aus und kopierst den fertigen Befehl.

Was im Export steht

Der Export legt mehrere Dateien an. Die wichtigsten zwei sind M365TenantConfig.ps1 und ConfigurationData.psd1. Die Dokumentation zum Klonen beschreibt das Ziel so: Die Konfigurationsdatei enthält keine Angaben zum Quell-Tenant und führt alles als Variablen. Erst beim Kompilieren gibst du die Angaben der Zielumgebung mit.

Wichtig ist die Anmeldung. Die Datei übernimmt dieselbe Methode wie der Export: Mit Zertifikat-Fingerabdruck enthält jede Ressource ApplicationId, TenantId und CertificateThumbprint, deren Werte in der ConfigurationData.psd1 stehen. Die Ressourcen heissen in der Datei nach zufälligen GUIDs, die du frei umbenennen darfst, solange kein Name doppelt vorkommt.

# M365TenantConfig.ps1 (gekürzt, schematisch)
Configuration M365TenantConfig
{
    param ( ... )   # Anmeldedaten bzw. ApplicationId, TenantId, Zertifikat
    $OrganizationName = $ConfigurationData.NonNodeData.OrganizationName
    Import-DscResource -ModuleName 'Microsoft365DSC' -ModuleVersion '<Version>'
    Node localhost
    {
        AADGroup '<GUID>' { DisplayName = '...'; Description = '...'; ... }
    }
}

Ehrlich bleibt der Hinweis der Dokumentation selbst: Das Ziel sei, tenantspezifische Angaben nur in der ConfigurationData.psd1 zu speichern, doch an einigen Stellen stünden sie noch in der M365TenantConfig.ps1. Suche dort nach der Domain der Quelle, bevor du kompilierst. Der Parameter -TokenReplacement ersetzt bestimmte Werte im Export durch Variablen und hilft bei Szenarien über mehrere Tenants.

Kompilieren und im Ziel einspielen

Jetzt folgt die Arbeit am Ziel. Du trägst in der ConfigurationData.psd1 die Daten des Test-Tenants ein, kompilierst die Konfiguration zu einer MOF-Datei und wendest sie an. Die Dokumentation empfiehlt Invoke-M365DSCConfigurationBuild aus PowerShell 7. Es nimmt die ConfigurationData.psd1 neben dem Skript automatisch und bewahrt Eigenschaften mit leerem Array, die ein direkter Aufruf des Skripts in PowerShell 7 weglässt.

Invoke-M365DSCConfigurationBuild -Path C:\Dsc\M365TenantConfig.ps1

# Anwenden (Windows PowerShell 5.1, LCM)
Start-DscConfiguration -Path C:\Dsc\M365TenantConfig -Wait -Verbose -Force

# Einmalig einspielen, ohne dass der LCM weiter prüft
Stop-DscConfiguration -Force
Remove-DscConfigurationDocument -Stage Current

Dazu ein Sicherheitshinweis aus dem Kapitel „Securing your Configurations“: Bei Anmeldung mit Benutzername und Kennwort landet das Kennwort standardmässig im Klartext in der MOF-Datei. Mit Set-M365DSCAgentCertificateConfiguration erzeugst du ein Zertifikat, das die Zugangsdaten verschlüsselt. Mit einem Dienstprinzipal und Zertifikat entfällt das Problem.

Das Einspielen kann Minuten bis Stunden dauern, wie die Dokumentation schreibt, und der LCM prüft danach alle 15 Minuten auf Abweichungen. Für ein einmaliges Einspielen entfernst du die Konfiguration wieder, wie oben gezeigt.

Der Ablauf im Überblick

Vergleichen und Abweichungen erkennen

Der Vergleich ist oft nützlicher als das Einspielen. New-M365DSCDeltaReport nimmt zwei Konfigurationsdateien (-Source, -Destination) und schreibt einen HTML-Bericht mit allen Unterschieden nach -OutputPath. Nach der Dokumentation geht das für zwei Snapshots desselben Tenants zu verschiedenen Zeitpunkten und für zwei verschiedene Tenants, etwa Entwicklung und Produktion.

New-M365DSCDeltaReport `
  -Source C:\Dsc\Quelle\M365TenantConfig.ps1 `
  -Destination C:\Dsc\Test\M365TenantConfig.ps1 `
  -OutputPath C:\Dsc\Delta.html

New-M365DSCReportFromConfiguration -Type 'Markdown' `
  -ConfigurationPath C:\Dsc\Quelle\M365TenantConfig.ps1 `
  -OutputPath C:\Dsc\Quelle-Bericht.md

Eine laufende Überwachung gibt es ebenfalls. Nach dem Einspielen prüft der LCM alle 15 Minuten, ob die Einstellungen im Tenant noch stimmen, und schreibt Abweichungen ins Ereignisprotokoll M365DSC. Stellst du den Konfigurationsmodus auf ApplyAndAutocorrect, setzt der LCM abweichende Werte selbst zurück. Im Test-Tenant ist das oft gewollt, im Produktiv-Tenant nur nach reiflicher Überlegung.

Wie sich ein Soll-Ist-Vergleich mit eigenen Graph-Skripten anfühlt, zeigt der Artikel zum Conditional-Access-Vergleich über mehrere Tenants. Beide Ansätze ergänzen sich: DSC beschreibt und setzt, ein Skript bewertet.

Die Technik dahinter: DSC, LCM, MOF

Microsoft365DSC setzt auf PowerShell Desired State Configuration auf. Microsoft Learn beschreibt DSC als deklarative Plattform mit drei Bausteinen. Eine Konfiguration legt fest, wie das Ziel aussehen soll. Ressourcen sind der Teil, der den Zustand herstellt und hält. Der Local Configuration Manager (LCM) fragt regelmässig ab, ob der Zustand noch stimmt, und ruft bei Abweichungen die Ressource auf.

Die Konfiguration wird zu einer MOF-Datei kompiliert, einem Format der Management-Welt, das dem LCM als Auftrag dient. Der Vorteil: Du beschreibst das Ergebnis, nicht den Weg. Microsoft Learn nennt DSC-Konfigurationen idempotent. Wendest du dieselbe Konfiguration zweimal an, ändert der zweite Lauf nichts mehr, weil der Zustand schon stimmt. Für Test-Tenants ist das ein Gewinn, denn ein abgebrochener Lauf lässt sich einfach wiederholen.

Praxis: Vorlage für Test-Tenants

Eine gute Vorlage ist klein und gezielt. Sie enthält, was ein Test-Tenant haben muss, damit er sich wie der Produktiv-Tenant verhält. Dazu zählen bei vielen Firmen eine Namenskonvention für Gruppen und eine Beschreibung, die den Zweck jeder Gruppe nennt. Beides lässt sich mit zwei Ressourcen ausliefern: AADGroupsNamingPolicy für die Regel und AADGroup für die Gruppen samt Beschreibung.

Das folgende Beispiel baut auf den Eigenschaften der beiden Ressourcen auf (PrefixSuffixNamingRequirement, CustomBlockedWordsList, DisplayName, MailNickname, Description, SecurityEnabled, MailEnabled). Die Namen und Texte sind frei gewählt und ein Muster, kein Standard.

AADGroupsNamingPolicy 'Namenskonvention'
{
    IsSingleInstance              = 'Yes'
    PrefixSuffixNamingRequirement = 'TST_[GroupName]'
    CustomBlockedWordsList        = @('Payroll','CEO')
    Ensure                        = 'Present'
    ApplicationId                 = $ApplicationId
    TenantId                      = $TenantId
    CertificateThumbprint         = $CertificateThumbprint
}

AADGroup 'Testgruppe-Vertrieb'
{
    DisplayName     = 'TST_Vertrieb'
    MailNickname    = 'tst-vertrieb'
    Description     = 'Testgruppe für Berechtigungstests im Vertrieb. Enthält nur Testkonten.'
    SecurityEnabled = $true
    MailEnabled     = $false
    Ensure          = 'Present'
    ApplicationId   = $ApplicationId
    TenantId        = $TenantId
    CertificateThumbprint = $CertificateThumbprint
}

Dabei gilt laut Microsoft Learn: Die Namensrichtlinie greift für Microsoft-365-Gruppen, die Nutzer anlegen, und sie setzt eine Entra-ID-P1-Lizenz voraus. Globale Administratoren sind ausgenommen. Eine Sicherheitsgruppe wie im Beispiel bekommt die Konvention nur, wenn du den Namen selbst so vergibst.

Ein Muster, das sich bewährt: Eine Vorlage pro Zweck. Eine für Grundstruktur und Gruppen, eine für Sicherheitseinstellungen, eine für SharePoint. Die Dokumentation rät ohnehin, Workloads auf mehrere Konfigurationsdateien zu verteilen, damit sie überschaubar bleiben. Die Cmdlets Join-M365DSCConfiguration und Split-M365DSCConfiguration stehen im Modulmanifest; prüfe ihre Hilfe, bevor du sie einsetzt.

Grenzen, die du kennen solltest

• Nicht alles ist exportierbar. Unterstützt sind die Ressourcen im Modul. Was keine Ressource hat, fehlt im Export.
• Daten sind keine Konfiguration. Der Standardmodus exportiert nur Konfigurationsobjekte. Postfächer, Dateien und Benutzerdaten verschiebt das Modul nicht.
• Lizenzen müssen im Ziel stimmen. Sechs Ressourcen für Defender for Office 365 brauchen laut README Plan 2, etwa EXOSafeLinksPolicy. Unterstützt sind Microsoft 365 E5, E3 mit Defender-Plan-2-Zusatz und Office 365 E5. Microsoft 365 E3 allein genügt für diese sechs nicht.
• Der Entwickler-Tenant ist nur für die Entwicklung gedacht. Die FAQ nennt 25 Lizenzen und schliesst jede andere Nutzung als Entwicklung aus. Für Demos vor Kunden brauchst du einen eigenen Test-Tenant mit passender Lizenz.
• Die Laufzeit kann lang sein. Die Dokumentation spricht von Minuten bis Stunden. Der Parameter -Parallel beschleunigt den Export nicht in jedem Fall und braucht laut Dokumentation viel Arbeitsspeicher (empfohlen sind 8 GB oder mehr).
• Die Anmeldung ist je Workload verschieden. Nicht jede Workload unterstützt jede Methode, und der Export warnt, wenn Komponenten mit der gewählten Methode nicht erreichbar sind.
• Geheimnisse bleiben ein eigenes Thema. Zertifikate und Kennwörter gehören in einen Tresor. Was der Export zu Geheimnissen enthält, belegt die Dokumentation nicht im Detail. Prüfe jede Exportdatei, bevor du sie in ein Repository legst.

Alternativen kurz eingeordnet

Für einzelne SharePoint-Sites gibt es PnP-Provisioning: Get-PnPSiteTemplate erzeugt aus einer Site eine Vorlage in XML oder als .pnp-Paket, mit Listen, Inhaltstypen, Sicherheit und Branding. Die Dokumentation von PnP PowerShell warnt, dass Vorlagen ohne ihre Abhängigkeiten nicht funktionieren können. Das passt, wenn du eine Site klonen willst, aber nicht den ganzen Tenant.

Graph-Skripte sind die Alternative für Dinge ohne Ressource. Du schreibst sie selbst, bekommst volle Kontrolle und trägst die Pflege allein. Bei vielen Teams liegt der Mittelweg: Microsoft365DSC für die Breite, Skripte für die Lücken und den Soll-Ist-Vergleich. Wer Microsoft-365-Daten für KI-Agenten öffnet, findet im Artikel zum MCP-Server für Microsoft 365 einen Anlass mehr, vorher in einem Test-Tenant zu üben.

Einordnung: Was das für Admins und IT-Dienstleister heisst

Für Admins ist der Gewinn ein reproduzierbarer Test-Tenant: Zugang klären, Vorlage exportieren, kompilieren, einspielen, vergleichen. Das spart nach jeder Neuerstellung des Entwickler-Tenants Stunden und macht Änderungen vorab prüfbar. Dienstleister erhalten eine Grundlage, die sich je Kunde mit anderen Werten einspielen lässt, ohne jedes Mal bei null zu beginnen. Plane den Aufwand ehrlich ein. Die Umstellung auf PowerShell 7.6, die Berechtigungen und die Pflege der Vorlage kosten Zeit, und das Projekt hat keinen regulären Microsoft-Support. Beginne mit zwei Ressourcen, einer Gruppe und einer Namensregel, und baue die Vorlage erst aus, wenn dieser Lauf im Test-Tenant sauber durchgeht.

Fazit

Microsoft365DSC macht aus einem Tenant eine Vorlage, die du exportieren, anpassen, einspielen und vergleichen kannst. Die Hürden liegen bei PowerShell 7.6, den Berechtigungen und der Tatsache, dass nicht jede Einstellung eine Ressource hat. Starte mit einem kleinen Export, prüfe ihn im Test-Tenant und erweitere die Vorlage Schritt für Schritt.

Quellen: Microsoft365DSC, Dokumentation, Microsoft365DSC auf GitHub (Prerequisites, PowerShell 7+ support, Deploying, Cloning Tenants), Microsoft365DSC in der PowerShell Gallery, PowerShell DSC bei Microsoft Learn, Microsoft 365 Developer Program FAQ, Gruppen-Namensrichtlinie in Entra ID, Get-PnPSiteTemplate. Foto: Haer_breizh / Pixabay. Zuletzt geprüft: 25. Oktober 2026.

Geschrieben von Andreas Brauckmann · So arbeitet die Redaktion