SharePoint Site-Erstellung über Microsoft Graph – endlich

Auf dieses Feature hab ich lange gewartet. Jahre, eigentlich. Und wenn du jemals eine Site-Provisioning-Lösung auf SharePoint Online gebaut hast, weißt du genau, was ich meine.

Auf der Ignite 2025 hat Microsoft eher leise etwas geliefert, worauf viele von uns schon nicht mehr gehofft hatten: einen ordentlichen Graph API Endpoint, um SharePoint Site Collections zu erstellen. Die Ankündigung im Microsoft 365 Developer Blog kam am 24. November mit den Details. Keine CSOM-Hacks mehr. Kein Kampf mit der Legacy SharePoint REST API. Einfach ein sauberer POST Request auf /sites und du bekommst eine neue Site Collection. Das war’s.

Warum das wichtig ist

Bis jetzt hieß SharePoint Sites programmatisch erstellen eines von zwei Dingen:

1. CSOM / PnP PowerShell – Aufrufe in das SharePoint-spezifische Client Object Model, das die SharePoint Admin URL braucht und den ganzen Ballast der Legacy API Surface mitbringt.
2. SharePoint REST API – /_api/SPSiteManager/create verwenden, was funktioniert, aber komplett außerhalb des Graph-Ökosystems lebt.

Beide Ansätze teilen eine schmerzhafte Eigenschaft: sie brauchen Sites.FullControl.All. Das ist ein Tenant-weiter, nuklearer Permission Scope. Deine App bekommt Full Control über jede Site im Tenant, nur weil sie neue erstellen muss. Jedes Security Review, in dem ich je war, hat das sofort angemerkt.

Der neue Graph Endpoint behebt das. Die Create Site API-Referenz auf Microsoft Learn hat die vollständige Spezifikation.

Die neue Berechtigung: Sites.Create.All

Das ist die eigentliche Headline. Microsoft hat einen neuen Permission Scope namens Sites.Create.All eingeführt. Er macht genau das, was der Name sagt – er lässt deine App Sites erstellen und sonst nichts.

Hier die Permission Matrix:

Der clevere Teil: Sites.Create.All ist designed, um mit Sites.Selected zusammenzuarbeiten. Wenn deine App eine neue Site erstellt, bekommt sie automatisch Sites.Selected mit FullControl auf genau dieser Site – und nur dieser Site. Deine App kann die Site provisionieren und sie dann sofort konfigurieren (Listen erstellen, Templates anwenden, Berechtigungen setzen), ohne Tenant-weiten Zugriff zu brauchen.

Für Enterprise-Szenarien ist das ein großer Schritt. Du kannst tatsächlich eine Provisioning-App bauen, die ein Security Review besteht, ohne eine dreistündige Diskussion.

Eine Site über Graph erstellen, Schritt für Schritt

1. App registrieren und Berechtigungen vergeben

Im Azure Portal (oder über das Microsoft Entra Admin Center) fügst du folgende API Permission zu deiner App Registration hinzu:

• Microsoft Graph > Application Permissions > Sites.Create.All

Admin Consent erteilen. Ja, Admin Consent ist weiterhin erforderlich – aber der Scope selbst ist deutlich weniger gefährlich als Sites.FullControl.All.

2. Token holen

Standard OAuth 2.0 Client Credentials Flow. Nichts Besonderes:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https://graph.microsoft.com/.default
&client_secret={client-secret}
&grant_type=client_credentials

3. Eine Communication Site erstellen

Schick einen POST Request an den Beta /sites Endpoint:

POST https://graph.microsoft.com/beta/sites
Content-Type: application/json
Authorization: Bearer {access-token}

{
  "name": "Project Aurora",
  "webUrl": "https://contoso.sharepoint.com/sites/project-aurora",
  "locale": "en-US",
  "shareByEmailEnabled": false,
  "description": "Communication site for Project Aurora updates",
  "template": "sitepagepublishing",
  "ownerIdentityToResolve": {
    "email": "alex@contoso.com"
  }
}

Die template Property akzeptiert zwei Werte:

