Perguntas frequentes do Windows Autopilot

Não. Desde que o ID do Inquilino seja uma entrada única no Centro de Parceiros que pode ser reutilizada com futuros carregamentos de dispositivos.

Após a conclusão do carregamento do ficheiro do dispositivo no Centro de Parceiros, o inquilino pode ver os dispositivos disponíveis para a configuração do Windows Autopilot no MSfB. O OEM tem de aconselhar o inquilino a aceder ao MSfB. A anotação automática do MSfB para o inquilino está a ser desenvolvida.

Antes de um OEM ou Parceiro de Canal poder registar um dispositivo para o Autopilot para um cliente, o cliente tem primeiro de dar-lhe consentimento. O processo de consentimento começa com o OEM ou o Parceiro de Canal a enviar uma ligação para o cliente que direciona o cliente para uma página de consentimento no MSfB. Para obter mais informações, veja Registo.

O cliente empresarial tem de eliminar os dispositivos no MSfB para que o CSP possa carregá-los e geri-los no Centro de Parceiros.

Não. O Windows Autopilot não suporta a remoção da conta de administrador local. No entanto, suporta a restrição da associação de domínio do Microsoft Entra ao utilizador durante a experiência inicial (OOBE) a uma conta padrão em comparação com uma conta de administrador por predefinição.

Apenas os parceiros CSP têm acesso ao portal do Centro de Parceiros. Se for um CSP, pode criar uma conta de utilizador do agente de vendas que tenha acesso a dispositivos para testar o ficheiro. Este teste pode ser feito hoje no Centro de Parceiros.

Para obter mais informações, veja Criar contas de utilizador.

Este requisito não se aplica aos OEMs de volume superior porque podem utilizar a API OEM Direct. Todas as outras pessoas que optem por utilizar o Centro de Parceiros da Microsoft (MPC) para registar dispositivos têm de se tornar CSPs para aceder ao MPC.

Para efeitos do Windows Autopilot, existem 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 registar dispositivos
2. Fornecedor CSP indireto: obtém permissão implícita para registar dispositivos através da relação que o parceiro revendedor CSP tem com o cliente. Os fornecedores CSP indiretos registam dispositivos através do Centro de Parceiros da Microsoft.
3. Revendedor CSP indireto: obtém autorização direta do cliente para registar dispositivos. Ao mesmo tempo, o parceiro de fornecedor CSP indireto também obtém autorização, o que significa que o fornecedor indireto ou o revendedor indireto pode registar dispositivos para o cliente. No entanto, o revendedor CSP indireto tem de registar dispositivos através da interface de utilizador do Centro de Parceiros ao carregar manualmente o ficheiro CSV. O fornecedor CSP indireto pode registar dispositivos com as APIs do Centro de Parceiros.

Não. As regiões de vendas do CSP dependem da localização do inquilino do Microsoft Entra. Um parceiro CSP só pode vender ou gerir clientes com um inquilino localizado na mesma região do CSP. A região CSP de um parceiro baseia-se na localização do inquilino que o parceiro CSP está a utilizar para realizar transações. Se o inquilino do cliente tiver sido criado nos EUA, apenas um parceiro que tenha uma inscrição CSP nos EUA pode estabelecer uma relação de revendedor com este cliente.

Para o Autopilot & Intune, a localização do utilizador final ou do dispositivo não importa. Um funcionário localizado na Alemanha pode inscrever um dispositivo com o perfil do Autopilot criado no inquilino dos EUA e geri-lo através da instância de serviço do Intune nos EUA. O utilizador na Alemanha também se autentica na instância do Microsoft Entra, com sede nos EUA.

Se um parceiro quiser gerir os clientes globalmente, tem de ter uma presença global. Precisam de várias inscrições CSP em cada uma das regiões de vendas do CSP onde realizam negócios.

Não é possível criar contas de utilizador que tenham acesso a todos os inquilinos do CSP. Este cenário traduzir-se-ia em 18 contas de utilizador para um agente de administração CSP que quer gerir todos os clientes em todo o mundo.

Em resumo, a localização do utilizador e dos dispositivos não importa. A localização do inquilino do cliente é importante. O registo de dispositivos transfronteiriços não é o problema. O problema são as vendas transfronteiriças através do CSP.

Não. O Centro de Parceiros não tem acesso a perfis criados no Intune ou na Microsoft Store para Empresas. Só tem acesso aos perfis do Autopilot criados através do Centro de Parceiros.

