Sektion 28: Custom Device Configurations: XML-Importe

Willkommen in Sektion 28 unserer Intune Masterclass. In den vorherigen Sektionen haben wir uns intensiv mit den nativen Konfigurationsprofilen von Microsoft Intune beschäftigt. Wir haben gesehen, wie bequem es ist, per Klick-Interface Einstellungen für Windows, iOS oder Android zu setzen. Doch in der Realität eines Enterprise-Administrators stößt man schnell an die Grenzen der GUI. Es gibt Einstellungen, die Microsoft in der Weboberfläche schlicht nicht anbietet, obwohl sie im Betriebssystem vorhanden sind.

Hier kommen Custom Device Configurations ins Spiel. In dieser Sektion tauchen wir tief in die Welt der XML-Importe und der OMA-URI (Open Mobile Alliance Uniform Resource Identifier) ein. Wenn du diese Sektion beherrschst, bist du nicht mehr auf das angewiesen, was Microsoft dir in das Menü legt, sondern du kannst nahezu jeden Registry-Wert und jede CSP-Einstellung (Configuration Service Provider) direkt ansteuern. Das ist der Moment, in dem du vom Anwender zum Power-User und echten Intune-Experten wirst.

Grundkonzepte: Was steckt hinter den Custom-Profilen?

Um Custom Configurations zu verstehen, müssen wir verstehen, wie Intune mit dem Endgerät kommuniziert. Intune sendet keine „Befehle“ im klassischen Sinne, sondern es synchronisiert Zustände. Die Sprache, die dabei auf Windows-Geräten gesprochen wird, ist die der Configuration Service Providers (CSPs).

Die Rolle der CSPs

Ein CSP ist im Grunde eine Schnittstelle im Windows-Betriebssystem, die es einem MDM-Server (wie Intune) ermöglicht, bestimmte Einstellungen zu lesen oder zu schreiben. Man kann sich einen CSP wie eine API für das Betriebssystem vorstellen. Jeder CSP ist für einen bestimmten Bereich zuständig, zum Beispiel der Policy CSP für Sicherheitsrichtlinien oder der WiFi CSP für Netzwerkverbindungen.

Die OMA-URI (Open Mobile Alliance URI)

Die OMA-URI ist der Pfad, über den Intune den CSP anspricht. Sie funktioniert wie ein Dateipfad. Ein Beispiel für eine OMA-URI sieht so aus:

./Vendor/MSFT/Policy/Config/Bluetooth/AllowBluetooth

In diesem Beispiel ist ./Vendor/MSFT/Policy/Config der Pfad zum Policy-CSP und Bluetooth/AllowBluetooth die spezifische Einstellung. Wenn wir in Intune ein „Custom“ Profil erstellen, sagen wir dem Gerät effektiv: „Gehe zu diesem Pfad und schreibe dort den Wert X hinein“.

Warum XML-Importe?

Während man einzelne OMA-URIs manuell in die Intune-Konsole eintippen kann, wird dies bei komplexen Konfigurationen (z.B. umfassenden Firewall-Regeln oder detaillierten WiFi-Profilen) unmöglich. Viele CSPs erwarten keine einfachen „Ja/Nein“-Werte, sondern strukturierte XML-Daten. Anstatt hunderte Zeilen XML in ein Textfeld zu kopieren, erlaubt Intune den Import von XML-Dateien, die direkt in die entsprechende CSP-Struktur überführt werden.

Praxis-Implementierung: Schritt für Schritt zum Custom Profil

Lass uns nun in die Praxis gehen. Wir nehmen ein konkretes Beispiel: Die Konfiguration eines komplexen WiFi-Profils oder einer spezifischen Sicherheitsrichtlinie, die in der GUI nicht verfügbar ist.

Schritt 1: Den richtigen CSP und die URI finden

Bevor du etwas konfigurieren kannst, musst du wissen, wo die Einstellung „wohnt“. Die wichtigste Ressource hierfür ist die offizielle Microsoft-Dokumentation für CSPs. Suche nach „Configuration Service Provider references“.

Wenn du beispielsweise die „Lock Screen“ Einstellungen tiefgreifend anpassen willst, suchst du nach dem Policy CSP. Dort findest du die exakte URI und den benötigten Datentyp (z.B. String, Integer oder XML).

Schritt 2: Die XML-Datei erstellen

Ein XML-Import in Intune ist oft eine Kombination aus einer OMA-URI und einem XML-Payload. Wenn der CSP eine XML-Struktur verlangt, muss diese exakt dem Schema entsprechen, das Windows erwartet. Ein häufiger Fehler ist die Verwendung von falschen Namespaces oder fehlenden Root-Elementen.

Beispiel für eine hypothetische XML-Struktur zur Definition von App-Locker-Regeln (stark vereinfacht):

<AppLockerPolicy>
  <RuleCollection Type="Exe">
    <PolicyType>Allow</PolicyType>
    <Rule>
      <Name>Allow Windows Folder</Name>
      <Conditions>
        <FilePathCondition Path="C:\Windows\*" />
      </Conditions>
    </Rule>
  </RuleCollection>
</AppLockerPolicy>

Schritt 3: Konfiguration in Intune anlegen

1. Navigiere zu Devices → Configuration profiles → Create profile.
2. Wähle als Plattform Windows 10 and later.
3. Wähle als Profiltyp Templates → Custom.
4. Klicke auf Add, um eine neue OMA-URI Einstellung hinzuzufügen.
5. Name: Gib einen sprechenden Namen an (z.B. „Custom AppLocker Policy“).
6. OMA-URI: Gib den vollständigen Pfad ein (z.B. ./Vendor/MSFT/Policy/Config/AppLocker/ApplicationPolicy).
7. Data type: Wähle String (wenn das XML als String übergeben wird) oder XML, falls die Option verfügbar ist.
8. Value: Hier kopierst du den Inhalt deiner XML-Datei hinein.

