For an english version please scroll down... ;-)

Durch den Anruf eines alten Bekannten und weil dieses Thema offensichtlich genau den Nerv der heutigen Zeit trifft, möchte ich meine kleine Exkursion in die Welt der CSPs fortsetzen und noch ein bisschen tiefer gehen. Bei dem besagten Anruf bin ich gefragt worden, ob es nicht eine Möglichkeit gibt, CSPs auch ohne Intune und Configuration Profiles nutzen bzw. setzen zu können. Schließlich sind diese ja Bestandteil von Windows 10/11 und bieten durchaus auch Abseits von Intune ein gewisses Potential.

Also gilt zunächst zu klären ob diese wirklich nur auf Intune beschränkt sind, was mit einem eindeutigen "Nein" beantwortet werden kann. Wie bereits in meinem ersten CSP Artikel beschrieben, handelt es sich hierbei lediglich um eine Schnittstelle die auch von anderen MDM Plattformen wie z.B. MobileIron (welches seit Dezember 2020 zur Ivanti Familie gehört) genutzt werden kann.

In meinem heutigen Artikel möchte ich zeigen, wie das Ansprechen und Verwenden von CSPs via WMI und PowerShell lokal am Client betrieben werden kann.

Der MDM Bridge WMI Provider

Um unser Vorhaben in die Tat umzusetzen benötigen wir den MDM Bridge WMI Provider, welcher es uns ermöglicht unsere mobilen Geräte zu verwalten. Eine ausführliche Dokumentation zu allen darin enthaltenen Klassen und deren Eigenschaften und Methoden ist bei Microsoft unter folgendem Link zu finden:

https://docs.microsoft.com/en-us/windows/win32/dmwmibridgeprov/mdm-bridge-wmi-provider-portal

Eine weitere Möglichkeit sich diese Informationen direkt am Client zu holen wäre, sich diese im entsprechenden WMI Namespace anzeigen zu lassen. Dies kann z.B. via PowerShell, das per default unter Windows verfügbare WMI Test Tool (wbemtest) oder jeden anderen WMI Explorer erfolgen.

Für die Verbindung ist lediglich der entsprechende Namespace "root\cimv2\mdm\dmmap" erforderlich. Anschließend kann man sich eine Übersicht über die verfügbaren Klassen ausgeben lassen.

Beispiel mit wbemtest:

​Beispiel mit PowerShell:

Je nach verwendeter Windows Version und installiertem Patch Stand kann die Anzahl der angezeigten Klassen leicht variieren. Da diese, wie bereits erwähnt Betriebssystembestandteil sind, werden neue CSPs mit neuen Windows Releases und kumulativen Updates auf die Clients ausgebracht. Dies gilt es vor allem in heterogenen Umgebungen zu beachten da einzelne Einstellungen auf älteren Systemen ggf. noch nicht verfügbar sind.

Ausführen von Methoden und Setzen von Eigenschaften per PowerShell

Um vorhandene Methoden ausführen zu können, liefert uns die Microsoft Dokumentation im Grunde bereits alles was wir brauchen.

https://docs.microsoft.com/en-us/windows/client-management/mdm/using-powershell-scripting-with-the-wmi-bridge-provider

Da sich der Inhalt des verlinkten Artikels allerdings vielleicht nicht gleich für jeden erschließt, möchte ich die Vorgehensweise anhand eines Beispiels etwas verdeutlichen. Suchen wir uns zunächst eine Eigenschaft, die wir gerne setzen möchten. Im konkreten Fall möchte ich die Firewall für das Domänenprofil an meinem Testclient aktivieren.

Betrachten wir nun das verwendete PowerShell Script. Zunächst wird der NameSpace und die gewünschte Klasse festgelegt. Für unser Vorhaben muss die Klasse "MDM_Firewall_DomainProfile02" verwendet werden. Anschließend muss entweder eine CIM (Common Information Model) Instanz oder Session erstellt werden sofern keine existiert. Hier sollte unter Umständen auch die Parallelität von Aktionen berücksichtigt werden um ein versehentliches Überschreiben von Einstellungen zu verhindern. An der erzeugten Instanz befindet sich eine Eigenschaft "EnableFirewall" vom Typ Bool, welche entsprechend gesetzt und die Instanz abschließend aktualisiert werden kann.

$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_Firewall_DomainProfile02"

# Get all instances available for MDM_Firewall_DomainProfile02 or create new one
$instance = Get-CimInstance -Namespace $namespaceName -ClassName $className
if (!($instance)) {
    New-CimInstance -Namespace $namespaceName -ClassName $className
    $intance = Get-CimInstance -Namespace $namespaceName -ClassName $className
}

# Check if State is 'disabled' and 'enable' it
if ($instance.EnableFirewall -eq $false) -or ($instance.EnableFirewall -eq "") {
    $instance.EnableFirewall = $true
    Set-CimInstance -CimInstance $instance
} 

Nach Ausführung des Scriptes wird der Status der Firewall adhoc geändert.

Finden von MDM WMI Klassen über OMA-URI Pfade

