Perguntas frequentes do Windows Autopilot

Não. Fornecer a ID do locatário é uma entrada única no Partner Center que pode ser reutilizada com uploads futuros de dispositivos.

Depois que o carregamento do arquivo de dispositivo for concluído no Partner Center, o locatário poderá ver os dispositivos disponíveis para a configuração do Windows Autopilot no MSfB. O OEM precisa aconselhar o locatário a acessar o MSfB. A autonotificação do MSfB para o locatário está sendo desenvolvida.

Antes que um OEM ou Parceiro de Canal possa registrar um dispositivo para o Windows Autopilot para um cliente, o cliente deve primeiro dar seu consentimento. O processo de consentimento começa com o OEM ou Parceiro de Canal enviando um link ao cliente que direciona o cliente para uma página de consentimento no MSfB. Para obter mais informações, consulte Registro.

O cliente empresarial deve excluir os dispositivos no MSfB antes que o CSP possa carregá-los e gerenciá-los no Partner Center.

Não. O Windows Autopilot não oferece suporte à remoção da conta de administrador local. No entanto, ele dá suporte à restrição do usuário que executa o ingresso no domínio do Microsoft Entra durante a OOBE (experiência inicial) para uma conta padrão em vez de uma conta de administrador por padrão.

Somente parceiros CSP têm acesso ao portal do Partner Center. Se você for um CSP, poderá criar uma conta de usuário de agente de vendas que tenha acesso a dispositivos para testar o arquivo. Esse teste pode ser feito hoje mesmo no Partner Center.

Para obter mais informações, consulte Criar contas de usuário.

Esse requisito não se aplica a OEMs de volume superior porque eles podem usar a API direta do OEM. Todos os outros que optarem por usar o Microsoft Partner Center (MPC) para registrar dispositivos devem se tornar CSPs para acessar o MPC.

Para fins do Windows Autopilot, há três tipos diferentes de CSPs, cada um com diferentes níveis de autoridade e acesso:

1. CSP direto: obtém autorização direta do cliente para registrar dispositivos
2. Provedor CSP indireto: obtém permissão implícita para registrar dispositivos por meio do relacionamento que seu parceiro revendedor CSP tem com o cliente. Os provedores CSP indiretos registram dispositivos por meio do Microsoft Partner Center.
3. Revendedor CSP indireto: obtém autorização direta do cliente para registrar dispositivos. Ao mesmo tempo, seu parceiro provedor CSP indireto também obtém autorização, o que significa que o provedor indireto ou o revendedor indireto pode registrar dispositivos para o cliente. No entanto, o revendedor CSP indireto deve registrar os dispositivos por meio da interface do usuário do Partner Center carregando manualmente o arquivo CSV. O provedor CSP indireto pode registrar dispositivos usando as APIs do Partner Center.

Não. As regiões de vendas do CSP dependem da localização do locatário do Microsoft Entra. Um parceiro CSP só pode vender ou gerenciar clientes com um locatário localizado na mesma região CSP. A região CSP de um parceiro é baseada na localização do locatário que o parceiro CSP está usando para realizar transações. Se o locatário do cliente tiver sido criado nos EUA, somente um parceiro que tenha um registro de CSP nos EUA poderá estabelecer uma relação de revendedor com esse cliente.

Para o Windows Autopilot & Intune, a localização do usuário ou dispositivo final não importa. Um funcionário localizado na Alemanha pode registrar um dispositivo usando o perfil do Windows Autopilot criado no locatário dos EUA e gerenciá-lo por meio da instância de serviço do Intune nos EUA. O usuário na Alemanha também se autentica na instância do Microsoft Entra baseada nos EUA.

Se um parceiro deseja gerenciar clientes globalmente, ele precisa ter uma presença global. Eles precisam de vários registros de CSP em cada uma das regiões de vendas de CSP onde realizam negócios.

Não é possível criar contas de usuário com acesso a todos os locatários CSP. Esse cenário se traduziria em 18 contas de usuário para um agente de administração CSP que deseja gerenciar todos os clientes ao redor do mundo.

Em resumo, a localização do usuário e dos dispositivos não importa. A localização do locatário do cliente é importante. O registro de dispositivos transfronteiriços não é o problema. O problema são as vendas internacionais via CSP.

Não. O Partner Center não tem acesso aos perfis criados no Intune ou na Microsoft Store para Empresas. Ele só tem acesso aos perfis do Windows Autopilot criados por meio do Partner Center.

