Fortgeschrittene Abfragen für dynamische Autopilot-Gruppen im Produktivbetrieb (Autopilot v1)

Table of Contents

Open Table of Contents

• Warum die Ein-Tag-Regel irgendwann nicht mehr reicht
• Mehrere Tags in der Abfrage für eine dynamische Autopilot-Gruppe
• Die Abfrage mit einer zweiten Bedingung eingrenzen (AND)
• Präfix-Familien mit -startsWith erfassen
• Ausschlüsse und der Fehler, den fast jeder einmal macht
• Tag-Muster mit -match abgleichen
• Kurzreferenz
• Einfach halten: Der Wartungsaufwand ist der eigentliche Preis
• Ein Hinweis zu Autopilot v2

Warum die Ein-Tag-Regel irgendwann nicht mehr reicht

Ich habe im Laufe der Jahre Dutzende Abfragen für dynamische Autopilot-Gruppen geschrieben, und fast jede beginnt gleich:

(device.devicePhysicalIds -any (_ -eq "[OrderID]:scloud"))

Ein Group Tag. Eine dynamische Gruppe. Ein Autopilot-Profil. Für einen einzelnen Standort oder einen einzelnen Kunden funktioniert das gut. Sobald du mehr als eine Handvoll Standorte, Business Units oder Hardware-Chargen verwaltest, bricht das schnell zusammen. Dann landest du entweder bei Dutzenden fast identischer Gruppen. Oder du fängst an, die Ein-Tag-Regel für Dinge zu missbrauchen, für die sie nie gedacht war.

Genau in dieses Problem bin ich bei einem Kunden mit zwölf Filialen hineingelaufen. Ein Tag pro Filiale hätte zwölf dynamische Gruppen und zwölf Profile bedeutet, die ich hätte synchron halten müssen. Ab diesem Punkt habe ich eine richtige Abfrage für eine dynamische Autopilot-Gruppe gebaut, statt eine Regel pro Tag zu pflegen.

Dieser Beitrag zeigt die Abfragemuster, die ich tatsächlich im Produktivbetrieb einsetze. Zuerst zeige ich dir, wie du mehrere Tags gleichzeitig matchst. Danach geht es darum, Tags korrekt auszuschliessen, denn hier gibt es einen echten Stolperstein. Zum Schluss zeige ich dir, wie du ganze Tag-Familien per Präfix erfasst. Alles Folgende gilt für Windows Autopilot v1, das klassische Deployment-Profil-Modell rund um dynamische Azure-AD- und Entra-ID-Gerätegruppen. Du setzt Group Tags beim Hash-Upload oder bei der Registrierung. Wenn du gerade Autopilot v2 (Device Preparation) ausrollst, spring direkt zum Hinweis am Ende. Dort funktioniert die Gruppierung anders.

Mehrere Tags in der Abfrage für eine dynamische Autopilot-Gruppe

Die häufigste Anfrage, die ich bekomme, ist einfach: Alle Geräte mit einem dieser Tags sollen in eine Gruppe. Du kannst Bedingungen mit -or verketten:

(device.devicePhysicalIds -any (_ -eq "[OrderID]:HQ")) -or
(device.devicePhysicalIds -any (_ -eq "[OrderID]:Branch01")) -or
(device.devicePhysicalIds -any (_ -eq "[OrderID]:Branch02"))

Oder du matchst kompakter gegen eine Liste mit -in:

(device.devicePhysicalIds -any (_ -in ["[OrderID]:HQ","[OrderID]:Branch01","[OrderID]:Branch02"]))

Mein Tipp: Wechsle zur -in-Form, sobald du mehr als zwei oder drei Tags hast. Sie ist kürzer zu schreiben. Vor allem aber ist sie in sechs Monaten leichter zu überblicken und zu erweitern, wenn jemand einen vierten Standort dazu haben möchte.

Die Abfrage mit einer zweiten Bedingung eingrenzen (AND)

Manchmal reicht das Tag allein nicht aus. Du willst Geräte mit einem bestimmten Tag, aber nur, wenn sie zusätzlich ein zweites Signal erfüllen, etwa ein bestimmtes OS-SKU oder eine bestimmte Gerätekategorie. Kombiniere beides mit -and:

(device.devicePhysicalIds -any (_ -eq "[OrderID]:Kiosk")) -and
(device.deviceOSType -eq "Windows")

