Blindar equipos de uso dedicado con el modo kiosco de Windows ── Cómo elegir entre Assigned Access y Shell Launcher, y diseñar su operación

«En un PC que se suponía dedicado a la recepción, un visitante abrió Excel desde la barra de tareas.» «Detrás de la pantalla de operación de un equipo se estaba reproduciendo YouTube, y esa era la causa de la queja sobre que el panel táctil respondía mal.» «La máquina de demostración de una feria amaneció con el escritorio a la vista y la pantalla de configuración del protector de pantalla abierta.» ── Si se los deja sin blindar, los equipos Windows que se suponían dedicados a una sola aplicación siempre terminan usándose como «un PC cualquiera».

Una medida habitual es «configurar el inicio de sesión automático y registrar la aplicación de negocio en el inicio», pero eso no protege nada: el shell de Explorer sigue completamente activo, así que con Alt+Tab o la tecla Windows se llega al escritorio en un instante. Por otro lado, Windows ofrece varios mecanismos para el kiosco —Assigned Access, Shell Launcher y el kiosco multiaplicación— y cuál se puede usar depende de la edición y de la versión de Windows, por lo que es habitual el retrabajo de «intenté configurarlo en un equipo Pro y resultó que Shell Launcher no estaba disponible».

Este artículo está dirigido a desarrolladores y responsables de TI que necesitan configurar «un PC que solo ejecuta una aplicación» —equipos de recepción, terminales de operación en fábrica, paneles de control de equipos de inspección, máquinas de demostración— y organiza, con respaldo en la documentación oficial, el panorama de los métodos, los requisitos de edición, ejemplos de configuración en PowerShell/XML y el diseño operativo: inicio de sesión automático, recuperación tras un cierre anormal, Windows Update y la vía de mantenimiento.

1. Conclusión resumida

• «Inicio de sesión automático + arranque desde el inicio» no es un kiosco. Mientras el shell de Explorer siga activo, el usuario puede hacer cualquier cosa. Si quiere protegerlo de verdad, use un mecanismo dedicado.
• El kiosco de una sola app de Assigned Access ejecuta a pantalla completa, por encima de la pantalla de bloqueo, una app UWP o Microsoft Edge, y se reinicia automáticamente si la app se cierra. Se puede usar desde la edición Pro en adelante.¹
• En Windows 11, Assigned Access también permite convertir en kiosco aplicaciones Win32 (de escritorio). Se indica la ruta del EXE en v4:ClassicAppPath, añadido en el esquema de Windows 11 (21H2) en adelante. En Windows 10, el kiosco se limita a UWP/Edge.²
• Shell Launcher es un mecanismo que reemplaza el propio Explorer.exe por la aplicación de negocio (Win32/UWP), y está limitado a las ediciones de la familia Enterprise, Education e IoT Enterprise. No se puede usar en Pro. El comportamiento al cerrarse el shell (reiniciar el shell, reiniciar el equipo, etc.) se puede declarar de forma declarativa.³⁴
• El kiosco multiaplicación (experiencia de usuario restringida) crea, mediante una lista de aplicaciones permitidas y un menú Inicio dedicado, un «equipo compartido en el que solo se pueden usar unas pocas aplicaciones». Se generan automáticamente reglas de AppLocker, de modo que las aplicaciones no permitidas no pueden iniciarse.²
• Los métodos de configuración se han ido unificando. Tanto la app única como la multiaplicación y Shell Launcher se configuran hoy, como procedimiento estándar, mediante el CSP AssignedAccess (MDM como Intune) o mediante el puente WMI que invoca localmente ese mismo CSP desde PowerShell.⁵⁶
• La salida de la experiencia de kiosco es, de forma predeterminada, Ctrl+Alt+Supr. En Windows 11 se puede cambiar con BreakoutSequence. Asegúrese siempre de dejar en el diseño una vía por la que el personal de mantenimiento pueda iniciar sesión.²
• Aunque blindemos el equipo, si el diseño de la propia aplicación de negocio no está resuelto (UI a pantalla completa, no mostrar botón de cierre, autorrecuperación ante excepciones) queda un agujero. El mecanismo del sistema operativo y el diseño de la aplicación van de la mano.

