Solucionar problemas de clientes de ativação baseada no Active Directory (ADBA) que não são ativados

Observação

Este artigo foi publicado originalmente como um blog do TechNet em 26 de março de 2018.

Recentemente ajudei um cliente na implantação do Windows Server 2016 em seu ambiente. Aproveitamos essa oportunidade para migrar também sua metodologia de ativação de um Servidor KMS para a Ativação baseada no Active Directory.

Como procedimento adequado para fazer todas as alterações, iniciamos a migração no ambiente de teste do cliente. Começamos a implantação seguindo as instruções em Ativação baseada no Active Directory versus Serviços de Gerenciamento de Chaves. Os controladores de domínio no ambiente de teste estavam todos executando o Windows Server 2012 R2, portanto, não precisávamos preparar a floresta. Instalamos a função em um controlador de domínio do Windows Server 2012 R2 e escolhemos a ativação baseada no Active Directory como o método de ativação de volume. Instalamos a chave KMS e demos a ela o nome de "Ativação do KMS AD (** LAB)". Seguimos o post do blog passo a passo.

Começamos criando quatro máquinas virtuais, duas Windows 2016 Server Standard e duas Windows 2016 Server Datacenter. Neste ponto, tudo estava ótimo. Construímos um servidor físico executando o Windows 2016 Server Standard e a máquina foi ativada corretamente.

Na verdade, a instalação e a configuração foram muito fáceis, portanto, essa parte era simples e direta. No entanto, todas as máquinas virtuais que construí na semana anterior mostraram que não foram ativadas. Voltei para o computador físico e estava certo. Fui até o cliente para discutir o que tinha acontecido. A primeira pergunta foi "O que mudou no fim de semana?" E, como de costume, a resposta foi "nada". Desta vez, nada realmente havia sido mudado e tivemos que descobrir o que estava acontecendo.

Fui a um dos servidores com problemas, abri um prompt de comando e verifiquei a saída do slmgr /ao-list comando. A /ao-list opção exibe todos os objetos de ativação no Active Directory.

Os resultados mostram que temos dois objetos de ativação: um para o Windows Server 2012 R2 e o recém-criado KMS AD Activation (** LAB), que é a licença do Windows Server 2016. Isso confirma que o Active Directory está configurado corretamente para ativar clientes KMS do Windows.

Sabendo que o comando é para ativação da slmgr licença, continuei com diferentes opções. Tentei o switch, que exibirá informações detalhadas sobre a /dlv licença. Isso parecia bom, eu estava executando a versão padrão do Windows Server 2016, há um ID de ativação, um ID de instalação, um URL de validação e até mesmo uma chave de produto parcial.

Alguém percebeu o que eu deixei passar neste momento? Voltaremos a ele após minhas outras etapas de solução de problemas, mas basta dizer que a resposta está nesta captura de tela.

Meu pensamento agora é que, por algum motivo, a chave está quebrada, então eu uso o /upk interruptor, que desinstala a chave atual. Embora isso tenha sido eficaz na remoção da chave, geralmente não é a melhor maneira de fazê-lo. Se o servidor for reinicializado antes de obter uma nova chave, ele pode deixar o servidor em mau estado? Descobri que usar o /ipk switch (o que faço mais tarde na minha solução de problemas) substitui a chave existente e é um caminho mais seguro a seguir.

Executei o /dlv switch novamente, para ver as informações detalhadas da licença. Infelizmente, isso não me deu nenhuma informação útil, apenas um erro de chave de produto não encontrada. Porque não há chave, pois acabei de desinstalá-lo.

Achei que era um tiro no escuro, mas tentei a opção, que deve ativar o /ato Windows nos servidores KMS conhecidos (ou no Active Directory, conforme o caso). Novamente, apenas um erro de produto não encontrado.

O próximo pensamento foi que, às vezes, parar e iniciar um serviço resolve, então tentei em seguida. Precisei interromper e iniciar o Serviço de Plataforma de Proteção de Software da Microsoft (serviço SPPSvc). A partir de um prompt de comando administrativo, eu uso os comandos trusty net stop e net start . Percebo a princípio que o serviço não está em execução, então acho que deve ser isso.

