Ativação do Windows: ADBA × KMS para Windows 11 e Server 2022 [Guia definitivo]

Guia prático e direto ao ponto para ativar Windows 11 e Windows Server 2022 por licenciamento por volume em ambientes com dois domínios, combinando ADBA, KMS e MAK sem dor de cabeça.

Índice

Visão geral do cenário

O ambiente a ser atendido possui:

Dois domínios (possivelmente na mesma floresta ou em florestas distintas).
23 servidores Windows Server 2022 ingressados em domínio.
8 estações Windows 11 ingressadas em domínio.
8 estações Windows 11 em workgroup (fora do AD).
Objetivo: ativar todos os sistemas por licenciamento por volume, com governança e baixa manutenção.

Como escolher entre ADBA, KMS e MAK

As três tecnologias se complementam. A tabela a seguir resume requisitos, alcance e detalhes que costumam gerar dúvidas.

Método	Requisitos de contagem	Abrangência	Observações‑chave
ADBA (Active Directory‑Based Activation)	Sem limite mínimo	Apenas membros do domínio na mesma floresta do AD	Exige instalar Volume Activation Services em um servidor (normalmente um DC) e *inserir no AD uma KMS Host Key* (CSVLK)*, criando o objeto de ativação. Os clientes usam as GVLKs padrão e se ativam automaticamente. Não atende workgroup*.
KMS (Key Management Service)	5 ativações únicas de servidor e 25 ativações únicas de cliente Windows (contagens separadas)	Qualquer máquina que resolva o SRV `vlmcs.tcp` ou tenha o host KMS configurado manualmente	Pode coexistir com ADBA. Necessita porta 1688/TCP liberada e (idealmente) publicação automática do registro DNS. Útil para máquinas fora do domínio se a contagem de 25 clientes for atingida. Os 23 servidores já atendem ao limite de 5.
MAK (Multiple Activation Key)	Sem contagem mínima	Ativa máquina a máquina com a Microsoft	Excelente para exceções (workgroup, laboratórios, viagem prolongada, DMZ sem acesso a KMS). Requer controle de consumo de ativações.

Nota importante sobre chaves:

GVLK (Generic Volume License Key) é a chave cliente e já vem nos produtos de volume. É usada em ADBA e KMS no lado do cliente.
CSVLK (também chamada de KMS Host Key) é a chave que você instala no AD (para ADBA) ou no host KMS.

Sobre Office em volume: quando ativado via KMS, o limite mínimo é 5 clientes Office (não 25). Em ADBA, segue a mesma lógica: membros de domínio na floresta, sem contagem mínima. O script de ativação é o ospp.vbs.

Arquitetura recomendada para o ambiente

Com base nos números fornecidos, estas são as opções que melhor equilibram simplicidade, confiabilidade e governança:

Plano base recomendado

ADBA para todos os membros de domínio: ativa automaticamente 23 servidores e 8 estações em domínio, sem dependência de contagem.
MAK para as 8 estações em workgroup: solução imediata, simples e sob controle de inventário de ativações.
KMS opcional: mantenha preparado apenas se houver perspectiva real de chegar a ≥ 25 clientes Windows fora do domínio no curto/médio prazo, ou se desejar centralizar a ativação de Office e de servidores por KMS.

Alternativa híbrida

Se a equipa desejar monitorização granular de ativações de Windows Server via contadores do host KMS, é viável:

Usar KMS para servidores (já há 23, acima do limiar 5) e manter ADBA para estações em domínio.
Workgroup permanece com MAK até que o parque atinja 25 clientes Windows elegíveis para KMS.

Matriz de decisão por grupo

Grupo	Método preferencial	Justificativa	Resultado
Servidores Windows Server 2022 (23, domínio)	ADBA (ou KMS se desejar métrica centralizada)	Sem contagem mínima no ADBA; no KMS já cumpre ≥ 5	Ativação automática e resiliente (ADBA) ou centralizada (KMS)
Estações Windows 11 (8, domínio)	ADBA	Sem contagem; experiência zero‑touch	Ativação silenciosa logo após logon/ingresso
Estações Windows 11 (8, workgroup)	MAK	Não pertencem ao AD; parque não alcança contagem 25 para KMS	Ativação direta, rastreável por inventário

Passo a passo de implementação

Preparação

Confirme as CSVLKs disponíveis (Windows Server, Windows Client e Office, se aplicável).
Verifique sincronização de tempo (NTP) e resolução DNS.
Defina quem pode executar o Volume Activation Tools (credenciais com permissão no AD).
Decida se os dois domínios estão na mesma floresta (uma única ADBA por floresta) ou em florestas distintas (crie uma ADBA em cada).