2. Panorama de las opciones ── Los cuatro métodos difieren en qué protegen

Primero pongamos los métodos uno junto a otro. Lo importante no es el aspecto visual, sino cómo queda el shell de Explorer y quién impide las operaciones no permitidas.

El criterio de uso es el siguiente.

• Equipos que tocan visitantes o personas no identificadas (recepción, exposición, navegación pública): kiosco de una sola app. La superficie expuesta es mínima.
• Equipos compartidos que usan un número fijo de aplicaciones (terminales de línea de producción, uso educativo): kiosco multiaplicación.
• Uso industrial en el que se ejecuta una sola aplicación de negocio Win32 como panel de operación de un equipo: Shell Launcher. Su punto fuerte es que la UI propia de Explorer (notificaciones, barra de tareas, UI que aparece al deslizar desde el borde) directamente no existe, y también resulta adecuado para equipos porque permite configurar la acción de recuperación según el código de salida.⁴
• El inicio de sesión automático + arranque desde el inicio se usa como componente (automatizar el inicio de sesión) de cualquiera de los métodos anteriores, pero por sí solo no es un kiosco.

Tenga en cuenta que no se puede configurar en el mismo equipo, al mismo tiempo, KioskModeApp (kiosco de una sola app) y Shell Launcher.² Debe elegir uno de los dos.

3. Requisitos de edición ── Qué se puede hacer con Pro y qué exige Enterprise

Antes de elegir el método, compruebe la edición del equipo con el que va a trabajar. Si deja esto para después, puede acabar rehaciendo todo el diseño.

• Assigned Access (una sola app / multiaplicación): Pro / Enterprise / Education / IoT Enterprise (incluidas sus respectivas LTSC).¹
• Shell Launcher: Enterprise / Enterprise LTSC / Education / IoT Enterprise / IoT Enterprise LTSC. No disponible en Pro.³
• Keyboard Filter (bloqueo de teclas): solo las familias Enterprise / Education / IoT Enterprise. No disponible en Pro.⁸

Es decir, la petición habitual de «quiero ejecutar una sola aplicación Win32 en un equipo Pro» se resuelve así:

• En Windows 11, se puede lograr directamente con v4:ClassicAppPath de Assigned Access.²
• En Windows 10 Pro no hay una opción directa: hay que convertir la app a UWP, aproximarse con un kiosco multiaplicación + inicio automático (rs5:AutoLaunch), o subir de edición.²

Si puede elegir el equipo desde cero para un uso embebido en maquinaria o un PC industrial, la opción natural es IoT Enterprise LTSC, que incluye Shell Launcher y Keyboard Filter y no impone actualizaciones de funciones. El criterio para elegir edición se trata en detalle en «Cómo elegir Windows para un PC industrial ── Guía práctica de IoT Enterprise LTSC», publicado el mismo día.

Otro requisito previo: la experiencia de kiosco necesita que UAC esté habilitado y que el inicio de sesión se haga desde la consola. No funciona a través de una conexión de Escritorio remoto.¹ La típica trampa de principiante es intentar «entrar por RDP para comprobar que funciona» y quedarse sin entender por qué no arranca. Para la relación entre la sesión de consola y la sesión RDP, consulte «Cómo entender la separación de sesiones en Windows».

4. Crear un kiosco de una sola app con Assigned Access

Hay tres vías de configuración. Las veremos en 4.1–4.3, de la más sencilla a la más completa, y para la vía recomendada —el XML de configuración— continuaremos con el procedimiento para aplicarlo realmente en el equipo (4.4) y con la forma de comprobar que se aplicó (4.5).

4.1 Crear desde la aplicación Configuración (un solo equipo; la vía más rápida con Edge/UWP)

El asistente permite crear la cuenta local para el kiosco y seleccionar la aplicación objetivo. El procedimiento es el siguiente.⁵

