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 to the same profile.

A profile has no effect if it's not associated to a config section.

You can start your file by pasting the following XML into an XML editor, and saving the file as filename .xml. Each section of this XML is explained in this article.

If you want to write a configuration file to be applied to both Windows 10 and Windows 11 devices, follow the Windows 10 instructions to add the StartLayout tag to your XML file, just above the StartPins tag. Windows will automatically ignore the sections that don't apply to the version running.

<?xml version="1.0" encoding="utf-8" ?>
<AssignedAccessConfiguration  
  xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config" xmlns:win11="http://schemas.microsoft.com/AssignedAccess/2022/config">
    <Profiles>
        <Profile Id="">
            <AllAppsList>
                <AllowedApps/>
            </AllAppsList>
            <win11:StartPins/>
            <Taskbar/>
        </Profile>
    </Profiles>
    <Configs>
        <Config>
            <Account/>
            <DefaultProfile Id=""/>
        </Config>
    </Configs>
</AssignedAccessConfiguration>
Profile
There are two types of profiles that you can specify in the XML:
Lockdown profile: Users assigned a lockdown profile will see the desktop in tablet mode with the specific apps on the Start screen.
Kiosk profile: Starting with Windows 10 version 1803, this profile replaces the KioskModeApp node of the AssignedAccess CSP. Users assigned a kiosk profile won't see the desktop, but only the kiosk app running in full-screen mode.
A lockdown profile section in the XML has the following entries:
AllowedApps
StartPins
Taskbar
A kiosk profile in the XML has the following entries:
KioskModeApp
The profile Id is a GUID attribute to uniquely identify the profile. You can create a GUID using a GUID generator. The GUID just needs to be unique within this XML file.
<Profiles>
  <Profile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}">…</Profile>
</Profiles>
AllowedApps
AllowedApps is a list of applications that are allowed to run. Apps can be Universal Windows Platform (UWP) apps or Windows desktop applications. Starting with Windows 10 version 1809, you can configure a single app in the AllowedApps list to run automatically when the assigned access user account signs in.
For UWP apps, you need to provide the App User Model ID (AUMID). Learn how to get the AUMID, or get the AUMID from the Start Layout XML.
For desktop apps, you need to specify the full path of the executable, which can contain one or more system environment variables in the form of %variableName%. For example, %systemroot% or %windir%.
If an app has a dependency on another app, both must be included in the allowed apps list. For example, Internet Explorer 64-bit has a dependency on Internet Explorer 32-bit, so you must allow both "C:\Program Files\internet explorer\iexplore.exe" and "C:\Program Files (x86)\Internet Explorer\iexplore.exe".
To configure a single app to launch automatically when the user signs in, include rs5:AutoLaunch="true" after the AUMID or path. You can also include arguments to be passed to the app. For an example, see the AllowedApps sample XML.
When the multi-app kiosk configuration is applied to a device, AppLocker rules will be generated to allow the apps that are listed in the configuration. Here are the predefined assigned access AppLocker rules for UWP apps:
Default rule is to allow all users to launch the signed package apps.
The package app blocklist is generated at runtime when the assigned access user signs in. Based on the installed/provisioned package apps available for the user account, assigned access generates the blocklist. This list will exclude the default allowed inbox package apps, which are critical for the system to function. It then excludes the allowed packages that enterprises defined in the assigned access configuration. If there are multiple apps within the same package, all these apps will be excluded. This blocklist will be used to prevent the user from accessing the apps that are currently available for the user but not in the allowed list.
You can't manage AppLocker rules that are generated by the multi-app kiosk configuration in MMC snap-ins. Avoid creating AppLocker rules that conflict with AppLocker rules that are generated by the multi-app kiosk configuration.
Multi-app kiosk mode doesn't block the enterprise or the users from installing UWP apps. When a new UWP app is installed during the current assigned access user session, this app will not be in the deny list. When the user signs out and signs in again, the app will be included in the blocklist. If this is an enterprise-deployed line-of-business app and you want to allow it to run, update the assigned access configuration to include it in the allowed app list.
Here are the predefined assigned access AppLocker rules for desktop apps:
Default rule is to allow all users to launch the desktop programs signed with Microsoft Certificate in order for the system to boot and function. The rule also allows the admin user group to launch all desktop programs.
There's a predefined inbox desktop app blocklist for the assigned access user account, and this blocklist is adjusted based on the desktop app allowlist that you defined in the multi-app configuration.
Enterprise-defined allowed desktop apps are added in the AppLocker allowlist.
The following example allows Photos, Weather, Calculator, Paint, and Notepad apps to run on the device, with Notepad configured to automatically launch and create a file called 123.text when the user signs in.
<AllAppsList>
        <AllowedApps>
          <App AppUserModelId="Microsoft.Windows.Photos_8wekyb3d8bbwe!App" />
          <App AppUserModelId="Microsoft.BingWeather_8wekyb3d8bbwe!App" />
          <App AppUserModelId="Microsoft.WindowsCalculator_8wekyb3d8bbwe!App" />
          <App DesktopAppPath="%windir%\system32\mspaint.exe" />
          <App DesktopAppPath="C:\Windows\System32\notepad.exe" rs5:AutoLaunch="true" rs5:AutoLaunchArguments="123.txt">
        </AllowedApps>
