Licenciamento Windows Server e CALs: Guia Sem Complicacao

Por que o licenciamento Windows Server confunde tanta gente

O Windows Server é um dos produtos mais utilizados em infraestrutura corporativa no Brasil, e também um dos mais mal licenciados. A razão é simples: desde a versão 2016, a Microsoft abandonou o modelo baseado em processadores e adotou o licenciamento por núcleos físicos (cores), combinado com a exigência separada de CALs (Client Access Licenses). São duas camadas de licença independentes que precisam existir simultaneamente — e é justamente aí que a maioria das empresas erra.

Na prática, ter uma licença do sistema operacional instalada no servidor não autoriza ninguém a usá-lo. A licença de core cobre o direito de rodar o Windows Server naquele hardware específico. As CALs cobrem o direito de cada pessoa ou cada dispositivo acessar aquele servidor. Sem as duas partes, a empresa está tecnicamente irregular — mesmo que o servidor esteja ativado, atualizado e funcionando perfeitamente há anos. O Windows não bloqueia acessos por falta de CAL: a conformidade é contratual, não técnica.

Essa característica é o que torna o tema perigoso. Diferente de um software que simplesmente para de funcionar quando a licença expira, o Windows Server continua rodando normalmente em situação irregular. A empresa só descobre o problema quando recebe uma notificação de auditoria da Microsoft ou de uma entidade como a BSA (The Software Alliance) — e nesse momento a conta já acumulou anos de uso não licenciado, com multas e valores retroativos.

Licenciamento por core: como calcular corretamente

O modelo atual, válido para Windows Server 2016, 2019, 2022 e 2025, exige licenciar todos os núcleos físicos de todos os processadores do servidor. Não importa quantos núcleos você realmente usa ou quantas máquinas virtuais estão ligadas: o cálculo é sobre o hardware físico completo.

As regras mínimas obrigatórias são:

• Mínimo de 8 núcleos licenciados por processador físico — mesmo que o processador tenha apenas 4 núcleos.
• Mínimo de 16 núcleos licenciados por servidor — mesmo em servidores de socket único.
• As licenças são vendidas em pacotes de 2 núcleos (2-core packs) ou pacotes de 16 núcleos.
• Todos os núcleos físicos de todos os sockets populados precisam estar cobertos.

Um exemplo concreto: um servidor com 2 processadores de 12 núcleos cada totaliza 24 núcleos físicos. Como cada processador excede o mínimo de 8, e o total excede o mínimo de 16, você precisa licenciar exatamente 24 núcleos — ou seja, 12 pacotes de 2 núcleos. Já um servidor com 1 processador de 6 núcleos exige o mínimo de 16 núcleos licenciados, mesmo tendo apenas 6 fisicamente.

A escolha entre as edições Standard e Datacenter depende da densidade de virtualização. A edição Standard permite executar até 2 máquinas virtuais Windows Server por conjunto de licenças aplicado ao servidor. Se você precisa de 4 VMs, licencia o servidor duas vezes (stacking). A edição Datacenter permite VMs ilimitadas no mesmo hardware. O ponto de equilíbrio financeiro geralmente aparece entre 10 e 14 VMs por host — acima disso, Datacenter costuma sair mais barato, além de incluir recursos como Storage Spaces Direct, Storage Replica e Software Defined Networking.

CALs: usuário ou dispositivo, e quando cada uma faz sentido

A CAL é a licença de acesso. Ela não é instalada em lugar nenhum e não gera nenhum registro automático — é um documento de direito de uso que a empresa precisa comprovar em caso de auditoria. Existem dois tipos, e escolher o errado significa pagar mais do que o necessário.

User CAL (por usuário): licencia uma pessoa específica para acessar os servidores a partir de quantos dispositivos quiser — notebook corporativo, desktop, celular, tablet, casa e escritório. É a escolha certa quando o número de pessoas é menor que o número de dispositivos, ou quando há mobilidade e trabalho híbrido.

Device CAL (por dispositivo): licencia um equipamento específico, que pode ser usado por quantas pessoas quiser. É a escolha certa em cenários de turno — chão de fábrica, call center, PDV de varejo, hospitais — onde três operadores diferentes usam o mesmo terminal ao longo do dia.

Regra prática: conte usuários e conte dispositivos. Se você tem 80 funcionários usando 120 equipamentos, compre 80 User CALs. Se tem 200 funcionários em turnos usando 60 terminais, compre 60 Device CALs. A diferença pode facilmente representar dezenas de milhares de reais.

É possível misturar os dois tipos no mesmo ambiente, desde que cada acesso esteja coberto por uma das duas formas. Também é importante lembrar que existem CALs adicionais para serviços específicos, cobradas separadamente da CAL base do Windows Server:

• RDS CAL — obrigatória para qualquer acesso via Remote Desktop Services / Terminal Server além das 2 conexões administrativas.
• SQL Server CAL — licenciamento independente, com modelo próprio de Server+CAL ou por core.
• Exchange, SharePoint e outros — cada produto de servidor tem sua própria família de CALs.