Ich greife zu diesem Muster, wenn ein Tag für mehr als einen Zweck wiederverwendet wird. Dann brauche ich ein zweites Kriterium, um Geräte zu unterscheiden. Das ersetzt aber nicht, von Anfang an ein spezifischeres Tag zu vergeben. Dazu gleich mehr.

Präfix-Familien mit -startsWith erfassen

Wenn deine Namenskonvention bereits eine Hierarchie im Tag codiert, musst du die Werte selten einzeln aufzählen. Nehmen wir an, jeder Managed-Service-Kunde bekommt ein Tag wie Cust-Contoso oder Cust-Fabrikam. Erfasse die ganze Familie mit -startsWith:

(device.devicePhysicalIds -any (_ -startsWith "[OrderID]:Cust-"))

Ich nutze dieses Muster für eine “Master”-Gruppe. Sie stellt ein Basisprofil oder eine Compliance-Richtlinie für alle verwalteten Kunden auf einmal bereit. Jede einzelne Cust-<Name>-Gruppe behält trotzdem ihre eigene dynamische Gruppe und ihr eigenes Autopilot-Profil.

Ausschlüsse und der Fehler, den fast jeder einmal macht

Hier ist der Klassiker, der fast jeden erwischt, mich eingeschlossen. Der erste Instinkt ist, ein Tag mit -any (_ -ne "…") auszuschliessen:

(device.devicePhysicalIds -any (_ -eq "[OrderID]:HQ")) -and
(device.devicePhysicalIds -any (_ -ne "[OrderID]:Decommissioned"))     ❌ fast immer wahr

Das sieht korrekt aus und wird auch von der Validierung akzeptiert. Es tut aber nicht das, was du erwartest. devicePhysicalIds ist eine mehrwertige Eigenschaft. Die Klausel -any (_ -ne "X") fragt, ob mindestens ein Wert im Array nicht X ist. Das trifft auf fast jedes Gerät zu. Ein Gerät hat viele physische IDs: Seriennummer, Hardware-Hash-Referenz, ZTDID und eben auch das Order- beziehungsweise Group Tag. Die -ne-Klausel matcht also still und leise alle, egal ob Ausschluss-Tag oder nicht.

Ich bin selbst erst darauf gestossen, als ich eine “Ausschlussregel” geprüft habe, die am Ende gar nichts ausschloss. Der korrekte Weg, einen Wert aus einer mehrwertigen Eigenschaft auszuschliessen, ist -all mit -ne, nicht -any:

(device.devicePhysicalIds -any (_ -eq "[OrderID]:HQ")) -and
(device.devicePhysicalIds -all (_ -ne "[OrderID]:Decommissioned"))     ✅ korrekt

-all (_ -ne "X") bedeutet, dass jeder Wert im Array nicht X ist. Also ist keiner davon X. Genau das ist der Ausschluss, den du willst. Es lohnt sich, jede bereits produktiv laufende Ausschlussregel damit gegenzuprüfen. Eine Regel, die sich im Portal sauber validieren lässt, tut nicht automatisch das, was du beabsichtigt hast.

Mein Rat: Wenn du überhaupt per Tag ausschliessen willst, frag dich zuerst, ob es einfacher geht. Eine separate statische Gruppe, etwa “ausgemustert” oder “nicht ausrollen”, die auf Zuweisungsebene ausgeschlossen wird, ist meist einfacher zu prüfen. Das ist oft nachvollziehbarer, als den Ausschluss in die dynamische Regel einzubacken. Der Ausschluss dynamischer Gruppen bei Zuweisungen hat allerdings eigene Tücken. Die beschreibe ich in Intune Zuweisungslogik: Was funktioniert und was alles schiefgehen kann.

Tag-Muster mit -match abgleichen

Für Namenskonventionen, die kein einfaches Präfix sind, hilft -match mit einem regulären Ausdruck. Nehmen wir an, deine Tags haben einen Regionscode in der Mitte, wie EU-Retail-HQ gegenüber US-Retail-HQ:

(device.devicePhysicalIds -any (_ -match "^\[OrderID\]:EU-.*-HQ$"))

