Como configurar um totem kiosk Windows sem travar

Se você já tentou configurar um totem em Windows para rodar um site em tela cheia, sem teclado, sem mouse, sem acesso a nada além daquela página, provavelmente já esbarrou em pelo menos um destes três problemas: o teclado touch simplesmente não aparece, uma mensagem genérica de “restrição do administrador” surge do nada, ou a sessão trava sozinha e devolve o usuário para a área de trabalho do Windows.

Nenhum desses problemas aparece documentado de forma clara em lugar nenhum. E é exatamente por isso que configurar um totem kiosk Windows continua sendo, na prática, um dos procedimentos mais subestimados do dia a dia de quem presta suporte técnico.

Este artigo documenta, passo a passo, a configuração que funcionou de ponta a ponta em um cenário real: um computador básico, sem grandes recursos, instalado numa academia para funcionar como totem de autoatendimento. Nada de servidor dedicado, nada de licenciamento corporativo — só Windows 10 Pro e as ferramentas que já vêm com ele.

Por que o kiosk mode do Windows é mais complicado do que parece

O Windows tem, oficialmente, suporte nativo a modo kiosk desde a versão 10. Na teoria, é só abrir Configurações, escolher uma conta, escolher o Microsoft Edge, colar a URL e pronto. Na prática, esse caminho pela interface gráfica falha silenciosamente em uma quantidade incômoda de máquinas — principalmente em instalações que já passaram por clonagem de imagem, reinstalação parcial ou qualquer processo fora do instalador oficial da Microsoft.

Quando isso acontece, a única saída confiável é configurar o kiosk diretamente via linha de comando, usando o mecanismo que o Windows usa internamente para isso: a classe MDM_AssignedAccess, acessada através do WMI Bridge Provider.

Parece assustador, mas o procedimento inteiro cabe em menos de dez comandos — o problema nunca foi a complexidade do comando em si, e sim os detalhes que ninguém documenta.

O que você precisa antes de começar

• Windows 10 Pro instalado (a edição Pro é obrigatória — o Home não tem suporte completo a Assigned Access)
• Acesso administrativo à máquina, local ou remoto
• PsExec, parte do pacote PSTools da Sysinternals — baixe direto da Microsoft
• Alguns minutos com acesso físico à tela no final, para os testes de toque (por RDP esse teste não é confiável)

Passo 1 — Preparar o PsExec e abrir uma sessão SYSTEM

Aqui já está o primeiro detalhe que derruba a maioria das tentativas: a classe MDM_AssignedAccess só aceita comandos executados no contexto SYSTEM. Rodar o PowerShell “Como Administrador” não é suficiente — mesmo uma conta administrativa comum recebe erro de permissão.

Baixe o PSTools, extraia numa pasta como C:\PSTools, e abra uma sessão SYSTEM assim:

cd C:\PSTools .\psexec.exe -i -s powershell.exe

Confirme que está no contexto certo:

whoami # resultado esperado: nt authority\system

Se não retornar exatamente isso, pare aqui — nenhum dos próximos comandos vai funcionar.

Passo 2 — O script de configuração do kiosk (a versão que realmente funciona)

Existem dois formatos de configuração de Assigned Access: single-app (trava a sessão inteira só naquele aplicativo) e multi-app (permite listar explicitamente quais processos podem rodar). O formato single-app parece mais simples, mas na prática costuma bloquear processos auxiliares do próprio navegador — inclusive o processo do teclado touch — sem deixar rastro em nenhum log. O formato multi-app é mais verboso, mas é o único que dá visibilidade real do que está sendo bloqueado.

Esse é o script que funcionou, testado em produção:

Add-Type -AssemblyName System.Web $assignedAccessConfigurationXml = @" <?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"> <Profiles> <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}"> <AllAppsList> <AllowedApps> <App DesktopAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge.exe" rs5:AutoLaunch="true" rs5:AutoLaunchArguments="--kiosk https://SEU-SITE-AQUI --edge-kiosk-type=fullscreen --no-first-run" /> <App DesktopAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge_proxy.exe" /> <App DesktopAppPath="C:\Program Files\Common Files\microsoft shared\ink\TabTip.exe" /> <App DesktopAppPath="C:\Windows\system32\backgroundTaskHost.exe" /> <App DesktopAppPath="C:\Program Files (x86)\Microsoft\Edge\Application\SUA-VERSAO-DO-EDGE\identity_helper.exe" /> </AllowedApps> </AllAppsList> <StartLayout> <![CDATA[<LayoutModificationTemplate xmlns:defaultlayout="http://schemas.microsoft.com/Start/2014/FullDefaultLayout" xmlns:start="http://schemas.microsoft.com/Start/2014/StartLayout" Version="1" xmlns="http://schemas.microsoft.com/Start/2014/LayoutModification"></LayoutModificationTemplate>]]> </StartLayout> <Taskbar ShowTaskbar="false"/> </Profile> </Profiles> <Configs> <Config> <AutoLogonAccount rs5:DisplayName="TotemKiosk" /> <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 $obj.Configuration = [System.Web.HttpUtility]::HtmlEncode($assignedAccessConfigurationXml) Set-CimInstance -CimInstance $obj

Troque SEU-SITE-AQUI pela URL que o totem deve exibir, e SUA-VERSAO-DO-EDGE pelo número de versão do Edge instalado na máquina (descubra com (Get-Item "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe").VersionInfo.ProductVersion). Depois, reinicie:

Restart-Computer