1. Abra Configuración > Cuentas > Otros usuarios
2. Pulse «Empezar» (Get Started) en «Configurar un kiosco» (Set up a kiosk)
3. En el cuadro de diálogo «Crear una cuenta», escriba el nombre de la cuenta y pulse «Siguiente» (si ya existe un usuario estándar local, también puede elegir «Usar una cuenta existente»)
4. Elija la aplicación que se ejecutará al iniciar sesión con la cuenta de kiosco. Si elige Microsoft Edge, a continuación configure lo siguiente
   • Si será a pantalla completa (señalización digital) o si conservará algunas funciones del navegador (navegador público)
   • La URL que se abrirá al iniciar sesión
   • Si elige navegador público, el tiempo de inactividad tras el cual se reinicia Edge
5. Pulse «Cerrar»

Tras la configuración, al reiniciar el equipo la cuenta local creada inicia sesión automáticamente y se abre la aplicación indicada.⁵ Si solo necesita un equipo con Edge o una app UWP sencilla, esto es suficiente.

4.2 Crear con cmdlets de PowerShell (solo UWP)

Set-AssignedAccess permite crear en una sola línea la configuración mínima de «este usuario estándar local solo puede usar esta app UWP» (limitado a UWP, a usuarios estándar locales; no admite cuentas de administrador).⁹

# Configurar el usuario estándar local KioskUser para que use exclusivamente la app UWP
Set-AssignedAccess -UserName 'KioskUser' -AppUserModelId 'Contoso.KenkiPanel_abc123!App'

# Revertir
Clear-AssignedAccess

El AUMID (AppUserModelID) que se pasa como argumento se averigua con Get-StartApps. Es el cmdlet que enumera el nombre y el AppID de las aplicaciones instaladas, y devuelve dos columnas, Name y AppID.¹⁰

# Buscar visualmente en la lista completa
Get-StartApps

# Filtrar por parte del nombre (admite comodines). El valor de la columna AppID es directamente el AUMID
Get-StartApps -Name '*KenkiPanel*' | Format-Table Name, AppID -AutoSize

La salida tiene esta forma (los valores varían según el entorno).¹⁰

Name              AppID
----              -----
KenkiPanel        Contoso.KenkiPanel_abc123!App

Un aspecto importante: Get-StartApps devuelve las aplicaciones instaladas del «usuario que lo ejecuta». Si quiere comprobar una aplicación aprovisionada para la cuenta de kiosco, inicie sesión con esa cuenta y ejecútelo desde ahí. El tropiezo típico es ejecutarlo con la cuenta de administrador y no ver la app. Tenga en cuenta también que el AUMID de una app UWP puede cambiar al actualizarse (en ese caso hay que rehacer la configuración).⁷

4.3 XML de configuración + CSP AssignedAccess (la vía recomendada)

Es el método recomendado, que cubre desde indicar una app Win32 hasta el inicio de sesión automático y el cambio de la tecla de salida. Desde un MDM como Intune se envía a ./Vendor/MSFT/AssignedAccess/Configuration; en un equipo independiente se inyecta el mismo XML a través del puente WMI desde PowerShell con privilegios SYSTEM.⁵ Los puntos clave del XML son los siguientes.

<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
    xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <!-- Windows 11: convertir una app Win32 en kiosco (también se pueden pasar argumentos) -->
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe"
                    v4:ClassicAppArguments="--line 3" />
      <!-- Cambiar la tecla de salida del Ctrl+Alt+Supr predeterminado -->
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <!-- Windows crea y gestiona un usuario estándar local dedicado e inicia sesión automáticamente -->
      <AutoLogonAccount rs5:DisplayName="Equipo de recepción" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>

Para una app UWP, se indica AppUserModelId (AUMID) en KioskModeApp. Tenga en cuenta que el AUMID de una app UWP puede cambiar al actualizarse, en cuyo caso hay que actualizar la configuración.⁷ Además, los perfiles de kiosco solo se pueden asignar a usuarios individuales, no a grupos.²

4.4 Aplicar la configuración con el puente WMI

En un equipo sin MDM, se invoca el mismo CSP a través del proveedor WMI del puente MDM. Es el punto donde más se suele atascar el procedimiento, así que lo detallamos paso a paso.⁵

