deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 05:17:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Update kiosk user account name in shell-launcher-quickstart-kiosk.md

Browse Source
This commit is contained in:
Paolo Matarazzo 2024-02-28 11:49:02 -05:00
parent 8bca2f1b28
commit bdbec818f5
6 changed files with 76 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
windows/configuration/assigned-access/assigned-access-configure.md
View File

@ -414,3 +414,24 @@ This procedure explains how to configure digital signage using Kiosk Browser on
1. Attach the USB drive to the device that you want to use for your digital sign.
1. Go to **Settings** > **Accounts** > **Access work or school** > **Add or remove a provisioning package** > **Add a package**, and select the package on the USB drive.
-->
<!-->
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 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 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'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.
-->

3
windows/configuration/assigned-access/index.md
View File

@ -62,8 +62,7 @@ There are several kiosk configuration methods that you can choose from, dependin
>[!IMPORTANT]
>Single-app kiosk mode isn't supported over a remote desktop connection. Your kiosk users must sign in on the physical device that is set up as a kiosk.
[!INCLUDE [assigned-access-kiosk-mode](../../../includes/licensing/assigned-access.md)]
[!INCLUDE [assigned-access-kiosk-mode](../../../includes/licensing/shell-launcher.md)]
[!INCLUDE [assigned-access](../../../includes/licensing/assigned-access.md)]
## Summary of configuration methods

28
windows/configuration/assigned-access/shell-launcher-configuration-file.md
View File

