Instalar o Windows 11 sem conta Microsoft mudou de figura em 2026: o atalho que os guias davam como garantido — o script oobe\bypassnro.cmd, lançado de uma consola no meio do OOBE — saiu das builds de instalação em março de 2025 e a Microsoft reforçou a política em outubro, removendo os mecanismos conhecidos de criação de conta local na experiência de configuração inicial. As ISOs recentes trazem essa política: o OOBE pressupõe ligação à rede e uma conta Microsoft, e quem chega ao ecrã de rede à procura do «continuar sem internet» já não o encontra.

Continuam a existir caminhos para um Windows 11 com conta local — são três: um autounattend.xml que cria a conta e esconde os ecrãs de sessão no pass oobeSystem, um pacote de provisioning do Windows Configuration Designer aplicado durante o OOBE, e o Windows Autopilot para dispositivos da organização.

💡 TL;DR

O bypassnro.cmd saiu da build 26200.5516 (março de 2025) e os atalhos conhecidos de conta local saíram da 26200/26220 (outubro de 2025) — o OOBE termina hoje com internet e conta Microsoft. Ficam documentados: LocalAccounts + HideOnlineAccountScreens no unattend, HideOobe num pacote .ppkg aplicado no OOBE, e Windows Autopilot nas máquinas da organização.

1. O OOBE em 2026 — o ecrã de rede sem saída

A primeira remoção: a build 26200.5516 (Dev Channel, 28 de março de 2025) retira o bypassnro.cmd. A justificação oficial é a segurança — e o efeito prático: todos saem da configuração inicial com internet e uma conta Microsoft. O ficheiro oobe\bypassnro.cmd deixa de existir nessa build e nas seguintes — o anúncio oficial dá a decisão em duas linhas, e é quanto basta.

A segunda remoção: a build 26220.6772 (6 de outubro de 2025) fecha os substitutos — remove os mecanismos conhecidos de criação de conta local no OOBE. Os atalhos que saltavam ecrãs deixavam o dispositivo mal configurado no fim da configuração. O destino oficial: o OOBE termina com internet e conta Microsoft. Guias antigos ainda mandam correr o oobe\bypassnro.cmd no ecrã de rede — nas builds actuais o script já não existe e o truque morre aí.

ℹ O que está confirmado: as duas remoções — o script e os restantes atalhos de conta local no OOBE. As páginas oficiais não dizem mais nada sobre este ecrã: nem comportamento por edição, nem atalhos novos. Os únicos caminhos são os três do artigo (autounattend.xml, pacote de provisioning, Autopilot). Tudo o resto é hipótese.

O resto deste artigo segue os três caminhos passo a passo — e as secções finais juntam os erros que mais vezes custam tempo. O que se nota na prática nos ecrãs das builds actuais é observação editorial: muda quando a build mudar.

2. Os três caminhos confirmados

Caminho O que está confirmado Pré-requisito
autounattend.xml LocalAccounts cria a conta na instalação e HideOnlineAccountScreens esconde o ecrã de sessão no pass oobeSystem USB de instalação com o XML na raiz
Pacote de provisioning (.ppkg) HideOobe esconde o fluxo interactivo do OOBE — com a conta definida no próprio pacote — e o pacote aplica-se durante o OOBE a partir do USB Windows Configuration Designer
Windows Autopilot Dispositivo registado com o hash de hardware e o tenant = dispositivo corporate owned, a correr com as identidades da organização Tenant Microsoft Entra ID + Intune

3. Caminho 1 — autounattend.xml com conta local