</AllAppsList>
StartPins
After you define the list of allowed applications, you can customize the Start layout for your kiosk experience. The easiest way to create a customized Start layout to apply to other Windows client devices is to set up the Start screen on a test device and then export the layout. Once you've decided, you can get the JSON needed for your kiosk configuration by following the steps to Get the pinnedList JSON. If you opt to do this using the PowerShell command, make sure that the system you run the command on has the same file structure as the device on which you will apply the kiosk (the path to the allowed apps must be the same). At the end of this step, you should have a JSON pinnedList that looks something like the below.
Add your pinnedList JSON into the StartPins tag in your XML file.
<win11:StartPins>
        <![CDATA[  
          { "pinnedList":[
            {"packagedAppId":"Microsoft.WindowsCalculator_8wekyb3d8bbwe!App"},
            {"packagedAppId":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App"},
            {"packagedAppId":"Microsoft.BingWeather_8wekyb3d8bbwe!App"},
            {"desktopAppLink":"%ALLUSERSPROFILE%\\Microsoft\\Windows\\StartMenu\\Programs\\Accessories\\Paint.lnk"},
            {"desktopAppLink":"%APPDATA%\\Microsoft\\Windows\\StartMenu\\Programs\\Accessories\\Notepad.lnk"}
      </win11:StartPins>
If an app isn't installed for the user, but is included in the Start layout XML, the app isn't shown on the Start screen.
Taskbar
Define whether you want to have the taskbar present in the kiosk device. For tablet-based or touch-enabled all-in-one kiosks, when you don't attach a keyboard and mouse, you can hide the taskbar as part of the multi-app experience if you want.
The following example exposes the taskbar to the end user:
<Taskbar ShowTaskbar="true"/>
The following example hides the taskbar:
<Taskbar ShowTaskbar="false"/>
This is different from the Automatically hide the taskbar option in tablet mode, which shows the taskbar when swiping up from or moving the mouse pointer down to the bottom of the screen. Setting ShowTaskbar as false will always keep the taskbar hidden.
KioskModeApp
KioskModeApp is used for a kiosk profile only. Enter the AUMID for a single app. You can only specify one kiosk profile in the XML.
<KioskModeApp AppUserModelId="Microsoft.WindowsCalculator_8wekyb3d8bbwe!App"/>
Important
The kiosk profile is designed for public-facing kiosk devices. We recommend that you use a local, non-administrator account. If the device is connected to your company network, using a domain or Azure Active Directory account could potentially compromise confidential information.
Configs
Under Configs, define which user account will be associated with the profile. When this user account signs in on the device, the associated assigned access profile will be enforced. This behavior includes the allowed apps, Start layout, taskbar configuration, and other local group policies or mobile device management (MDM) policies set as part of the multi-app experience.
The full multi-app assigned access experience can only work for non-admin users. It's not supported to associate an admin user with the assigned access profile. Making this configuration in the XML file will result in unexpected or unsupported experiences when this admin user signs in.
You can assign:
A local standard user account that signs in automatically (Applies to Windows 10, version 1803 only)
An individual account, which can be local, domain, or Azure Active Directory (Azure AD)
A group account, which can be local, Active Directory (domain), or Azure AD (Applies to Windows 10, version 1803 only).
Configs that specify group accounts cannot use a kiosk profile, only a lockdown profile. If a group is configured to a kiosk profile, the CSP will reject the request.
Config for AutoLogon Account
When you use <AutoLogonAccount> and the configuration is applied to a device, the specified account (managed by Assigned Access) is created on the device as a local standard user account. The specified account is signed in automatically after restart.
The following example shows how to specify an account to sign in automatically.
<Configs>
  <Config>
    <AutoLogonAccount/>
    <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
  </Config>
</Configs>
Starting with Windows 10 version 1809, you can configure the display name that will be shown when the user signs in. The following example shows how to create an AutoLogon Account that shows the name "Hello World".
<Configs>
  <Config>
    <AutoLogonAccount rs5:DisplayName="Hello World"/>
    <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
  </Config>
</Configs>
On domain-joined devices, local user accounts aren't shown on the sign-in screen by default. To show the AutoLogonAccount on the sign-in screen, enable the following Group Policy setting: Computer Configuration > Administrative Templates > System > Logon > Enumerate local users on domain-joined computers. (The corresponding MDM policy setting is WindowsLogon/EnumerateLocalUsersOnDomainJoinedComputers in the Policy CSP.)
Important
When Exchange Active Sync (EAS) password restrictions are active on the device, the autologon feature does not work. This behavior is by design. For more informations, see How to turn on automatic logon in Windows.
Config for individual accounts
Individual accounts are specified using <Account>.
Local account can be entered as machinename\account or .\account or just account.
Domain account should be entered as domain\account.
Azure AD account must be specified in this format: AzureAD\{email address}. AzureAD must be provided as is, and consider it's a fixed domain name. Then follow with the Azure AD email address. For example, AzureAD\someone@contoso.onmicrosoft.com
Warning
Assigned access can be configured via WMI or CSP to run its applications under a domain user or service account, rather than a local account.  However, use of domain user or service accounts introduces risks that an attacker subverting the assigned access application might gain access to sensitive domain resources that have been inadvertently left accessible to any domain account. We recommend that customers proceed with caution when using domain accounts with assigned access, and consider the domain resources potentially exposed by the decision to do so.
Before applying the multi-app configuration, make sure the specified user account is available on the device, otherwise it will fail.
For both domain and Azure AD accounts, it's not required that target account is explicitly added to the device. As long as the device is AD-joined or Azure AD-joined, the account can be discovered in the domain forest or tenant that the device is joined to. For local accounts, it is required that the account exist before you configure the account for assigned access.
<Configs>
  <Config>
    <Account>MultiAppKioskUser</Account>
    <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
  </Config>
</Configs>
Config for group accounts
Group accounts are specified using <UserGroup>. Nested groups aren't supported. For example, if user A is member of Group 1, Group 1 is member of Group 2, and Group 2 is used in <Config/>, user A won't have the kiosk experience.
Local group: Specify the group type as LocalGroup and put the group name in Name attribute. Any Azure AD accounts that are added to the local group won't have the kiosk settings applied.
<Config>
  <UserGroup Type="LocalGroup" Name="mygroup" />
  <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
</Config>
Domain group: Both security and distribution groups are supported. Specify the group type as ActiveDirectoryGroup. Use the domain name as the prefix in the name attribute.
<Config>
  <UserGroup Type="ActiveDirectoryGroup" Name="mydomain\mygroup" />
  <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
</Config>
Azure AD group: Use the group object ID from the Azure portal to uniquely identify the group in the Name attribute. You can find the object ID on the overview page for the group in Users and groups > All groups. Specify the group type as AzureActiveDirectoryGroup. The kiosk device must have internet connectivity when users that belong to the group sign-in.
<Config>
  <UserGroup Type="AzureActiveDirectoryGroup" Name="a8d36e43-4180-4ac5-a627-fb8149bba1ac" />
  <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
</Config>
If an Azure AD group is configured with a lockdown profile on a device, a user in the Azure AD group must change their password (after the account has been created with default password on the portal) before they can sign in to this device. If the user uses the default password to sign in to the device, the user will be immediately signed out.
Configure a kiosk using WMI Bridge
Environments that use Windows Management Instrumentation (WMI) can use the MDM Bridge WMI Provider to configure the MDM_AssignedAccess class.
Here's an example of how to set AssignedAccess configuration:
Download the psexec tool.
Run psexec.exe -i -s cmd.exe.
In the command prompt launched by psexec.exe, enter powershell.exe to open PowerShell.
Run the following script replacing the placeholder "your XML here, with the XML you created above.
$nameSpaceName="root\cimv2\mdm\dmmap"
$className="MDM_AssignedAccess"
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
Add-Type -AssemblyName System.Web
$obj.Configuration = [System.Web.HttpUtility]::HtmlEncode(@"
<your XML here>
Set-CimInstance -CimInstance $obj
Sample Assigned Access XML
Compare the below to your XML file to check for correct formatting.
<?xml version="1.0" encoding="utf-8" ?>
<AssignedAccessConfiguration  
  xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config" xmlns:win11="http://schemas.microsoft.com/AssignedAccess/2022/config">
  <Profiles>
    <Profile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}">       
      <AllAppsList>
        <AllowedApps> 
          <App AppUserModelId="Microsoft.ZuneMusic_8wekyb3d8bbwe!Microsoft.ZuneMusic" /> 
          <App AppUserModelId="Microsoft.ZuneVideo_8wekyb3d8bbwe!Microsoft.ZuneVideo" /> 
          <App AppUserModelId="Microsoft.Windows.Photos_8wekyb3d8bbwe!App" /> 
          <App AppUserModelId="Microsoft.BingWeather_8wekyb3d8bbwe!App" /> 
          <App AppUserModelId="Microsoft.WindowsCalculator_8wekyb3d8bbwe!App" /> 
          <App DesktopAppPath="%windir%\system32\mspaint.exe" /> 
          <App DesktopAppPath="C:\Windows\System32\notepad.exe" /> 
        </AllowedApps> 
      </AllAppsList> 
      <win11:StartPins>
        <![CDATA[  
          { "pinnedList":[
            {"packagedAppId":"Microsoft.WindowsCalculator_8wekyb3d8bbwe!App"},
            {"packagedAppId":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App"},
            {"packagedAppId":"Microsoft.ZuneMusic_8wekyb3d8bbwe!Microsoft.ZuneMusic"},
            {"packagedAppId":"Microsoft.ZuneVideo_8wekyb3d8bbwe!Microsoft.ZuneVideo"},
            {"packagedAppId":"Microsoft.BingWeather_8wekyb3d8bbwe!App"},
            {"desktopAppLink":"%ALLUSERSPROFILE%\\Microsoft\\Windows\\StartMenu\\Programs\\Accessories\\Paint.lnk"},
            {"desktopAppLink":"%APPDATA%\\Microsoft\\Windows\\StartMenu\\Programs\\Accessories\\Notepad.lnk"}
      </win11:StartPins>
      <Taskbar ShowTaskbar="true"/>
    </Profile> 
  </Profiles>
  <Configs>
    <Config>
      <Account>MultiAppKioskUser</Account>
      <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
    </Config>
  </Configs>
</AssignedAccessConfiguration>