Windows

Single App Kiosk Mode Configuration using MDM Bridge WMI Provider

These same steps apply to create a multi.-app kiosk as well. the XML needs to be updated with more applications under the allowed app (win32, uwp application). in this example, intune, Microsoft configuration designer, and mdm were not used. before we proceed, let’s explain some key terms.

AssignedAccess Configuration Service Provider (CSP): This is an interface to read, set, modify, or delete configuration settings on the device. These settings map to registry keys or files and this is used to set the device to run in kiosk mode. Once the CSP has been executed, then the next user login that is associated with the kiosk mode puts the device into the kiosk mode running the application specified in the CSP configuration.

Starting from Windows 10, version 1709, the AssignedAccess configuration service provider (CSP) was expanded to make it easy for Admins to create kiosks that run more than one app. Currently, as at the time of this writing, Local settings works only with UWP application and NOT with Desktop Application (Win32). (I have previously created an XML, exported but did not work. 

MDM Bridge WMI Provider and Windows 10 MDM Capabilities: See this link for more details. Here are the steps needed to deploy a Single App Kiosk on Windows 10 using the MDM Bridge WMI Provider

Step 1: Create a Local Kiosk Account: Ensure the Kiosk account is created before proceeding with these steps.
Note: There are different ways to create an account in W10.

Now your account is created and can also be verified from here
– Control PanelUser Accountsuser Accounts and
– Click on Manage User Accounts

Steps 2: Create an XML file or Export the Start layout file and modify it. From the Start menu
– Right-click on Windows PowerShell
– launch PowerShell with Administrators privilege (or else Access will be denied when you run the cmdlets).
– At the Windows PowerShell command prompt, enter the following command.

Export-StartLayout –path <path><file name>.xml

Run the following command
- PS C:WINDOWSsystem32> export-startlayout -path .start1.xml 

The output will be saved in this location: C:WindowsSystem32 as shown below.                   

You can also save this to a different path order than C:WindowsSystem32

Step 3: Let’s build the XML file. Let’s discuss the structure of the XML file
– A configuration XML can define multiple profiles. Each profile has a unique Id and defines a set of applications that are allowed to run, whether the taskbar is visible, and can include a custom Start layout.
– A configuration XML can have multiple config sections. Each config section associates a non-admin user account to a default profile Id.
– Multiple config sections can be associated with the same profile.
– A profile has no effect if it’s not associated with a config section. See more this link for more information.

<Create the Profile > apps + layout
<Config>=account + Profile ID
Note: The profile are identified by a Unique ID, i.e,
<Profile id=GUID>

At this moment, it is safe to save the file with the .XML extension.

Define the Profile: There are two types of profiles which are
– Lockdown Profile and
– Kiosk Profile.

In this lab demonstration, I will be using the Kiosk profile and this will ensure that the users are only able to the app running on the desktop. The following entries will apply to my chosen profile.

– Profile Id
– KioskModeApp

Profile ID: This is a GUID attribute that uniquely identifies a profile. There are different methods for creating a GUID. You can choose to use any, but ensure the GUID unique throughout the XML file for a specific user.

For my test, I will be using the Desktop Application only. below is how to generate a profile ID (GUID) via PowerShell. This will be the profile id of a user kiosk.

See other methods here:
https://www.guidgen.com/
https://www.guidgenerator.com/online-guid-generator.aspx

AllowedApps: Here you will have to define a list of applications that are allowed to run (whether Universal Windows Platform (UWP) apps or Windows desktop applications (Win32 Apps). from Windows 10, version 1809, you can optionally configure a single app in the AllowedApps list to run automatically when the assigned access user account signs in. I configured a single app successfully in the lab.

In the allowed App session, if it is a desktop app, use the app path as shown below

<App DesktopAppPath=”c:windows|system32weather.exe” />
<App DesktopAppPath=”c:windowsProgram FilesNotepadNotepad++.exe” />

But if the App is a UWP app, you should use the AppUsermodelID. See the link here on how this is performed.

Configure the Application for Auto launch: This sample demonstrates that both UWP and Win32 apps can be configured to automatically launch when assigned access account login. One profile can have at most one app configured for auto-launch. AutoLaunchArguments are passed to the apps as is and the app needs to handle the arguments explicitly. Therefore, specify the allowed app and set the auto-launch = true in the xml as well.

Hide the Taskbar: I have also decided to hide the taskbar, so I’m including it in the xml file as shown below.

Config configuration: This defines the user account that will be associated with the profile. When this user account signs in on the device, the associated assigned access profile will be enforced, including the allowed apps, Start layout, and taskbar configuration, as well as other local group policies or mobile device management (MDM) policies set as part of the multi-app experience. and in this area, you specify the Account and the defaultProfile id of the account as shown below.

See the link below for more details about the XML file https://docs.microsoft.com/en-us/windows/configuration/kiosk-xml

<?xml version="1.0" encoding="utf-8" ?>
<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:r1809="http://schemas.microsoft.com/AssignedAccess/201810/config"
>
    <Profiles>
        <Profile Id="{xxxx6-4925-xxxxx-0b95xxxxxxxx}">
            <AllAppsList>
                <AllowedApps>
                    <App DesktopAppPath="C:Program FilesNotepad++notepad++.exe" r1809:AutoLaunch="true" />
                </AllowedApps>
            </AllAppsList>
            <StartLayout>
                <![CDATA[<LayoutModificationTemplate xmlns:defaultlayout="http://schemas.microsoft.com/Start/2014/FullDefaultLayout" xmlns:start="http://schemas.microsoft.com/Start/2014/StartLayout" Version="1" xmlns="http://schemas.microsoft.com/Start/2014/LayoutModification">
</LayoutModificationTemplate>
                ]]>
            </StartLayout>
            <Taskbar ShowTaskbar="false"/>
        </Profile>
    </Profiles>
    <Configs>
        <Config>
            <Account>kiosktester</Account>
            <DefaultProfile Id="{xxxx6-4925-xxxxx-0b95xxxxxxxx}"/>
        </Config>
    </Configs>

Next, wrap this in PowerShell by using the MDM bridge to apply the AssignedAccess configuration. Ensure to save this file below with the PowerShell extension, that is .ps1

$nameSpaceName="rootcimv2mdmdmmap"
$className="MDM_AssignedAccess"
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
Add-Type -AssemblyName System.Web
$obj.Configuration = [System.Web.HttpUtility]::HtmlEncode(@"
<?xml version="1.0" encoding="utf-8" ?>
<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:r1809="http://schemas.microsoft.com/AssignedAccess/201810/config"
>
    <Profiles>
        <Profile Id="{xxxx6-4925-xxxxx-0b95xxxxxxxx}">
            <AllAppsList>
                <AllowedApps>
                    <App DesktopAppPath="C:Program FilesNotepad++notepad++.exe" r1809:AutoLaunch="true" />
                </AllowedApps>
            </AllAppsList>
            <StartLayout>
                <![CDATA[<LayoutModificationTemplate xmlns:defaultlayout="http://schemas.microsoft.com/Start/2014/FullDefaultLayout" xmlns:start="http://schemas.microsoft.com/Start/2014/StartLayout" Version="1" xmlns="http://schemas.microsoft.com/Start/2014/LayoutModification">
</LayoutModificationTemplate>
                ]]>
            </StartLayout>
            <Taskbar ShowTaskbar="false"/>
        </Profile>
    </Profiles>
    <Configs>
        <Config>
            <Account>kiosktester</Account>
            <DefaultProfile Id="{xxxx6-4925-xxxxx-0b95xxxxxxxx}"/>
        </Config>
    </Configs>
</AssignedAccessConfiguration>
"@)
Set-CimInstance -CimInstance $obj

The CDATA is used to embed the StartLayout XML. The script must run and will be executed in the system context. So it makes sense to have this script placed in C:WindowsSystem32 location.

Step 4: Configure the MDM Bridge WMI Provider: This will be used to map the CSP to WMI.

Download the PSTools from here https://docs.microsoft.com/en-us/sysinternals/downloads/pstools
– Run PowerShell as an Administrator
– Set-ExecutionPolicy Unrestricted
This will prevent you from running into errors when using the code.

The command below will resolve the error as shown    

Note: Best practice is to allow the script kiosktester.ps1 to run only in order not to set the global execution policy to unrestricted as shown below.

powershell.exe -ExecutionPolicy Bypass -File .Kiotester.ps1

In the download path oft he PsTool. Enter the command to launch PsExec in CMD or Power Shell as shown below. Below are the two commands that can be run.
– psexec.exe -i -s cmd.exe
– psexec.exe -i -s PowerShell.exe

See how to use the PsExec tool: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec

Output for PowerShell command since I will be running a PowerShell script, The PSExec tool will connect to your device and run the Powershell command

After the AssignedAccess script has been created in step 3 above, launch in the following ways.

Ensure to run the script as System and save the PowerShell script to this location as well. When you do not have the account pre-created, you will be prompted with the following error.

Note: I have previously created this account, but simulated it to generate this error.

Run the script with the account created, it should be successful.

You can use the first three lines of the PS1 script to query the AssignedAccess MDM to ensure that the code has been injected OK, or if you update the code and re-inject and need to check your changes have been accepted. Note:

Check the $Obj variable to confirm. This will display the Assigned Access Configuration file
– Without following the order, using the object variable will not work and the desired out will not be prompted.

Sign out of the current account that is being used to configure the Assigned Access and login as the AssignedAccess user and this will take effect immediately and work as desired.

Note: You can add this PowerShell script to a task sequence on WDS (as a post-installation or custom installation).

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x