Solucionar problemas de clientes do ADBA (Ativação Baseada no Active Directory) que não são ativados

Observação

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

Recentemente ajudei um cliente a implantar Windows Server 2016 em seu ambiente. Aproveitamos essa oportunidade para migrar também a metodologia de ativação de um KMS Server para 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. Iniciamos a implantação seguindo as instruções no Active Directory-Based Activation vs. Key Management Services. Os controladores de domínio no ambiente de teste estavam todos executando Windows Server 2012 R2, então não precisávamos preparar a floresta. Instalamos a função em um Windows Server 2012 Controlador de Domínio R2 e escolhemos Ativação Baseada no Active Directory como o método de ativação de volume. Instalamos a chave KMS e demos a ela um nome de "KMS AD Activation (** LAB)." Seguimos a postagem 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. Criamos um servidor físico executando o Windows 2016 Server Standard e o computador foi ativado corretamente.

Sinceramente, a configuração e configuração foram super fáceis, de modo que a 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 a máquina física e estava tudo bem. Fui ao cliente discutir o que tinha acontecido. A primeira pergunta foi "O que mudou no fim de semana?" E, como de costume, a resposta era "nada". Desta vez, nada realmente tinha sido mudado, e tivemos que descobrir o que estava acontecendo.

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

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

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

Alguém vê o que eu perdi neste momento? Voltaremos a ele depois das 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 comutador, que desinstala a chave atual. Embora isso tenha sido eficaz na remoção da chave, geralmente não é a melhor maneira de fazê-la. O servidor deve ser reiniciado antes de obter uma nova chave que pode deixar o servidor em um estado ruim? Descobri que usar o /ipk comutador (que faço mais tarde na solução de problemas) substitui a chave existente e é um caminho mais seguro a ser feito.

Eu executei a opção /dlv novamente, para ver as informações detalhadas da licença. Infelizmente, isso não me deu nenhuma informação útil, apenas uma chave de produto não encontrada erro. Porque não há chave desde que a desinstalei.

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

O próximo pensamento era que às vezes parar e começar um serviço faz o truque, então eu tentei isso em seguida. Preciso parar e iniciar o serviço SPPSvc (Serviço de Plataforma de Proteção de Software da Microsoft). De um prompt de comando administrativo, uso os comandos e net start confiáveisnet stop. No início, notei 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 não encontrado do produto.

Em seguida, olhei para o Log de Eventos do Aplicativo em um dos servidores de problemas. Acho um erro relacionado à Ativação de Licença, ID de Evento 8198, que tem um código de 0x8007007B.

Ao procurar 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 de 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, portanto, 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 que os problemas estavam em outro lugar.

Então eu sei que o DNS está bem. O Active Directory está configurado corretamente como uma fonte de ativação do KMS. O servidor físico foi ativado corretamente. Isso pode ser um problema apenas com VMs? Como uma observação lateral interessante neste momento, meu cliente me informa que alguém em um departamento diferente decidiu criar mais de uma dúzia de máquinas de Windows Server 2016 virtuais também. Então, agora eu suponho que eu tenho mais uma dúzia de servidores para lidar com isso não será ativada. No entanto, esses servidores ativaram muito bem.

Voltei para o slmgr comando para descobrir como ativar esses monstros. Desta vez vou usar o comutador, o /ipk que me permitirá instalar uma chave de produto. Fui ao Apêndice A: Chaves de Instalaçã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 corrigir este primeiro.

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

Daqui em diante, eu só capturei resultados das minhas experiências do Datacenter, mas elas eram as mesmas. Usei a opção /ato para forçar a ativação. Recebemos a mensagem incrível de que o produto foi ativado com êxito.

Usando a opção /dlv novamente, podemos ver que agora fomos ativados pelo Active Directory.

O que deu errado? Por que tive que remover a chave instalada e adicionar essas chaves genéricas para que esses computadores sejam ativados corretamente? Por que as outras dezenas de computadores foram ativadas sem problemas? Como eu disse anteriormente, perdi algo importante nos estágios iniciais de olhar para o problema. Eu estava completamente confuso, então entrei em contato com o pôster do blog inicial. O cartaz viu o problema imediatamente e me ajudou a entender o que eu tinha perdido no início.

Quando executei o primeiro /dlv comutador, na descrição estava a chave. A descrição foi Sistema Operacional Windows®, Canal RETAIL. Eu tinha olhado para isso e pensei que retail channel significava que ele tinha sido comprado e era uma chave válida.

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

Então, o que esse canal retail significa? Bem, isso significa que a mídia usada para instalar o sistema operacional era um ISO MSDN. Voltei para meu cliente e perguntei se, por alguma chance, havia um segundo Windows Server 2016 ISO flutuando pela rede. Acontece que sim, havia outro ISO na rede, e ele tinha sido usado para criar as outras dezenas de computadores. Eles compararam os dois ISOs e, com certeza, o que me foi dado para criar os servidores virtuais foi, de fato, um ISO MSDN. Eles removeram o ISO do MSDN de sua rede e agora temos todos os servidores existentes ativados e sem mais preocupações com a falha de ativação em builds futuros.