Configurar ADBA na floresta

No servidor escolhido (preferencialmente um Controlador de Domínio), instale a função: Install-WindowsFeature -Name VolumeActivation -IncludeManagementTools
Abra o Volume Activation Tools e selecione Active Directory-Based Activation.
Insira a CSVLK correspondente (por exemplo, Windows Server ou Windows Client, conforme o que pretende ativar pela ADBA) e conclua a ativação online ou por telefone.
O assistente criará o Objeto de Ativação no AD (replicado por toda a floresta). Não é necessário manter a função instalada em todos os DCs; o que importa é o objeto no AD.
Nas máquinas cliente já em domínio (Windows 11 e Server 2022), a ativação ocorre automatizada durante a avaliação do serviço de licenciamento (Software Protection Platform).

Validação rápida da ADBA

slmgr /ato
slmgr /dlv

O /dlv apresenta o canal de licenciamento (deve indicar ADBA quando bem‑sucedido) e dados da licença.

Configurar KMS (opcional, se optar por híbrido ou precisar para Office)

Instale a função Volume Activation Services num servidor estável (pode ser membro de domínio).
No Volume Activation Tools, escolha Key Management Service (KMS) e insira a CSVLK apropriada.
Garanta que o DNS publique o registro vlmcs.tcp apontando para o host KMS, e que a porta 1688/TCP esteja liberada entre clientes e KMS.
Caso não deseje publicação automática, defina o host nos clientes via GPO ou manualmente: slmgr /skms kms.seu‑dominio.tld:1688 slmgr /ato

Verificação de descoberta DNS

nslookup -type=srv vlmcs.tcp.seu-dominio.tld

Confirme a presença do registro SRV e o alvo correto do host KMS.

Ativar estações em workgroup

Para as oito máquinas fora do AD, use MAK ou, se houver KMS e pretenda usá‑lo, aponte explicitamente o host.

MAK (recomendado neste cenário): slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX slmgr /ato Substitua pela MAK correta da edição instalada.
KMS (se implementar KMS e optar por usá‑lo com clientes): slmgr /ipk <GVLK-da-edição-Windows-11> slmgr /skms kms.seu‑dominio.tld slmgr /ato

Políticas de GPO úteis

Para padronizar o comportamento em membros de domínio:

Software Protection Platform → Set the KMS server name e Set the KMS port (somente se optar por KMS).
Definir Startup Script com validações leves (slmgr /ato) em imagens recém‑implantadas.
Bloquear uso inadvertido de chaves indevidas (ex.: impedir instalação de chaves Retail em parque de volume).

Validação e auditoria

No host KMS: slmgr /dli slmgr /dlv Estes comandos mostram o total de ativações únicas alcançadas por família de produto.
Nos clientes: slmgr /xpr slmgr /dlv /xpr revela se a licença é permanente (ADBA/KMS) ou se há prazo de expiração.
Eventos: Event Viewer → Applications and Services Logs → Key Management Service (no host KMS) e Application → Software Protection Platform (nos clientes).

Operação, segurança e manutenção

Segurança e rede

Restrinja a porta 1688/TCP no firewall do KMS para sub‑redes autorizadas: netsh advfirewall firewall add rule name="KMS 1688" dir=in action=allow protocol=TCP localport=1688 remoteip=10.0.0.0/8,192.168.0.0/16
Não exponha o host KMS à Internet. Use VPN ou ExpressRoute/S2S para redes remotas.
Em ADBA, proteja o acesso administrativo que permite criar/alterar o Activation Object e as chaves armazenadas.

Continuidade e recuperação

O objeto de ADBA é replicado na floresta. A perda do servidor onde o assistente foi executado não impacta a ativação já publicada.
Documente as CSVLKs e o fluxo para recriar a ADBA/KMS se necessário.
Mantenha imagens douradas (golden images) sem chaves Retail gravadas e com GVLK da edição correta.

Automação com PowerShell

Exemplo simplificado para verificar rapidamente o estado de ativação em múltiplos computadores em domínio:

$computers = @("PC01","PC02","SRV01","SRV02")
Invoke-Command -ComputerName $computers -ScriptBlock {
    $lic = cscript.exe /Nologo $env:SystemRoot\System32\slmgr.vbs /dlv
    $channel = ($lic | Select-String -Pattern "Description|License Status|KMS|AD Activation").Line
    Write-Host "$env:COMPUTERNAME`n$channel`n---`n"
}

Office em volume

Se o Microsoft Office (Volume) fizer parte do parque, considere:

KMS: limiar de 5 clientes. No cliente: cscript "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /sethst:kms.seu‑dominio.tld cscript "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /act
ADBA: similar ao Windows, os clientes em domínio ativam sem contagem mínima após publicar a CSVLK de Office via Volume Activation Tools.
MAK: para workgroup ou uso fora de rede corporativa.

Resolução de problemas

Erros comuns e como contornar

Sintoma	Causa provável	Correção
Falha com código indicando incapacidade de contatar KMS	DNS SRV ausente, porta 1688 bloqueada, host incorreto	Valide `vlmcs.tcp`, libere 1688/TCP, ajuste `slmgr /skms`
Cliente em domínio não ativa por ADBA	Máquina não localiza o objeto de ativação, GVLK incorreta, problema de confiança	Verifique ingresso no domínio, `slmgr /dlv` para canal, reinstale GVLK correta, confirme replicação do AD
Workstation em workgroup não ativa	KMS não alcançado ou contagem mínima não cumprida	Use MAK ou aponte explicitamente para KMS (se já houver ≥ 25 clientes Windows)
KMS ativa servidores mas não clientes Windows	Limiar de clientes Windows (25) não atingido	Inclua mais clientes Windows no KMS ou opte por ADBA/MAK
Office não ativa no KMS	Contagem de 5 não atingida ou host não definido	Configurar `ospp.vbs` para apontar ao KMS e garantir ≥ 5 clientes

Comandos úteis do slmgr

slmgr /ipk <CHAVE>     :: instala uma chave (GVLK/MAK/CSVLK conforme o contexto)
slmgr /ato              :: tenta ativar imediatamente
slmgr /dlv              :: detalhes da licença e do canal (ADBA/KMS/MAK)
slmgr /dli              :: resumo da licença
slmgr /xpr              :: status de expiração
slmgr /skms host:porta  :: define o host KMS
slmgr /ckms             :: remove host KMS configurado
slmgr /rearm            :: redefine período de avaliação (uso criterioso)

Boas práticas que evitam dores futuras

Mantenha simples: ADBA para tudo que for de domínio; MAK para o que ficar fora. Traga KMS apenas quando houver motivação clara (ex.: parque grande de clientes fora do AD, Office via KMS, métricas centralizadas).
Padronize imagens com GVLK correta e scripts de validação (slmgr /ato no final do processo de implantação).
Documente chaves (CSVLK/MAK) e o procedimento para reimplantar ADBA/KMS em DR.
Audite periodicamente com inventário (CMID, canal, última ativação) e alerte desvios (ex.: chave Retail).
Evite instalar a função de ADBA em todos os DCs sem necessidade: basta criar o objeto uma vez por floresta; ele se replica. A redundância está no próprio AD.

Aplicando ao seu cenário, de ponta a ponta

Na(s) floresta(s): publique ADBA com a CSVLK adequada (Windows Server e/ou Windows Client).
Domínio:
- Servidores 2022 e estações 11 em domínio: ativarão via ADBA automaticamente.
- Opcional: se preferir KMS para servidores, configure KMS e aponte apenas os servidores para ele via GPO.
Workgroup:
- Ative por MAK (prático e imediato) ou aponte para KMS caso a organização já tenha atingido a contagem mínima de 25 clientes Windows.
Office (se houver):
- Escolha ADBA ou KMS; lembre do limiar 5 no KMS. Workgroup: MAK.
Valide: slmgr /dlv em amostras, DNS SRV, logs de KMS e relatórios de inventário.

Perguntas rápidas

ADBA e KMS conflitam? Não. Cada um usa chaves e mecanismos diferentes. O que determina é o canal que o cliente escolhe (por descoberta ou configuração).
Posso ativar máquinas de uma floresta A por ADBA publicado na floresta B? Não. ADBA é por floresta. Use KMS entre florestas (via DNS/roteamento) ou publique ADBA em cada uma.
Preciso manter a função instalada após criar a ADBA? Não. Após criar o objeto no AD, pode remover a função. O objeto permanece replicado.
E se a máquina ficar offline muito tempo? KMS exige contato periódico (por padrão, a renovação ocorre a cada 7 dias). ADBA é resiliente a desconexões típicas; MAK é definitivo por máquina.

Resumo executivo

ADBA cobre com folga todos os dispositivos em domínio, com menor esforço operacional.
KMS é útil para workgroup apenas quando houver massa crítica de ≥ 25 clientes Windows ou para padronizar ativação de Office e servidores, podendo coexistir com ADBA.
MAK permanece a alternativa simples e imediata para quantidades pequenas, máquinas isoladas ou cenários fora de rede corporativa.

Com estas diretrizes, a ativação por volume torna‑se previsível, auditável e resistente a mudanças de topologia, sem surpresas com contagens mínimas.