Windows 10 app deployment by using Microsoft Intune

Microsoft Intune supports a variety of app types and deployment scenarios on Windows 10 devices. After you’ve added an app to Intune, you can assign the app to users and devices. This article provides more details on the supported Windows 10 scenarios, and also covers key details to note when you’re deploying apps to Windows. For information about deploying an app, also known as assigning an app, see Assign an app to a group.

Line-of-business (LOB) apps and Microsoft Store for Business apps are the app types supported on Windows 10 devices. The file extensions for Windows apps include .msi, .appx, and .appxbundle.

To deploy modern apps, you need at least:

Only Windows 10 1803 and later support installing apps when there is no primary user associated.

LOB app deployment isn’t supported on devices running Windows 10 Home editions.

Supported Windows 10 app types

Specific app types are supported based on the version of Windows 10 that your users are running. The following table provides the app type and Windows 10 supportability.

App type	Home	Pro	Business	Enterprise	Education	S-Mode	HoloLens 1	Surface Hub	WCOS	Mobile
.MSI	No	Yes	Yes	Yes	Yes	No	No	No	No	No
.IntuneWin	No	Yes	Yes	Yes	Yes	19H2+	No	No	No	No
Office C2R	No	Yes	Yes	Yes	Yes	RS4+	No	No	No	No
LOB: APPX/MSIX	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
MSFB Offline	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
MSFB Online	Yes	Yes	Yes	Yes	Yes	Yes	RS4+	No	Yes	Yes
Web Apps	Yes	Yes	Yes	Yes	Yes	Yes	Yes 2	Yes 2	Yes	Yes 2
Store Link	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Microsoft Edge	No	Yes	Yes	Yes	Yes	19H2+ 3	No	No	No	No

1 To unlock app management, upgrade your HoloLens device to Holographic for Business.
2 Launch from the Company Portal only.
3 For Edge app to install successfully, devices must also be assigned an S-Mode policy.

All Windows app types require enrollment.

Windows 10 LOB apps

You can sign and upload Windows 10 LOB apps to the Intune admin console. These can include modern apps, such as Universal Windows Platform (UWP) apps and Windows App Packages (AppX), as well as Win 32 apps, such as simple Microsoft Installer package files (MSI). The admin must manually upload and deploy updates of LOB apps. These updates are automatically installed on user devices that have installed the app. No user intervention is required, and the user has no control over the updates.

Microsoft Store for Business apps

Microsoft Store for Business apps are modern apps, purchased from the Microsoft Store for Business admin portal. They are then synced over to Microsoft Intune for management. The apps can either be online licensed or offline licensed. The Microsoft Store directly manages updates, with no additional action required by the admin. You can also prevent updates to specific apps by using a custom Uniform Resource Identifier (URI). For more information, see Enterprise app management — Prevent app from automatic updates. The user can also disable updates for all Microsoft Store for Business apps on the device.

Categorize Microsoft Store for Business apps

To categorize Microsoft Store for Business apps:

1. Sign in to the Microsoft Endpoint Manager admin center.
2. Select Apps >All apps.
3. Select a Microsoft Store for Business app. Then select Properties >App Information >Category.
4. Select a category.

Install apps on Windows 10 devices

Depending on the app type, you can install the app on a Windows 10 device in one of two ways:

• User Context: When an app is deployed in user context, the managed app is installed for that user on the device when the user signs in to the device. Note that the app installation doesn’t succeed until the user signs in to the device.
  • Modern LOB apps and Microsoft Store for Business apps (both online and offline) can be deployed in user context. The apps support both the Required and Available intents.
  • Win32 apps built as User Mode or Dual Mode can be deployed in user context, and support both the Required and Available intents.
• Device Context: When an app is deployed in device context, the managed app is installed directly to the device by Intune.
  • Only modern LOB apps and offline licensed Microsoft Store for Business apps can be deployed in device context. These apps only support the Required intent.
  • Win32 apps built as Machine Mode or Dual Mode can be deployed in device context, and support only the Required intent.

For Win32 apps built as Dual Mode apps, the admin must choose if the app will function as a User Mode or Machine Mode app for all assignments associated with that instance. The deployment context can’t be changed per assignment.