Passo 3 — Por que o teclado touch some (e como não sofrer tentando resolver isso)

Essa é a armadilha mais silenciosa de todas. A documentação da Microsoft garante que o teclado touch sobe automaticamente ao tocar em um campo de texto, desde que não haja teclado físico conectado — e isso é verdade. O problema é que, no formato single-app, o processo do teclado touch (TabTip.exe) muitas vezes é bloqueado pela própria sessão de kiosk, sem gerar nenhum log de erro visível.

A solução não é mexer em nenhuma chave de registro (o que parece intuitivo, mas não resolve a causa real) — é simplesmente garantir que o TabTip.exe esteja na lista de aplicativos permitidos, como já está no script do passo 2. Uma vez liberado, o teclado volta a funcionar nativamente, sem nenhuma configuração adicional.

Passo 4 — A mensagem “operação cancelada por restrições” e como caçar a causa

Se essa mensagem aparecer na tela do totem, ela está avisando — de forma pouco clara — que um processo específico está sendo bloqueado pelo AppLocker do Windows. O erro não diz qual processo é. Para descobrir, habilite os logs de diagnóstico (eles vêm desativados por padrão):

1. No Visualizador de Eventos, vá em Exibir → Mostrar Logs Analíticos e de Depuração
2. Navegue até Logs de Aplicativos e Serviços → Microsoft → Windows → AppLocker
3. Habilite o log em “EXE e DLL” e em “Packaged app-Execution”

Reproduza o problema (reinicie o totem) e volte nesses logs, procurando pelo evento 8022. Ele mostra o caminho completo do executável que foi bloqueado. Basta adicionar esse caminho na lista AllowedApps do script e reaplicar a configuração.

No caso documentado aqui, dois processos auxiliares do próprio Edge (identity_helper.exe e backgroundTaskHost.exe) precisaram ser liberados manualmente — e é por isso que o script do passo 2 já vem com eles.

Passo 5 — Evitar que o kiosk “vaze” para a área de trabalho

Em teste real, deixar a página parada por alguns minutos com o parâmetro --kiosk-idle-timeout-minutes ativo no Edge fez a sessão cair para a tela cheia do Menu Iniciar do Windows — com acesso a Loja, Calculadora, e-mail, tudo. Isso é um problema sério de segurança para um totem público.

A causa foi o próprio timeout de inatividade do Edge, que fecha e tenta reabrir o navegador — e nem sempre esse relançamento automático funciona de forma confiável dentro do Assigned Access. A solução foi simples: não usar esse parâmetro. O script do passo 2 já está sem ele, por esse motivo.

Passo 6 — Um detalhe bobo que quebra o login automático

Se você criar manualmente uma conta local chamada, por exemplo, “TotemKiosk”, e depois usar o mesmo nome de exibição no XML (rs5:DisplayName="TotemKiosk"), o Windows cria uma segunda conta interna própria do kiosk — chamada kioskUser0 — só que exibida na tela de login com o mesmo nome da conta que você já tinha criado.

Duas contas com o mesmo nome de exibição confundem o mecanismo de login automático, e a máquina passa a exigir seleção manual de usuário no boot — o que é inaceitável num totem sem teclado. A solução é não criar contas manuais com esse nome: deixe o Windows criar a conta kioskUser0 sozinho a partir do AutoLogonAccount do XML.

Checklist final de validação

• O boot entra direto no kiosk, sem tela de seleção de usuário
• O Edge abre em tela cheia, direto na URL configurada, sem barra de endereço
• A mensagem de restrição não aparece mais
• O teclado touch sobe ao tocar em um campo de texto (testar na tela física, nunca por RDP)
• A tela permanece estável após 15 minutos parada, sem cair para o desktop
• Não há acesso a barra de tarefas, Menu Iniciar ou qualquer outro aplicativo

Perguntas frequentes

Preciso de licença corporativa ou Intune para configurar um kiosk assim?

Não. Todo o procedimento descrito aqui usa apenas o Windows 10 Pro e ferramentas gratuitas da própria Microsoft (PowerShell e PsExec). Intune e MDM corporativo são alternativas válidas para gerenciar muitos totens ao mesmo tempo, mas não são obrigatórios para configurar um totem individual.

O totem precisa de um computador potente?

Não. O procedimento documentado aqui foi validado em um computador básico, com recursos limitados, sem placa de vídeo dedicada nem processador de última geração. O gargalo nunca é hardware — é a configuração correta do Windows e do navegador.

Por que não usar só a interface gráfica de Configurações do Windows para isso?

Porque em boa parte das instalações reais — principalmente máquinas que já passaram por clonagem de imagem ou reinstalação parcial — a tela de configuração de kiosk pela interface gráfica simplesmente não funciona, sem indicar o motivo. A configuração via linha de comando é mais trabalhosa, mas é a única que dá controle total e visibilidade de erro.

Quando vale a pena chamar alguém para resolver

Segundo dados do NIC.br, mais de 60% das pequenas empresas brasileiras já terceirizam algum modelo de estrutura tecnológica — e não é por falta de capacidade técnica: é porque diagnosticar esse tipo de problema exige tempo que a maioria dos times de TI não tem sobrando, especialmente quando o equipamento já está em produção e cada minuto de totem fora do ar é um cliente mal atendido.

Se você seguiu esse passo a passo e ainda assim o totem não travou de vez, ou se prefere simplesmente não perder um dia inteiro de trabalho com isso, fale com a gente.

Quero um diagnóstico gratuito: fale com a gente no WhatsApp.