Windows 11 Start menu folders

As we've seen in an earlier article, many of the settings in the Windows 11 Setting app map one-on-one to values in the Windows Registry. But there are some exceptions, and one of them is found in Personalization > Start > Folders. On this page you can Choose which folders appear on the Start menu next to the Power button. As we will see in this article, changing these settings with Windows PowerShell is a lot more complex than simply setting a registry value.

CIM, WMI, MDM, and CSP

Before we can write a Windows powerShell script to pin some folders to the Start menu, we need to understand a set of technologies available in Windows that will be be used to manage these and other settings. We will have to understand multiple TLAs (three-letter acronyms).

(Dont care? Then skip to the code!)

CIM: Common Information Model

The Common Information Model (CIM) is an open standard for representing physical and logical things in an IT environment. These things can be routers, computers, hard drives, applications, and even individual files. The model is object-oriented and extensible, so new classes that represent things can be defined, and instances of those classes can be created. Classes are grouped into namespaces. Class names have prefixes to indicate which schema the class belongs to.

For example, the CIM_Printer class in the Root\CIMV2 namespace belongs to the CIM schema and represents a logical printer insofar it can be managed. The Win32_ShortcutFile class in the Root\CIMV2 namespace belongs to the Win32 schema and represents a shortcut file.

Instances can be found through queries and, once found, an instance's methods can be called and its properties can be changed. These instances can be located remotely, in which case the WBEM standard is used for communication.

WMI: Windows Management Instrumentation

Windows Management Instrumentation (WMI) is Microsoft's implementation of CIM and WBEM for Windows operating systems. WMI exposes operating system information so it can be viewed and modified. WMI is Window's CIM Object Manager server. WMI can be used in scripting languages like Windows PowerShell, and in programming languages like C#, and via the C:\Windows\System32\wbem\WMIC.exe command-line program.

WMI defines the classes that describe the Windows operating system, as well as the query language to find instances of these classes. WMI providers translate changes to instances into changes to the operating system. The most important WMI provider is the Win32 provider.

WMI is available in PowerShell via the cmdlets such as Get-WmiObject in the Microsoft.PowerShell.Management PowerShell module, as well as cmdlets such as Get-CimInstance in the new CimCmdlets module. The newer cmdlets support autocompletion for parameters like -Namespace and -ClassName, but they return PowerShell objects that are dynamically bound to the class or instance, meaning class or instance methods can not be invoked via the PowerShell object, you have to call Invoke-CimMethod instead to invoke a class or instance method.

MDM: Mobile Device Management

Mobile Device Management (MDM) is a solution for managing Windows clients remotely. On the server-side Microsoft offers a product (Microsoft Intune) that can be used to manage devices, including devices that do not run Windows. With this software a company can support you bringing your own device to work (BYOD) while the company can still manage some settings on your device.

A Windows computer can also be a managed device. For this Windows includes a DM (device management) client. This client communicates with the server (using the Open Mobile Alliance Device Management protocol and SyncML) and forwards the configuration requests it receives from the server to providers that can handle those requests.

CSP: Configuration Service Providers

Configuration Service Providers (CSPs) are providers that handle device management requests on Windows. CSPs provide an interface to configuration settings for Windows features. There are several types of providers, and some are read-only, for example the DeviceStatus CSP, which can handle requests for basic device information.

A CSP of special interest for us is the Policy CSP. This CSP is used to ensure a managed device follows the rules of the organization that manages the device. There are many configuration policies that can be enforced, and such policies are specified as a path: ./{Scope}/Vendor/MSFT/Policy/{Verb}/{Area}/{Policy}.

The {Scope} placeholder must be Device or User. The {Verb} placeholder must be Config when configuring, and Result when reading. An example of {Area} is Browser for Microsoft Edge, and an example of {Policy} is AllowSearchSuggestionsinAddressBar.

Why was any of the above relevant?

Because, the folders on the Start menu can only be configured using policies such as AllowPinnedFolderDownloads and AllowPinnedFolderPersonalFolder in the Start device management configuration area. Normally the Policy CSP must receive a configuration policy from an MDM server, such as Microsoft Intune. But there is also a purely client-side WMI-to-MDM bridge. So we can use WMI's CIM cmdlets to create policies!

The schema for the CIM classes related to MDM is MDM, the provider is DMWmiBridgeProv, and the classes reside in the Root\CIMv2\MDM\DMMap namespace. We can use the MDM_Policy_Result01_Start02 class to read, and the MDM_Policy_Config01_Start02 to configure.

Okay, let's just do it

Because the CIM classes we will use are decorated with the InPartition("local-system") attribute, we will need to run some of the PowerShell cmdlets as the NT AUTHORITY\SYSTEM account. This is possible by executing code as a scheduled task. The Invoke-CommandAs PowerShell module does this, so we first need to install that: Install-Module -Name Invoke-CommandAs (this command requires an elevated Windows PowerShell session).

The Windows PowerShell script below configures several policies under ./Vendor/MSFT/Policy/Config/Start:

(This script requires an elevated Windows PowerShell session.)

Invoke-CommandAs -AsSystem -ScriptBlock {
    # Define the policies in the Start area
    $policies = @{
        AllowPinnedFolderDownloads = 1
        AllowPinnedFolderFileExplorer = 1
        AllowPinnedFolderPersonalFolder = 1
        AllowPinnedFolderSettings = 1
    }

    # Define common parameters for CIM cmdlets
    $parameters = @{
        Namespace = "Root\CIMv2\MDM\DMMap"
        ClassName = "MDM_Policy_Config01_Start02"
    }

    # Define values for some of the CIM instance's properties
    $path = "./Vendor/MSFT/Policy/Config"
    $area = "Start"

    # Try to get the CIM instance
    $instance = Get-CimInstance @parameters -Filter "ParentID = '$path' AND InstanceID = '$area'"

    # Define the properties of the CIM instance using the defined policies
    $properties = @{
        Property = $policies
    }

    # If there is no CIM instance, 
    if ($instance -eq $null)
    {
        # Add 
        $properties.Property.ParentID = $path
        $properties.Property.InstanceID = $area

        # Create the CIM instance with the properties
        $instance = New-CimInstance @parameters @properties
    }
    else
    {
        # Update the CIM instance
        $instance | Set-CimInstance @properties
    }
}

The script first defines all the policies to be configured, and then uses the CIM cmdlets in a script block passed to Invoke-CommandAs -AsSystem to set these policies via the WMI-to-MDM bridge. The result is shown in the screenshot below:

Since the settings are now managed by your organization, they can no longer be changed via the Settings app:

Summary

There is a very roundabout way to configure device management policies locally using Windows PowerShell. Although it's not strictly necessary to understand all the technologies involved (CIM, WMI, MDM, CSP, and the WMI-to-MDM bridge), knowing how they are related will certainly be helpful when trying to configure other policies using this technique. The complexity of this technique is a downside, as is the requirement to run the CIM cmdlets as NT AUTHORITY\SYSTEM.