--- title: Create an Assigned Access configuration file description: Learn how to create an XML file to configure a kiosk device. ms.date: 02/12/2024 ms.topic: how-to zone_pivot_groups: windows-versions-11-10 appliesto: --- # Create an Assigned Access configuration XML file The multi-app kiosk experience is defined in an Assigned Access Configuration XML file. In this section, we will go through the process to create a XML file that contains all the lockdown entries available for customization. Let's start by looking at the basic structure of the XML file. - A configuration xml can define multiple `profiles`. Each profile has a *profile Id* and defines a set of applications that are allowed to run - A configuration xml can have multiple `configs`. Each config associates a non-admin user account to a default profile Id - A profile has no effect if it's not associated to a user account You can start your file by pasting the following XML code into a text editor, and saving the file as `filename.xml`. ::: zone pivot="windows-11" ```xml ``` ::: zone-end ::: zone pivot="windows-10" ```xml ``` ::: zone-end ## Profiles node 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](/windows/client-management/mdm/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: - [**Id**](#id) - [**AllowedApps**](#allowedapps) - [**StartPins**](#startpins) - [**Taskbar**](#taskbar) A kiosk profile in the XML has the following entries: - [**Id**](#id) - [**KioskModeApp**](#kioskmodeapp) In the XML file, you define each profile with a globally unique identifier (GUID), which must be unique within the XML file. > [!TIP] > You can generate a GUID with the PowerShell cmdlet `New-Guid`. ```xml ... ``` A *profile node* contains the following properties: |Property|Description| |-|-| |Id|a GUID attribute to uniquely identify the profile| |AllowedApps|a node with a list of applications that are allowed to run. Apps can be Universal Windows Platform (UWP) apps or Classic Windows desktop apps| |StartLayout|a node for startlayout policy xml| |Taskbar|a node with a Boolean attribute ShowTaskbar to indicate whether to show the taskbar| ```xml ``` ### AllowedApps node Based on the purpose of the kiosk device, define the list of applications that are allowed to run. This list can contain both UWP apps and desktop apps. When the mult-app kiosk configuration is applied to a device, AppLocker rules will be generated to allow the apps that are listed in the configuration. - For UWP apps, you must provide the App User Model ID (AUMID) - [Learn how to get the AUMID]() - For desktop apps, specify the AUMID or 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 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, 1. Default rule is to allow all users to launch the signed package apps. 2. The package app deny list 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 deny list. This list will exclude the default allowed inbox package apps which are critical for the system to function, and then exclude 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 deny list will be used to prevent the user from accessing the apps which are currently available for the user but not in the allowed list. Note: Assigned access multi-app mode doesn't block the enterprises 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 back next time, it will be included in the deny list. 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. For desktop apps, 1. 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. 2. There is a predefined inbox desktop app deny list for the assigned access user account, and this deny list is adjusted based on the desktop app allow list that you defined in the multi-app configuration. 3. Enterprise-defined allowed desktop apps are added in the AppLocker allow list. --> The following example allows Calculator, Photos, Weather, Calculator, Command Prompt, and Windows PowerShell apps to run on the device. ```xml ``` ::: zone pivot="windows-10" ### StartLayout node After the definition of allowed applications, customize the Start layout for the kiosk experience. You can choose to pin all the allowed applications on the Start menu, or a subset. The easiest way to create a customized Start layout is to configure the Start menu on a test device and then export the layout. For detailed steps, refer to Customize and export Start layout. > [!NOTE] > - The test device on which you customize the Start layout should have the same OS version that is installed on the device where you plan to deploy the Assigned Access configuration > - There are no apps pinned on the taskbar in the multi-app mode, and it's not supported to configure Taskbar layout using the tag in a layout modification XML as part of the Assigned Access configuration The following example pins Calculator, Photos, Weather, Calculator, Command Prompt, and Windows PowerShell apps to the Start menu. ```xml ]]> ``` ::: zone-end ::: zone pivot="windows-11" ### StartPins node 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](../start/customize-and-export-start-layout.md). 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. ```xml ``` ::: zone-end > [!NOTE] > 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: The following example hides the taskbar: > [!NOTE] > 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](#profile) only. Enter the AUMID for a single app. You can only specify one kiosk profile in the XML. ```xml ``` > [!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 Microsoft Entra account could potentially compromise confidential information. ## Configs Under `Configs`, define one or more user accounts and their association with a profile. When the user account signs in on the device, the associated Assigned Access profile is enforced along with policy settings that are part of the restricted user experience. You can assign: - A standard user account, which can be local, domain, or Microsoft Entra ID - A group account, which can be local, Active Directory (domain), or Microsoft Entra ID Limitations: - Configs that specify group accounts cannot use a kiosk profile, only a restricted ser experience profile - Apply the restrcited user experience to standard users only. It's not supported to associate an admin user with an Assigned Access profile :::row::: :::column::: ### AutoLogon Account :::column-end::: :::column::: With `` you can configure an account created and managed by Assigned Access, to automatically sign in after a device restart. The account is a local standard user. The following example shows how to specify an account to sign in automatically, and the optional display name shown during sign-in: ```xml ``` >[!NOTE] > On Microsoft Entra joined and domain-joined devices, local user accounts aren't disaplyed on the sign-in screen by default. To show the **AutoLogonAccount** on the sign-in screen, enable the policy setting: > >- GPO: **Computer Configuration > Administrative Templates > System > Logon > Enumerate local users on domain-joined computers** >- CSP: `WindowsLogon/`[EnumerateLocalUsersOnDomainJoinedComputers](/windows/client-management/mdm/policy-csp-windowslogon#windowslogon-enumeratelocalusersondomainjoinedcomputers) >[!IMPORTANT] >When Exchange Active Sync (EAS) password restrictions are active on the device, the autologon feature doesn't work. This behavior is by design. For more informations, see [How to turn on automatic logon in Windows](/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon). :::column-end::: :::row-end::: ### Config for individual accounts Individual accounts are specified using ``. - Local account can be entered as `machinename\account` or `.\account` or just `account`. - Domain account should be entered as `domain\account`. - Microsoft Entra 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 Microsoft Entra ID 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. > [!NOTE] > For both domain and Microsoft Entra accounts, it's not required that target account is explicitly added to the device. As long as the device is AD-joined or Microsoft Entra 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. ```xml MultiAppKioskUser ``` ### Config for group accounts Group accounts are specified using ``. 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 ``, 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 Microsoft Entra accounts that are added to the local group won't have the kiosk settings applied. ```xml ``` - 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. ```xml ``` - Microsoft Entra 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. ```xml ``` > [!NOTE] > If a Microsoft Entra group is configured with a lockdown profile on a device, a user in the Microsoft Entra 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. ## Full XML example ::: zone pivot="windows-11" ```xml ``` ::: zone-end ### FileExplorerNamespaceRestrictions Starting in Windows 10 version 1809, you can explicitly allow some known folders to be accessed when the user tries to open the file dialog box in multi-app assigned access by including **FileExplorerNamespaceRestrictions** in your XML file. Currently, **Downloads** is the only folder supported. This behavior can also be set using Microsoft Intune. The following example shows how to allow user access to the Downloads folder in the common file dialog box. > [!TIP] > To grant access to the Downloads folder through File Explorer, add "Explorer.exe" to the list of allowed apps, and pin a file explorer shortcut to the kiosk start menu. ```xml ... ... ``` > [!NOTE] > - `FileExplorerNamespaceRestrictions` and `AllowedNamespace:Downloads` are available in namespace `https://schemas.microsoft.com/AssignedAccess/201810/config`. > - `AllowRemovableDrives` and `NoRestriction` are defined in a new namespace `https://schemas.microsoft.com/AssignedAccess/2020/config`. - When `FileExplorerNamespaceRestrictions` node isn't used, or used but left empty, the user won't be able to access any folder in a common dialog. For example, **Save As** in the Microsoft Edge browser. - When Downloads is mentioned in allowed namespace, user will be able to access Downloads folder. - When `AllowRemovableDrives` is used, user will be to access removable drives. - When `NoRestriction` is used, no restriction will be applied to the dialog. - `AllowRemovableDrives` and `AllowedNamespace:Downloads` can be used at the same time. :::row::: :::column span="1"::: **Scenario** :::column-end::: :::column span="3"::: **Sample Xml** :::column-end::: :::row-end::: :::row::: :::column span="1"::: **Block everything** :::column-end::: :::column span="3"::: Either don't use the node or leave it empty ```xml ``` :::column-end::: :::row-end::: :::row::: :::column span="1"::: **Only allow downloads** :::column-end::: :::column span="3"::: ```xml ``` :::column-end::: :::row-end::: :::row::: :::column span="1"::: **Only allow removable drives** :::column-end::: :::column span="3"::: ```xml ``` :::column-end::: :::row-end::: :::row::: :::column span="1"::: **Allow both Downloads, and removable drives** :::column-end::: :::column span="3"::: ```xml ``` :::column-end::: :::row-end::: :::row::: :::column span="1"::: **No restrictions, all locations are allowed** :::column-end::: :::column span="3"::: ```xml ``` :::column-end::: :::row-end::: ## Assigned Access configuration XML examples This article provides practical examples of Assigned Access XML configuration files. For more details, review the Assigned Access XSD reference article. ## Kiosk example 1 ```xml ... domain\account AzureAD\john@contoso.onmicrosoft.com localaccount ``` ## Kiosk only sample XML ```xml singleappuser ``` ## Auto Launch Sample XML This sample demonstrates that both UWP and Win32 apps can be configured to automatically launch, when assigned access account logs in. 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. ```xml aauser1 aauser2 ``` ## Microsoft Edge Kiosk XML Sample ```xml EdgeKioskUser ``` ## Global Profile Sample XML Global Profile is supported on: - Windows 11 - Windows 10, version 2004 and later Global Profile is designed for scenarios where a user doesn't have a designated profile, yet you still want the user to run in lockdown mode. It's also used as mitigation when a profile can't be determined for a user. This sample demonstrates that only a global profile is used, with no active user configured. Global Profile will be applied when every non-admin account signs in. ```xml ``` Below sample shows dedicated profile and global profile mixed usage, a user would use one profile, everyone else that's non-admin will use another profile. ```xml aauser ``` ## Folder Access sample xml Starting with Windows 10 version 1809 +, folder access is locked down so that when common file dialog is opened, IT Admin can specify if the user has access to the Downloads folder, or no access to any folder at all. This restriction has been redesigned for finer granularity and easier use, and is available in Windows 10 version 2009+. IT Admin now can specify user access to Downloads folder, Removable drives, or no restrictions at all. Downloads and Removable Drives can be allowed at the same time. ```xml multi1 multi2 multi3 multi4 multi5 multi6 ``` To authorize a compatible configuration XML that includes elements and attributes from Windows 10 version 1809 or newer / Windows 11, always include the namespace of these add-on schemas, and decorate the attributes and elements accordingly with the namespace alias. For example, to configure the autolaunch feature that was added in Windows 10 version 1809 / Windows 11, use the following sample. Notice an alias r1809 is given to the 201810 namespace for Windows 10 version 1809 / Windows 11, and the alias is tagged on AutoLaunch and AutoLaunchArguments inline. ## Single app Assigned Access XML example ## Multi-app Assigned Access XML example