Wichtig: Es gibt kein group Template. Microsoft hatte ursprünglich geplant, die Erstellung von Group-connected Team Sites über diesen Endpoint zu unterstützen, aber es funktionierte nicht zuverlässig und wurde zurückgezogen. Wenn du eine Group-connected Team Site brauchst, erstelle zuerst die Microsoft 365 Group (via POST /groups) und die Site wird automatisch provisioniert.

4. Die Response verarbeiten

Wenn der Request erfolgreich ist, bekommst du ein 202 Accepted mit einem Location Header zurück:

HTTP/1.1 202 Accepted
Location: https://graph.microsoft.com/beta/sites/getOperationStatus(operationId='JXMnaHR0cHMlM0...')

Die Site-Erstellung ist asynchron. Der Location Header zeigt auf einen Operation Status Endpoint, den du pollen kannst:

GET https://graph.microsoft.com/beta/sites/getOperationStatus(operationId='JXMnaHR0cHMlM0...')
Authorization: Bearer {access-token}

Geduld ist hier gefragt. In meinen Tests dauert es ungefähr fünf bis zehn Minuten, bis die Site vollständig provisioniert und auffindbar ist. Geh nicht davon aus, dass es sofort geht.

5. Eine Team Site erstellen (ohne Group)

Selber Endpoint, anderes Template:

POST https://graph.microsoft.com/beta/sites
Content-Type: application/json
Authorization: Bearer {access-token}

{
  "name": "Engineering Wiki",
  "webUrl": "https://contoso.sharepoint.com/sites/engineering-wiki",
  "locale": "en-US",
  "shareByEmailEnabled": true,
  "description": "Internal engineering knowledge base",
  "template": "sts",
  "ownerIdentityToResolve": {
    "email": "eng-lead@contoso.com"
  }
}

Das war’s auch schon. Zwei Templates, ein Endpoint.

Vergleich mit den alten Ansätzen

So schlägt sich die neue Graph API gegenüber den alten Methoden:

Die Graph API gewinnt bei Berechtigungen und Ökosystem-Integration. Die Legacy-Ansätze gewinnen noch bei Reife und Feature-Vollständigkeit. Für neue Projekte würd ich mit der Graph API starten. Für bestehende Lösungen, die auf Group-connected Sites angewiesen sind, bleib erstmal bei PnP PowerShell.

Anwendungsfälle

Ein paar Szenarien, die vorher mühsam waren und jetzt deutlich einfacher sind:

Self-Service Site Requests. Bau einen Approval Workflow in Power Automate oder Logic Apps. User reicht einen Request ein, Manager genehmigt, der Flow ruft die Graph API auf, um die Site zu provisionieren. Kein Admin-Eingriff nötig.

Automatisierte Projekt-Workspaces. Wenn ein neues Projekt in deinem Projektmanagement-System angelegt wird, automatisch eine SharePoint Site mit standardisierter Struktur hochfahren. Die Sites.Create.All + Sites.Selected Kombi bedeutet, deine Integration hat nur Zugriff auf die Sites, die sie selbst erstellt hat.

Tenant-Migrationen. Von einem Tenant zu einem anderen migrieren? Die Site-Erstellung per Skript über die Graph API in Bulk machen, dann den automatischen Sites.Selected Grant nutzen, um Content zu befüllen.

Dev/Test-Umgebungen. Test-Sites hochfahren, Integration Tests laufen lassen, wieder abreißen. Das niedrigere Permission Model macht das viel sicherer als vorher.

Was noch nicht funktioniert

Ein paar Dinge, die du wissen solltest:

• Nur Beta. Dieser Endpoint lebt unter /beta. Microsoft sagt explizit, dass Beta APIs sich ändern können und nicht in Production verwendet werden sollten. Auf eigenes Risiko – wobei ich vermute, dass GA bald kommt.
• Keine Group-connected Team Sites. Wie erwähnt, das group Template wurde entfernt. Du kannst keine Team Site mit einer verknüpften Microsoft 365 Group über diese API erstellen.
• Kein Graph PowerShell Cmdlet. Es gibt noch kein New-MgSite Cmdlet. Du musst Invoke-MgGraphRequest mit dem rohen Endpoint verwenden. Das SDK wird nachziehen, sobald die API Metadata verarbeitet sind.
• Kein Membership Management. Es gibt keine Graph API, um Site Members über diesen Endpoint hinzuzufügen. Du musst Membership separat handeln, über SharePoint-spezifische APIs oder indem du Berechtigungen über den /sites/{site-id}/permissions Endpoint vergibst.
• Provisioning-Verzögerung. Sites brauchen fünf bis zehn Minuten, bis sie vollständig verfügbar sind. Plane deine Automation entsprechend – häng keine abhängigen Operationen direkt nach der Erstellung an.
• Admin Consent erforderlich. Auch wenn Sites.Create.All weniger Rechte hat, braucht es trotzdem Tenant Admin Consent. Für ISVs, die Multi-Tenant Apps vertreiben, bleibt das ein Reibungspunkt.

Copilot Agents und Self-Service-Provisionierung

Ein Szenario, das mir nicht aus dem Kopf geht: Copilot Agents. Jetzt wo die in Microsoft 365 Realität sind, stell dir folgenden Flow vor:

Ein User öffnet Teams und sagt zu einem Custom Copilot Agent: “Ich brauch eine neue Projekt-Site für Project Aurora mit Standard-Dokumentbibliotheken und einem Projekt-Tracker.”

Der Agent:

1. Validiert den Request gegen deine Naming Conventions und Governance Policies.
2. Ruft die Graph API mit Sites.Create.All auf, um die Site zu provisionieren.
3. Nutzt den automatischen Sites.Selected Grant, um die Site zu konfigurieren – Listen erstellen, Site Template anwenden, Navigation einrichten.
4. Meldet dem User die Site-URL zurück.

Kein Portal. Kein Ticket. Kein Warten. Das Permission Model macht es sicher, das End-to-End zu automatisieren, weil der Agent immer nur Zugriff auf die Sites hat, die er selbst erstellt hat.

Ich glaub, Sites.Create.All wurde genau für solche Szenarien konzipiert. Das ist ehrlich gesagt der Aspekt, der mich an der neuen API am meisten begeistert – nicht nur Site-Erstellung per Skript, sondern Agent-gesteuerte, konversationelle Provisionierung, bei der Governance von Anfang an eingebaut ist. Kein anderer Provisioning-Ansatz gibt dir die Kombination aus Least-Privilege-Berechtigungen und vollem Graph-Ökosystem-Zugang, die dieses Pattern im großen Maßstab sicher macht.

Wo wir jetzt stehen

Die SharePoint Site Creation API in Microsoft Graph war eines der meistgewünschten Features in der M365 Developer Community seit Jahren. Sie ist endlich da – in Beta, mit ein paar Ecken und Kanten, aber sie funktioniert. Allein die Sites.Create.All Berechtigung ist es wert, beachtet zu werden, weil sie ein echtes Sicherheitsproblem löst, das jede Enterprise-Provisioning-Lösung umgehen musste.

Ich erwarte, dass das irgendwann 2026 GA wird. Wenn das passiert, wird es der Standard-Weg, Sites programmatisch zu provisionieren. Fang jetzt mit der Beta an zu experimentieren, damit du bereit bist.

Weiterlesen

• SharePoint Site Creation in Microsoft Graph – Microsoft 365 Developer Blog – die offizielle Ankündigung mit API-Details und Permission Model
• Create site – Microsoft Graph beta API-Referenz | Microsoft Learn – vollständige Endpoint-Spezifikation, Request/Response-Schemas und Berechtigungsanforderungen
• SharePoint Showcase: Announcements at Microsoft Ignite 2025 – breiterer Kontext, wo die Site-Erstellung in die Ignite-Ankündigungen passt
• How to Use the Graph create Site API to Create New SPO Sites – Tony Redmond, Office 365 IT Pros – ein PowerShell-fokussierter Walkthrough, wenn du Connect-MgGraph gegenüber rohem HTTP bevorzugst