Wie bereits in meinem letzten Blog zum Thema Configuration Service Provider (CSP) angeschnitten, verwenden Microsoft Intune Custom Configuration Profiles sogenannte OMA-URI-Einstellungen. OMA-URI steht in diesem Fall für "Open Mobile Alliance Uniform Resource Identifier" und könnte vereinfacht gesagt auch als Pfad zu einer bestimmten CSP Konfiguration oder Einstellung bezeichnet werden.
Heute möchte ich etwas genauer auf den Aufbau und die Verwendung von OMA-URI eingehen. Sehen wir uns hierfür zunächst einmal den Kommunikationsweg an.
Wie ebenfalls im oben verlinkten Artikel erwähnt, verwendet Microsoft für die Kommunikation "SyncML" und "OMA DM". Die Intune Policy wird hierbei in einer Art XML Format via OMA DM auf den Client übertragen und zeigt dort auf einen CSP, der wiederum mit einer Datei oder einem RegKey verbunden ist. Die folgende Grafik aus der entsprechenden Microsoft Referenz (https://docs.microsoft.com/de-de/troubleshoot/mem/intune/deploy-oma-uris-to-target-csp-via-intune) soll dies veranschaulichen.
Doch warum muss dieser Aufwand überhaupt betrieben werden? Schließlich scheint das Herausfinden der OMA-URI Pfade nicht gerade immer intuitiv oder anwenderfreundlich zu sein. Um diese Frage beantworten zu können, werfen wir zunächst einen Blick ins Admin Center.
Erstellt man sich ein neues Configuration Profile muss der Profile Type definiert werden. An dieser Stelle kann zwischen dem "Settings catalog" und den "Templates" unterschieden werden. Der Katalog umfasst demnach alle via UI setzbaren Einstellungen und soll dem Admin somit das Suchen und Setzen von Einstellungen erleichtern. Der Punkt Templates beinhaltet eine logische Gruppierung von Einstellungen oder Funktionen wie z.B. Zertifikate, VPN, WLAN etc.
Unabhängig vom Typ des verwendeten Profiles sind nun genau zwei Dinge festzuhalten:
- Im Vergleich zu On-Prem verfügbaren GPOs wird der ein oder andere schnell feststellen, dass der Umfang an möglichen Einstellungen über das Admin Center (immer noch) recht überschaubar ist. (Wird jedoch ständig erweitert :-))
- Auch die im Admin Center verfügbaren Einstellungen verwenden im Hintergrund OMA-URI und bieten mehr oder weniger nur eine vereinfachte Ansicht um dem oben angesprochenen Aufwand entgegen zu wirken.
Aufbau des OMA-URI Pfades
Versuchen wir nun anhand eines OMA-URI Pfades den Aufbau der CSPs etwas genauer zu beleuchten. Hierfür nehmen wir uns als Beispiel die wahrscheinlich bei vielen bekannte Möglichkeit den zuletzt angemeldeten Benutzer bei der Windows Anmeldung nicht anzeigen zu lassen (DontDisplayLastUsername).
Der Aufbau des Pfades setzt sich demnach aus vier Teilen zusammen. Zunächst findet sich der Scope (Device oder User) danach folgt der Root Knoten (bei allen Custom Configuration Profiles immer /Vendor/MSFT/Policy) gefolgt von der jeweiligen CSP Unterkategorie (Config oder Result) und der Information zu unserer Policy, die sich wiederum aus dem Namen der Policy und dem übergeordneten Bereich zusammen setzt.
Erstellen eines Custom Configuration Profile
Nachdem wir den Aufbau des OMA-URI Pfades nun analysiert haben, können wir zu unserem Profil zurückkehren. Wie bereits beschrieben benötigen wir zum setzen unserer Einstellung ein "Benutzerdefiniertes" Profil, welches unter Templates zu finden ist.
Innerhalb des Profils können über den "Add" Button neue OMA-URI Einstellungen hinzugefügt werden.
Nach erfolgreicher Zuweisung und Anwendung unserer Policy sollte der Client in der Anmeldemaske, wie gewünscht, den zuletzt angemeldeten Benutzer nicht mehr anzeigen.
Eine Liste der unter Windows 10 und 11 verfügbaren CSPs ist unter folgendem Link zu finden:
https://docs.microsoft.com/de-de/windows/client-management/mdm/configuration-service-provider-reference