Fortgeschrittene Technik: PowerShell zur XML-Generierung

In einer echten Enterprise-Umgebung schreibst du XML-Dateien nicht von Hand. Du nutzt PowerShell, um die XML-Struktur dynamisch zu generieren, basierend auf deinen Anforderungen. Dies stellt sicher, dass keine Syntaxfehler passieren.

Hier ist ein Beispiel, wie du ein XML-Objekt in PowerShell erstellst und es als String exportierst, den du dann in Intune einfügen kannst:

# PowerShell Script zur Generierung eines XML-Payloads
$xmlSettings = New-Object System.Xml.XmlDocument
$root = $xmlSettings.CreateElement("CustomConfig")
$xmlSettings.AppendChild($root) | Out-Null

$setting = $xmlSettings.CreateElement("Setting")
$setting.SetAttribute("Name", "DisableTelemetry")
$setting.SetAttribute("Value", "1")
$root.AppendChild($setting) | Out-Null

# Konvertierung in einen kompakten String für Intune
$xmlString = $xmlSettings.OuterXml.Replace("`r`n", "").Replace(" ", "")
Write-Output "Kopiere diesen String in das Intune Value-Feld:"
Write-Output $xmlString

Best Practices für XML-Importe und Custom Profiles

Custom Profiles sind mächtig, aber sie sind auch „gefährlich“, da sie die Validierung der Intune-GUI umgehen. Ein kleiner Tippfehler in einer OMA-URI kann dazu führen, dass das Profil auf dem Client mit einem Fehler (0x87D101F4) fehlschlägt.

1. Das Prinzip der kleinstmöglichen Änderung

Versuche nicht, ein riesiges XML-Monster-Profil zu erstellen, das alles regelt. Teile deine Custom-Konfigurationen in logische Blöcke auf. Anstatt eines „Global-Custom-Profils“ erstelle lieber „Custom-WiFi“, „Custom-Security-Hardening“ und „Custom-App-Restrictions“. Das erleichtert das Troubleshooting massiv.

2. Test-Gruppe (Canary Deployment)

Custom-Einstellungen sollten NIEMALS direkt auf die gesamte Organisation ausgerollt werden. Da sie tiefer in das OS eingreifen, können sie unerwartete Nebenwirkungen haben. Nutze immer eine Testgruppe mit verschiedenen Hardware-Modellen und Windows-Builds.

3. Dokumentation der URIs

Da Intune in der Liste der Profile nur den Namen anzeigt, den du vergeben hast, verliert man schnell den Überblick, welche OMA-URI eigentlich gesetzt wurde. Führe eine interne Liste (z.B. in einem Wiki oder Git-Repo), in der du dokumentierst:

• Welche OMA-URI verwendet wird.
• Welchen Zweck die Einstellung hat.
• Woher die Quelle der Einstellung stammt (Link zur MS-Dokumentation).
• Welcher Wert aktuell gesetzt ist.

Troubleshooting: Wenn das Profil auf „Error“ steht

Es wird passieren: Ein Custom Profil wird fehlschlagen. Hier ist dein Schlachtplan zur Fehlerbehebung.

Die häufigsten Fehlerursachen

• Falsche URI: Ein Tippfehler in der URI führt dazu, dass Windows den Pfad nicht findet.
• Falscher Datentyp: Du hast „Integer“ gewählt, aber die URI erwartet einen „String“.
• Build-Inkompatibilität: Die CSP-Einstellung wurde erst in Windows 11 22H2 eingeführt, aber du rollst sie auf Windows 10 Geräte aus.
• Konflikte: Eine native Intune-Richtlinie setzt denselben Wert wie dein Custom-Profil. In diesem Fall gewinnt oft die native Richtlinie oder es entsteht ein „Conflict“-Status.

Analyse auf dem Client

Wenn Intune einen Fehler meldet, schau direkt auf dem Gerät nach. Der beste Ort dafür ist der Event Viewer:

Pfad: Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin

Suche nach Fehlern im Zusammenhang mit der OMA-URI. Windows loggt hier oft sehr präzise, warum ein Schreibvorgang fehlgeschlagen ist (z.B. „The parameter is incorrect“ oder „Access denied“).

Fazit

Custom Device Configurations über XML-Importe und OMA-URIs sind das „Schweizer Taschenmesser“ des Intune-Administrators. Sie erlauben es dir, die volle Kontrolle über das Endgerät zu übernehmen, unabhängig davon, ob Microsoft eine hübsche Checkbox in der Weboberfläche bereitgestellt hat oder nicht.

Zusammenfassend hast du gelernt:

• Dass CSPs die Schnittstellen zum OS sind und OMA-URIs die Adressen dieser Schnittstellen.
• Wie man XML-Payloads strukturiert und diese in Custom-Profilen hinterlegt.
• Dass PowerShell ein unverzichtbares Werkzeug zur Generierung valider XML-Strings ist.
• Wie man durch den Event Viewer auf dem Client echte Ursachen für Fehler findet.

Mit diesem Wissen bist du nun in der Lage, selbst komplexeste Enterprise-Anforderungen an deine Windows-Flotte heranzutragen. Im nächsten Schritt werden wir uns ansehen, wie wir diese Konfigurationen mit dynamischen Gruppen verknüpfen, um eine wirklich intelligente Infrastruktur aufzubauen.

↑ Zur Kursübersicht: Intune-Kurs (alle Sektionen)