Apps can only be installed in the device context when supported by the device and the Intune app type. Device context installs are supported on Windows 10 desktops and Teams devices, such as the Surface Hub. They aren’t supported on devices running Windows Holographic for Business, such as the Microsoft HoloLens.

You can install the following app types in the device context and assign these apps to a device group:

• Win32 apps
• Offline licensed Microsoft Store for Business apps
• LOB apps (MSI, APPX and MSIX)
• Microsoft 365 Apps for enterprise

Windows LOB apps (specifically APPX and MSIX) and Microsoft Store for Business apps (Offline apps) that you’ve selected to install in device context must be assigned to a device group. The installation fails if one of these apps is deployed in the user context. The following status and error appears in the admin console:

• Status: Failed.
• Error: A user can’t be targeted with a device context install.

When used in combination with an Autopilot pre-provisioning scenario, there is no requirement for LOB apps and Microsoft Store for Business apps deployed in device context to target a device group. For more information, see Windows Autopilot pre-provisioning deployment.

After you save an app assignment with a specific deployment, you can’t change the context for that assignment, except for modern apps. For modern apps, you can change the context from user context to device context.

If there’s a conflict in policies on a single user or device, the following priorities apply:

• A device context policy is a higher priority than a user context policy.
• An install policy is a higher priority than an uninstall policy.

For more information, see Include and exclude app assignments in Microsoft Intune. For more information about app types in Intune, see Add apps to Microsoft Intune.

Getting started with App-V for Windows 10

Applies to: Windows 10, version 1607

Microsoft Application Virtualization (App-V) for Windows 10 delivers Win32 applications to users as virtual applications. Virtual applications are installed on centrally managed servers and delivered to users as a service in real time and on an as-needed basis. Users launch virtual applications from familiar access points and interact with them as if they were installed locally.

With the release of Windows 10, version 1607, App-V is included with the Windows 10 for Enterprise edition. If you’re new to Windows 10 and App-V, you’ll need to download, activate, and install server- and client-side components to start delivering virtual applications to users. To learn what you need to know before getting started with App-V, see the Application Virtualization (App-V) overview.

If you’re already using App-V, performing an in-place upgrade to Windows 10 on user devices automatically installs the App-V client and migrates users’ App-V applications and settings. For more information about how to configure an existing App-V installation after upgrading user devices to Windows 10, see Upgrading to App-V for Windows 10 from an existing installation.

You can upgrade your existing App-V installation to App-V for Windows from App-V versions 5.0 SP2 and higher only. If you are using an earlier version of App-V, you’ll need to upgrade your existing App-V installation to App-V 5.0 SP2 before upgrading to App-V for Windows.

To learn more about previous versions of App-V, see MDOP information experience.

Getting started with App-V for Windows 10 (new installations)

To start using App-V to deliver virtual applications to users, you’ll need to download, enable, and install server- and client-side components. The following table describes the App-V for Windows 10 components, what they do, and where to find them.

Component	What it does	Where to find it
App-V server components	App-V offers five server components that work together to allow you to host and publish virtual applications, generate usage reports, and manage your App-V environment. For more details, see Deploying the App-V Server. If you’re already using App-V 5.x, you don’t need to redeploy the App-V server components, as they haven’t changed since App-V 5.0’s release.	The App-V server components are included in the Microsoft Desktop Optimization Pack (MDOP) 2015 ISO package that can be downloaded from the following locations: If you have a Microsoft Developer Network (MSDN) subscription, use the MSDN (Microsoft Developer Network) subscriptions site to download the MDOP ISO package. See Deploying the App-V Server for more information about installing and using the server components.
App-V client and App-V Remote Desktop Services (RDS) client	The App-V client is the component that runs virtualized applications on user devices, allowing users to interact with icons and file names to start virtualized applications.	The App-V client is automatically installed with Windows 10, version 1607. To learn how to enable the client, see Enable the App-V desktop client.
App-V sequencer	Use the App-V sequencer to convert Win32 applications into virtual packages for deployment to user devices. Devices must run the App-V client to allow users to interact with virtual applications.	Installed with the Windows Assessment and Deployment kit (ADK) for Windows 10, version 1607.