Não são necessárias alterações no piso de fábrica para ativar a implementação do Windows Autopilot.

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

Sim. Se quiserem o Windows Autopilot, é necessária uma versão suportada do Windows. Um cliente também deve receber o ficheiro CSV ou ter o carregamento do ficheiro concluído em seu nome.

Não. Os OEMs apenas enviam o Relatório de Compilação do Computador (CBR) como habitualmente para a Microsoft. Não são enviadas imagens para a Microsoft para ativar o Windows Autopilot. O Windows Autopilot só personaliza o OOBE e permite configurações de políticas.

Os dispositivos têm de estar a executar uma versão suportada do canal de disponibilidade geral do Windows para se inscreverem na implementaçã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 registar o dispositivo em nome do cliente. Neste caso, têm de carregar o ficheiro CSV do ID do dispositivo para o Centro de Parceiros da Microsoft ou utilizar a API direta do OEM.

Não.

Não.

Sim. O ficheiro CSV só pode conter 500 dispositivos a aplicar a um único perfil. Se mais de 500 dispositivos precisarem de ser aplicados a um perfil, os dispositivos têm de ser carregados através de vários ficheiros CSV.

Encripte o ficheiro CSV ao enviá-lo para o cliente empresarial para registar os respetivos dispositivos Windows Autopilot através de MPC, MSfB ou Intune.

Todos os hashs de hardware submetidos pelo OEM têm de conter os seguintes dados:

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

Uma vez que o Windows Autopilot se baseia na capacidade de identificar exclusivamente os dispositivos que se aplicam à configuração da cloud, é fundamental submeter hashes de hardware que cumpram o requisito descrito.

À medida que partes do dispositivo são adicionadas ou removidas, estes campos são necessários para identificar um dispositivo ao criar o hash de hardware. Uma vez que não temos um identificador exclusivo para dispositivos Windows, estes 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 chama-se hash OA3, que tem 4K de tamanho e é utilizada para o cenário de implementação do Windows Autopilot.

Sim. Se substituir partes, poderá ter de gerar um novo hash de hardware. Depende das partes que foram substituídas e das características das partes.

Por exemplo, se substituir o TPM ou a placa principal, este é um novo dispositivo e tem de obter um novo hash de hardware. Se substituir uma placa de rede, provavelmente não é um dispositivo novo e o dispositivo funciona com o hash de hardware antigo.

Em geral, após quaisquer alterações de hardware, suponha que o hash de hardware antigo é inválido e obtenha um novo hash de hardware. Este processo é recomendado sempre que substituir peças.

A substituição da placa principal está fora do âmbito do Autopilot. Qualquer dispositivo reparado ou reparado que altere a capacidade de identificar o dispositivo para o Windows Autopilot tem de passar pelo processo OOBE normal. Tem de selecionar manualmente as definições corretas ou aplicar uma imagem personalizada.

Para reutilizar o mesmo dispositivo para o Windows Autopilot após uma substituição da placa principal, utilize o seguinte processo:

1. Anule o registo do dispositivo do Autopilot.
2. Substitua a placa principal.
3. Gere um novo hash de hardware 4K.
4. Registe o dispositivo com o novo hash de hardware 4K ou ID do dispositivo.

Tem de ser exclusivo conforme especificado nos requisitos de hardware do Windows.

Tem de cumprir todos os requisitos de hardware do Windows. Para obter mais informações, veja Especificações e Políticas do Programa de Compatibilidade de Hardware do Windows.

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

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

O método para obter estas informações varia consoante o cenário, mas em geral:

• O número de série do disco é proveniente de IOCTL_STORAGE_QUERY_PROPERTY com StorageDeviceProperty/PropertyStandardQuery.

• O endereço MAC de rede é de IOCTL_NDIS_QUERY_GLOBAL_STATSOID_802_3_PERMANENT_ADDRESS.

Todos os valores disponíveis são utilizados, embora possam existir regras de utilização 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 amovíveis não devem ser utilizadas se forem detetadas como amovíveis. LAN vs WLAN não deve importar, pois ambos são utilizados.

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 início de sessão.

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

Para ajudar a resolver problemas, execute licensingdiag.exe e envie o .cab ficheiro (cab) para AutopilotHelp@microsoft.com. Se possível, recolha também um ETL do Windows Performance Recorder (WPR).

Muitas vezes, nestes casos, os utilizadores não iniciam sessão no inquilino do Microsoft Entra correto ou estão a criar contas de utilizador locais.

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

