Perguntas frequentes do Windows Autopilot

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

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

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

O cliente comercial 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 dá suporte à remoção da conta de administrador local. No entanto, ele dá suporte à restrição do usuário que executa Microsoft Entra ingresso de domínio no OOBE a uma conta padrão (versus uma conta de administrador por padrão).

Somente os parceiros CSP têm acesso ao portal do Partner Center. Se você for um CSP, poderá criar uma conta de usuário do agente de vendas que tenha acesso a dispositivos para testar o arquivo. Este teste pode ser feito hoje 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 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 da relação que seu parceiro revendedor CSP tem com o cliente. Provedores CSP indiretos registram dispositivos por meio do Centro de Parceiros da Microsoft.
3. Revendedor CSP indireto: obtém autorização direta do cliente para registrar dispositivos. Ao mesmo tempo, seu parceiro de provedor CSP indireto também obtém autorização, o que significa que o provedor indireto ou o revendedor indireto podem registrar dispositivos para o cliente. No entanto, o revendedor CSP indireto deve registrar 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 do local do locatário 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 baseia-se na localização do locatário que o parceiro CSP está usando para transacionar. Se o locatário do cliente foi criado nos EUA, apenas um parceiro que tenha um registro CSP nos EUA poderá estabelecer uma relação de revendedor com esse cliente.

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

Se um parceiro quiser gerenciar clientes globalmente, ele precisará ter uma presença global. Eles precisam de vários registros CSP em cada uma das regiões de vendas do CSP em que conduzem negócios.

Não é possível criar contas de usuário que tenham acesso a todos os locatários do CSP. Esse cenário se traduziria em 18 contas de usuário para um agente administrador do CSP que deseja gerenciar todos os clientes em todo o 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 dispositivo transfronteiriço não é o problema. O problema são as vendas transfronteiriças por meio do CSP.

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

Nenhuma alteração é necessária no chão de fábrica para habilitar 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.

Sim. Se eles querem o Windows Autopilot, é necessária 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 os CBRs como de costume para a Microsoft. Nenhuma imagem é enviada à Microsoft para habilitar o Windows Autopilot. O Windows Autopilot personaliza apenas 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 registrar 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 no Microsoft Partner Center ou usar a API direta do OEM.

Não.

Não.

Sim. O arquivo CSV só pode conter 500 dispositivos a serem aplicados 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 comercial para registrar automaticamente seus dispositivos Windows Autopilot por meio de MPC, MSfB ou Intune.

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

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

Como o Windows Autopilot se baseia na capacidade de identificar exclusivamente 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 4K de tamanho, 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 partes que foram substituídas e das características das partes.

Por exemplo, se você substituir o TPM ou a placa-mãe, ele será um novo dispositivo e deverá obter um novo hash de hardware. Se você substituir um cartão de rede, provavelmente não é um dispositivo novo 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. Esse processo é recomendado sempre que você substitui peças.

A substituição da placa-mãe está fora do escopo do 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 certas ou aplicar uma imagem personalizada.

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

1. Cancelar o registro do dispositivo do Autopilot.
2. Substitua a placa-mãe.
3. Gerar 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 de disco vem com IOCTL_STORAGE_QUERY_PROPERTYStorageDeviceProperty/PropertyStandardQuery.

• O endereço MAC de rede é de IOCTL_NDIS_QUERY_GLOBAL_STATSOID_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. As interfaces de rede removíveis não devem ser usadas se detectadas como removíveis. LAN vs WLAN não deve importar, pois ambos são usados.

Um dispositivo recebeu uma configuração do Autopilot, mas ainda não a aplicou quando a página de seleção é ignorada e é imediatamente levada para uma página de entrada genérica ou personalizada.

Microsoft Entra administradores 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 .cab arquivo (gabinete) para AutopilotHelp@microsoft.com. Se possível, também colete um ETL do Gravador de Desempenho do Windows (WPR).

Geralmente, nesses casos, os usuários não estão entrando no locatário certo Microsoft Entra ou estão criando contas de usuário locais.

