Wer Windows Autopilot in größeren Umgebungen ausrollt, steht schnell vor einer zentralen Herausforderung: Ein Notebook für den Standort Berlin braucht andere lokale Applikationen, WLAN-Profile und Netzwerkkonfigurationen als ein Gerät in München. Gleichzeitig benötigen aber beide Geräte zwingend dieselben grundlegenden Sicherheitsvorgaben, Unternehmenszertifikate und Standard-Software.
Die naive Lösung, für jeden Standort eine eigene Gruppe mit allen nötigen Richtlinien, führt schnell in eine Konfigurationsshölle aus redundanten Zuweisungen. Wenn ich eine neue Security Baseline einführe, muss ich sie jeder einzelnen Gruppe zuweisen. Fehler sind vorprogrammiert.
Die elegante Lösung ist ein intelligentes, mehrstufiges Modell aus Group Tags (OrderID) und dynamischen Entra ID Gerätegruppen. In diesem Beitrag erkläre ich das Setup anhand eines praxisnahen Architekturmodells, von der Konzeption bis zur fertigen Implementierung.
Was sind Autopilot Group Tags?
Beim Import eines Geräts in Intune (manuell, via Windows Autopilot Deployment Service oder über einen Reseller) kann eine sogenannte OrderID mitgegeben werden der Group Tag. Dieser Tag wird direkt am Geräteobjekt in Intune gespeichert und steht als device.devicePhysicalIds-Attribut in Entra ID zur Verfügung.
Das ist der Schlüssel zu allem, was folgt. Denn dynamische Entra ID Gruppen können auf dieses Attribut mit zwei Operatoren reagieren:
| Operator | Verhalten | Beispiel |
|---|---|---|
-contains | Prüft, ob der Tag die Zeichenkette enthält | office_berlin enthält office_ → ✅ Match |
-eq | Prüft, ob der Tag exakt gleich ist | office_berlin ist gleich office_berlin → ✅ Match |
Dieses Zusammenspiel ist das Fundament unseres Architekturmodells.
Das Architekturmodell: Zwei-Ebenen-Vererbung
Das Ziel ist eine sauber getrennte, aber miteinander verknüpfte Gruppenstruktur:
Ein Gerät mit dem Tag office_berlin landet automatisch in beiden Gruppen in Office-All via -contains und in Office-Berlin via -eq. Es bekommt damit sowohl die Baseline als auch die standortspezifische Konfiguration, vollständig ohne manuellen Eingriff.
Schritt-für-Schritt Implementierung
Erweiterungen und Variationen
Abteilungen statt Standorte
Das Modell funktioniert genauso gut für Abteilungstrennung:
office_ → Basis (alle)
office_it → IT-Abteilung (Admin-Tools, erhöhte Rechte via LAPS)
office_hr → HR (DSGVO-konforme Verschlüsselung, spez. Apps)
office_exec → Führungsebene (besonders restriktive Policies)Gerätetypen als zweite Dimension
Du kannst Group Tags auch mehrdimensional aufbauen:
laptop_berlin → Laptops in Berlin
desktop_munich → Desktops in München
kiosk_all → Alle Kiosk-Geräte (stark eingeschränkt)Schreibe dann für Kiosk eine eigene Basis-Gruppe mit -contains "kiosk_" und entsprechend restriktiven Policies.
Automatisiertes Tag-Setzen via Graph API
Für Umgebungen, in denen Geräte programmatisch importiert werden, kannst du den Group Tag direkt per Graph API setzen:
# Group Tag via Microsoft Graph API setzen
$deviceId = "<autopilot-device-id>"
$groupTag = "office_berlin"
$body = @{
groupTag = $groupTag
} | ConvertTo-Json
Invoke-MgGraphRequest `
-Method PATCH `
-Uri "https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotDeviceIdentities/$deviceId" `
-Body $body `
-ContentType "application/json"
Write-Host "Group Tag '$groupTag' erfolgreich gesetzt."Wenn du Fragen zu dieser Architektur hast schreibe doch gerne einen Kommentar!