O ficheiro com o nome exacto autounattend.xml na raiz do USB é detectado automaticamente pelo Windows Setup quando nenhum outro ficheiro de resposta é indicado (Windows Setup Automation Overview). O guia irmão Windows 11: Implementação Automatizada com Unattend e OSDCloud cobre o pass windowsPE — disco, imagem e product key — até ao specialize. Aqui fica a peça que decide a conta: o pass oobeSystem.

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
  <settings pass="windowsPE">
    <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <UserData>
        <AcceptEula>true</AcceptEula>
        <ProductKey><Key>W269N-WFGWX-YVC9B-4J6C9-T83GX</Key></ProductKey>
      </UserData>
    </component>
  </settings>
  <settings pass="oobeSystem">
    <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <InputLocale>0816:00000816</InputLocale>
      <SystemLocale>pt-PT</SystemLocale>
      <UILanguage>pt-PT</UILanguage>
      <UserLocale>pt-PT</UserLocale>
    </component>
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <OOBE>
        <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
        <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
        <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
        <ProtectYourPC>3</ProtectYourPC>
      </OOBE>
      <UserAccounts>
        <LocalAccounts>
          <LocalAccount wcm:action="add">
            <Name>AdminLocal</Name>
            <DisplayName>AdminLocal</DisplayName>
            <Description>Conta de administrador local</Description>
            <Group>Administrators</Group>
            <Password>
              <Value>AlterarEstaPassword</Value>
              <PlainText>true</PlainText>
            </Password>
          </LocalAccount>
        </LocalAccounts>
      </UserAccounts>
    </component>
  </settings>
</unattend>

A chave do bloco é a genérica KMS do Windows 11 Pro — a GVLK publicada pela Microsoft na página KMS client activation and product keys. Não activa nada sozinha: só contra um servidor KMS próprio. O valor a colocar depende da máquina — re-instalação em máquina com licença digital: corta o bloco ProductKey inteiro, a licença vem do hardware — licença própria da compra: mete a tua no lugar — máquinas do domínio com KMS: mantém esta.

As duas secções decidem o resultado. O componente Microsoft-Windows-International-Core leva a língua da interface e os locales (o InputLocale fixa o teclado, o UILanguage a língua do sistema, o UserLocale os formatos de datas, horas e moeda). No componente Microsoft-Windows-Shell-Setup, a página-mãe do OOBE lista as chaves que o pass oobeSystem aceita:

Chave Efeito real
HideOnlineAccountScreens Com true, esconde a página de sessão do OOBE — a página pede ligação à internet para aparecer, e a definição existe sobretudo para organizações que não querem o email como nome de utilizador
HideOEMRegistrationScreen Esconde a página de registo OEM
HideWirelessSetupInOOBE Esconde a página de rede sem fios
ProtectYourPC 3 desliga as configurações Express (1 e 2 ligam) — sem valor, a página «Get going fast» abre durante a instalação
HideEULAPage Esconde a página de termos de licença — a definição reserva-se a OEMs e System Builders em testes antes do envio — em instalações de cliente, os termos resolvem-se no windowsPE com AcceptEula

A conta entra pelo LocalAccount, na hierarquia Shell-Setup | UserAccounts | LocalAccounts: O LocalAccount, na hierarquia Shell-Setup | UserAccounts | LocalAccounts, especifica os detalhes de uma conta local a criar durante a instalação e aceita Name, DisplayName, Description, Group e Password (com Value e PlainText). O exemplo oficial do LocalAccounts codifica a password com PlainText=false — com true o valor fica legível no ficheiro.

⚠ Atenção à password: o Setup copia o autounattend.xml para %WINDIR%\Panther. Com PlainText=true a password fica legível no ficheiro — troca-a no primeiro arranque (ou usa o formato codificado do exemplo oficial) e não entregues a máquina sem limpar o ficheiro.

ℹ Erro clássico: HideLocalAccountScreen também aparece na página-mãe do OOBE — mas a definição aplica-se apenas às edições Windows Server. Nos clientes Windows 11, a conta local vem do LocalAccounts, não desta chave.

4. Caminho 2 — pacote de provisioning no OOBE

O Windows Configuration Designer cria um pacote de provisioning (.ppkg) com as definições construídas sobre configuration service providers. O fluxo — criação de um pacote avançado — corre assim: projeto por Advanced provisioning → destino All Windows desktop editions → configuração no painel Available customizations → Export > Provisioning Package → na janela Describe the provisioning package definem-se Name, Version, Owner (IT Admin) e Rank → Build. Encriptar e assinar o pacote fica opcional — as duas opções reservam-se a pacotes com dados sensíveis.

No painel de customizações, as definições de OOBE ficam na referência do WCD: Desktop > HideOobe com valor True esconde o fluxo interactivo do OOBE — e fica a condição da própria definição: sem a conta criada no próprio pacote, o dispositivo fica inutilizável. A conta entra nas customizações do pacote (secção de contas), juntamente com as definições de idioma e rede que a organização quiser fixar.