For more information about these components, see High Level Architecture for App-V.

If you’re new to App-V, it’s a good idea to read the documentation thoroughly. Before deploying App-V in a production environment, you can ensure installation goes smoothly by validating your deployment plan in a test network environment. You might also consider taking a class about relevant technologies. To get started, see the Microsoft Training Overview.

Getting started with App-V

What’s new in App-V provides a high-level overview of App-V and how it can be used in your organization.

Evaluating App-V provides information about how you can best evaluate App-V for use in your organization.

High Level Architecture for App-V provides a description of the App-V features and how they work together.

Set up a multi-app kiosk

Applies to

• Windows 10 Pro, Enterprise, and Education

A kiosk device typically runs a single app, and users are prevented from accessing any features or functions on the device outside of the kiosk app. In Windows 10, version 1709, the AssignedAccess configuration service provider (CSP) was expanded to make it easy for administrators to create kiosks that run more than one app. The benefit of a kiosk that runs only one or more specified apps is to provide an easy-to-understand experience for individuals by putting in front of them only the things they need to use, and removing from their view the things they don’t need to access.

The following table lists changes to multi-app kiosk in recent updates.

New features and improvements	In update
— Configure a single-app kiosk profile in your XML file — Configure an account to sign in automatically	Windows 10, version 1803
— Explicitly allow some known folders when user opens file dialog box — Configure a display name for the autologon account	Windows 10, version 1809 Important: To use features released in Windows 10, version 1809, make sure that your XML file references https://schemas.microsoft.com/AssignedAccess/201810/config .

The assigned access feature is intended for corporate-owned fixed-purpose devices, like kiosks. When the multi-app assigned access configuration is applied on the device, certain policies are enforced system-wide, and will impact other users on the device. Deleting the kiosk configuration will remove the assigned access lockdown profiles associated with the users, but it cannot revert all the enforced policies (such as Start layout). A factory reset is needed to clear all the policies enforced via assigned access.

You can configure multi-app kiosks using Microsoft Intune or a provisioning package.

Be sure to check the configuration recommendations before you set up your kiosk.

Configure a kiosk in Microsoft Intune

Configure a kiosk using a provisioning package

Watch how to use a provisioning package to configure a multi-app kiosk.

If you don’t want to use a provisioning package, you can deploy the configuration XML file using mobile device management (MDM) or you can configure assigned access using the MDM Bridge WMI Provider.

Prerequisites

• Windows Configuration Designer (Windows 10, version 1709 or later)
• The kiosk device must be running Windows 10 (S, Pro, Enterprise, or Education), version 1709 or later

For devices running versions of Windows 10 earlier than version 1709, you can create AppLocker rules to configure a multi-app kiosk.

Create XML file

Let’s start by looking at the basic 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 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 (or any other examples in this topic) into a XML editor, and saving the file as filename.xml. Each section of this XML is explained in this topic. You can see a full sample version in the Assigned access XML reference.

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: New in Windows 10, version 1803, this profile replaces the KioskModeApp node of the AssignedAccess CSP. Users assigned a kiosk profile will not see the desktop, but only the kiosk app running in full-screen mode.

A lockdown profile section in the XML has the following entries:

A kiosk profile in the XML has the following entries:

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.

AllowedApps