Um erro clássico: a empresa compra Windows Server + CALs corretamente, publica aplicações via RDP para 30 usuários e esquece completamente das 30 RDS CALs. Esse é um dos achados mais comuns em auditoria, porque o servidor de licenças RDS registra os acessos e a evidência fica documentada nos próprios logs da empresa.

Como funciona uma auditoria Microsoft na prática

Auditorias podem chegar por três caminhos: uma solicitação formal de SAM (Software Asset Management) enviada pela própria Microsoft, uma notificação da BSA — frequentemente originada por denúncia anônima de ex-funcionário — ou uma revisão contratual durante renovação de Enterprise Agreement. O contrato de licença que a empresa aceitou ao instalar o produto já prevê o direito de auditoria, então não há como simplesmente recusar.

O processo típico envolve a execução de ferramentas de inventário no ambiente, coleta de dados do Active Directory, análise de logs de acesso e conciliação contra as notas fiscais e comprovantes de licença apresentados pela empresa. A carga da prova é sempre do cliente: se a empresa não consegue apresentar o documento de compra, a licença é considerada inexistente, mesmo que o produto esteja lá há dez anos.

As consequências de irregularidade incluem a regularização retroativa pelo preço de tabela cheio (sem descontos de volume), multas contratuais e, em casos de pirataria caracterizada, ação judicial por violação de direito autoral com base na Lei 9.610/98 e na Lei 9.609/98. Além do custo direto, há o impacto operacional: auditorias consomem semanas de trabalho da equipe de TI e travam projetos.

Os pontos que mais geram autuação na prática:

1. Licenças OEM migradas para outro hardware — a licença OEM morre com o servidor original.
2. Downgrade rights usados sem o direito contratual correspondente.
3. VMs criadas em quantidade acima do permitido pela edição Standard.
4. Migração para cloud sem Software Assurance e sem License Mobility.
5. Servidores de teste, homologação e DR não licenciados.
6. Ausência total de controle de CALs — o achado mais frequente de todos.

Boas práticas para manter compliance contínuo

Compliance de licenciamento não é um projeto pontual, é um processo. A abordagem que funciona começa por um inventário confiável e termina em uma rotina de revisão periódica atrelada aos ciclos de compra e de mudança de infraestrutura.

O primeiro passo é montar e manter um repositório central com todas as evidências: notas fiscais, chaves de produto, contratos Open/CSP/EA, comprovantes de Software Assurance e o mapeamento de qual licença cobre qual servidor. Esse repositório precisa sobreviver a trocas de fornecedor e de equipe — muita empresa perde a comprovação simplesmente porque o gestor de TI anterior guardava tudo no e-mail pessoal.

Em seguida, mantenha o inventário técnico atualizado: hosts físicos, número de sockets e núcleos por host, edição instalada, quantidade de VMs por host, contagem de usuários ativos no Active Directory e contagem de dispositivos. Recomendamos revisar essa base a cada trimestre e obrigatoriamente antes de qualquer projeto de virtualização, migração para cloud ou renovação contratual.

Outras práticas que reduzem risco significativamente:

• Desativar contas de usuários desligados imediatamente — contas ativas contam como acessos potenciais.
• Avaliar Software Assurance quando há planos de cloud, pois License Mobility depende dela.
• Considerar o Azure Hybrid Benefit para reaproveitar licenças on-premise em nuvem.
• Documentar ambientes de teste e DR, que também exigem licenciamento salvo exceções contratuais específicas.
• Fazer uma auditoria interna anual, simulando o que a Microsoft pediria.

Como a Duk ajuda sua empresa a ficar em conformidade

Licenciamento Microsoft é uma disciplina que combina conhecimento contratual, entendimento profundo de infraestrutura e leitura correta dos termos de produto — que mudam a cada versão. É comum encontrarmos empresas pagando por licenças que não precisam ao mesmo tempo em que estão descobertas em pontos críticos, porque a compra foi feita sem análise técnica do ambiente real.

Com mais de 18 anos de mercado, 550+ empresas atendidas e condição de Microsoft Gold Partner, a Duk Informática & Cloud atua nos dois lados dessa equação: reduzir custo desnecessário e eliminar exposição a auditoria. Nosso trabalho começa por um levantamento completo do parque — hosts, núcleos, edições, VMs, usuários e dispositivos — seguido da conciliação contra as licenças que a empresa efetivamente possui e documenta.

A partir desse diagnóstico, montamos o plano de regularização com o modelo de licenciamento mais adequado ao seu cenário: escolha entre Standard e Datacenter conforme densidade de virtualização, definição entre User CAL e Device CAL conforme perfil de uso, avaliação de Software Assurance e Azure Hybrid Benefit quando há estratégia de nuvem, e organização do repositório de evidências. Se você não sabe responder com segurança quantas CALs sua empresa possui hoje e onde está o comprovante, esse é exatamente o momento de conversar com a gente.