mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-15 18:33:43 +00:00
Update function to handle edge case
This commit is contained in:
@ -166,7 +166,7 @@ A *profile node* contains the following properties:
|
||||
|
||||
### 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.
|
||||
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 are 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]()
|
||||
@ -175,21 +175,21 @@ Based on the purpose of the kiosk device, define the list of applications that a
|
||||
- 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
|
||||
When the multi-app kiosk configuration is applied to a device, AppLocker rules are 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.
|
||||
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 are excluded. This deny list is 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.
|
||||
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 won't 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.
|
||||
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's 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.
|
||||
-->
|
||||
@ -257,7 +257,7 @@ The following example pins Calculator, Photos, Weather, Calculator, Command Prom
|
||||
|
||||
### 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.
|
||||
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'll 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.
|
||||
|
||||
@ -335,8 +335,8 @@ You can assign:
|
||||
|
||||
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
|
||||
- Configs that specify group accounts can't use a kiosk profile, only a restricted user experience profile
|
||||
- Apply the restricted user experience to standard users only. It's not supported to associate an admin user with an Assigned Access profile
|
||||
|
||||
:::row:::
|
||||
:::column:::
|
||||
@ -380,7 +380,7 @@ Individual accounts are specified using `<Account>`.
|
||||
> [!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.
|
||||
Before applying the multi-app configuration, make sure the specified user account is available on the device, otherwise it fails.
|
||||
|
||||
> [!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.
|
||||
@ -396,7 +396,7 @@ Before applying the multi-app configuration, make sure the specified user accoun
|
||||
|
||||
### 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.
|
||||
Group accounts are specified using `<UserGroup>`. Nested groups aren't supported. For example, if *User A* is member of *Group A*, *Group A* is member of *Group B*, and *Group B* is used in `<Config/>`, *User A* doesn't have the kiosk experience.
|
||||
|
||||
|
||||
:::row:::
|
||||
@ -501,7 +501,7 @@ This sample demonstrates that both UWP and Win32 apps can be configured to autom
|
||||
|
||||
### Global profile
|
||||
|
||||
With `GlobalProfile` you can define an Assigned Access profile that is applied to every non-admin account that signs in. This can be useful in scenarios like front line workers or student devices, where you want to ensure that every user has a consistent experience.
|
||||
With `GlobalProfile` you can define an Assigned Access profile that is applied to every non-admin account that signs in. This can be useful in scenarios like frontline workers or student devices, where you want to ensure that every user has a consistent experience.
|
||||
|
||||
```xml
|
||||
<Configs>
|
||||
|
Reference in New Issue
Block a user