Para obter uma lista completa de 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, as configurações definidas no momento são aplicadas. Em seguida, o perfil é descartado no dispositivo. Se o dispositivo for reimageado 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 MDM, o dispositivo passará pela experiência OOBE padrão. Em seguida, você precisa registrar manualmente esse dispositivo no MDM. Na próxima vez que o dispositivo for redefinido, ele passará pela experiência OOBE do Windows Autopilot.

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 é atribuído ao dispositivo, o usuário vê o OOBE padrão.

A melhor maneira de coletar logs no 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 Autopilot, mas outros podem não ter o mesmo conjunto completo de recursos do Windows Autopilot que Intune. A melhor experiência é com Intune.

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

O cogerenciamento permite que você gerencie simultaneamente versões com suporte atual do Windows usando Microsoft Configuration Manager e Microsoft Intune. Ele permite que você anexe à nuvem seu investimento existente no Configuration Manager 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 Configuration Manager cliente e é registrado para Intune, você obtém os benefícios de ambos os serviços. Você controla quais cargas de trabalho, se houver, alterna a autoridade do Configuration Manager 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 Configuration Manager aos quais o cogerenciamento não oferece suporte.

Para saber mais, confira os seguintes artigos:

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

Não. Não é necessário, mas você pode usá-lo junto com o Autopilot nos seguintes cenários:

• Cogerenciamento
• Autopilot para dispositivos existentes

O modo de auto-implantação exige 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, confira Modo de auto-implantação do Windows Autopilot.

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

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

A redefinição do Windows Autopilot remove aplicativos e configurações de usuário de um dispositivo, mas mantém Microsoft Entra ingressamento de domínio e registro de 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
• Personalizar a dica de nome de usuário
• Logotipo da sua organização

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

Para obter mais informações, consulte 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 essa lista assim que eles estiverem integrados. Para obter mais informações, consulte Retorno da funcionalidade de chave para entrada e implantação do Windows Autopilot.

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

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

Para o Surface Hub, o Windows Mobile e outras SKUs, não há suporte para o Windows Autopilot. O HoloLens 1 também não dá suporte ao Windows Autopilot. Com o Windows Holographic versão 2004, HoloLens 2 dá suporte ao modo de auto-implantação do Windows Autopilot com Microsoft Intune. Não há suporte para provedores de MDM de terceiros.

Para obter mais informações sobre HoloLens 2, consulte Windows Autopilot para HoloLens 2.

Sim. Para obter mais informações, consulte Diretrizes de 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 Microsoft Entra pode registrar em Microsoft Entra ID e o número de dispositivos com suporte por usuário em Intune. Esses limites são configuráveis, mas não infinitos. Se você reutilizar dispositivos ou reverter para instantâneos de máquina virtual anteriores, esse erro ocorrerá com frequência.

Por design, 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 Microsoft Entra. Por exemplo, badguys.com registra um dispositivo de propriedade de contoso.com. Na pior das hipóteses, o usuário é direcionado para entrar em badguys.com. Quando o usuário insere seu email e senha, as informações de entrada são redirecionadas por meio de Microsoft Entra ID para a autenticação de Microsoft Entra adequada e o usuário é solicitado a entrar em contoso.com. Como contoso.com não corresponde badguys.com como o locatário, o perfil mal-intencionado não é aplicado e o usuário vê o OOBE regular.

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 Microsoft Entra é registrado em uma nuvem soberana. Esse armazenamento se aplica a todos os dados do Windows Autopilot, qualquer portal usado para implantar o Autopilot.

Os dados do cliente não são armazenados, apenas dados comerciais que permitem que a Microsoft forneça 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 remove os dados de negócios. No momento, o Autopilot não tem suporte em nenhuma nuvem soberana.

Há 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 upload de arquivo CSV
6. Microsoft 365 Business Premium portal usando o 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 de Intune ou de outro serviço MDM
4. portal Microsoft 365 Business Premium

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

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

O 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 Autopilot para implantar dispositivos. Se a Contoso usar o Azure China 21Vianet, os funcionários da Contoso não poderão usar o Autopilot. Enquanto o Autopilot está disponível em locatários globais, os usuários na China podem ter pouca conectividade e alta latência ao implantar devido a problemas relacionados ao ISP. Se você estiver enfrentando esses problemas ao implantar na região, entre em contato com o ISP local para obter suporte.

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

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

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

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