A aplicação durante o OOBE segue a página Apply a provisioning package:

  1. Confirma que o dispositivo está no ecrã inicial da configuração — se passou, manda-se repor o dispositivo e começar de novo.
  2. Introduz o USB com o .ppkg.
  3. Se nada acontecer, carrega cinco vezes na tecla Windows.
  4. Com mais de um pacote no USB, o setup pergunta como aplicar o provisioning ao dispositivo — Install provisioning package e Next.
  5. Selecciona o pacote e confirma com Yes.
  6. Quando surge «You can remove your removable media now!», o USB pode sair e o provisioning continua.

⚠ O efeito combinado dos passos nas builds actuais — a exigência de rede e de conta Microsoft — não vem confirmado por página nenhuma: é observação prática. Valida o pacote no hardware-alvo com a build da tua ISO antes de o usar em produção.

5. Caminho 3 — Autopilot e Intune na organização

Para parques geridos, o caminho a sério nas ISOs recentes chama-se Windows Autopilot: o dispositivo não luta contra o OOBE — passa por ele com o perfil da organização e a sessão corre em identidades do Microsoft Entra ID. A página de registo do Autopilot fixa os dois processos obrigatórios: o hardware hash do dispositivo capturado e carregado no serviço Autopilot, e a associação do dispositivo ao tenant ID. O ideal é que o OEM, o revendedor ou o distribuidor faça o registo na compra — em alternativa, a organização recolhe o hash de dispositivos novos ou existentes e carrega-o manualmente no Intune.

Os dispositivos registados aparecem no Microsoft Intune admin center em Devices > Enrollment > Windows > Windows Autopilot > Devices, e o registo cria automaticamente o objecto no Microsoft Entra ID — o dispositivo entra como corporate owned: a Microsoft lista-o como dispositivo da empresa, identidade dada pelo tenant e não pela conta pessoal. Sem perfil atribuído, o dispositivo recebe o perfil por omissão do Autopilot.

O custo está na infra-estrutura: tenant, licenciamento e políticas do Intune atrás. A contrapartida é o que nenhum truque dá: as máquinas chegam do fornecedor já associadas à organização, os utilizadores entram com as contas da empresa e as políticas aplicam-se no primeiro arranque. O percurso zero-touch completo — perfis, Enrollment Status Page e a integração com o Intune — vive no guia Dia 26: Windows Autopilot — Implementação Zero-Touch com Intune.

Erros comuns

  • Correr oobe\bypassnro.cmd a partir do Shift+F10 numa ISO nova — o script saiu das builds com a remoção anunciada em março de 2025 — os guias que o mandam correr descrevem uma instalação que já não existe.
  • Recorrer a valores de registo (o BypassNRO do HKLM\...\OOBE) ou a comandos ocultos do OOBE — nenhuma página oficial os descreve, e o anúncio de outubro de 2025 descreve a remoção dos mecanismos conhecidos de criar conta local no OOBE. Um truque fora das páginas citadas é hipótese, não caminho.
  • Contar com SkipMachineOOBE ou SkipUserOOBE — as chaves já não constam na tabela de elementos filhos da página do OOBE — o conjunto actual é o das secções anteriores.
  • Usar HideLocalAccountScreen no cliente — a página marca a chave para as edições Windows Server.
  • Esperar o efeito do HideOnlineAccountScreens sem unattend — a chave corre no pass oobeSystem de um ficheiro de resposta — sem ele, o OOBE corre interactivo e pede internet e conta.

Checklist final

  • ISO do Windows 11 recente criada a partir do guia de download e ISO — o comportamento do OOBE segue a build que instalas, não a do guia que lês
  • autounattend.xml na raiz do USB com o pass oobeSystem, HideOnlineAccountScreens a true e ProtectYourPC a 3
  • LocalAccount com Group Administrators — password trocada no primeiro arranque se ficou em texto simples
  • .ppkg com HideOobe e a conta definida no pacote — aplicado no ecrã inicial do OOBE (tecla Windows cinco vezes)
  • Parque gerido: hardware hash carregado, tenant ID associado e perfil Autopilot atribuído no Intune admin center
  • Nenhum passo do guia depende de truque não-documentado — se um caminho não estiver nas páginas oficiais, não entra na imagem de instalação

Fontes Oficiais

Artigos Relacionados