@ -103,6 +103,34 @@ The `Shell` node defines the application that executes when the user signs in:
</ShellLauncherConfiguration>
```
## Default action, custom action, exit code
Shell Launcher defines four actions to handle app exits. You can customize Shell Launcher and use the actions based on different exit code.
| Value | Description |
|--|--|
| 0 | Restart the shell |
| 1 | Restart the device |
| 2 | Shut down the device |
| 3 | Do nothing |
These actions can be used as default action, or can be mapped to a specific exit code. Refer to [Shell Launcher](/windows-hardware/customize/enterprise/wesl-usersettingsetcustomshell) to see how these codes with Shell Launcher WMI.
To configure these actions with Shell Launcher CSP, use below syntax in the Shell Launcher configuration xml. You can specify at most four custom actions mapping to four exit codes, and one default action for all other exit codes. When app exits and if the exit code is not found in the custom action mapping, or there is no default action defined, it will be no-op, i.e. nothing happens. So it's recommended to at least define DefaultAction. [Get XML examples for different Shell Launcher v2 configurations.](https://github.com/Microsoft/Windows-iotcore-samples/tree/develop/Samples/ShellLauncherV2)
``` xml
<ReturnCodeActions>
<ReturnCodeAction ReturnCode="0" Action="RestartShell"/>
<ReturnCodeAction ReturnCode="-1" Action="RestartDevice"/>
<ReturnCodeAction ReturnCode="255" Action="ShutdownDevice"/>
<ReturnCodeAction ReturnCode="1" Action="DoNothing"/>
</ReturnCodeActions>
<DefaultAction Action="RestartDevice"/>
```
## AllAppsFullScreen
In the XML for Shell Launcher v2, note the **AllAppsFullScreen** attribute. When set to **True**, Shell Launcher will run every app in full screen, or maximized for desktop apps. When this attribute is set to **False** or not set, only the custom shell app runs in full screen; other apps launched by the user will run in windowed mode.
### AppType

84
windows/configuration/assigned-access/shell-launcher-configure.md
View File

@ -5,83 +5,47 @@ ms.date: 05/12/2023
ms.topic: how-to
---
## Configure devices with Shell Launcher
# Configure devices with Shell Launcher
Shell Launcher is an Assigned Access configuration that replaces the default Windows Explorer shell (`explorer.exe`) with the `CustomShellHost.exe` application. CustomShellHost can launch a Windows desktop application or a UWP app.
>[!NOTE]
>Shell Launcher controls which application the user sees as the shell after sign-in. It doesn't prevent the user from accessing other desktop applications and system components.
>
>Methods of controlling access to other desktop applications and system components can be used in addition to using the Shell Launcher. These methods include, but are not limited to:
>- [Group Policy](https://www.microsoft.com/download/details.aspx?id=25250) - example: Prevent access to registry editing tools
>- [AppLocker](/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview) - Application control policies
>- [Mobile Device Management](/windows/client-management/mdm) - Enterprise management of device security policies
Shell Launcher controls which application the user sees as the shell after sign-in. It doesn't prevent the user from accessing other desktop applications and system components. From a custom shell, you can launch secondary views displayed on multiple monitors, or launch other apps in full screen on user's demand.
You can configure Shell Launcher via [PowerShell](#configure-a-custom-shell-using-powershell) and [CSP](#configure-a-custom-shell-in-mdm).
Methods of controlling access to other desktop applications and system components can be used with Shell Launcher. These methods include, but are not limited to:
Shell Launcher offers the following features:
- Configuration Service Provider (CSP): you can use a Mobile Device Management (MDM) solution like Microsoft Intune
- Group policy (GPO)
- [AppLocker](/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview)
- You can use a custom Windows desktop application that can then launch UWP apps, such as *Settings* or *Touch Keyboard*
- From a custom UWP shell, you can launch secondary views displayed on multiple monitors
- The custom shell app runs in full screen, and can run other apps in full screen on user's demand
## Windows edition requirements
The following table lists the Windows editions that support Shell Launcher:
## Requirements
|Windows Pro|Windows Enterprise|Windows Pro Education/SE|Windows Education|
|:---:|:---:|:---:|:---:|
|No|Yes|No|Yes|
>[!WARNING]
>
>- Windows 10 doesn't support setting a custom shell prior to OOBE. If you do, you won't be able to deploy the resulting image.
>- Shell Launcher doesn't support a custom shell with an application that launches a different process and exits. For example, you cannot specify **write.exe** in Shell Launcher. Shell Launcher launches a custom shell and monitors the process to identify when the custom shell exits. **Write.exe** creates a 32-bit wordpad.exe process and exits. Because Shell Launcher is not aware of the newly created wordpad.exe process, Shell Launcher will take action based on the exit code of **Write.exe**, such as restarting the custom shell.
## Limitations
- A domain, Microsoft Entra ID, or local user account.
- A Windows application that is installed for that account. The app can be your own company application or a common app like Internet Explorer.
Here are some limitations to consider when using Shell Launcher:
[See the technical reference for the Shell Launcher component.](/windows-hardware/customize/enterprise/shell-launcher)
- Windows doesn't support setting a custom shell prior to out-of-box experience OOBE. If you do, you can't deploy the resulting image
- Shell Launcher doesn't support a custom shell with an application that launches a different process and exits. For example, you can't specify `write.exe` in Shell Launcher. Shell Launcher launches a custom shell and monitors the process to identify when the custom shell exits. `Write.exe` creates a 32-bit `wordpad.exe` process and exits. Since Shell Launcher is not aware of the newly created `wordpad.exe` process, Shell Launcher will take action based on the exit code of `Write.exe`, such as restarting the custom shell.
## Configure a custom shell in MDM
## Configure a device with Shell Launcher
You can use XML and a [custom OMA-URI setting](#custom-oma-uri-setting) to configure Shell Launcher in MDM.
[!INCLUDE [tab-intro](../../../includes/configure/tab-intro.md)]
### XML for Shell Launcher configuration
#### [:::image type="icon" source="../images/icons/intune.svg"::: **Intune/CSP**](#tab/intune)
You can configure devices using a [custom policy][MEM-1] with the [AssignedAccess CSP][WIN-3].
>[!TIP]
>In the XML for Shell Launcher v2, note the **AllAppsFullScreen** attribute. When set to **True**, Shell Launcher will run every app in full screen, or maximized for desktop apps. When this attribute is set to **False** or not set, only the custom shell app runs in full screen; other apps launched by the user will run in windowed mode.
- **Setting:** `./Vendor/MSFT/AssignedAccess/ShellLauncher`
- **Value:** content of the XML configuration file
### Custom OMA-URI setting
#### [:::image type="icon" source="../images/icons/powershell.svg"::: **PowerShell**](#tab/ps)
In your MDM service, you can create a [custom OMA-URI setting](/intune/custom-settings-windows-10) to configure Shell Launcher v1 or v1. (The [XML](#xml-for-shell-launcher-configuration) that you use for your setting determines whether you apply Shell Launcher v1 or v2.)
---
The OMA-URI path is `./Device/Vendor/MSFT/AssignedAccess/ShellLauncher`.
Depending on your configuration method, you can have a user to automatically sign in to the device.
For the value, you can select data type `String` and paste the desired configuration file content into the value box. If you wish to upload the xml instead of pasting the content, choose data type `String (XML file)`.
After you configure the profile containing the custom Shell Launcher setting, select **All Devices** or selected groups of devices to apply the profile to. Don't assign the profile to users or user groups.
## Configure a custom shell using PowerShell
## Default action, custom action, exit code
Shell Launcher defines four actions to handle app exits. You can customize Shell Launcher and use the actions based on different exit code.
| Value | Description |
|--|--|
| 0 | Restart the shell |
| 1 | Restart the device |
| 2 | Shut down the device |
| 3 | Do nothing |
These actions can be used as default action, or can be mapped to a specific exit code. Refer to [Shell Launcher](/windows-hardware/customize/enterprise/wesl-usersettingsetcustomshell) to see how these codes with Shell Launcher WMI.
To configure these actions with Shell Launcher CSP, use below syntax in the Shell Launcher configuration xml. You can specify at most four custom actions mapping to four exit codes, and one default action for all other exit codes. When app exits and if the exit code is not found in the custom action mapping, or there is no default action defined, it will be no-op, i.e. nothing happens. So it's recommended to at least define DefaultAction. [Get XML examples for different Shell Launcher v2 configurations.](https://github.com/Microsoft/Windows-iotcore-samples/tree/develop/Samples/ShellLauncherV2)
``` xml
<ReturnCodeActions>
<ReturnCodeAction ReturnCode="0" Action="RestartShell"/>
<ReturnCodeAction ReturnCode="-1" Action="RestartDevice"/>
<ReturnCodeAction ReturnCode="255" Action="ShutdownDevice"/>
<ReturnCodeAction ReturnCode="1" Action="DoNothing"/>
</ReturnCodeActions>
<DefaultAction Action="RestartDevice"/>
```

2
windows/configuration/assigned-access/shell-launcher-quickstart-kiosk.md
View File

@ -56,7 +56,7 @@ Alternatively, you can configure devices using a [custom policy][MEM-1] with the
## User experience
After the settings are applied, reboot the device. A local user account named `Airport Kiosk` is automatically signed in, opening Microsoft Edge.
After the settings are applied, reboot the device. A local user account is automatically signed in, opening Microsoft Edge.
## Next steps

2
windows/security/includes/sections/operating-system-security.md
View File

@ -13,7 +13,7 @@ ms.topic: include
| **[Measured boot](/windows/compatibility/measured-boot)** | Measured Boot measures all important code and configuration settings during the boot of Windows. This includes: the firmware, boot manager, hypervisor, kernel, secure kernel and operating system. Measured Boot stores the measurements in the TPM on the machine, and makes them available in a log that can be tested remotely to verify the boot state of the client.<br><br>The Measured Boot feature provides anti-malware software with a trusted (resistant to spoofing and tampering) log of all boot components that started before it. The anti-malware software can use the log to determine whether components that ran before it are trustworthy, or if they're infected with malware. The anti-malware software on the local machine can send the log to a remote server for evaluation. The remote server may initiate remediation actions, either by interacting with software on the client, or through out-of-band mechanisms, as appropriate. |
| **[Device health attestation service](/windows/security/operating-system-security/system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices)** | The Windows device health attestation process supports a zero-trust paradigm that shifts the focus from static, network-based perimeters, to users, assets, and resources. The attestation process confirms the device, firmware, and boot process are in a good state and haven't been tampered with before they can access corporate resources. The determinations are made with data stored in the TPM, which provides a secure root of trust. The information is sent to an attestation service, such as Azure Attestation, to verify the device is in a trusted state. Then, an MDM tool like Microsoft Intune reviews device health and connects this information with Microsoft Entra ID for conditional access. |
| **[Windows security policy settings and auditing](/windows/security/threat-protection/security-policy-settings/security-policy-settings)** | Microsoft provides a robust set of security settings policies that IT administrators can use to protect Windows devices and other resources in their organization. |
| **[Assigned Access](/windows/configuration/assigned-access)** | Some desktop devices in an enterprise serve a special purpose. For example, a PC in the lobby that customers use to see your product catalog. Or, a PC displaying visual content as a digital sign. Windows client offers two different locked-down experiences for public or specialized use: A single-app kiosk that runs a single Universal Windows Platform (UWP) app in full screen above the lock screen, or A multi-app kiosk that runs one or more apps from the desktop.<br><br>Kiosk configurations are based on Assigned Access, a feature in Windows that allows an administrator to manage the user's experience by limiting the application entry points exposed to the user. |
| **[Assigned Access](/windows/configuration/assigned-access/)** | Some desktop devices in an enterprise serve a special purpose. For example, a PC in the lobby that customers use to see your product catalog. Or, a PC displaying visual content as a digital sign. Windows client offers two different locked-down experiences for public or specialized use: A single-app kiosk that runs a single Universal Windows Platform (UWP) app in full screen above the lock screen, or A multi-app kiosk that runs one or more apps from the desktop.<br><br>Kiosk configurations are based on Assigned Access, a feature in Windows that allows an administrator to manage the user's experience by limiting the application entry points exposed to the user. |
## Virus and threat protection