Paso 1: iniciar PowerShell como SYSTEM. El puente WMI de la configuración del dispositivo debe ejecutarse con la cuenta SYSTEM (LocalSystem). Un PowerShell con privilegios de administrador no es suficiente.⁵ El método que indica oficialmente la documentación es usar PsExec de Sysinternals.

:: Abra el símbolo del sistema como administrador e inicie un PowerShell interactivo con privilegios SYSTEM
psexec.exe -i -s powershell.exe

Paso 2: comprobar que el PowerShell iniciado es realmente SYSTEM. Avanzar sin comprobar esto y acabar con «no da error, pero no surte efecto» es lo habitual.

# Si muestra NT AUTHORITY\SYSTEM, está correcto
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

Paso 3: codificar el XML como HTML e inyectarlo. Se ejecuta en esa misma sesión de PowerShell con privilegios SYSTEM.

$assignedAccessConfiguration = @"
<?xml version="1.0" encoding="utf-8"?>
<AssignedAccessConfiguration xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config" xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config" xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe" v4:ClassicAppArguments="--line 3" />
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount rs5:DisplayName="Equipo de recepción" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>
"@

$namespaceName = "root\cimv2\mdm\dmmap"
$className     = "MDM_AssignedAccess"

$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
# En lugar de pasar el XML tal cual, se codifica como HTML antes de asignarlo
$obj.Configuration = [System.Net.WebUtility]::HtmlEncode($assignedAccessConfiguration)
Set-CimInstance -CimInstance $obj

Paso 4: reiniciar el equipo. La configuración surte efecto a partir del inicio de sesión posterior al reinicio. Al reiniciar, la cuenta local creada por AutoLogonAccount inicia sesión automáticamente y se abre la aplicación indicada.⁵

Para revertir la configuración, desde el mismo PowerShell con privilegios SYSTEM, asigne $null a Configuration y reinicie.⁵

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration = $null
Set-CimInstance -CimInstance $obj

4.5 Cómo comprobar que la configuración se aplicó

Para diagnosticar el caso de «no da error, pero no está surtiendo efecto», conviene tener preparadas tres formas de comprobación.

(a) Habilitar y revisar el registro de eventos. Este es el canal que indica oficialmente la documentación.⁷ Ahí aparecen los errores de validación del XML de configuración y los fallos en tiempo de ejecución.

Visor de eventos
  > Registros de aplicaciones y servicios
    > Microsoft
      > Windows
        > AssignedAccess
          > Operational

Puede estar deshabilitado de forma predeterminada, así que seleccione el canal, pulse «Habilitar registro» en el panel derecho y luego reproduzca el problema.

(b) Comprobar en el Registro la configuración escrita. La configuración de Assigned Access queda registrada en las siguientes claves.⁷

(c) Leer de vuelta desde el CSP. Justo después de inyectar la configuración, si la vuelve a leer desde el mismo PowerShell con privilegios SYSTEM, puede comprobar en el acto si el valor quedó registrado.

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration

# Si se devuelve codificado y es difícil de leer, decodifíquelo para inspeccionarlo visualmente
[System.Net.WebUtility]::HtmlDecode($obj.Configuration)

Si esto sale vacío, la aplicación en sí falló; si tiene contenido pero no funciona, sospeche del contenido del XML (la ruta de la app, un desajuste de GUID entre el perfil y el Config, los requisitos de edición). Si el paso 3 da error, vuelva primero a la comprobación de SYSTEM del paso 2.

5. Convertir una app Win32 en shell con Shell Launcher

Si puede usar una edición de la familia Enterprise, Shell Launcher es la opción más sólida para equipos como los paneles de operación de maquinaria, donde «la mera presencia de Explorer estorba». Shell Launcher v2 (Windows 10 1809 en adelante) hace que CustomShellHost.exe, en lugar de Explorer.exe, inicie y supervise la aplicación de negocio, y permite convertir en shell tanto apps Win32 como UWP.³

