## Einführung: Warum Settings Catalog das Game ändert
Das Settings Catalog ist nicht einfach nur eine weitere Option im Intune-Portal – es ist der fundamentale Wechsel von einer „vorkonfigurierten Menü“-Welt hin zu einer CSP-nativen Verwaltungsebene. Während Administrative Templates auf ADMX-Dateien basieren, die Microsoft bereitstellt und versioniert, arbeitet das Settings Catalog direkt mit den zugrundeliegenden Configuration Service Providers (CSPs).
**Der kritische Unterschied:**
| Administrative Templates | Settings Catalog |
|————————-|——————|
| ADMX-basiert (XML-Definitionen) | CSP-nativ (OMADM-Protokoll) |
| Microsoft kuratiert die verfügbaren Settings | Vollständiger Zugriff auf alle dokumentierten CSPs |
| Update-Zyklus an Windows/ADMX gebunden | Neue Settings sofort verfügbar, sobald CSP dokumentiert ist |
| Begrenzt auf vordefinierte Kategorien | Flachere Hierarchie, direkte CSP-Pfad-Zuordnung |
Für IT-Admins bedeutet das: Settings Catalog gibt dir Zugriff auf Settings, die in Administrative Templates nie erscheinen werden – insbesondere bei Edge Cases, Preview-Features oder herstellerspezifischen CSP-Erweiterungen.
—
## Technische Architektur: Vom UI zum CSP-Pfad
Jedes Setting im Settings Catalog mappt 1:1 auf einen OMADM-CSP-Pfad. Wenn du im Portal ein Setting konfigurierst, übersetzt Intune das in eine SyncML-Nachricht, die direkt an den entsprechenden CSP auf dem Client gesendet wird.
**Beispiel: BitLocker Konfiguration**
„`
CSP-Pfad: ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption
OMADM-URI: ./Vendor/MSFT/BitLocker/RequireDeviceEncryption
SyncML-Operation: Replace
„`
Das Settings Catalog UI abstrahiert diese Pfade – aber für Troubleshooting musst du sie verstehen. Die vollständige CSP-Dokumentation findest du unter:
`https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider`
**Wichtige CSP-Kategorien im Alltag:**
– `./Device/Vendor/MSFT/Policy/Config/…` – Die meisten Policy-Settings
– `./User/Vendor/MSFT/Policy/Config/…` – User-spezifische Policies
– `./Device/Vendor/MSFT/BitLocker/…` – BitLocker-Konfiguration
– `./Device/Vendor/MSFT/PassportForWork/…` – Windows Hello for Business
– `./Device/Vendor/MSFT/RemoteDesktop/…` – RDP-Einstellungen
—
## Settings Catalog vs. Administrative Templates: Wann was?
### Administrative Templates verwenden, wenn:
1. **Gruppenrichtlinien-Migration:** Du bestehende GPOs 1:1 nach Intune migrierst. ADMX-Struktur ist GPOs ähnlicher.
2. **Dokumentierte Best Practices:** Microsoft hat für das Setting explizite ADMX-basierte Empfehlungen.
3. **Legacy-Windows-Versionen:** Ältere Windows 10 Builds (vor 2004) haben unvollständige Settings Catalog-Unterstützung.
### Settings Catalog verwenden, wenn:
1. **Neue Windows-Features:** Ein Feature wurde gerade released und ist noch nicht in ADMX enthalten.
2. **Tiefere Kontrolle:** Du benötigst Settings, die in ADMX-Kategorien nicht sichtbar sind.
3. **CSP-Direct-Access:** Du arbeitest mit herstellerspezifischen CSPs (Surface Hub, HoloLens, IoT).
4. **Future-Proofing:** Microsoft verschiebt den Fokus klar zu Settings Catalog – neue Features erscheinen primär dort.
**Praktischer Test:** Suche im Portal dasselbe Setting in beiden Katalogen. Wenn es in beiden existiert, nimm Settings Catalog – es ist die zukunftssichere Wahl.
—
## Real-World Szenario 1: Windows Security Hardening
**Ausgangslage:** Ein Finanzdienstleister benötigt ein gehärtetes Windows 11 Image für Trading-Terminals. Anforderungen: Kein USB Storage, Deaktivierung von PowerShell für Standard-User, Erzwingung von Secure Boot + TPM 2.0, LAPS für lokale Admin-Passwörter.
**Profile-Struktur:**
„`
Profile-Name: SEC-WIN11-TradingTerminal-Hardening
Platform: Windows 10 and later
Profile-Type: Settings Catalog
Assignment: Alle Trading-Terminal Devices (AAD Device Group)
„`
**Konkrete Settings (Auszug):**
| Setting-Kategorie | Setting-Name | Wert | CSP-Pfad |
|——————|————–|——|———-|
| Device Guard | Allow Microsoft Signed Applications | Enable | ./Device/Vendor/MSFT/DeviceGuard/AllowMicrosoftSignedApplications |
| PowerShell | Enable PowerShell Script Block Logging | Enable | ./Device/Vendor/MSFT/Policy/Config/PowerShell/EnableScriptBlockLogging |
| USB | Allow USB Storage | Disable | ./Device/Vendor/MSFT/Policy/Config/Connectivity/AllowUSBStorage |
| LAPS | Enable Local Administrator Password Solution | Enable | ./Device/Vendor/MSFT/LAPS/Enable |
| Secure Boot | Require Secure Boot | Enable | ./Device/Vendor/MSFT/SecureBoot/RequireSecureBoot |
**Wichtig:** Manche Settings erfordern einen Reboot, um wirksam zu werden. Das Settings Catalog zeigt das nicht immer im UI an. Dokumentiere Reboot-Pflicht in deinem Change-Log.
**Verifikation per PowerShell (auf dem Client):**
„`powershell
# USB Storage Status prüfen
Get-ItemProperty -Path „HKLM:\SYSTEM\CurrentControlSet\Services\USBSTOR“ -Name „Start“
# PowerShell Script Block Logging prüfen
Get-ItemProperty -Path „HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging“ -Name „EnableScriptBlockLogging“
# LAPS Status
Get-ItemProperty -Path „HKLM:\Software\Policies\Microsoft Services\AdmPwd“ -Name „AdmPwdEnabled“
„`
—
## Real-World Szenario 2: Edge Browser Kiosk Mode
**Ausgangslage:** Ein Call-Center betreibt 200 Windows 10 Devices im Kiosk-Modus. Einzige erlaubte Anwendung: Microsoft Edge im Assigned Access Mode mit festgelegter Startseite, keine Navigation außerhalb der Whitelist, kein Download, kein Print-Screen.
**Profile-Struktur:**
„`
Profile-Name: EDGE-Kiosk-CallCenter-LockedDown
Platform: Windows 10 and later
Profile-Type: Settings Catalog
Assignment: Kiosk-Devices Device Group
„`
**Kritische Settings:**
| Setting-Kategorie | Setting-Name | Wert |
|——————|————–|——|
| Edge – Startup | Configure the home button | Enable (URL: https://intranet.callcenter.local) |
| Edge – Privacy | Prevent access to browser history | Enable |
| Edge – Downloads | Prevent downloading of files | Enable |
| Edge – Print | Prevent printing | Enable |
| Edge – Extensions | Control which extensions can be installed | Block all, whitelist nur benötigte |
| Kiosk Mode | Assigned Access Configuration | Single App Mode: Edge |
**Edge-spezifische CSPs:** Viele Edge-Settings liegen unter `./Device/Vendor/MSFT/Policy/Config/Edge~Policy~MicrosoftEdge/…` – die Tilde (~) ist Teil des CSP-Namens, kein Trennzeichen.
**Fallback-Strategie:** Wenn ein Edge-Setting im Settings Catalog nicht greift, prüfe den CSP-Pfad manuell via MDM-Diagnose-Tool. Manchmal ist das Setting nur für bestimmte Windows-Editionen freigegeben (z.B. Enterprise-only).
—
## Troubleshooting: Wenn Settings nicht ankommen
### Schritt 1: Intune Portal – Device Status prüfen
Navigiere zu: `Devices > All Devices > [Device-Name] > Device Profile`
Status-Werte:
– **Succeeded:** Policy wurde angewendet
– **Failed:** Fehlerdetails im Fehler-Tab anzeigen
– **Not Applicable:** Setting ist für diese OS-Version/Edition nicht verfügbar
– **Conflict:** Eine andere Policy überschreibt dieses Setting
### Schritt 2: Client-seitige Diagnose
Auf dem Windows-Client:
„`powershell
# MDM-Diagnose-Tool ausführen
cd „C:\Program Files\Windows Security\MDMDiagnostics“
.\MDMDiagnosticsTool.exe -out C:\Temp\MDMReport -area Policy
# Event Log prüfen
Get-WinEvent -LogName „Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin“ |
Where-Object {$_.Level -eq 2} |
Select-Object TimeCreated, Message -First 20
„`
### Schritt 3: CSP-Pfad manuell testen
Manchmal hilft es, den CSP-Pfad direkt abzufragen:
„`powershell
# Beispiel: BitLocker-Status via CSP
$bitlockerPath = „./Device/Vendor/MSFT/BitLocker“
# Hinweis: Direkter CSP-Zugriff erfordert OMADM-Provider oder spezielle Tools
„`
Besser: Verwende das **Microsoft MDM Diagnostic Report Tool** (Download im Microsoft Download Center). Das generiert einen vollständigen Report aller angewendeten CSPs.
### Schritt 4: Conflict Detection
Zwei Policies mit demselben Setting auf dasselbe Device = Conflict. Intune löst das nicht automatisch auf.
**Lösung:**
1. Identifiziere beide Policies im Portal
2. Entscheide, welche Policy priorisiert werden soll
3. Ändere die Assignment-Filter oder Scope-Tags, um Overlap zu vermeiden
4. Oder: Konsolidiere beide Settings in eine einzige Policy
—
## Best Practices für Production-Einsatz
### 1. Naming Convention
Verwende eine konsistente Namensstruktur:
„`
Beispiele:
SEC-WIN11-AllUsers-v1.2
EDGE-Kiosk-CallCenter-v2.0
BITL-Encrypt-AllDevices-v1.0
„`
### 2. Versionierung im Beschreibungsfeld
Das Beschreibungsfeld im Intune Portal ist dein Change-Log:
„`
v1.0 – Initial Release (2026-01-15)
v1.1 – Added LAPS Policy (2026-02-03)
v1.2 – Removed USB-Block für Admin-Group (2026-03-10)
„`
### 3. Scope Tags für Mandanten-Trennung
Bei Multi-Tenant oder Department-Separation:
„`
Scope Tag: Finance-HR-Devices
Scope Tag: Production-Floor-Devices
Scope Tag: Kiosk-Public-Devices
„`
### 4. Assignment Filters statt harter Device Groups
Dynamische Assignment Filters sind flexibler als statische AAD Groups:
„`
Filter-Name: Win11-Enterprise-Only
Rule: (device.deviceOSVersion -contains „Windows 11“) and (device.systemSKU -contains „Enterprise“)
„`
### 5. Pilot-Gruppe vor Broad Deployment
Immer erst auf eine Pilot-Gruppe (5-10 Devices) deployen, 48h warten, Event Logs prüfen, dann breit rollen.
—
## Limits und bekannte Einschränkungen
**Settings Catalog Limits (Stand 2026-01):**
– Maximal 800 Settings pro Configuration Profile
– Maximal 1000 Configuration Profiles pro Tenant
– Manche CSPs unterstützen nur „Replace“, nicht „Delete“ – einmal gesetzt, bleibt das Setting bis zur expliziten Rücknahme
– User-Targeted Policies benötigen Hybrid Azure AD Join oder AAD Join – Hybrid Azure AD only unterstützt Device-Targeted Policies
**Bekannte Bugs:**
1. **Edge-Extensions:** Whitelist-Einträge werden manchmal nicht korrekt syncronisiert – Workaround: Extension direkt via PowerShell deployen
2. **BitLocker + TPM 2.0:** Auf manchen OEM-Geräten wird TPM 2.0 nicht korrekt erkannt – Firmware-Update erforderlich
3. **Kiosk Mode + Multiple Profiles:** Wenn mehrere Kiosk-Profile auf ein Device assigned werden, kann es zu Race Conditions kommen – immer nur ein Kiosk-Profil pro Device
—
## Zusammenfassung
Das Settings Catalog ist die CSP-native Zukunft der Intune Configuration Profiles. Es bietet:
✅ Vollständigen Zugriff auf alle dokumentierten Windows CSPs
✅ Schnellere Verfügbarkeit neuer Settings (kein ADMX-Update-Zyklus)
✅ Bessere Troubleshooting-Möglichkeiten via CSP-Pfad-Analyse
✅ Zukunftssicherheit (Microsoft priorisiert Settings Catalog)
**Kritische Erfolgsfaktoren:**
– Verstehe die CSP-Architektur (OMADM, SyncML, Pfade)
– Dokumentiere jede Policy mit Version und Change-Log
– Teste immer erst auf einer Pilot-Gruppe
– Verwende Assignment Filters für dynamische Targeting
– Prüfe Conflicts aktiv im Device Status
**Nächste Sektion:** Sektion 17 behandelt App Protection Policies (MAM) für mobile Devices – hier geht es um den Schutz von Unternehmensdaten auf BYOD-Geräten ohne Full Device Enrollment.
—
*Artikel-Ende – Intune Mastercourse Sektion 16*
Academy
Weiterlernen in der Kaffeeundcode Academy
Wenn du diese Themen systematisch vertiefen willst, schau dir den ersten Academy-Kurs zur PSADT-Softwarepaketierung an. Im Fokus stehen .msi, .exe, Silent Switches, Detection, Logs und ein belastbarer Troubleshooting-Workflow.