AllowedApps is a list of applications that are allowed to run. Apps can be Universal Windows Platform (UWP) apps or Windows desktop applications. In 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% (i.e. %systemroot%, %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 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.

You cannot 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 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.

Here are the predefined assigned access AppLocker rules 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 Groove Music, Movies & TV, 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.

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 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.

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.

FileExplorerNamespaceRestriction has been extended in current Windows 10 Prerelease for finer granularity and easier use, see in the Assigned access XML reference. for full samples. The changes will allow IT Admin to configure if user can access Downloads folder, Removable drives, or no restriction at all by using certain new elements. Note that FileExplorerNamesapceRestrictions 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 is not used, or used but left empty, user will not be able to access any folder in common dialog (e.g. Save As in 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.

StartLayout

After you define the list of allowed applications, you can customize the Start layout for your kiosk experience. You can choose to pin all the allowed apps on the Start screen or just a subset, depending on whether you want the end user to directly access them on the Start screen.

The easiest way to create a customized Start layout to apply to other Windows 10 devices is to set up the Start screen on a test device and then export the layout. For detailed steps, see Customize and export Start layout.

A few things to note here:

• 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 multi-app assigned access configuration.
• Since the multi-app assigned access experience is intended for fixed-purpose devices, to ensure the device experiences are consistent and predictable, use the full Start layout option instead of the partial Start layout.
• There are no apps pinned on the taskbar in the multi-app mode, and it is not supported to configure Taskbar layout using the tag in a layout modification XML as part of the assigned access configuration.
• The following example uses DesktopApplicationLinkPath to pin the desktop app to start. When the desktop app doesn’t have a shortcut link on the target device, learn how to provision .lnk files using Windows Configuration Designer.

This example pins Groove Music, Movies & TV, Photos, Weather, Calculator, Paint, and Notepad apps on Start.

If an app is not installed for the user but is included in the Start layout XML, the app will not be 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:

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.

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, 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.

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; doing this in the XML file will result in unexpected/unsupported experiences when this admin user signs in.

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

The following example shows how to specify an account to sign in automatically.

In 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».

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.)

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 .

• 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\ . AzureAD must be provided AS IS (consider it’s a fixed domain name), then follow with the Azure AD email address, e.g. AzureAD\someone@contoso.onmicrosoft.com.

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.

Config for group accounts

Group accounts are specified using . Nested groups are not 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 will not 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 will not have the kiosk settings applied.

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.

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.

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.

[Preview] Global Profile

Global profile is added in current Windows 10 Prerelease. There are times when IT Admin wants to everyone who logging into a specific devices are assigned access users, even there is no dedicated profile for that user, or there are times that Assigned Access could not identify a profile for the user and a fallback profile is wished to use. Global Profile is designed for these scenarios.

Usage is demonstrated below, by using the new xml namespace and specify GlobalProfile from that namespace. When GlobalProfile is configured, a non-admin account logs in, if this user does not have designated profile in Assigned Access, or Assigned Access fails to determine a profile for current user, global profile will be applied for the user.

1. GlobalProfile can only be multi-app profile
2. Only one GlobalProfile can be used in one AssignedAccess Configuration Xml
3. GlobalProfile can be used as the only config, or it can be used among with regular user or group Config.

Add XML file to provisioning package

Before you add the XML file to a provisioning package, you can validate your configuration XML against the XSD.

Use the Windows Configuration Designer tool to create a provisioning package. Learn how to install Windows Configuration Designer.

When you build a provisioning package, you may include sensitive information in the project files and in the provisioning package (.ppkg) file. Although you have the option to encrypt the .ppkg file, project files are not encrypted. You should store the project files in a secure location and delete the project files when they are no longer needed.

Open Windows Configuration Designer (by default, %systemdrive%\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Imaging and Configuration Designer\x86\ICD.exe).

Choose Advanced provisioning.

Name your project, and click Next.

Choose All Windows desktop editions and click Next.

On New project, click Finish. The workspace for your package opens.

Expand Runtime settings > AssignedAccess > MultiAppAssignedAccessSettings.

In the center pane, click Browse to locate and select the assigned access configuration XML file that you created.

(Optional: If you want to apply the provisioning package after device initial setup and there is an admin user already available on the kiosk device, skip this step.) Create an admin user account in Runtime settings > Accounts > Users. Provide a UserName and Password, and select UserGroup as Administrators. With this account, you can view the provisioning status and logs if needed.

(Optional: If you already have a non-admin account on the kiosk device, skip this step.) Create a local standard user account in Runtime settings > Accounts > Users. Make sure the UserName is the same as the account that you specify in the configuration XML. Select UserGroup as Standard Users.

On the File menu, select Save.

On the Export menu, select Provisioning package.

Change Owner to IT Admin, which will set the precedence of this provisioning package higher than provisioning packages applied to this device from other sources, and then select Next.

Optional. In the Provisioning package security window, you can choose to encrypt the package and enable package signing.

Enable package encryption — If you select this option, an auto-generated password will be shown on the screen.

Enable package signing — If you select this option, you must select a valid certificate to use for signing the package. You can specify the certificate by clicking Browse and choosing the certificate you want to use to sign the package.

Click Next to specify the output location where you want the provisioning package to go when it’s built. By default, Windows Imaging and Configuration Designer (ICD) uses the project folder as the output location.

Optionally, you can click Browse to change the default output location.

Click Next.

Click Build to start building the package. The provisioning package doesn’t take long to build. The project information is displayed in the build page and the progress bar indicates the build status.

If you need to cancel the build, click Cancel. This cancels the current build process, closes the wizard, and takes you back to the Customizations Page.

If your build fails, an error message will show up that includes a link to the project folder. You can scan the logs to determine what caused the error. Once you fix the issue, try building the package again.

If your build is successful, the name of the provisioning package, output directory, and project directory will be shown.

• If you choose, you can build the provisioning package again and pick a different path for the output package. To do this, click Back to change the output package name and path, and then click Next to start another build.
• If you are done, click Finish to close the wizard and go back to the Customizations Page.

Copy the provisioning package to the root directory of a USB drive.

Apply provisioning package to device

Provisioning packages can be applied to a device during the first-run experience (out-of-box experience or «OOBE») and after («runtime»).

In addition to the methods below, you can use the PowerShell comdlet install-provisioningpackage with -LogsDirectoryPath to get logs for the operation.

During initial setup, from a USB drive

Start with a computer on the first-run setup screen. If the PC has gone past this screen, reset the PC to start over. To reset the PC, go to Settings > Update & security > Recovery > Reset this PC.

Insert the USB drive. Windows Setup will recognize the drive and ask if you want to set up the device. Select Set up.

The next screen asks you to select a provisioning source. Select Removable Media and tap Next.

Select the provisioning package (*.ppkg) that you want to apply, and tap Next.

Select Yes, add it.

After setup, from a USB drive, network folder, or SharePoint site

1. Sign in with an admin account.
2. Insert the USB drive to a desktop computer, navigate to Settings >Accounts >Access work or school >Add or remove a provisioning package >Add a package, and select the package to install. For a provisioning package stored on a network folder or on a SharePoint site, navigate to the provisioning package and double-click it to begin installation.

if your provisioning package doesn’t include the assigned access user account creation, make sure the account you specified in the multi-app configuration XML exists on the device.

### Use MDM to deploy the multi-app configuration

Multi-app kiosk mode is enabled by the AssignedAccess configuration service provider (CSP). Your MDM policy can contain the assigned access configuration XML.

If your device is enrolled with a MDM server which supports applying the assigned access configuration, you can use it to apply the setting remotely.

The OMA-URI for multi-app policy is ./Device/Vendor/MSFT/AssignedAccess/Configuration .

Considerations for Windows Mixed Reality immersive headsets

With the advent of mixed reality devices (video link), you might want to create a kiosk that can run mixed reality apps.

To create a multi-app kiosk that can run mixed reality apps, you must include the following apps in the AllowedApps list:

These are in addition to any mixed reality apps that you allow.

Before your kiosk user signs in: An admin user must sign in to the PC, connect a mixed reality device, and complete the guided setup for the Mixed Reality Portal. The first time that the Mixed Reality Portal is set up, some files and content are downloaded. A kiosk user would not have permissions to download and so their setup of the Mixed Reality Portal would fail.

After the admin has completed setup, the kiosk account can sign in and repeat the setup. The admin user may want to complete the kiosk user setup before providing the PC to employees or customers.

There is a difference between the mixed reality experiences for a kiosk user and other users. Typically, when a user connects a mixed reality device, they begin in the Mixed Reality home. The Mixed Reality home is a shell that runs in «silent» mode when the PC is configured as a kiosk. When a kiosk user connects a mixed reality device, they will see only a blank display in the device, and will not have access to the features and functionality available in the home. To run a mixed reality app, the kiosk user must launch the app from the PC Start screen.

Policies set by multi-app kiosk configuration

It is not recommended to set policies enforced in assigned access multi-app mode to different values using other channels, as the multi-app mode has been optimized to provide a locked-down experience.

When the multi-app assigned access configuration is applied on the device, certain policies are enforced system-wide, and will impact other users on the device.

Group Policy

The following local policies affect all non-administrator users on the system, regardless whether the user is configured as an assigned access user or not. This includes local users, domain users, and Azure Active Directory users.

Setting	Value
Remove access to the context menus for the task bar	Enabled
Clear history of recently opened documents on exit	Enabled
Prevent users from customizing their Start Screen	Enabled
Prevent users from uninstalling applications from Start	Enabled
Remove All Programs list from the Start menu	Enabled
Remove Run menu from Start Menu	Enabled
Disable showing balloon notifications as toast	Enabled
Do not allow pinning items in Jump Lists	Enabled
Do not allow pinning programs to the Taskbar	Enabled
Do not display or track items in Jump Lists from remote locations	Enabled
Remove Notifications and Action Center	Enabled
Lock all taskbar settings	Enabled
Lock the Taskbar	Enabled
Prevent users from adding or removing toolbars	Enabled
Prevent users from resizing the taskbar	Enabled
Remove frequent programs list from the Start Menu	Enabled
Remove ‘Map Network Drive’ and ‘Disconnect Network Drive’	Enabled
Remove the Security and Maintenance icon	Enabled
Turn off all balloon notifications	Enabled
Turn off feature advertisement balloon notifications	Enabled
Turn off toast notifications	Enabled
Remove Task Manager	Enabled
Remove Change Password option in Security Options UI	Enabled
Remove Sign Out option in Security Options UI	Enabled
Remove All Programs list from the Start Menu	Enabled – Remove and disable setting
Prevent access to drives from My Computer	Enabled — Restrict all drivers

When Prevent access to drives from My Computer is enabled, users can browse the directory structure in File Explorer, but they cannot open folders and access the contents. Also, they cannot use the Run dialog box or the Map Network Drive dialog box to view the directories on these drives. The icons representing the specified drives still appear in File Explorer, but if users double-click the icons, a message appears explaining that a setting prevents the action. This setting does not prevent users from using programs to access local and network drives. It does not prevent users from using the Disk Management snap-in to view and change drive characteristics.

MDM policy

Some of the MDM policies based on the Policy configuration service provider (CSP) affect all users on the system (i.e. system-wide).

Setting	Value	System-wide
Experience/AllowCortana	0 — Not allowed	Yes
Start/AllowPinnedFolderDocuments	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderDownloads	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderFileExplorer	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderHomeGroup	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderMusic	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderNetwork	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderPersonalFolder	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderPictures	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderSettings	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/AllowPinnedFolderVideos	0 — Shortcut is hidden and disables the setting in the Settings app	Yes
Start/DisableContextMenus	1 — Context menus are hidden for Start apps	No
Start/HidePeopleBar	1 — True (hide)	No
Start/HideChangeAccountSettings	1 — True (hide)	Yes
WindowsInkWorkspace/AllowWindowsInkWorkspace	0 — Access to ink workspace is disabled and the feature is turned off	Yes
Start/StartLayout	Configuration dependent	No
WindowsLogon/DontDisplayNetworkSelectionUI	Yes

Provision .lnk files using Windows Configuration Designer

First, create your desktop app’s shortcut file by installing the app on a test device, using the default installation location. Right-click the installed application, and choose Send to > Desktop (create shortcut). Rename the shortcut to .lnk

Next, create a batch file with two commands. If the desktop app is already installed on the target device, skip the first command for MSI install.

In Windows Configuration Designer, under ProvisioningCommands > DeviceContext:

Under CommandFiles, upload your batch file, your .lnk file, and your desktop app installation file.

Paste the full file path to the .lnk file in the CommandFiles field. If you browse to and select the .lnk file, the file path will be changed to the path of the target of the .lnk.

Under CommandLine, enter cmd /c *FileName*.bat .