La configuración se hace con un XML dedicado, y su característica más destacada es que permite declarar la acción de recuperación al cerrarse la app, según el código de salida.⁴

<ShellLauncherConfiguration
    xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration"
    xmlns:V2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
  <Profiles>
    <DefaultProfile>
      <!-- Los usuarios sin perfil asignado (por ejemplo, el personal de mantenimiento) obtienen el Explorer normal -->
      <Shell Shell="%SystemRoot%\explorer.exe" />
    </DefaultProfile>
    <Profile Id="{GUID que usted asigne}">
      <Shell Shell="%ProgramFiles%\Contoso\KensaPanel.exe" V2:AppType="Desktop"
             V2:AllAppsFullScreen="true">
        <ReturnCodeActions>
          <ReturnCodeAction ReturnCode="0"  Action="RestartShell"/>   <!-- Cierre normal -> reiniciar el shell -->
          <ReturnCodeAction ReturnCode="10" Action="RestartDevice"/>  <!-- Solicitar reinicio del equipo -->
        </ReturnCodeActions>
        <DefaultAction Action="RestartShell"/>
      </Shell>
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount/>  <!-- Crea y gestiona automáticamente el usuario estándar local "Kiosk" e inicia sesión automáticamente -->
      <Profile Id="{GUID que usted asigne}"/>
    </Config>
  </Configs>
</ShellLauncherConfiguration>

El GUID de Profile Id no es algo que se solicite ni que emita ninguna entidad. Es un valor que usted mismo asigna, de modo que sea único dentro del XML, y se puede generar con New-Guid de PowerShell.⁴

# Generar uno con llaves. Pegue esta cadena en el XML
"{$((New-Guid).Guid.ToUpper())}"

Escriba el valor generado, con la misma forma (llaves incluidas), tanto en la parte de Profiles como en la de Configs. El motivo por el que el ejemplo anterior no funciona si se copia tal cual es que hace falta hacer esta sustitución. El Profile Id / DefaultProfile Id que aparecen en el XML de configuración de Assigned Access del capítulo 4 son valores de la misma naturaleza.

Las acciones son de cuatro tipos: RestartShell / RestartDevice / ShutdownDevice / DoNothing. Si el código de salida no está en el mapeo y tampoco hay un DefaultAction definido, «no ocurre nada», es decir, el equipo se queda con la pantalla en negro. Defina siempre un DefaultAction.⁴ Para aplicarlo, en un MDM se envía a ./Vendor/MSFT/AssignedAccess/ShellLauncher; en local, se establece el XML en la propiedad ShellLauncher de MDM_AssignedAccess mediante el mismo puente WMI que usa Assigned Access.⁶ Según el entorno, puede ser necesario habilitar de antemano, desde «Activar o desactivar las características de Windows», la característica Shell Launcher (Client-EmbeddedShellLauncher) que está bajo el bloqueo de dispositivos.

A continuación, tres trampas propias de Shell Launcher.³

• No se puede convertir en shell una app que lanza otro proceso y termina ella misma. Shell Launcher supervisa el cierre del proceso indicado, así que si se indica un EXE de tipo lanzador (en el ejemplo de la documentación oficial, write.exe), se considera «cerrado» de inmediato.
• El shell se ejecuta con los permisos del usuario que inició sesión. Si asigna el shell a una cuenta de administrador, se podrá hacer cualquier cosa con esos permisos, y si la propia app del shell solicita elevación de administrador, no podrá iniciarse a menos que se deshabilite UAC. Antes de llegar a ese punto, la app debería diseñarse para no requerir elevación.
• Shell Launcher no impide iniciar otras aplicaciones. Solo reemplaza el shell, así que queda abierta la vía de iniciar un EXE, por ejemplo, a través de un cuadro de diálogo de archivos dentro de la aplicación de negocio. En equipos donde no se puede confiar en quien los va a usar, combine AppLocker o Keyboard Filter.

6. Diseño operativo ── Inicio de sesión automático, recuperación, actualizaciones y vía de mantenimiento

Elegir el método y configurarlo no es el final. El diseño para que el equipo siga funcionando sin supervisión es el verdadero núcleo del kiosco.

