Como remover registros _VLMCS obsoletos e migrar com segurança para KMS e ADBA no Windows Server

Introdução
Ter entradas DNS limpas é fundamental para garantir ativações consistentes de Windows e Office. Registros SRV vlmcs.tcp desatualizados podem atrasar migrações para um novo host KMS ou causar tentativas de ativação contra servidores que já não existem. Este guia apresenta um procedimento completo — do diagnóstico à remoção do registro — para ajudá‑lo a migrar com confiança para KMS moderno e/ou ADBA.

Índice

Por que o registro `vlmcs.tcp` é tão importante?

O Windows procura automaticamente por um serviço KMS anunciando‑se via DNS através do registro SRV vlmcs.tcp.<DOMÍNIO>. Se pelo menos uma entrada apontar para um host inexistente, as seguintes situações podem ocorrer:

Latência de ativação: cada cliente testa todos os alvos retornados antes de desistir.
Erros intermitentes: quando a ordem de resposta muda no cache DNS, algumas máquinas podem falhar.
Auditoria imprecisa: contadores de ativação no Volume Activation Management Tool (VAMT) não refletem o parque real.

Visão geral do problema observado em campo

Em muitos ambientes é comum encontrar este quadro:

O host KMS histórico foi desativado sem remoção do SRV.
Servidores/estações continuam mostrando “Windows is activated (VOLUMEKMSWS16)” em slmgr /dlv.
Admin levanta a hipótese de as licenças estarem “presas” graças à chave de reserva BackupProductKeyDefault no Registro.

O que realmente acontece

A ativação KMS grava um certificado local com validade de 180 dias. A chave GVLK armazenada no Registro não renova a licença; ela apenas informa ao Software Protection Platform que o canal escolhido é KMS. Portanto:

Se a máquina ficou sem contato com o KMS por até 179 dias, ela segue “genuína”.
No 180.º dia, o serviço de licenciamento entra em grace period de 30 dias antes de exibir banners e degrade de funcionalidade.
Se um novo host válido responder dentro desse intervalo, a ativação renova por mais 180 dias.

É seguro remover o registro DNS antigo?

Sim. Excluir um registro SRV vlmcs.tcp que aponta para um host inexistente não afeta ativações já concluídas. A licença persiste localmente até expirar. Você apenas impede que novos dispositivos percam tempo tentando um endereço morto.

Boas práticas antes da remoção

Faça backup da zona DNS (export / snapshot).
Execute nslookup -type=all vlmcs.tcp.<domínio> para documentar o estado atual.
Valide que o host legado está de fato desligado e não será religado.
Comunique a mudança para a equipe de suporte e descreva plano de volta (restaurar snapshot).

Tabela de impacto em diferentes canais de ativação

Canal do cliente	Comportamento após exclusão do SRV obsoleto	Ação indicada
MAK	Independe de KMS/AD. Permanece ativo até atingir o contador on‑line da Microsoft.	Sem intervenção. Manter MAK para máquinas que ficam fora da rede corporativa por longos períodos.
KMS herdado	Clientes mantêm a licença até 180 dias após último contato. Buscarão novo SRV automaticamente.	Implantar novo host KMS com mesmo nome DNS ou usar GPO/Script (`slmgr /skms`) para agilizar.
ADBA	Necessita logon no AD a cada 180 dias. Sem AD ≠ sem renovação.	Garantir VPN ou oferecer chave MAK de contingência para notebooks remotos.

Checklist de migração para um novo host KMS/ADBA

Planejamento
- Decida se usará apenas ADBA, apenas KMS ou modelo híbrido.
- Levante chaves GVLK adequadas (2019/2022, Office, Visio).
- Reserve nome DNS (ex.: kms.contoso.internal) e IP fixo.
Provisionamento do servidor
- Instale a função “Serviços de Ativação por Volume”.
- Adicione chave host KMS recebida pelo Volume Licensing Service Center.
- Permita porta 1688/TCP no firewall.
Configuração ADBA (opcional)
- No mesmo assistente selecione “Ativação Baseada em Active Directory”.
- Importe a chave Genérica de Ativação AD (GADA).
- A partir daqui, qualquer objeto de computador ingressado no domínio com GVLK é ativado no próximo Group Policy refresh.
Limpeza de registros antigos
- Abra DNS Manager › Forward Lookup Zones.
- Navegue em tcp › vlmcs; exclua entradas inválidas.
- Automatizar com dnscmd <DC> /recorddelete <domínio> vlmcs tcp SRV /f.
Redistribuição do ponto de serviço
- Se mantiver DNS SRV, adicione o novo servidor e garanta prioridade & peso corretos.
- Opcionalmente, aplique política de computador: Computer Configuration › Administrative Templates › Windows Components › Software Protection Platform › Specify KMS host name.
Validação
- Em clientes de teste, execute: slmgr /ato slmgr /dli
- Confirme contagem “Remaining Windows rearm 0” e data de expiração 180 dias à frente.
- No host KMS novo rode slmgr /dli para conferir o contador de clientes requeridos (25 estações ou 5 servidores).