Nenhuma alteração é necessária no chão de fábrica para permitir a implantação do Windows Autopilot.

O Windows Autopilot pode funcionar com qualquer versão da ferramenta OA3. Recomendamos usar uma versão com suporte do Windows para gerar o hash de hardware 4K (4K HH).

Sim. Se eles quiserem o Windows Autopilot, é necessário ter uma versão com suporte do Windows. Um cliente também deve receber o arquivo CSV ou ter o upload do arquivo concluído em seu nome.

Não. Os OEMs apenas enviam o Relatório de Compilação do Computador (CBR) como de costume para a Microsoft. Nenhuma imagem é enviada à Microsoft para habilitar o Windows Autopilot. O Windows Autopilot apenas personaliza o OOBE e permite configurações de política.

Os dispositivos devem estar executando uma versão com suporte do canal de disponibilidade geral do Windows para se registrarem na implantação do Windows Autopilot. Caso contrário, geralmente não há problema. Para obter mais informações, consulte Windows Autopilot: problemas conhecidos.

Não.

Nada, a menos que o OEM opte por registrar o dispositivo em nome do cliente. Nesse caso, eles devem carregar o arquivo CSV da ID do dispositivo para o Microsoft Partner Center ou usar a API direta do OEM.

Não.

Não.

Sim. O arquivo CSV só pode conter 500 dispositivos para aplicar a um único perfil. Se mais de 500 dispositivos precisarem ser aplicados a um perfil, os dispositivos precisarão ser carregados por meio de vários arquivos CSV.

Criptografe o arquivo CSV ao enviá-lo ao cliente empresarial para registrar automaticamente seus dispositivos Windows Autopilot por meio do MPC, MSfB ou Intune.

Cada hash de hardware enviado pelo OEM deve conter os seguintes dados:

• SMBIOS UUID: um identificador universalmente exclusivo.
• Endereço MAC: o identificador exclusivo da card de rede.
• Número de série do disco exclusivo: se você usar a ferramenta Windows OEM Activation 3.0.

Como o Windows Autopilot se baseia na capacidade de identificar exclusivamente os dispositivos que se aplicam à configuração de nuvem, é fundamental enviar hashes de hardware que atendam ao requisito descrito.

À medida que partes do dispositivo são adicionadas ou removidas, esses campos são necessários para identificar um dispositivo ao criar o hash de hardware. Como não temos um identificador exclusivo para dispositivos Windows, esses campos são a melhor lógica para identificar um dispositivo.

Nenhuma. São nomes diferentes para a mesma coisa. A saída da ferramenta OA3 é chamada de hash OA3, que tem tamanho de 4K e é usada para o cenário de implantação do Windows Autopilot.

Sim. Se você substituir peças, talvez seja necessário gerar um novo hash de hardware. Depende das peças que foram substituídas e das características das peças.

Por exemplo, se você substituir o TPM ou a placa-mãe, ele será um novo dispositivo e você deverá obter um novo hash de hardware. Se você substituir um card de rede, provavelmente não é um novo dispositivo, e o dispositivo funciona com o hash de hardware antigo.

Em geral, após qualquer alteração de hardware, suponha que o hash de hardware antigo seja inválido e obtenha um novo hash de hardware. Este processo é recomendado sempre que você substitui peças.

A substituição da placa-mãe está fora do escopo do Windows Autopilot. Qualquer dispositivo reparado ou reparado que altere a capacidade de identificar o dispositivo para o Windows Autopilot deve passar pelo processo OOBE normal. Ele deve selecionar manualmente as configurações corretas ou aplicar uma imagem personalizada.

Para reutilizar o mesmo dispositivo para o Windows Autopilot após a substituição da placa-mãe, use o seguinte processo:

1. Cancele o registro do dispositivo no Windows Autopilot.
2. Substitua a placa-mãe.
3. Gere um novo hash de hardware 4K.
4. Registre o dispositivo com o novo hash de hardware 4K ou ID do dispositivo.

Ele deve ser exclusivo, conforme especificado nos requisitos de hardware do Windows.

Ele deve atender a todos os requisitos de hardware do Windows. Para obter mais informações, consulte Especificações e políticas do Programa de Compatibilidade de Hardware do Windows.

Não. No mínimo, os seguintes campos SMBIOS precisam ter valores exclusivos:

• ProductKeyID.
• SmbiosSystemManufacturer.
• SmbiosSystemProductName.
• SmbiosSystemSerialNumber.
• SmbiosSkuNumber.
• SmbiosSystemFamily.
• MacAddress.
• SmbiosUuid.
• DiskSerialNumber.
• TPM.
• EkPub.

O método para obter essas informações varia dependendo do cenário, mas em geral:

• O número de série do disco vem com IOCTL_STORAGE_QUERY_PROPERTYStorageDeviceProperty/PropertyStandardQuery.

• O endereço MAC de rede é de IOCTL_NDIS_QUERY_GLOBAL_STATS .OID_802_3_PERMANENT_ADDRESS

Todos os valores disponíveis são usados, embora possa haver regras de uso específicas. O número de série do disco do sistema é mais importante do que os outros discos disponíveis. Os adaptadores de rede removíveis não devem ser usados se detectados, pois são removíveis. LAN vs WLAN não deve importar, pois ambos são usados.

Um dispositivo recebeu uma configuração do Windows Autopilot, mas ainda não a aplicou quando a página de seleção é ignorada e são imediatamente levados para uma página de entrada.

Os administradores do Microsoft Entra são sempre administradores locais, mesmo que o Windows Autopilot esteja configurado para desabilitar essa configuração.

Para ajudar a solucionar problemas, execute licensingdiag.exe e envie o arquivo (gabinete) para AutopilotHelp@microsoft.com..cab Se possível, colete também um ETL do WPR (Gravador de Desempenho do Windows).

Muitas vezes, nesses casos, os usuários não estão entrando no locatário correto do Microsoft Entra ou estão criando contas de usuário locais.

Para obter uma lista completa das opções de suporte, consulte Suporte ao Windows Autopilot.

Não. Os perfis do Windows Autopilot não são residentes no dispositivo. Eles são baixados durante o OOBE e as configurações são definidas no momento em que são aplicadas. Em seguida, o perfil é descartado no dispositivo. Se o dispositivo for recriado ou redefinido, as novas configurações de perfil entrarão em vigor na próxima vez que o dispositivo passar pelo OOBE.

Se o dispositivo não estiver registrado, ele não receberá a experiência do Windows Autopilot e o usuário final passará pelo OOBE normal. As configurações do Windows Autopilot não serão aplicadas até que o usuário execute o OOBE novamente, após o registro. Se um dispositivo for iniciado antes da criação de um perfil de gerenciamento de dispositivo móvel (MDM), o dispositivo passará pela experiência padrão do OOBE. Em seguida, você precisa registrar manualmente esse dispositivo no MDM. Na próxima vez que o dispositivo for redefinido, ele passará pela experiência do Windows Autopilot OOBE.

Para receber uma experiência de entrada personalizada, configure a identidade visual do locatário no portal do Azure.

Como nenhum perfil do Windows Autopilot está atribuído ao dispositivo, o usuário vê o OOBE padrão.

A melhor maneira de coletar logs para o desempenho do Windows Autopilot é coletar um rastreamento WPR durante o OOBE. O arquivo XML (extensão WPRP) para esse rastreamento pode ser fornecido mediante solicitação.

Não. Qualquer MDM funciona com o Windows Autopilot, mas outros podem não ter o mesmo conjunto completo de recursos do Windows Autopilot que o Intune. A melhor experiência é com o Intune.

Sim. O Intune dá suporte a aplicativos Win32 usando wrappers MSI e MSIX.

O cogerenciamento permite que você gerencie simultaneamente as versões atualmente com suporte do Windows usando o Microsoft Configuration Manager e o Microsoft Intune. Ele permite que você anexe à nuvem seu investimento existente no Gerenciador de Configurações adicionando novas funcionalidades. Ao usar o cogerenciamento, você tem a flexibilidade de usar a solução de tecnologia que funciona melhor para a sua organização.

Quando um dispositivo Windows tem o cliente do Gerenciador de Configurações e é registrado no Intune, você obtém os benefícios de ambos os serviços. Você controla quais cargas de trabalho, se houver, alterna a autoridade do Gerenciador de Configurações para o Intune. O Gerenciador de Configurações continua gerenciando todas as outras cargas de trabalho, incluindo aquelas que você não alterna para o Intune, e todos os outros recursos do Gerenciador de Configurações aos quais o cogerenciamento não oferece suporte.

Para saber mais, confira os seguintes artigos:

• O que é cogestão?.
• Como se inscrever no cogerenciamento ao provisionar com o Windows Autopilot.

Não. Não é obrigatório, mas você pode usar o Gerenciador de Configurações junto com o Windows Autopilot nos seguintes cenários:

• Cogerenciamento.
• Windows Autopilot para dispositivos existentes.

O modo de autoimplantação requer apenas que o usuário ligue o dispositivo. É útil para cenários em que uma conta de usuário padrão não é necessária. Por exemplo, dispositivos compartilhados ou de quiosque.

Para obter mais informações, consulte Modo de autoimplantação do Windows Autopilot.

Os dispositivos híbridos ingressados no Microsoft Entra se conectam a um domínio do Active Directory local e ao Microsoft Entra ID.

Para obter mais informações, consulte Introdução ao gerenciamento de dispositivos no Microsoft Entra ID.

A redefinição do Windows Autopilot remove os aplicativos e as configurações do usuário de um dispositivo, mas mantém o ingresso no domínio do Microsoft Entra e o registro no MDM. Esse recurso é útil quando você transfere um dispositivo de um usuário para outro.

Para obter mais informações, consulte Redefinição do Windows Autopilot.

Você pode adicionar as seguintes personalizações à experiência OOBE:

• Uma mensagem de boas-vindas personalizada.
• Personalize a dica de nome de usuário.
• O logotipo da sua organização.

O Windows Autopilot para dispositivos existentes oferece um caminho de atualização para as versões atualmente com suporte do Windows para um dispositivo Windows existente.

Para obter mais informações, consulte Windows Autopilot para dispositivos existentes.

Os fabricantes atuais habilitados para essa alteração são Dell, Dynabook, HP, Lenovo e Microsoft Surface. Estamos trabalhando para adicionar outros fabricantes e atualizaremos esta lista assim que eles forem integrados. Para obter mais informações, consulte Retorno da funcionalidade principal para entrada e implantação do Windows Autopilot.

Sim. Se o dispositivo ainda estiver registrado para o Windows Autopilot e estiver executando uma versão com suporte do Windows, ele receberá a experiência do Windows Autopilot.

Sim. Se o dispositivo estiver executando uma versão compatível do Windows, você poderá coletar impressões digitais do dispositivo para registro. Não há planos para fazer backport da funcionalidade para versões anteriores. Não há como coletá-los em dispositivos que executam versões sem suporte do Windows.

• O Surface Hub e outras SKUs não abordadas nos requisitos de software não são compatíveis com o Windows Autopilot.
• O HoloLens 1 não suporta o Windows Autopilot.
• O HoloLens 2 oferece suporte ao modo de autoimplantação do Windows Autopilot com o Microsoft Intune e uma versão atualmente com suporte do Windows Holographic. Não há suporte para provedores MDM que não sejam da Microsoft.

Para obter mais informações sobre o HoloLens 2, consulte Piloto automático do Windows para o HoloLens 2.

Sim. Para obter mais informações, consulte Orientação do cenário de substituição da placa-mãe do Windows Autopilot.

Há limites para o número de dispositivos que um determinado usuário do Microsoft Entra pode registrar no Microsoft Entra ID e o número de dispositivos com suporte por usuário no Intune. Esses limites são configuráveis, mas não infinitos. Se você reutilizar dispositivos ou reverter para instantâneos anteriores da máquina virtual, esse erro ocorrerá com frequência.

Por padrão, o Windows Autopilot não aplica um perfil até que o usuário entre com o locatário correspondente para o perfil configurado usando o processo de entrada do Microsoft Entra. Por exemplo, badguys.com registra um dispositivo de propriedade do contoso.com. Na pior das hipóteses, o usuário é direcionado para entrar no badguys.com. Quando o usuário insere seu email e senha, as informações de entrada são redirecionadas por meio do Microsoft Entra ID para a autenticação adequada do Microsoft Entra e o usuário é solicitado a entrar.contoso.com Como contoso.com não corresponde como badguys.com locatário, o perfil mal-intencionado não é aplicado e o usuário vê o OOBE normal.

Os dados do Windows Autopilot são armazenados na União Europeia (UE). Ele não é armazenado em uma nuvem soberana, mesmo quando o locatário do Microsoft Entra é registrado em uma nuvem soberana. Esse armazenamento se aplica a todos os dados do Windows Autopilot, independentemente do portal usado para implantar o Windows Autopilot.