Para el inicio de sesión automático, la primera opción debe ser AutoLogonAccount del XML de configuración. Como Windows crea y gestiona un usuario estándar local dedicado, no hace falta guardar la contraseña.²⁴ También se puede usar el método tradicional del Registro de Winlogon (AutoAdminLogon/DefaultUserName/DefaultPassword), pero deja la contraseña en texto plano. Además, el inicio de sesión automático no funciona en equipos con restricciones de contraseña de Exchange ActiveSync (EAS) aplicadas, así que compruebe que no entra en conflicto con las directivas del MDM.⁷

Cuando la aplicación se cae, deje la recuperación de primer nivel en manos del sistema operativo. El kiosco de Assigned Access se reinicia automáticamente cuando la app se cierra.¹ En Shell Launcher, la acción de recuperación se configura con DefaultAction/ReturnCodeActions.⁴ Además, para el caso de «se sigue cayendo con la misma excepción aunque se reinicie», programar una tarea de reinicio periódico nocturno mejora la capacidad de recuperación (para cómo montar la tarea, vea «Diseño operativo seguro del Programador de tareas»).

En cuanto a Windows Update, no se trata de detenerlo, sino de controlar el horario. La configuración recomendada oficialmente es ajustar las horas activas al horario laboral, usar descarga automática + instalación programada nocturna, y desactivar las notificaciones, incluida la advertencia de reinicio.⁷ Compruebe en el equipo real que, tras el reinicio, la cadena «inicio de sesión automático → recuperación del kiosco» se completa de forma automática. De igual modo, en la configuración de energía, ponga en 0 (deshabilitado) los tiempos de espera de suspensión y apagado de pantalla, y deshabilite el botón de encendido.⁷ Los equipos reutilizados de portátil y las máquinas con Modern Standby tienen un comportamiento especialmente peculiar, así que consulte también «Suspensión, hibernación, Modern Standby y aplicaciones de ejecución prolongada».

Los agujeros de teclado y táctil varían según el método. En el kiosco multiaplicación (experiencia de usuario restringida), Alt+F4, Alt+Tab y Ctrl+Alt+Supr no están bloqueados de forma predeterminada.⁷ Keyboard Filter es lo que cierra estos agujeros: puede bloquear combinaciones de teclas tanto del teclado físico como del teclado en pantalla (se habilita con Dism /online /Enable-Feature /FeatureName:Client-KeyboardFilter, limitado a las familias Enterprise).⁸ En equipos tipo tableta, configure en deshabilitado (0) la directiva LockDown/AllowEdgeSwipe para que deslizar desde el borde de la pantalla no muestre la UI del sistema.

Asegurar una vía de mantenimiento es tan importante como cerrar los agujeros. La salida del kiosco de Assigned Access es, de forma predeterminada, Ctrl+Alt+Supr (se puede cambiar con BreakoutSequence en Windows 11), y desde ahí se inicia sesión con la cuenta de administrador.² Si Keyboard Filter bloquea Ctrl+Alt+Supr, la tecla de escape propia de Keyboard Filter (de forma predeterminada, pulsar cinco veces la tecla Windows izquierda) se convierte en la última vía hacia la pantalla de bienvenida.⁸ Además, Keyboard Filter está deshabilitado en modo seguro y se puede excluir de las cuentas de administrador.⁸ La experiencia de kiosco es exclusiva de la consola, pero el mantenimiento por RDP con una cuenta de administrador se puede usar en paralelo, así que dejar también esa vía remota reduce los desplazamientos al sitio. En caso de problemas, el canal «AssignedAccess > Operational» del registro de eventos es la primera fuente de información sobre errores de configuración.⁷

7. Diseño de la aplicación de negocio y prácticas habituales (tabla de decisión)

Por mucho que se blinde el sistema operativo, si la aplicación sigue siendo «una aplicación de escritorio normal», queda un agujero. A continuación, los requisitos de diseño de una app pensada para el kiosco.

