Como configurar um totem kiosk Windows

Por Christian Thompson

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, pode ter esbarrado 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.

A documentação oficial da Microsoft cobre bem o assistente gráfico de configuração de kiosk, mas não cobre esses três sintomas específicos. Este artigo documenta, passo a passo, a configuração de um totem kiosk Windows que funcionou de ponta a ponta num caso 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 duas ferramentas gratuitas: o PowerShell, que já vem com o Windows, e o PsExec, que precisa ser baixado à parte (sem custo, direto da própria Microsoft).

Por que configurar um totem kiosk Windows é mais complicado do que parece

O Windows tem, oficialmente, suporte nativo a modo kiosk desde a versão 10, através do recurso Assigned Access. Na teoria, é só abrir Configurações, escolher uma conta, escolher o Microsoft Edge, colar a URL e pronto.

No caso documentado aqui, esse caminho pela interface gráfica não funcionou — a máquina já tinha passado por uma clonagem de imagem antes da instalação do totem, e o assistente gráfico falhou sem indicar o motivo. Quando isso acontece, a saída mais 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 — uma das formas oficialmente documentadas pela Microsoft para configurar o kiosk, ao lado de Intune e pacotes de provisionamento.

Parece assustador, mas o procedimento inteiro cabe em menos de dez comandos — o problema não é a complexidade do comando em si, e sim os detalhes que a documentação oficial não cobre.

O que você precisa antes de começar

• Windows 10 Pro instalado (a edição Pro é obrigatória — o Home não tem suporte a Assigned Access, em nenhum grau)
• 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 (a Microsoft não dá suporte ao kiosk por conexão remota, e o teclado touch não é acionado em VM — por RDP esse teste não é confiável)

Nota de atualidade (2026): este caso foi executado em Windows 10 Pro. O suporte padrão ao Windows 10 terminou em 14 de outubro de 2025. O Assigned Access continua disponível nas edições atualmente suportadas do Windows — Pro, Enterprise, Education e IoT Enterprise, incluindo Windows 11 — configurado da mesma forma via PowerShell e WMI Bridge Provider. O XML deste script usa apenas os namespaces base e rs5 do schema do Assigned Access, válidos desde o Windows 10 e sem alteração em Windows 11. Recursos mais recentes (como StartPins ou taskbar personalizada) usam namespaces adicionais específicos de versões mais novas — se for além do que está neste script, confira o schema correspondente à sua versão.

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

Aqui está um detalhe decisivo: a classe MDM_AssignedAccess só aceita comandos executados no contexto SYSTEM — é assim que a própria Microsoft documenta o uso do WMI Bridge Provider via PowerShell. 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 funcionou)

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 foi o que causou problema neste caso: bloqueou processos auxiliares do próprio navegador — inclusive o processo do teclado touch — sem indicar isso em nenhum log verificado. O formato multi-app, usado no script abaixo, é mais verboso, mas 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 confirma que o teclado touch sobe automaticamente ao tocar em um campo de texto, desde que não haja teclado físico conectado. O problema, neste caso, foi que o formato single-app bloqueou o processo do teclado touch (TabTip.exe) junto com a sessão de kiosk, sem gerar nenhum log de erro visível.

A solução não é mexer em nenhuma chave de registro — é 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 esse sintoma aparecer em uma versão atual do Windows, vale checar primeiro se o equipamento está atualizado. A Microsoft documenta um problema conhecido em que essa mesma mensagem pode aparecer durante o login de kiosks que têm o Microsoft Edge entre os aplicativos permitidos, corrigido nos builds 26100.7705, 26200.7705 e posteriores — a orientação oficial inclui reaplicar a configuração do kiosk após a atualização. No caso Thompsontech documentado neste artigo, executado em Windows 10 Pro, a investigação dos logs identificou executáveis bloqueados pelo AppLocker — é esse cenário que os passos abaixo mostram como investigar.

Para descobrir qual processo está sendo bloqueado, habilite os logs de diagnóstico do AppLocker (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. Para executáveis desktop como os deste script, o evento a procurar é o 8004, no log “EXE e DLL” (o evento 8022 é para apps empacotados/UWP — não é o caso aqui). Ele mostra o caminho completo do executável que foi bloqueado.

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 parâmetro: segundo a documentação da Microsoft, ele fecha o Edge após o tempo de inatividade configurado, mas não o reabre sozinho — quem deveria reabrir é o próprio Assigned Access, e nem sempre isso acontece de forma confiável. 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 — Login automático sem conflito

O AutoLogonAccount do XML já cria a conta de login automático sozinho — tecnicamente é a conta interna kioskUser0, exibida na tela de login com o nome definido em rs5:DisplayName. Não crie uma conta local manual com esse mesmo nome antes de aplicar a configuração: deixe o Windows criar a conta a partir do XML, exatamente como está no script do Passo 2.

Passo 7 — Como reverter a configuração, se algo sair errado

Antes de aplicar em produção, vale saber como desfazer. A remoção usa a mesma classe WMI, só que zerando a configuração:

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

Rode isso na mesma sessão SYSTEM do Passo 1 e reinicie a máquina. A Microsoft documenta uma ressalva importante: remover a configuração desfaz as políticas de restrição, mas não reverte tudo — em cenário multi-app, a personalização do menu Iniciar aplicada pelo kiosk permanece na conta. Se essa personalização residual for relevante no seu ambiente, trate a restauração do perfil separadamente.

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
• O procedimento de reversão foi documentado e validado antes da entrada em produção

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 num computador básico, com recursos limitados, sem placa de vídeo dedicada nem processador de última geração. Neste caso, o gargalo não foi hardware — foi 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, neste caso — uma máquina que já tinha passado por clonagem de imagem —, a tela de configuração de kiosk pela interface gráfica simplesmente não funcionou, sem indicar o motivo. A configuração via linha de comando é mais trabalhosa, mas dá controle total e visibilidade de erro.

Se você travou em outro tipo de bloqueio do Windows

O mesmo raciocínio de investigação por log — descobrir exatamente qual processo está sendo bloqueado antes de tentar liberar algo — vale para outros bloqueios silenciosos do Windows. Se o problema não foi num totem e sim numa instalação normal sendo barrada sem explicação, veja também Smart App Control bloqueou seu programa? Veja como resolver.

Precisa de apoio especializado num ambiente empresarial, com vários totens ou terminais para gerenciar? Conheça o suporte gerenciado da Thompsontech.