Não. Os perfis do Windows Autopilot não são residentes no dispositivo. São transferidas durante o OOBE e as definições são definidas no momento em que são aplicadas. Em seguida, o perfil é eliminado no dispositivo. Se o dispositivo for recriado ou reposto, as novas definições de perfil entrarão em vigor da próxima vez que o dispositivo passar pelo OOBE.

Se o dispositivo não estiver registado, não receberá a experiência do Windows Autopilot e o utilizador final passa pelo OOBE normal. As configurações do Windows Autopilot não serão aplicadas até que o utilizador execute novamente o OOBE, após o registo. Se um dispositivo for iniciado antes da criação de um perfil de gestão de dispositivos móveis (MDM), o dispositivo passa por uma experiência OOBE padrão. Em seguida, tem de inscrever manualmente esse dispositivo na MDM. Da próxima vez que o dispositivo for reposto, passará pela experiência OOBE do Windows Autopilot.

Para receber uma experiência de início de sessão personalizada, configure a imagem corporativa do inquilino no portal do Azure.

Uma vez que nenhum perfil do Windows Autopilot está atribuído ao dispositivo, o utilizador vê o OOBE predefinido.

A melhor forma de recolher registos sobre o desempenho do Windows Autopilot é recolher um rastreio WPR durante o OOBE. O ficheiro XML (extensão WPRP) para este rastreio pode ser fornecido mediante pedido.

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

Sim. O Intune suporta aplicações Win32 com wrappers MSI e MSIX.

A cogestão permite-lhe gerir simultaneamente versões suportadas atualmente do Windows com o Microsoft Configuration Manager e o 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 cliente do Configuration Manager e está inscrito no Intune, 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 é a cogestão?.
• Como inscrever-se com a cogestão quando aprovisionar com o Windows Autopilot.

Não. Não é necessário, mas pode utilizá-lo em conjunto com o Autopilot nos seguintes cenários:

• Cogestão.
• Autopilot para dispositivos existentes.

O modo de implementação automática só requer que o utilizador aceda ao dispositivo. É útil para cenários em que não é necessária uma conta de utilizador padrão. Por exemplo, dispositivos partilhados ou de quiosque.

Para obter mais informações, veja Modo de implementação automática do Windows Autopilot.

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

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

A reposição do Windows Autopilot remove as definições e aplicações de utilizador de um dispositivo, mas mantém a associação a um domínio do Microsoft Entra e a inscrição mdm. Esta funcionalidade é útil quando transfere um dispositivo de um utilizador para outro.

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

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

• Uma mensagem de boas-vindas personalizada.
• Personalize a sugestão de nome de utilizador.
• O logótipo da sua organização.

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

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

Os fabricantes atuais ativados para esta alteração são Dell, Dynabook, HP, Lenovo e Microsoft Surface. Estamos a trabalhar para adicionar outros fabricantes e atualizaremos esta lista assim que estiverem integrados. Para obter mais informações, veja Return of key functionality for Windows Autopilot sign-in and deployment (Devolução das principais funcionalidades de início de sessão e implementação do Windows Autopilot).

Sim. Se o dispositivo ainda estiver registado no Autopilot e estiver a executar uma versão suportada do Windows, receberá a experiência do Autopilot.

Sim. Se o dispositivo estiver a executar uma versão suportada do Windows, pode recolher impressões digitais do dispositivo para registo. Não existem planos para criar backportar a funcionalidade para versões anteriores. Não existe forma de os recolher em dispositivos com versões não suportadas do Windows.

• O Surface Hub e outros SKUs não abrangidos pelos requisitos de Software não são suportados com o Windows Autopilot.
• O HoloLens 1 não suporta o Windows Autopilot.
• O HoloLens 2 suporta o modo de implementação automática do Windows Autopilot com o Microsoft Intune e uma versão atualmente suportada do Windows Holographic. Os fornecedores de MDM não Microsoft não são suportados.

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

Sim. Para obter mais informações, veja Windows Autopilot motherboard replacement scenario guidance (Orientação do cenário de substituição da placa principal do Windows Autopilot).

Existem limites para o número de dispositivos que um utilizador específico do Microsoft Entra pode inscrever no Microsoft Entra ID e o número de dispositivos suportados por utilizador no Intune. Estes limites são configuráveis, mas não infinitos. Se reutilizar dispositivos ou reverter para instantâneos de máquinas virtuais anteriores, este erro ocorre frequentemente.