• Mantener por sí misma la pantalla completa sin bordes. Existe V2:AllAppsFullScreen de Shell Launcher, pero, en general, la propia app debe diseñarse para mantenerse maximizada, en primer plano y sin barra de título, y para volver al frente cuando pierde el foco.
• No mostrar un botón de cierre. En lugar de dejar un medio de cierre en pantalla, se muestra el menú de mantenimiento mediante una operación oculta que solo conoce el personal de mantenimiento (por ejemplo, tocar las cuatro esquinas de la pantalla en orden + contraseña). Si además separa los códigos de salida, con ReturnCodeActions de Shell Launcher se pueden coordinar acciones como «salida desde el menú de mantenimiento → no hacer nada, para volver a Explorer» o «salida tras una actualización → reiniciar el equipo».⁴
• Autorrecuperarse ante excepciones. El peor escenario es tragarse una excepción no controlada y dejar la pantalla congelada e inoperable. Registre el evento en el log, cierre el propio proceso cuanto antes y deje que lo recoja el mecanismo de reinicio del sistema operativo (el reinicio automático del kiosco, el RestartShell de Shell Launcher).
• Evitar la ejecución múltiple. Cuando el mecanismo de reinicio automático se solapa con la propia lógica de reinicio de la app, es fácil que se produzca un inicio duplicado. Incorpore una protección contra ejecución múltiple basada en Mutex (vea «Evitar la ejecución múltiple de una aplicación de Windows»).
• No solicitar elevación. Como regla general, la cuenta de kiosco debe ser un usuario estándar, y en Shell Launcher un shell que requiera elevación obliga a deshabilitar UAC.³ Separe de antemano el procesamiento que requiere permisos de administrador (vea «Cómo aislar en la práctica «solo el procesamiento que requiere permisos de administrador» en una app de Windows»).

Por último, la tabla de decisión.

8. Resumen

• «Inicio de sesión automático + arranque desde el inicio» no es un kiosco. Mientras Explorer siga activo no se protege nada, así que use Assigned Access o Shell Launcher.
• Assigned Access se puede usar desde Pro en adelante, y permite configurar tanto el kiosco de una sola app (UWP/Edge, y en Windows 11 también Win32) como la experiencia de usuario restringida multiaplicación.
• Shell Launcher es un mecanismo, limitado a las familias Enterprise / Education / IoT Enterprise, que reemplaza Explorer.exe por la aplicación de negocio, y permite declarar la acción de recuperación (RestartShell, etc.) según el código de salida.
• La configuración está unificada en el CSP AssignedAccess, y aunque no haya MDM, se puede aplicar el mismo XML mediante el puente WMI + PowerShell (con privilegios SYSTEM).
• El eje del diseño operativo es el inicio de sesión automático mediante AutoLogonAccount, la recuperación con el mecanismo de reinicio del sistema operativo más un reinicio periódico, el control horario de Windows Update, y asegurar las vías de escape: BreakoutSequence, la tecla de escape y el mantenimiento remoto.
• El último bastión es el diseño de la aplicación de negocio. Solo cuando se cumplen el mantenimiento de la pantalla completa, la ausencia de botón de cierre, la autorrecuperación ante excepciones, la prevención de ejecución múltiple y la no necesidad de elevación, se completa realmente «un PC que solo ejecuta una aplicación».

Artículos relacionados

• Cómo elegir Windows para un PC industrial ── Guía práctica de IoT Enterprise LTSC
• Evitar la ejecución múltiple de una aplicación de Windows
• Cómo entender la separación de sesiones en Windows
• Suspensión, hibernación, Modern Standby y aplicaciones de ejecución prolongada
• Diseño operativo seguro del Programador de tareas
• Cómo aislar en la práctica «solo el procesamiento que requiere permisos de administrador» en una app de Windows

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa de la elección del método y la configuración de equipos de kiosco —terminales de recepción, terminales de operación de fábrica, paneles de control de equipos de inspección—, del diseño y desarrollo de aplicaciones de negocio capaces de resistir el kiosco (UI a pantalla completa, autorrecuperación, separación de permisos) y de «volver a blindar» equipos ya existentes.