No entanto, depois de iniciar o serviço e tentar ativar o Windows novamente, ainda recebo o erro do produto não encontrado.

Depois, examinei o Log de Eventos do Aplicativo em um dos servidores com problemas. Encontrei um erro relacionado à Ativação da Licença, ID de Evento 8198, cujo código é 0x8007007B.

Ao pesquisar esse código, encontrei um artigo que diz que o código de erro significa que o nome do arquivo, o nome do diretório ou a sintaxe do rótulo do volume estão incorretos. Lendo os métodos descritos no artigo, não parecia que nenhum deles se encaixasse na situação. Quando executei o nslookup -type=all _vlmcs._tcp comando, encontrei o servidor KMS existente (ainda muitos computadores Windows 7 e Server 2008 no ambiente, por isso era necessário mantê-lo por perto), mas também os cinco controladores de domínio. Isso indicava que não era um problema de DNS e os problemas estavam em outro lugar.

Então soube que não havia nada de errado com o DNS. O Active Directory estava devidamente configurado como uma fonte de ativação do KMS. O servidor físico foi ativado corretamente. Isso poderia ser um problema apenas com VMs? Como uma observação interessante neste ponto, meu cliente informa que alguém em um departamento diferente decidiu criar mais de uma dúzia de máquinas virtuais do Windows Server 2016 também. Então agora eu suponho que tenho mais uma dúzia de servidores para lidar que não serão ativados. No entanto, esses servidores foram ativados muito bem.

Bem, voltei ao slmgr comando para descobrir como ativar esses monstros. Desta vez, vou usar o /ipk switch, que me permitirá instalar uma chave de produto. Fui para o Apêndice A: Chaves de configuração do cliente KMS para obter as chaves apropriadas para a versão Standard do Windows Server 2016. Alguns servidores são Datacenter, mas preciso consertar este primeiro.

Usei a /ipk opção para instalar uma chave do produto, escolhendo a chave padrão do Windows Server 2016.

Daqui em diante, capturei apenas os resultados de minhas experiências com o Datacenter, mas eles eram os mesmos. Usei o /ato interruptor para forçar a ativação. Recebemos a mensagem incrível de que o produto foi ativado com sucesso.

Usando a /dlv chave novamente, podemos ver que agora fomos ativados pelo Active Directory.

E agora, o que tinha dado errado? Por que eu preciso remover a chave instalada e adicionar essas chaves genéricas para ativar essas máquinas adequadamente? Por que a outra dúzia de computadores foi ativada sem problemas? Como eu disse anteriormente, deixei passar alguma chave nas etapas iniciais de exame do problema. Eu estava completamente confuso, então entrei em contato com o pôster do blog inicial. O pôster viu o problema imediatamente e me ajudou a entender o que eu havia perdido no início.

Quando eu corri o primeiro /dlv switch, na descrição foi a chave. A descrição era Sistema Operacional Windows®, Canal COMERCIAL. Eu tinha examinado isso e achei que Canal COMERCIAL queria dizer que ela tinha sido adquirida e era uma chave válida.

Quando olhamos para a /dlv saída do switch de um servidor ativado corretamente, observe que a descrição agora indica o canal VOLUME_KMSCLIENT. Isso nos permite saber que é realmente uma licença por volume.

Então, o que canal COMERCIAL quer dizer? Bom, isso significa que a mídia que foi usada para instalar o sistema operacional era um ISO do MSDN. Voltei ao meu cliente e perguntei se, por acaso, havia uma segunda ISO do Windows Server 2016 flutuando ao redor da rede. Acontece que sim, havia outro ISO na rede e ele tinha sido usado para criar a outra dúzia de computadores. Eles compararam os dois ISOs e certamente o que foi dado a mim para criar os servidores virtuais era, na verdade, um ISO do MSDN. Eles removeram o ISO do MSDN de sua rede e agora temos todos os servidores existentes ativados e não há mais preocupações com a falha de ativação em compilações futuras.