Por predefinição, o Windows Autopilot não aplica um perfil até que o utilizador inicie sessão com o inquilino correspondente para o perfil configurado através do processo de início de sessão do Microsoft Entra. Por exemplo, badguys.com regista um dispositivo pertencente a contoso.com. Na pior das hipóteses, o utilizador é direcionado para iniciar sessão no badguys.com. Quando o utilizador introduz o respetivo e-mail e palavra-passe, as informações de início de sessão são redirecionadas através do Microsoft Entra ID para a autenticação adequada do Microsoft Entra e é pedido ao utilizador para iniciar sessão em contoso.com. Uma contoso.com vez que não corresponde badguys.com como inquilino, o perfil malicioso não é aplicado e o utilizador vê o OOBE normal.

Os dados do Windows Autopilot são armazenados na União Europeia (UE). Não é armazenado numa cloud soberana, mesmo quando o inquilino do Microsoft Entra está registado numa cloud soberana. Este armazenamento aplica-se a todos os dados do Windows Autopilot, seja qual for o portal utilizado para implementar o Autopilot.

Os dados do cliente não são armazenados, apenas os dados empresariais que permitem à Microsoft fornecer um serviço. Por esse motivo, é apropriado que os dados sejam armazenados nos EUA. Os clientes podem deixar de subscrever o serviço em qualquer altura. Nesse caso, a Microsoft remove os dados de negócio. O Autopilot não é atualmente suportado em nenhuma cloud soberana.

Existem seis formas de registar um dispositivo, consoante quem faz o processo:

1. API direta OEM, que só está disponível para TVOs.
2. MPC com a API MPC, que só está disponível para CSPs.
3. MPC através do carregamento manual do ficheiro CSV na IU, que só está disponível para CSPs.
4. MSfB com o carregamento de ficheiros CSV.
5. Intune com o carregamento de ficheiros CSV.
6. Portal do Microsoft 365 Empresas Premium com o carregamento de ficheiros CSV.

Existem quatro formas de criar e atribuir um perfil do Windows Autopilot:

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

A Microsoft recomenda a criação e atribuição de perfis através do Intune.

1. As entradas de hash de hardware incorretas ou em falta podem originar tentativas de registo com falhas.
2. Carateres especiais ocultos em ficheiros CSV. Para evitar este problema, depois de criar o ficheiro CSV, abra-o no Bloco de Notas para procurar carateres ocultos, espaços à direita ou outros danos.

O Autopilot só suporta clientes que utilizam o Azure global. O Azure Global não inclui as três entidades seguintes:

• Azure Alemanha.
• Azure China 21Vianet.
• Azure Government.

Se utilizar o Azure global, não existem restrições de região. Por exemplo, a Contoso utiliza o Azure global, mas tem colaboradores a trabalhar na China. Os funcionários da Contoso que trabalham na China ainda podem utilizar o Autopilot para implementar dispositivos. Se a Contoso utilizar o Azure China 21Vianet, os funcionários da Contoso não poderão utilizar o Autopilot.

Embora o Autopilot esteja disponível em inquilinos globais, os utilizadores na China podem deparar-se com conectividade fraca e latência elevada durante a implementação devido a problemas relacionados com o ISP. Se estiver a ter estes problemas ao implementar na região, contacte o ISP local para obter suporte.

O aprovisionamento do TPM envolve gerar e processar chaves criptográficas fortes. Consoante as características do hardware TPM utilizado num dispositivo, pode demorar mais de um minuto no primeiro arranque.

Quando é utilizado o início de sessão automático com o modo de implementação automática do Windows Autopilot, o início de sessão automático utiliza a conta local KioskUser0. Por predefinição, o ESP do utilizador não é processado para contas locais, incluindo o KioskUser0, e um token de dispositivo não é emitido até o utilizador ESP ser processado. Ao utilizar o registo automático, para que as aplicações sejam instaladas após a conclusão do ESP, ignore o ESP do utilizador com a OMA-URI SkipUserStatusPage personalizada. Para saber mais, confira os seguintes artigos:

• Como posso desativar a parte esp do utilizador da Página de Estado da Inscrição (ESP) se um ESP tiver sido configurado no dispositivo?.
• Implemente OMA-URIs para direcionar um CSP através do Intune e uma comparação com o local.

A conformidade do dispositivo no Microsoft Entra ID é reposta durante o Fluxo de utilizador. Assim que o Fluxo de utilizador for concluído, a compatibilidade é reavaliada e atualizada. Esse comportamento é esperado.