Setze das sparsam ein. Regex-Regeln sind mächtig, aber sie sind auch das Muster auf dieser Seite, das man am schwersten auf einen Blick liest. Sie sind auch am leichtesten subtil falsch zu machen. Die ^- und $-Anker sind wichtig: Ein nicht verankertes Muster kann mehr matchen, als du beabsichtigst. Wenn eine Kombination aus -startsWith und -in ausreicht, nimm die.

Kurzreferenz

Szenario	Muster für die Mitgliedschaftsregel	Wann einsetzen
Einzelnes Tag	(device.devicePhysicalIds -any (_ -eq "[OrderID]:X"))	Ein Standort, ein Kunde, ein Profil: der Standardfall
Mehrere Tags (OR)	(device.devicePhysicalIds -any (_ -in ["[OrderID]:A","[OrderID]:B"]))	Mehrere Standorte oder Tags teilen sich ein Autopilot-Profil oder eine Richtlinie
Mit zweitem Signal eingrenzen (AND)	Tag-Regel -and (device.deviceOSType -eq "Windows")	Ein Tag wird mehrfach verwendet und braucht eine Unterscheidung
Präfix-Familie	(device.devicePhysicalIds -any (_ -startsWith "[OrderID]:Cust-"))	Die Namenskonvention codiert die gewünschte Gruppierung bereits
Tag ausschliessen	Tag-Regel -and (device.devicePhysicalIds -all (_ -ne "[OrderID]:X"))	Selten: besser eine statische Ausschlussgruppe verwenden
Muster- oder Regionsabgleich	(device.devicePhysicalIds -any (_ -match "^\[OrderID\]:EU-.*-HQ$"))	Die Namenskonvention ist kein einfaches Präfix, und -startsWith/-in reicht nicht

Einfach halten: Der Wartungsaufwand ist der eigentliche Preis

Jede zusätzliche Klausel in einer dynamischen Mitgliedschaftsregel muss ein künftiger Admin erst verstehen. Dieser Admin bist vielleicht du selbst, in acht Monaten, ohne Erinnerung, warum die Klausel dort steht. Er muss sie verstehen, bevor er ein Tag umbenennen, einen Standort hinzufügen oder debuggen kann, warum ein Gerät in der falschen Gruppe gelandet ist. Eine fünfzeilige Regel mit drei -or-Zweigen und einer -match-Regex ist einmal geschrieben nicht schwer. Dauerhaft gepflegt zu werden, ist sie schon.

Ein paar Gewohnheiten zahlen sich langfristig aus:

• Dokumentiere die Absicht direkt bei der Gruppe. Verlass dich nicht auf ein Wiki, das niemand öffnet. Eine einzeilige Beschreibung an der Gruppe selbst, etwa “alle EU-Retail-HQ-Geräte, Tag-Präfix EU-Retail-HQ”, erspart der nächsten Person, die Regex reverse-engineeren zu müssen.
• Bevorzuge mehrere gut benannte, einfache Gruppen statt einer cleveren Mega-Regel. Die Auswertung dynamischer Gruppen ist bei typischen Flottengrössen schnell genug. Deshalb kostet “mehr Gruppen” selten etwas Reales. Lesbarkeit ist hier mehr wert als Cleverness.
• Prüfe Ausschlussregeln regelmässig neu, besonders auf den -any-versus--all-Fehler von oben. Es ist leicht, eine alte Regel einfach weiterzukopieren, ohne nochmal zu prüfen, ob sie noch tut, was sie soll.

Ein Hinweis zu Autopilot v2

Alles oben Beschriebene gilt spezifisch für Autopilot v1. Das Group Tag eines Geräts liegt in devicePhysicalIds, und dynamische Mitgliedschaftsregeln routen Geräte zu Profilen. Autopilot v2 (Device Preparation) nutzt dieses Modell nicht. Stattdessen gruppiert die Device-Preparation-Richtlinie Geräte zum Zeitpunkt der Registrierung, über ihre eigene Konto- oder Gruppenzuweisung während der OOBE. Es gibt kein Group Tag, das eine dynamische Regel im Nachhinein per Pattern-Matching auswerten müsste. Wenn du gerade ein neues v2-Rollout aufbaust, baue diese Group-Tag-Muster nicht nach. Nutze stattdessen die vorgesehene Gruppierung zum Registrierungszeitpunkt. Die dynamischen Regeln in diesem Beitrag gelten nur für v1.