In einem meiner letzten Artikel zum Thema OMA-URI bin ich etwas genauer auf den Aufbau der Pfade eingegangen. Mit den nun dargestellten Möglichkeiten kann die entsprechende MDM Klasse aus jedem beliebigen OMA-URI Pfad heraus identifiziert werden. Nehmen wir daher die bereits verwendete Einstellung "DontDisplayLastUsername" um den zuletzt angemeldeten Benutzer bei der Windows Anmeldung an- bzw. nicht anzeigen lassen zu können.

Wie bereits damals erwähnt und noch einmal im Screenshot zu sehen, setzt sich der OMA-URI Pfad aus vier Knoten zusammen. Der Aufbau der MDM Klasse erfolgt nun über genau diese Knoten. Hier noch einmal zur Veranschaulichung über das WMI Test Tool.

Auf diese Weise können nun alle verfügbaren CSPs angesprochen und lokal am Client (ohne Intune Configuration Profile) ausgeführt werden. Natürlich bietet sich diese Variante auch dafür an, um lästige und oftmals auch nicht gerade sehr kurze Wartezeiten mit Intune zu umgehen und Richtlinien schnell und einfach lokal testen zu können.

English Version

Since most of my readers come from German-speaking countries, I usually write only German articles. However, since this is a rather new and exciting topic and since I was asked on Twitter for an English translation, I decided to write this article in both languages. ;-)

Due to a call from an old friend and because this topic obviously hits the nerve of today, I would like to continue my little excursion into the world of CSPs and go a bit deeper. During the call I was asked if there is a possibility to use CSPs without Intune and Configuration Profiles. After all, these are part of Windows 10/11 and offer a certain potential apart from Intune.

So the first thing to clarify is if they are really limited to Intune, which can be answered with a clear "No". As already described in my first CSP article, this is merely an interface that can also be used by other MDM platforms such as MobileIron (which has been part of the Ivanti family since December 2020).

In today's article I want to show how addressing and using CSPs via WMI and PowerShell can be done locally on the client.

The MDM Bridge WMI Provider

To put our plan into action we need the MDM Bridge WMI Provider, which allows us to manage our mobile devices locally. A detailed documentation of all classes contained in it and their properties and methods can be found at Microsoft at the following link:

https://docs.microsoft.com/en-us/windows/win32/dmwmibridgeprov/mdm-bridge-wmi-provider-portal

Another way to get this information directly from the client would be to display it in the corresponding WMI namespace. This can be done e.g. via PowerShell, the WMI Test Tool (wbemtest) available by default under Windows or any other WMI Explorer.

The connection only requires the corresponding namespace "root\cimv2\mdm\dmmap". Afterwards you can get an overview of the available classes.

Example with wbemtest:

Example with PowerShell:

Depending on the Windows version used and the patch level installed, the number of classes displayed may vary a little bit. As these are, as already mentioned, part of the operating system, new CSPs are deployed to the clients with new Windows releases and cumulative updates. This is especially important in heterogeneous environments, as some settings may not yet be available on older systems.

Executing methods and setting properties via PowerShell

To be able to execute existing methods, the Microsoft documentation basically already provides us with everything we need.

https://docs.microsoft.com/en-us/windows/client-management/mdm/using-powershell-scripting-with-the-wmi-bridge-provider

However, since the content of the linked article may not be immediately obvious to everyone, I would like to clarify the procedure a bit with an example. Let's first find a property that we would like to set. In this specific case, I would like to enable the firewall for the domain profile on my test client.

Now let's look at the PowerShell script used. First, the NameSpace and the desired class are specified. For our project the class "MDM_Firewall_DomainProfile02" must be used. Then either a CIM (Common Information Model) instance or session must be created if none exists. The created instance has a property "EnableFirewall" of the type Bool, which can be set accordingly and the instance will finally be updated.

$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_Firewall_DomainProfile02"

# Get all instances available for MDM_Firewall_DomainProfile02 or create new one
$instance = Get-CimInstance -Namespace $namespaceName -ClassName $className
if (!($instance)) {
    New-CimInstance -Namespace $namespaceName -ClassName $className
    $intance = Get-CimInstance -Namespace $namespaceName -ClassName $className
}

# Check if State is 'disabled' and 'enable' it
if ($instance.EnableFirewall -eq $false) -or ($instance.EnableFirewall -eq "") {
    $instance.EnableFirewall = $true
    Set-CimInstance -CimInstance $instance
} 

After the script is executed, the status of the firewall is changed ad hoc.

Finding MDM WMI classes via OMA URI paths

In one of my last articles on the subject of OMA-URI, I went into a little more detail about the structure of the paths. With the options now presented, the corresponding MDM class can be identified from any OMA-URI path. So let's take the already used setting "DontDisplayLastUsername" from the last article with whitch we are able to display or not display the last logged in user at the Windows login.

As already mentioned at that time and to be seen again in the screenshot, the OMA-URI path is composed of four nodes. The MDM class is now built using exactly these nodes. Here again for illustration over the WMI test tool.

In this way, all available CSPs can now be addressed and executed locally on the client (without Intune Configuration Profiles). Of course, this variant is also suitable for bypassing annoying and often not very short waiting times with Intune and to be able to test policies quickly and easily locally.