Fluxograma de renovação de licença

O diagrama lógico ajuda a antecipar problemas antes que ocorram:

Boot/Logon
 └─► Revalidação necessária? (180 dias passados)
      ├─► Não → S/O continua genuíno
      └─► Sim
            ├─► SRV _vlmcs resolve?
            │     ├─► Sim → Falar 1688/TCP → Sucesso → Zerar contador
            │     └─► Não
            │           ├─► Máquina no domínio + ADBA habilitado → Logon ao DC → Sucesso
            │           └─► Falha
            └─► Inicia 30 dias de tolerância
                    ├─► Ativação obtida? → Retorna ao início
                    └─► Modo funcionalidade reduzida + Notificações

Dúvidas frequentes

Posso editar o registro BackupProductKeyDefault para forçar reativação? Não. Esse valor serve apenas de referência. A maneira correta é aplicar a chave apropriada via slmgr /ipk ou política de GPO e depois acionar slmgr /ato. Quantas vezes posso rearmar um cliente MAK antes de precisar de suporte Microsoft? Cada MAK dispõe de um contador de ativações vinculado ao contrato de licenciamento. A quantidade exata é exibida no VLSC. Quando esgotado, é preciso abrir chamado para aumento de limite. O que muda se eu hospedar o KMS na nuvem (Azure VM)? É totalmente suportado desde que a VM permaneça “ligada” para atender clientes. Configure Site‑to‑Site VPN ou peering de rede para que os segmentos on‑premises acessem a porta 1688.

Monitoramento contínuo

Use estas ferramentas para garantir que tudo permaneça saudável:

VAMT 3.2 — consolida estatísticas de licenciamento e permite reports em CSV.
Event Viewer — Application › SoftwareProtectionPlatform; filtre Event IDs 12290 (sucesso) e 12288 (falha).
Performance Monitor — contador “KMS Licensing Cache→ Requests per sec” ajuda a dimensionar CPU da VM.
Alertas de 150 dias — configure script PowerShell para rodar Get-WmiObject -Query "SELECT Remain... e gerar ticket antes do grace period.

Melhores práticas de segurança

Restrinja ACL no registro SRV; apenas DNSAdmins podem editar.
Use certificado TLS (HTTPS) para acesso remoto ao servidor KMS (RDP sobre Gateway).
Rotacione senhas do serviço via LAPS ou Managed Service Accounts.
Audite alterações na OU “Activation Objects” criada pelo ADBA com Advanced Audit Policy Configuration › Directory Service Changes.

Considerações para notebooks fora do escritório

Equipamentos que viajam com frequência correm maior risco de ultrapassar 180 + 30 dias. Para evitar chamados:

Habilitar VPN “sempre conectada” com split‑tunneling específico para o DC ou host KMS.
Distribuir script de autocorreção (if (Get-Date) -gt $expiry) { slmgr /ato }) via Intune.
Manter uma chave MAK de contingência (não divulgada publicamente) documentada em cofre de senhas.

Conclusão

Remover registros vlmcs.tcp órfãos limpa latência de DNS, evita tentativas contra servidores mortos e abre caminho para adoção de ADBA ou KMS atualizados em Windows Server 2019/2022. Siga o checklist, confirme que pelo menos 25 clientes estão relatando, monitore os contadores e garanta que dispositivos portáteis tenham um caminho seguro (VPN ou MAK) para renovar suas licenças. Dessa forma, a transição ocorre sem alertas de ativação inesperados e sem impacto no usuário final.

Boa migração!