• Desarrollo de aplicaciones para Windows
• Integración con equipos y desarrollo de aplicaciones de tiempo real flexible
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Se puede usar Assigned Access también en Windows Pro?

Sí. Assigned Access (el kiosco de una sola app y la experiencia de usuario restringida multiaplicación) es compatible con Pro / Enterprise / Education / IoT Enterprise (incluidas sus respectivas LTSC). En cambio, Shell Launcher, que reemplaza el propio Explorer.exe por la aplicación de negocio, solo está disponible en las familias Enterprise / Education / IoT Enterprise, y no se puede usar en Pro. Además, la experiencia de kiosco requiere que UAC esté habilitado y que el inicio de sesión se haga desde la consola; no se admite la experiencia de kiosco a través de una conexión de Escritorio remoto.

¿Es imprescindible Shell Launcher para convertir en kiosco una app Win32 (de escritorio)?

En Windows 11 ya no es imprescindible. Assigned Access en Windows 11 (esquema 21H2 en adelante) permite indicar la ruta del ejecutable de una app de escritorio en el atributo v4:ClassicAppPath del elemento KioskModeApp, de modo que también se puede configurar un kiosco de una sola app Win32 en un equipo Pro. El kiosco de Assigned Access en Windows 10 se limita a apps UWP y Microsoft Edge, así que si solo va a ejecutar una app Win32, la solución práctica es Shell Launcher (limitado a la familia Enterprise) o una configuración multiaplicación con AutoLaunch. Compruebe primero la correspondencia entre la edición y el método antes de diseñar la solución.

Si la aplicación de kiosco termina de forma anómala, ¿se recupera automáticamente?

El comportamiento depende del método. El kiosco de una sola app de Assigned Access está diseñado para reiniciarse automáticamente cuando la app se cierra. En Shell Launcher, el comportamiento al cerrarse la app convertida en shell se puede configurar de forma declarativa con DefaultAction y ReturnCodeActions, eligiendo entre RestartShell (reiniciar el shell), RestartDevice (reiniciar el equipo), ShutdownDevice y DoNothing. Si no hay una acción definida para el código de salida y tampoco hay DefaultAction, no ocurre nada y el equipo se queda con la pantalla en negro, así que defina siempre DefaultAction. La propia aplicación también necesita un diseño que, ante una excepción no controlada, se cierre por sí misma y así active el mecanismo de recuperación.

¿Cómo debe iniciar sesión el personal de mantenimiento como administrador?

En la experiencia de kiosco de Assigned Access, de forma predeterminada se puede salir a la pantalla de inicio de sesión con Ctrl+Alt+Supr, y en Windows 11 esta combinación se puede cambiar con el elemento BreakoutSequence. En una configuración donde Keyboard Filter bloquea también Ctrl+Alt+Supr, se puede conservar el camino de vuelta a la pantalla de bienvenida mediante la tecla de escape propia de Keyboard Filter (de forma predeterminada, pulsar cinco veces la tecla Windows izquierda). La experiencia de kiosco en sí es exclusiva de la consola, pero el mantenimiento por Escritorio remoto con una cuenta de administrador se puede usar en paralelo, como una sesión distinta. Es importante no cerrar todas las vías de escape y acabar con un equipo que solo se pueda recuperar desde el sitio.

¿Es seguro escribir la contraseña del inicio de sesión automático en el Registro?

No se recomienda. En el método AutoAdminLogon de Winlogon, DefaultPassword queda en el Registro en texto plano. Los XML de configuración de Assigned Access y de Shell Launcher tienen el elemento AutoLogonAccount, con el que Windows crea y gestiona por sí mismo un usuario estándar local dedicado e inicia sesión automáticamente, de modo que no hace falta guardar la contraseña usted mismo. Como principio, la cuenta de kiosco debe ser un usuario estándar local con el mínimo de permisos, evitando reutilizar una cuenta de dominio. Tenga en cuenta además que el inicio de sesión automático no funciona en equipos donde está en vigor una directiva de restricción de contraseña de Exchange ActiveSync.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.