Os dados do cliente não são armazenados, apenas os dados corporativos que permitem à Microsoft fornecer um serviço. Por esse motivo, é apropriado que os dados sejam armazenados nos EUA. Os clientes podem parar de assinar o serviço a qualquer momento. Nesse caso, a Microsoft removerá os dados corporativos. No momento, o Windows Autopilot não é compatível com nenhuma nuvem soberana.

Existem seis maneiras de registrar um dispositivo, dependendo de quem faz o processo:

1. API direta do OEM, que só está disponível para TVOs.
2. MPC usando a API do MPC, que só está disponível para CSPs.
3. MPC usando o upload manual do arquivo CSV na interface do usuário, que só está disponível para CSPs.
4. MSfB usando o upload de arquivo CSV.
5. Intune usando o carregamento de arquivo CSV.
6. Portal do Microsoft 365 Business Premium usando upload de arquivo CSV.

Há quatro maneiras de criar e atribuir um perfil do Windows Autopilot:

1. Por meio do MPC, que só está disponível para CSPs.
2. Por meio do MSfB.
3. Por meio do Intune ou de outro serviço MDM.
4. Portal do Microsoft 365 Business Premium.

A Microsoft recomenda a criação e a atribuição de perfis por meio do Intune.

1. Entradas de hash de hardware inválidas ou ausentes podem levar a tentativas de registro com falha.
2. Caracteres especiais ocultos em arquivos CSV. Para evitar esse problema, depois de criar seu arquivo CSV, abra-o no Bloco de Notas para procurar caracteres ocultos, espaços à direita ou outras corrupções.

O Windows Autopilot só dá suporte a clientes que usam o Azure global. O Azure global não inclui as três entidades a seguir:

• Azure Alemanha.
• Azure China 21Vianet.
• Azure Governamental.

Se você usar o Azure global, não haverá restrições de região. Por exemplo, a Contoso usa o Azure global, mas tem funcionários trabalhando na China. Os funcionários da Contoso que trabalham na China ainda podem usar o Windows Autopilot para implantar dispositivos. Se a Contoso usar o Azure China 21Vianet, os funcionários da Contoso não poderão usar o Windows Autopilot.

Embora o Windows Autopilot esteja disponível em locatários globais, os usuários na China podem experimentar conectividade ruim e alta latência durante a implantação devido a problemas relacionados ao ISP. Se você estiver enfrentando esses problemas ao implantar na região, entre em contato com seu ISP local para obter suporte.

Para ambientes de GCCH (Nuvem da Comunidade Governamental Alta) e DoD (Departamento de Defesa), considere usar a preparação do dispositivo do Windows Autopilot.

O provisionamento do TPM envolve a geração e o processamento de chaves criptográficas fortes. Dependendo das características do hardware do TPM usado em um dispositivo, pode levar mais de um minuto na primeira inicialização.

Quando o logon automático com o modo de autoimplantação do Windows Autopilot é usado, o logon automático usa a conta local KioskUser0. Por padrão, o ESP do usuário não é processado para contas locais, incluindo KioskUser0, e um token de dispositivo não é emitido até que o ESP do usuário seja processado. Ao usar o logon automático, para que os aplicativos sejam instalados após a conclusão do ESP, ignore o ESP do usuário usando o OMA-URI personalizado SkipUserStatusPage. Para saber mais, confira os seguintes artigos:

• Como posso desabilitar a parte ESP do usuário da Página de Status do Registro (ESP) se um ESP tiver sido configurado no dispositivo?.
• Implante OMA-URIs para direcionar um CSP por meio do Intune e uma comparação com o local.

A conformidade do dispositivo no Microsoft Entra ID é redefinida durante o fluxo do usuário. Quando o fluxo de Usuário for concluído, a conformidade será reavaliada e atualizada. Esse comportamento é esperado.

O Conector do Intune para Active Directory atualizado fortalece a segurança e segue os princípios de privilégio mínimo usando uma MSA (Conta de Serviço Gerenciada) em vez de usar a conta de computador (SYSTEM) do servidor que executa o Conector do Intune para Active Directory.

Não. o instalador do Conector do Intune para Active Directory cuida da configuração de todas as permissões adequadas necessárias para o MSA nas UOs. As etapas para aumentar o limite de conta de computador nas UOs só precisarão ser seguidas se o administrador que está instalando e configurando o Conector do Intune para Active Directory não tiver as permissões descritas no Conector do Intune para Requisitos do Active Directory.