Eduardo Popovici

Ollama com Windows Server 2025 Server Core em uma IaaS no Azure, será que compensa?

2026-10-28T11:34:29.542-03:00

Área de tecnologia principal: Azure | IA
Áreas de tecnologia adicionais: Windows Server Core
Dados do autor: https://linktr.ee/edupopov

1. Chatbot no Azure IaaS — Windows Server 2025 Core + Ollama

Importante: Todas as figuras deste artigo foram criadas com o Microsoft M365 Copilot utilizando o motor GPT 6.0. A licença de testes foi cedida pelo time da Atual-IT.

Sair de um ambiente totalmente onpremise para um ambiente Cloud tem suas vantagens e seus desafios, contudo, se você optar pelo formato de lift and shift (do jeito que está vai), precisa ficar atento ao FinOps.

Este artigo não oferece uma bala de prata. Se você optar por uma infra local, haverão desafios de rede, link, integração e segurança que são diferentes de manter uma estrutura dentro do Azure ou GCP. Cada estratégia exige planejamento, um orçamento para testes (POC) e revisões constantes sob a análise de dados como iterações, custo baseado em SKU e região, etc.

A mudança de formato de operação é interessante porque passamos a combinar a flexibilidade de uma infraestrutura Windows Server administrada pela empresa com os recursos de rede, segurança, backup e escalabilidade do Microsoft Azure (e isso não é barato).

E existe uma vantagem adicional: o Microsoft Entra ID já faz parte da estratégia de autenticação do portal editorial de uma ferramenta de chatbot, portanto podemos manter uma integração de identidade bastante natural.

Minha recomendação seria manter a aplicação de chatbot sem separar os componentes em máquinas virtuais e serviços Azure.

2. O que muda em relação ao servidor local?

A maior vantagem do Azure IaaS: podemos começar com um ambiente pequeno e aumentar a capacidade sem comprar servidores físicos.

A maior desvantagem: uma VM com GPU ligada continuamente pode custar significativamente mais que a inferência via APIs de IA generativa.

A Microsoft disponibiliza imagens oficiais de Windows Server 2025 Datacenter Server Core no Azure Marketplace.

Windows Server Core não possuem interface gráfica e possuem uma superfície de ataquem reduzida e performance aumentada (vale estudar esse formato de instalação).

Arquitetura recomendada para este cenário

São especificações iniciais de planejamento, não dimensionamento validado. A capacidade do servidor de inferência depende principalmente do modelo escolhido, do tamanho do contexto e do número de solicitações simultâneas.

Para reduzir custos no primeiro piloto, podemos concentrar portal, API e indexador na mesma VM, mantendo a IA e os dados isolados. Em produção, separaria ao menos o endpoint público do portal editorial que alimenta a base de conhecimento do chatbot, mesmo que ambos usem um backend compartilhado com permissões distintas.

3. O grande diferencial: escolher uma VM com GPU

No Azure, não precisamos comprar uma placa NVIDIA. Podemos contratar máquinas virtuais que disponibilizam GPUs. Isso não significa que vai ficar "barato".

Duas famílias interessantes para avaliação:

NCasT4_v3 — NVIDIA T4

Família de máquinas com GPU T4, adequada para investigar inferência com modelos compactos. A placa T4 possui 16 GB de memória de GPU.

NVadsA10_v5 — NVIDIA A10

Família com GPU A10, que pode oferecer frações de GPU ou configurações maiores. A memória disponível depende do tamanho contratado.

A NVIDIA lista Windows Server 2025 entre os sistemas convidados suportados nessas famílias. A disponibilidade de cada SKU e da imagem Server Core precisa ser confirmada na região escolhida.

NVIDIA Virtual GPU Software Documentation

Atenção: suporte da NVIDIA ao Windows Server na VM não significa homologação automática do Ollama em Windows Server Core. O Ollama possui distribuição Windows e executável CLI independente, mas o conjunto completo precisa ser testado. Testei em laboratório e funcionou, porém não apliquei carga (uma coisa é funcionar, outra é entrar em produção).

Preparando um piloto

Para um piloto eu começaria com uma GPU de aproximadamente 16 GB de VRAM, caso disponível, e avaliaria modelos quantizados de 7B–8B. A configuração definitiva dependeria da janela de contexto e do desempenho sob carga.

Uma API simples, feita em Python e TypeScript em um laboratório, usando o BitNet está com uma VM de 4 core e 8GBRam sem nenhuma placa de vídeo específica, contudo, deu muito trabalho configurar a interpretação de idioma (PT-BR) e montar as bases de conhecimento.

A API se comportou bem, alocando dados em memória. Aqui o programador precisa saber como usar o hardware da melhor maneira possível e a performance cai. A experiência do usuário conta muito para a tomada de decisões.

4. O que muda na autenticação corporativa?

Praticamente nada para o usuário que alimenta a base de conhecimento.

O usuário continua acessando a URL interna do Content Hub e autenticando-se no Microsoft Entra ID por OIDC, com MFA e regras de acesso corporativas.

A grande vantagem é que podemos combinar:

VPN Site-to-Site ou ExpressRoute para conectividade EMPRESA–Azure.
Application Gateway interno para disponibilizar o portal somente em endereços privados.
Entra ID para autenticar colaboradores.
Grupos corporativos para autorização de repórteres e administradores.
Azure Bastion para administração remota sem liberar RDP à internet.

O Azure Application Gateway suporta balanceadores privados com endereços internos, acessíveis somente a clientes que possuam conectividade à rede virtual.

A área pública teria outro endpoint, protegido por WAF e com acesso somente à API de atendimento.

Um detalhe importante: a VM de inferência não precisa ingressar no domínio Active Directory. Eu preferiria uma conta de serviço local restrita, autenticação entre aplicações e acesso administrativo por mecanismos corporativos autorizados, reduzindo a exposição de credenciais do domínio da empresa (no meu lab ficou como popovici.local).

5. Como ficaria o Content Hub?

O botão Publicar e indexar deverá executar operações reais: salvar a versão, gerar embeddings, atualizar o índice, confirmar a disponibilização e exibir o resultado.

Eu adicionaria somente um controle discreto de status, indicando Salvando, Indexando, Publicado ou Erro. Não haveria uma etapa formal de revisão, conforme definimos, mas manteria controle de permissões, versões e registro de auditoria.

Também manteria uma distinção entre testar conteúdo ainda não publicado e testar a base pública. O chatbot de testes deve indicar claramente qual base está consultando, para não confundir o usuário.

6. O ponto mais importante: custo do Azure IaaS

Aqui a mudança é significativa em relação ao GCP ou Azure com APIs generativas.

No Ollama local ou no BitNet, não pagamos por token processado, o que é uma tremenda vantagem para o pré-processamento antes de encaminhar o conteúdo para qualquer provedor de IA. No Azure IaaS, também não existe cobrança de tokens pelo Ollama ou BitNet, mas pagamos pelo tempo de utilização da máquina virtual.

É aqui que o FinOps deve concentrar esforços reais.

A fórmula de custo mensal será:

Não seria correto atribuir um valor mensal fixo para essa arquitetura sem conhecer a região, o SKU, o horário de funcionamento e as exigências de disponibilidade.

Por exemplo, uma VM GPU ligada 24 horas por dia durante um mês de 30 dias consome aproximadamente 720 horas faturáveis de computação.

Uma VM desalocada deixa de gerar cobrança de computação, mas discos e determinados recursos de rede continuam cobrados.

Um benefício possível para a empresa

O Azure Hybrid Benefit pode reduzir o custo das VMs Windows Server quando a organização possui licenças elegíveis com Software Assurance ativo ou assinaturas qualificadas.

Eu verificaria isso antes da contratação.

Também utilizaria o Azure Pricing Calculator para validar valores oficiais de cada configuração.

7. Comparação final das três arquiteturas

8. Minha recomendação

Vejo aqui três caminhos práticos:

1 - Azure IaaS com Ollama — prova de conceito

Criar o chatbot usando Windows Server 2025 Core, PostgreSQL, API TypeScript e Ollama. Validar se o modelo local entrega respostas de qualidade e latência aceitável.

2 - Azure IaaS com modelos via API — alternativa econômica

Hospedar o Content Hub, banco e orquestrador em VMs menores e chamar um modelo hospedado no Microsoft Foundry. Evita uma GPU dedicada 24 horas por dia, mas possui custo por token.

3 - Azure híbrido de inferência — possível evolução

Utilizar Ollama para respostas simples e um modelo gerenciado para consultas complexas ou períodos de sobrecarga. Isso exige controles de roteamento, orçamento e privacidade dos dados enviados ao serviço.

Eu começaria pelo cenário 1 em homologação, mas avaliaria o cenário 2 para produção. Com os volumes de 10 mil a 70 mil interações mensais que discutimos, um serviço de IA cobrado por consumo pode ser mais econômico do que manter uma GPU Azure dedicada continuamente — especialmente se os atendimentos tiverem picos concentrados durante um período de tempo (em uma black Friday por exemplo).

A vantagem é que podemos manter exatamente o mesmo portal editorial, autenticação Entra ID, banco de conhecimento, tags, indexação e chatbot do blog/site. O backend pode ter uma interface de inferência intercambiável: Ollama, BitNet ou modelo gerenciado. Assim, a infraestrutura de IA pode mudar sem reconstruir o projeto inteiro.

Minha arquitetura preferencial seria, portanto, Windows Server 2025 Core no Azure para o Content Hub e a orquestração, com uma camada de IA substituível e isolada, preservando a segurança e reduzindo o risco de dependência de uma tecnologia específica.

Agradecimento

Gostaria de agradecer à diretoria da ATUAL-IT por ceder uma licença completa do Microsoft M365 Copilot para que eu pudesse criar as figuras deste e dos demais artigos deste blog.

Evento presencial na Casa Nina, em Guarulhos: tecnologia, inovação e inteligência artificial!

2026-10-27T19:55:54.453-03:00

No dia 31 de outubro, estarei em Guarulhos (SP) como palestrante convidado de um evento presencial e gratuito na Casa Nina, um espaço dedicado ao empreendedorismo, à troca de experiências e ao compartilhamento de conhecimento.

É sempre uma satisfação participar de iniciativas que aproximam a tecnologia das pessoas, especialmente em um momento em que a Inteligência Artificial está transformando profundamente a maneira como trabalhamos, aprendemos, desenvolvemos soluções e empreendemos.

Ao longo da minha trajetória profissional, atuando com infraestrutura de TI, computação em nuvem, cibersegurança e Inteligência Artificial, tenho acompanhado de perto como essas tecnologias estão deixando de ser apenas tendências para se tornarem ferramentas reais de transformação.

E é justamente esse conhecimento que gosto de compartilhar em eventos presenciais: experiências práticas, desafios encontrados no mundo corporativo e reflexões sobre as oportunidades que surgem com a evolução tecnológica.

Muito além da teoria: tecnologia aplicada ao mundo real

Quem acompanha meus artigos, palestras e projetos sabe que gosto de explorar a tecnologia de maneira prática.

Seja desenvolvendo agentes de Inteligência Artificial, criando aplicações com ferramentas generativas, trabalhando com soluções Microsoft, Azure e Google Cloud ou explorando modelos locais de IA, acredito que o conhecimento ganha ainda mais valor quando conseguimos demonstrar sua aplicação no cotidiano.

Também acredito que não basta conhecer uma ferramenta. É fundamental compreender seus fundamentos, suas limitações e os impactos que ela pode produzir nas empresas e na sociedade.

A Inteligência Artificial não elimina a importância do conhecimento técnico. Pelo contrário, torna ainda mais necessário saber formular boas perguntas, interpretar resultados e tomar decisões conscientes.

A importância de compartilhar conhecimento

Participar de eventos como esse também representa uma oportunidade de conhecer pessoas, trocar experiências e fortalecer a comunidade de tecnologia e empreendedorismo.

Como profissional de TI, Microsoft MVP e instrutor, acredito que a educação e o compartilhamento de experiências são fundamentais para preparar profissionais para os desafios de um mercado em constante transformação.

Mais do que apresentar tecnologias, meu objetivo é despertar a curiosidade, incentivar o aprendizado contínuo e mostrar que a inovação pode estar muito mais próxima da nossa realidade do que imaginamos.

Nos encontramos em Guarulhos!

Fica aqui meu convite para quem está em Guarulhos e região e deseja participar de um encontro presencial, ampliar sua rede de contatos e compartilhar experiências.

📍 Local: Casa Nina — Guarulhos, São Paulo

📅 Data: 31 de outubro de 2026 (sábado)

🎟️ Participação: Evento gratuito

🎤 Palestrante convidado: Eduardo Popovici

Será um prazer participar desse encontro e contribuir com mais uma oportunidade de aprendizado, conexões e boas conversas.

Nos vemos na Casa Nina!

Eduardo Popovici

Microsoft MVP | Microsoft Certified Trainer | Especialista em Infraestrutura, Cloud, Cibersegurança e Inteligência Artificial

Como foi o evento:

Montamos algumas APIs, do famoso e clássico jogo da velha, a um sistema de gestão de PetShop (Baixe aqui no GitHub). Tentei mostrar mais do que simplesmente digitar prompts e criar figuras.

Agora pequenos empreendedores podem desenvolver suas aplicações customizadas, sem depender de um programador. Também falei da importância do uso responsável e dos desafios da segurança com o VibeCode.

GitHub Copilot, Antigravity, Codex, Cloude Code, Lovable... cada um deles e seu funcionamento básico (devo ressaltar que meu coração vai para o lado do GitHub Copilot).

Evento Tech Week da FATEC de Bauru, falando sobre IA aplicada ao mundo real.

2026-10-20T20:30:24.997-03:00

GitHub Copilot, OpenAI Codex, Google AI Studio e Lovable: ferramentas diferentes, um mesmo objetivo — transformar ideias em soluções reais.

Tive o prazer de participar como palestrante da Tech Week da FATEC de Bauru, um evento dedicado à tecnologia, inovação e compartilhamento de conhecimento.

Durante minha apresentação, tive a oportunidade de conversar com os participantes sobre um dos assuntos que mais têm despertado meu interesse nos últimos anos: a utilização da Inteligência Artificial como ferramenta de apoio à criação de aplicações, automação de tarefas e desenvolvimento de soluções tecnológicas.

Mas, dessa vez, quis ir além dos conceitos teóricos.

Minha proposta foi demonstrar, na prática, como ferramentas de IA generativa podem ajudar a transformar uma ideia em uma aplicação funcional, mesmo quando partimos de uma necessidade cotidiana.

E, para isso, escolhi exemplos que fazem parte da realidade de muitas pessoas: cuidar dos nossos animais de estimação, organizar informações e até criar jogos.

Quando uma ideia se transforma em software

Imagine que você tenha um ou vários animais de estimação e queira organizar melhor a rotina deles.

Controle de vacinas, alimentação, consultas veterinárias, medicamentos, peso, histórico de saúde e despesas são informações que normalmente acabam distribuídas entre anotações, aplicativos diferentes, documentos e mensagens.

Por que não transformar essa necessidade em uma aplicação personalizada?

Durante a palestra, utilizei esse cenário para demonstrar como a Inteligência Artificial pode auxiliar no planejamento, na construção de interfaces e na geração de código.

Exploramos a ideia de criar uma aplicação web capaz de centralizar os principais cuidados com nossos pets, utilizando tecnologias modernas e ferramentas de IA como assistentes de desenvolvimento.

O objetivo não era simplesmente pedir que uma IA criasse uma tela bonita. Era mostrar aos participantes como descrever uma necessidade, organizar requisitos, escolher tecnologias, orientar a geração de código e avaliar o resultado.

Afinal, uma aplicação precisa fazer muito mais do que impressionar visualmente: precisa funcionar!

GitHub Copilot e Codex: a IA como parceira no desenvolvimento

Uma das partes da apresentação foi dedicada ao GitHub Copilot e ao OpenAI Codex.

Essas ferramentas demonstram como a relação entre desenvolvedores e código está passando por uma transformação significativa.

Com o GitHub Copilot, podemos utilizar a Inteligência Artificial para auxiliar na escrita de funções, compreender trechos de código, sugerir melhorias, identificar possíveis problemas e acelerar tarefas repetitivas.

Já o Codex permite explorar fluxos mais abrangentes de desenvolvimento, envolvendo interpretação de requisitos, criação e modificação de arquivos, implementação de funcionalidades e execução de testes, conforme o ambiente e as permissões disponíveis.

Durante a demonstração, destaquei uma questão importante:

A qualidade da solução gerada pela IA está diretamente relacionada à clareza dos requisitos, ao contexto fornecido e à capacidade de validar tecnicamente aquilo que foi produzido.

Não basta escrever "crie um sistema para cuidar dos meus pets".

Precisamos explicar quais dados serão armazenados, como os módulos devem funcionar, quais tecnologias serão utilizadas, como a informação será persistida e o que esperamos da experiência do usuário.

É nesse momento que o conhecimento técnico continua fazendo toda a diferença.

Gemini e Google AI Studio: explorando novas possibilidades

Também apresentei possibilidades utilizando o Gemini por meio do Google AI Studio, ambiente do Google voltado à experimentação e ao desenvolvimento de soluções com modelos de Inteligência Artificial.

O interessante é perceber como podemos utilizar diferentes ferramentas para estudar abordagens, estruturar soluções, produzir exemplos de código e explorar recursos que vão além de um chatbot tradicional.

O Google AI Studio permite experimentar modelos, trabalhar com instruções e testar possibilidades de integração com aplicações.

Essa diversidade de ferramentas foi um dos pontos centrais da palestra: não precisamos enxergar as plataformas de IA como concorrentes que obrigatoriamente exigem uma escolha exclusiva.

Podemos conhecê-las, compreender seus pontos fortes e selecionar a alternativa mais adequada para cada necessidade.

Criando jogos com Lovable

Outro momento interessante da apresentação foi a utilização do Lovable para demonstrar a criação de jogos e experiências interativas.

A proposta era mostrar que a Inteligência Artificial também pode ser uma ferramenta de experimentação, criatividade e aprendizagem.

A partir de descrições em linguagem natural, podemos orientar a construção de interfaces, mecânicas de interação e funcionalidades que ajudam a transformar uma ideia em algo visual e utilizável.

Para quem está começando na programação, esse tipo de experiência pode representar uma excelente porta de entrada.

O estudante consegue visualizar rapidamente o resultado de suas ideias e, a partir disso, passa a fazer perguntas mais interessantes:

Como essa aplicação funciona? Onde os dados estão armazenados? Como os eventos são executados? O que acontece quando o usuário clica em um botão? Como melhorar o desempenho? Como testar e proteger a solução?

E é justamente nesse processo de curiosidade, experimentação e validação que acontece uma parte importante do aprendizado.

A IA não elimina a necessidade de conhecimento técnico

Esse foi um dos conceitos que procurei reforçar durante a palestra.

As ferramentas de IA estão reduzindo o esforço necessário para executar diversas atividades de desenvolvimento, mas isso não significa que arquitetura, programação, segurança, infraestrutura e engenharia de software tenham deixado de ser importantes.

Na realidade, considero que estamos diante de um cenário em que essas competências se tornam ainda mais relevantes.

Uma IA pode gerar uma aplicação com dezenas de arquivos, componentes, bibliotecas e integrações. Entretanto, alguém precisa compreender se aquela arquitetura é adequada, se os dados estão protegidos, se o código é sustentável e se as funcionalidades realmente atendem à necessidade original.

Uma interface visualmente bonita não significa que o software esteja pronto para produção.

Da mesma forma, uma aplicação que funciona em um primeiro teste não está necessariamente preparada para lidar com erros, crescimento, segurança e manutenção.

A Inteligência Artificial pode acelerar a construção de uma solução, mas a responsabilidade pela qualidade da engenharia continua sendo nossa.

O futuro do desenvolvimento também passa pela capacidade de fazer boas perguntas

Um dos aspectos mais interessantes dessa transformação é a importância crescente da comunicação.

Saber formular um problema, dividir uma necessidade em etapas, escrever requisitos objetivos e interpretar os resultados produzidos pela IA está se tornando parte do conjunto de habilidades de um profissional de tecnologia.

Na prática, estamos aprendendo uma nova maneira de trabalhar.

Em vez de concentrar todo o esforço na escrita manual de cada linha de código, podemos dedicar mais tempo ao planejamento, à arquitetura, à validação, à segurança e à experiência de quem utilizará a solução.

Isso não significa abandonar o aprendizado de programação. Muito pelo contrário.

Quanto maior for o conhecimento sobre algoritmos, estruturas de dados, redes, APIs, bancos de dados, sistemas operacionais e segurança, maior será nossa capacidade de orientar e avaliar o trabalho produzido pela IA.

Uma experiência de troca de conhecimento

Participar da Tech Week da FATEC Bauru foi uma excelente oportunidade para compartilhar experiências e demonstrar o potencial dessas tecnologias em situações práticas.

Acredito muito na importância de aproximar estudantes e profissionais das ferramentas que estão transformando o mercado.

Mais do que apresentar produtos, meu objetivo foi incentivar os participantes a experimentar, questionar, construir e aprender.

Se hoje conseguimos transformar uma ideia relacionada aos cuidados com nossos pets em um projeto de aplicação, ou explorar a criação de jogos com apoio de IA, imagine quantas outras necessidades podem ser atendidas com criatividade, conhecimento e boas ferramentas.

Quero deixar meu agradecimento à FATEC Bauru, à organização da Tech Week e a todos os participantes pela oportunidade de compartilhar conhecimento.

Continuo acreditando que a tecnologia se torna ainda mais valiosa quando conseguimos transformá-la em aprendizado e soluções que fazem sentido para as pessoas.

E uma coisa é certa: estamos apenas começando a explorar o potencial da Inteligência Artificial no desenvolvimento de software.

A IA não substitui a necessidade de pensar. Ela amplia nossas possibilidades de construir.

Por trás do console do Hyper-V: compreendendo os processos VMConnect, VMMS e VMWP no Windows Server

2026-10-19T08:00:00.000-03:00

Área de tecnologia principal: Datacenter | Hyper-V
Áreas de tecnologia adicionais: Windows Server
Dados do autor: https://linktr.ee/edupopov

Introdução

A virtualização representa uma das transformações mais significativas da infraestrutura computacional moderna. Sua adoção permitiu que organizações consolidassem servidores físicos, ampliassem a disponibilidade dos serviços e desenvolvessem ambientes operacionais mais flexíveis, escaláveis e administráveis. Entretanto, embora o gerenciamento de máquinas virtuais tenha se tornado uma atividade relativamente comum, os mecanismos responsáveis por seu funcionamento permanecem pouco explorados por muitos profissionais de tecnologia.

No ecossistema Microsoft, o Hyper-V utiliza uma arquitetura de virtualização baseada em hipervisor do tipo 1, na qual diferentes componentes trabalham conjuntamente para administrar recursos computacionais, estabelecer canais de comunicação e assegurar o isolamento entre os sistemas operacionais convidados.

Entre esses componentes, três executáveis merecem atenção especial: vmconnect.exe, vmms.exe e vmwp.exe.

Embora frequentemente associados à operação das máquinas virtuais, esses processos desempenham responsabilidades distintas. Compreender suas funções permite não apenas aprofundar o conhecimento sobre a arquitetura do Hyper-V, mas também aperfeiçoar procedimentos de diagnóstico, administração e segurança.

Neste artigo, analisaremos como esses executáveis interagem, suas relações com o hipervisor e a importância de conhecer os mecanismos internos da virtualização em ambientes Windows Server, incluindo o Windows Server 2025.

1. A arquitetura do Hyper-V e a separação de responsabilidades

O Hyper-V é uma plataforma de virtualização desenvolvida pela Microsoft que utiliza recursos de virtualização assistida por hardware para permitir a execução simultânea de diferentes sistemas operacionais sobre um mesmo equipamento físico.

Diferentemente de soluções de virtualização hospedadas, nas quais o mecanismo responsável pelas máquinas virtuais depende diretamente de um sistema operacional convencional como camada intermediária, o Hyper-V utiliza uma arquitetura baseada em um hipervisor de tipo 1.

O hipervisor é responsável por estabelecer os mecanismos fundamentais de isolamento das partições, virtualização de processadores e gerenciamento das interações entre os ambientes virtualizados e os recursos físicos.

Entretanto, é importante compreender que nem todas as operações são executadas diretamente pelo hipervisor.

Parte significativa das atividades administrativas e de entrada e saída de dados é realizada por componentes existentes na chamada partição raiz, que executa o Windows e abriga a pilha de gerenciamento da virtualização.

Essa arquitetura estabelece diferentes níveis de responsabilidade.

O hipervisor fornece os mecanismos fundamentais de virtualização. A partição raiz disponibiliza serviços de gerenciamento e dispositivos virtuais. As partições filhas executam os sistemas operacionais convidados, conhecidos como guest operating systems.

Essa separação constitui um elemento central para compreender os processos analisados ao longo deste artigo.

2. VMConnect.exe: a interface de acesso ao console virtual

O executável vmconnect.exe, denominado Virtual Machine Connection, é responsável por disponibilizar uma interface de interação com o console das máquinas virtuais hospedadas no Hyper-V.

Seu funcionamento pode ser comparado, sob determinados aspectos, ao acesso físico realizado por um administrador diante do monitor e do teclado de um servidor.

Entretanto, diferentemente de uma conexão convencional de Área de Trabalho Remota, o VMConnect permite acompanhar etapas anteriores ao carregamento completo do sistema operacional convidado.

Isso inclui o processo de inicialização, a apresentação do firmware virtual, mensagens de erro de boot e operações realizadas durante a instalação de sistemas operacionais.

Essa característica torna a ferramenta especialmente relevante quando uma máquina virtual apresenta problemas que inviabilizam sua administração pelos mecanismos tradicionais de rede.

Considere, por exemplo, um servidor virtualizado que perdeu sua configuração de endereço IP após uma alteração incorreta no adaptador de rede.

Nesse cenário, uma tentativa de conexão por RDP poderá falhar, uma vez que depende da disponibilidade dos serviços necessários e de comunicação IP com o destino.

O VMConnect, por outro lado, possibilita o acesso ao console virtual independentemente da existência de um endereço IP funcional dentro da máquina virtual.

Essa diferença é fundamental para procedimentos de recuperação operacional.

2.1 Executando o VMConnect

Em instalações Windows que possuem as ferramentas de gerenciamento do Hyper-V, o executável normalmente está disponível no seguinte diretório:

C:\Windows\System32\vmconnect.exe

Sua execução pode ocorrer diretamente pelo PowerShell:

vmconnect.exe

Também é possível indicar um servidor Hyper-V e uma máquina virtual específica:

vmconnect.exe HV-SRV01 "VM-DC01"

Nesse exemplo, a ferramenta inicia uma conexão com o console da máquina virtual denominada VM-DC01, hospedada no servidor HV-SRV01.

É importante destacar que a comunicação remota com o host exige conectividade, autenticação e permissões apropriadas.

Portanto, quando afirmamos que o VMConnect não depende da rede da máquina virtual, estamos nos referindo à conectividade do sistema operacional convidado. Isso não elimina os requisitos de comunicação entre a estação administrativa e o host Hyper-V.

2.2 Modo básico e modo de sessão aprimorada

O VMConnect possui modalidades de conexão com características diferentes.

No modo básico, a interação ocorre diretamente com o console virtual, permitindo acompanhar o funcionamento da máquina mesmo antes da inicialização completa do sistema operacional.

Já o modo de sessão aprimorada, também denominado Enhanced Session Mode, utiliza recursos do protocolo RDP para proporcionar uma experiência de interação mais completa.

Quando atendidos os requisitos de compatibilidade e configuração, esse modo permite funcionalidades como redimensionamento de tela, compartilhamento da área de transferência, redirecionamento de áudio, impressoras e unidades de armazenamento.

Um detalhe arquitetural relevante é que a sessão aprimorada utiliza mecanismos de comunicação do Hyper-V, incluindo o VMBus, sem exigir uma conexão RDP convencional pela interface de rede da máquina virtual.

Entretanto, essa funcionalidade deve ser analisada também sob a perspectiva da segurança, especialmente quando envolve o compartilhamento de recursos entre o computador administrativo e o sistema operacional convidado.

3. VMMS.exe: o serviço responsável pelo gerenciamento das máquinas virtuais

O segundo componente fundamental é o vmms.exe, associado ao Virtual Machine Management Service.

Enquanto o VMConnect representa uma interface de interação, o VMMS possui responsabilidades administrativas mais abrangentes.

Sua principal função consiste em gerenciar o ciclo de vida das máquinas virtuais hospedadas no servidor.

Isso envolve atividades como inicialização, desligamento, controle de estados operacionais, gerenciamento de configurações e coordenação dos processos utilizados pelas máquinas virtuais.

O VMMS também disponibiliza interfaces de gerenciamento utilizadas por ferramentas administrativas e mecanismos de automação.

Essa característica explica por que determinadas operações do Hyper-V podem ser executadas tanto por interfaces gráficas quanto por comandos PowerShell.

Considere o seguinte comando:

Start-VM -Name "VM-DC01"

Embora a solicitação seja realizada por meio do PowerShell, a operação depende da infraestrutura de gerenciamento do Hyper-V.

De maneira semelhante, o comando:

Stop-VM -Name "VM-DC01"

solicita a alteração do estado operacional da máquina virtual por meio dos componentes de gerenciamento disponíveis no host.

Essa separação entre a ferramenta que solicita uma operação e o serviço responsável por coordená-la é um princípio recorrente em arquiteturas de sistemas.

3.1 Identificando o serviço VMMS

O estado do serviço pode ser verificado pelo PowerShell:

Get-Service -Name vmms

Para obter informações adicionais:

Get-CimInstance Win32_Service -Filter "Name='vmms'" |
Select-Object Name, State, StartMode, ProcessId

O resultado permite identificar o estado do serviço, sua modalidade de inicialização e o identificador do processo correspondente.

Em um ambiente de produção, falhas nesse componente podem prejudicar operações administrativas sobre as máquinas virtuais.

Entretanto, uma distinção importante deve ser observada: a interrupção ou falha do serviço de gerenciamento não significa, necessariamente, que todas as máquinas virtuais em execução sejam imediatamente desligadas.

O plano de gerenciamento e a execução das máquinas virtuais representam responsabilidades relacionadas, mas não inteiramente equivalentes.

Essa compreensão evita interpretações incorretas durante procedimentos de troubleshooting.

4. VMWP.exe: o processo de trabalho das máquinas virtuais

O terceiro executável é o vmwp.exe, denominado Virtual Machine Worker Process.

Esse processo representa uma parte importante da infraestrutura responsável pelo funcionamento individual das máquinas virtuais.

Em condições normais, o Hyper-V utiliza processos de trabalho separados para as máquinas virtuais em execução.

Consequentemente, um servidor que hospeda diferentes VMs poderá apresentar múltiplas instâncias do vmwp.exe.

Cada processo está associado a uma determinada máquina virtual e participa da prestação dos serviços necessários à sua operação, incluindo atividades relacionadas aos dispositivos virtuais e à infraestrutura de execução.

É essencial esclarecer que o vmwp.exe não representa todo o ambiente de execução de uma máquina virtual.

Os processadores virtuais, o isolamento de memória e outros mecanismos fundamentais são implementados por componentes do hipervisor e da pilha de virtualização.

Portanto, interpretar o vmwp.exe como um simples processo que contém integralmente uma máquina virtual seria uma simplificação tecnicamente inadequada.

4.1 Identificando processos VMWP

Em um servidor Hyper-V, podemos utilizar o seguinte comando:

Get-Process -Name vmwp -ErrorAction SilentlyContinue

Para identificar detalhes adicionais:

Get-CimInstance Win32_Process -Filter "Name='vmwp.exe'" |
Select-Object ProcessId, ParentProcessId, CommandLine

A consulta apresenta os identificadores dos processos e as linhas de comando disponibilizadas pelo Windows.

Dependendo da versão e da implementação do Hyper-V, a linha de comando poderá fornecer elementos que auxiliam na associação entre o processo e a máquina virtual.

Para consultar os identificadores das VMs:

Get-VM |
Select-Object Name, Id, State

A associação entre os identificadores das máquinas virtuais e seus respectivos processos de trabalho pode contribuir para análises mais detalhadas, especialmente quando há necessidade de investigar consumo de recursos, falhas ou comportamentos inesperados.

Contudo, os valores de memória e CPU apresentados pelo Windows para o vmwp.exe não devem ser interpretados automaticamente como o consumo total de recursos da máquina virtual correspondente.

A virtualização possui mecanismos próprios de contabilização de recursos, sendo recomendável utilizar também os indicadores disponibilizados pelo Hyper-V e seus contadores de desempenho.

5. Como VMConnect, VMMS e VMWP trabalham em conjunto

A relação entre os três componentes pode ser compreendida por meio de um cenário operacional.

Imagine um servidor Windows Server 2025 com a função Hyper-V instalada, hospedando duas máquinas virtuais.

A primeira executa o Active Directory Domain Services, enquanto a segunda disponibiliza uma aplicação corporativa.

Um administrador, utilizando uma estação de trabalho Windows 11, precisa acessar o console da primeira VM para investigar um problema de inicialização.

A operação começa com a execução do VMConnect, responsável por disponibilizar a interface de interação.

A infraestrutura de gerenciamento do Hyper-V participa da identificação da máquina virtual e da validação das condições necessárias para a conexão.

O VMMS mantém a responsabilidade sobre o gerenciamento das máquinas virtuais e seus estados operacionais.

Por sua vez, o VMWP associado à VM participa dos serviços de execução e da infraestrutura que disponibiliza seus dispositivos virtuais.

O hipervisor e os componentes de virtualização existentes na partição raiz fornecem os mecanismos necessários ao funcionamento das partições e ao acesso aos recursos computacionais.

O resultado é uma experiência na qual o administrador consegue interagir com a máquina virtual como se estivesse utilizando um console local.

Entretanto, essa aparente simplicidade oculta diferentes camadas de comunicação, isolamento e gerenciamento.

Também é importante observar que esse modelo representa uma descrição funcional da arquitetura, e não uma afirmação de que todos os eventos de teclado, vídeo ou dispositivos percorram sequencialmente os três executáveis.

Os caminhos efetivos de comunicação dependem do tipo de operação e dos componentes envolvidos.

6. VMBus: comunicação entre a partição raiz e as máquinas virtuais

Para compreender adequadamente a arquitetura do Hyper-V, também é necessário conhecer o Virtual Machine Bus, ou simplesmente VMBus.

O VMBus representa um mecanismo de comunicação entre as partições que compõem o ambiente virtualizado.

Sua utilização permite que determinados dispositivos e serviços virtuais realizem operações de maneira mais eficiente, reduzindo a necessidade de recorrer exclusivamente à emulação tradicional de hardware.

Essa arquitetura envolve dois componentes relevantes.

O primeiro é denominado Virtualization Service Provider (VSP), normalmente localizado na partição raiz.

O segundo é denominado Virtualization Service Client (VSC), localizado na partição filha.

O VSC solicita serviços relacionados aos dispositivos virtuais, enquanto o VSP disponibiliza os recursos correspondentes na partição raiz.

A comunicação entre esses componentes ocorre por meio do VMBus.

Um exemplo pode ser observado nas operações realizadas por determinados dispositivos sintéticos de armazenamento e rede.

Em vez de reproduzir integralmente o comportamento de um equipamento físico antigo, o Hyper-V utiliza mecanismos de comunicação otimizados para ambientes virtualizados.

Essa abordagem contribui para reduzir a sobrecarga de processamento e melhorar a eficiência operacional.

É importante ressaltar que o VMBus não deve ser confundido com um switch virtual Ethernet ou com uma rede TCP/IP convencional.

Trata-se de um mecanismo específico de comunicação entre partições, com finalidade e características próprias.

7. Segurança: o hipervisor como fronteira de isolamento

A segurança representa um dos aspectos mais relevantes da arquitetura de virtualização.

Em ambientes tradicionais, a separação entre diferentes servidores é estabelecida, em grande parte, por fronteiras físicas.

Na virtualização, múltiplos sistemas operacionais compartilham o mesmo hardware, tornando indispensável a existência de mecanismos capazes de impedir acessos indevidos entre os ambientes.

O hipervisor contribui diretamente para esse isolamento, enquanto a partição raiz abriga componentes privilegiados de gerenciamento e infraestrutura.

Consequentemente, a segurança de uma máquina virtual não depende exclusivamente das configurações aplicadas dentro do sistema operacional convidado.

Ela também está relacionada à integridade e à proteção do host Hyper-V.

Um comprometimento administrativo da partição raiz pode representar riscos significativos às máquinas virtuais hospedadas, mesmo quando elas possuem configurações internas de segurança adequadas.

Da mesma forma, vulnerabilidades presentes em dispositivos virtuais ou componentes da pilha de virtualização podem comprometer as fronteiras de isolamento, dependendo das condições de exploração.

7.1 A importância do controle de acesso ao VMConnect

O acesso ao console de uma máquina virtual deve ser tratado como uma capacidade administrativa relevante.

Isso porque um operador autorizado a interagir com o console pode acompanhar o processo de inicialização e realizar operações diretamente na interface do sistema operacional convidado.

Embora o acesso ao console não signifique, automaticamente, possuir credenciais administrativas dentro da VM, ele pode ampliar as possibilidades de intervenção, especialmente quando combinado com outras permissões.

Por essa razão, a concessão de acesso deve seguir o princípio do menor privilégio.

O Hyper-V disponibiliza mecanismos para conceder permissões específicas de conexão ao console, incluindo o cmdlet Grant-VMConnectAccess.

Um exemplo de utilização seria:

Grant-VMConnectAccess `
    -VMName "VM-DC01" `
    -UserName "CONTOSO\Operador"

O comando concede à identidade especificada a permissão de conexão à máquina virtual.

Essa autorização não deve ser confundida com a atribuição irrestrita de privilégios administrativos sobre todo o host.

Além disso, a autorização de conexão ao console não dispensa as demais exigências de autenticação, conectividade e políticas de acesso aplicáveis ao ambiente.

7.2 A exposição de recursos no modo de sessão aprimorada

O modo de sessão aprimorada proporciona maior conveniência administrativa, mas também amplia as possibilidades de interação entre o computador do operador e a máquina virtual.

Recursos como unidades de armazenamento, área de transferência e dispositivos redirecionados podem estabelecer caminhos de transferência de informações entre ambientes com diferentes níveis de confiança.

Em máquinas virtuais utilizadas para análise de arquivos suspeitos, investigação de incidentes ou execução de software não confiável, esses recursos merecem atenção especial.

Nesses casos, pode ser prudente utilizar o modo básico e restringir o compartilhamento de dispositivos, reduzindo as oportunidades de transferência não intencional de informações.

A configuração deve ser orientada pelo nível de risco e pelos requisitos operacionais de cada ambiente.

8. Diagnóstico e investigação utilizando PowerShell

O PowerShell representa uma ferramenta importante para examinar os componentes internos do Hyper-V.

Em servidores que utilizam Windows Server Core, sua importância é ainda maior, considerando a ausência da experiência gráfica tradicional de gerenciamento local.

Uma estratégia inicial de diagnóstico consiste em verificar o estado do serviço VMMS, identificar os processos VMWP e consultar a situação operacional das máquinas virtuais.

O exemplo a seguir reúne essas informações:

# Verifica o serviço de gerenciamento do Hyper-V
Get-Service -Name vmms

# Lista os processos de trabalho das VMs
Get-CimInstance Win32_Process -Filter "Name='vmwp.exe'" |
    Select-Object ProcessId, CommandLine

# Consulta as máquinas virtuais existentes
Get-VM |
    Select-Object Name, State, Status, Id

# Lista informações de utilização de memória das VMs
Get-VM |
    Select-Object Name, State, MemoryAssigned, MemoryDemand

Os comandos permitem obter uma visão inicial sobre o estado do ambiente.

Entretanto, sua interpretação deve considerar a natureza de cada indicador.

A existência de um processo vmwp.exe não comprova, isoladamente, a integridade completa de uma máquina virtual.

Da mesma maneira, uma VM identificada como Running pode apresentar problemas internos, incluindo falhas de inicialização de serviços, indisponibilidade de aplicações ou dificuldades de comunicação.

Portanto, o diagnóstico deve combinar observações do host e do sistema operacional convidado.

8.1 Eventos relacionados ao Hyper-V

Outra fonte importante de informação é o Visualizador de Eventos do Windows.

O Hyper-V mantém diferentes canais de eventos relacionados aos seus componentes de gerenciamento e execução.

É possível descobrir esses canais com o PowerShell:

Get-WinEvent -ListLog "*Hyper-V*" |
Select-Object LogName, RecordCount, IsEnabled

Para consultar eventos recentes do serviço de gerenciamento, quando o canal estiver disponível:

Get-WinEvent -LogName `
"Microsoft-Windows-Hyper-V-VMMS-Admin" `
-MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, Message

A análise dos eventos permite investigar problemas de inicialização, falhas de configuração e outras condições operacionais registradas pelo Hyper-V.

Em ambientes corporativos, esses registros também podem ser encaminhados a plataformas de observabilidade ou sistemas de gerenciamento de eventos de segurança.

9. Windows Server Core e a administração remota do Hyper-V

O Windows Server Core representa uma alternativa importante para servidores de infraestrutura que não necessitam da experiência gráfica completa do Windows.

Sua proposta consiste em disponibilizar os componentes necessários à execução das funções de servidor com uma superfície de instalação e manutenção mais reduzida.

No contexto do Hyper-V, essa abordagem permite manter o host com uma interface administrativa local mínima, realizando a maior parte das atividades de gerenciamento por ferramentas remotas.

Uma estação Windows 11 com as ferramentas de gerenciamento do Hyper-V instaladas pode ser utilizada para administrar um host Windows Server 2025 Server Core.

Nesse cenário, o VMConnect é executado na estação administrativa, enquanto os serviços e processos de virtualização permanecem no servidor.

Essa separação favorece uma arquitetura na qual o host é dedicado às atividades de virtualização, enquanto as operações administrativas ocorrem por caminhos de acesso controlados.

Entretanto, a adoção do Server Core não elimina a necessidade de proteção das interfaces de gerenciamento, contas privilegiadas e serviços acessíveis remotamente.

A ausência de uma interface gráfica completa reduz determinados componentes da instalação, mas não constitui, isoladamente, uma garantia de segurança.

10. Considerações sobre desempenho e disponibilidade

O conhecimento dos processos internos do Hyper-V também contribui para uma análise mais precisa de desempenho.

Em ambientes com múltiplas máquinas virtuais, o consumo de CPU, memória, armazenamento e rede deve ser interpretado considerando as características do hipervisor e da partição raiz.

Uma utilização elevada de recursos em determinado processo do host pode indicar a necessidade de investigação, mas não deve ser considerada uma evidência conclusiva de falha.

O consumo observado pode estar relacionado à carga operacional, aos mecanismos de virtualização ou a condições específicas dos dispositivos virtuais.

Também é necessário considerar que os recursos atribuídos às máquinas virtuais são administrados por diferentes camadas.

A memória utilizada por uma VM, por exemplo, não corresponde necessariamente à memória privada apresentada pelo Gerenciador de Tarefas para seu respectivo vmwp.exe.

Por essa razão, recomenda-se utilizar os contadores e mecanismos de monitoramento disponibilizados pelo Hyper-V, relacionando essas informações aos indicadores observados dentro das máquinas virtuais.

Essa abordagem reduz o risco de conclusões equivocadas e favorece a identificação das causas efetivas de problemas de desempenho.

11. Boas práticas para ambientes corporativos

A compreensão da arquitetura deve resultar em procedimentos operacionais mais seguros e consistentes.

Em ambientes de produção, algumas medidas são especialmente relevantes:

Segregação administrativa: limitar a quantidade de identidades que possuem privilégios sobre o host Hyper-V, diferenciando-as das contas administrativas utilizadas dentro das máquinas virtuais.
Atualização dos componentes: manter o sistema operacional do host e os sistemas convidados devidamente atualizados, observando as recomendações de compatibilidade e manutenção.
Proteção das conexões administrativas: restringir a exposição das interfaces de gerenciamento e utilizar mecanismos apropriados de autenticação.
Controle de dispositivos redirecionados: avaliar a necessidade de compartilhar área de transferência, unidades e periféricos nas sessões aprimoradas.
Monitoramento operacional: acompanhar eventos, estados das máquinas virtuais e indicadores de desempenho, estabelecendo critérios para investigação de anomalias.
Proteção das cargas virtualizadas: considerar tecnologias adicionais, como máquinas virtuais protegidas, quando os requisitos de confidencialidade e integridade justificarem sua implementação.

Essas medidas devem fazer parte de uma política mais ampla de segurança, envolvendo também proteção de credenciais, armazenamento, redes, recuperação de desastres e governança dos recursos computacionais.

Conclusão

A utilização cotidiana do Hyper-V pode transmitir a impressão de que uma máquina virtual constitui apenas um sistema operacional executado dentro de uma janela administrativa.

Entretanto, sua operação depende de uma arquitetura sofisticada, composta por processos de gerenciamento, mecanismos de comunicação entre partições e serviços de virtualização integrados ao sistema operacional.

O estudo dos executáveis vmconnect.exe, vmms.exe e vmwp.exe demonstra como essas responsabilidades são distribuídas.

O VMConnect oferece a interface de acesso ao console virtual. O VMMS gerencia os estados e as operações administrativas das máquinas virtuais. O VMWP participa dos serviços de execução associados a cada instância virtualizada.

Esses componentes operam em conjunto com o hipervisor, o VMBus e os mecanismos da partição raiz, formando uma infraestrutura que busca conciliar isolamento, eficiência e capacidade de gerenciamento.

Compreender essa organização possui implicações práticas importantes.

Para o administrador de sistemas, significa diagnosticar problemas com maior precisão. Para o arquiteto de infraestrutura, significa reconhecer as dependências e os limites de confiança da plataforma. Para o profissional de segurança, representa a possibilidade de avaliar as superfícies de ataque e estabelecer controles mais adequados.

Em ambientes corporativos, especialmente aqueles que utilizam Windows Server 2025 e administração remota, esse conhecimento contribui para decisões técnicas mais fundamentadas.

Afinal, administrar adequadamente uma infraestrutura virtualizada exige compreender não apenas as máquinas virtuais que são apresentadas pelas ferramentas de gerenciamento, mas também os mecanismos que tornam sua execução possível.

Referências técnicas

MICROSOFT. Arquitetura do Hyper-V. Microsoft Learn. Disponível em: https://learn.microsoft.com/pt-br/windows-server/virtualization/hyper-v/architecture

MICROSOFT. Conexão com Máquina Virtual do Hyper-V. Microsoft Learn. Disponível em: https://learn.microsoft.com/pt-br/windows-server/virtualization/hyper-v/virtual-machine-connection

MICROSOFT. Compartilhar dispositivos com máquinas virtuais Hyper-V. Microsoft Learn. Disponível em: https://learn.microsoft.com/pt-br/windows-server/virtualization/hyper-v/enhanced-session-mode

MICROSOFT. Grant-VMConnectAccess (Hyper-V). Microsoft Learn. Disponível em: https://learn.microsoft.com/en-us/powershell/module/hyper-v/grant-vmconnectaccess?view=windowsserver2025-ps

MICROSOFT. Hyper-V Architecture — Performance Tuning. Microsoft Learn. Disponível em: https://learn.microsoft.com/windows-server/administration/performance-tuning/role/hyper-v-server/architecture

Texto autoral, elaborado a partir de uma análise técnica da arquitetura do Hyper-V, com referências utilizadas para fundamentação e verificação dos conceitos apresentados.

O que consegui criar com BitNet - Projeto Boris - Inteligência Artificial Local, BitNet e RAG: estamos diante de uma nova era da infraestrutura de TI?

2026-10-15T17:45:36.927-03:00

Área de tecnologia principal: Azure | Microsoft Azure
Áreas de tecnologia adicionais: IA
Dados do autor: https://linktr.ee/edupopov

Uma reflexão sobre o impacto da Inteligência Artificial na computação em nuvem, na cibersegurança e no futuro dos profissionais de tecnologia.

Criar uma solução realmente funcional utilizando Inteligência Artificial, especialmente modelos locais como o BitNet, não é uma tarefa tão simples quanto parece. Embora estejamos vivendo um período em que praticamente qualquer pessoa consegue interagir com uma IA generativa, existe uma diferença considerável entre solicitar a criação de algo e compreender tecnicamente aquilo que está sendo construído.

E aqui chegamos a um ponto que considero particularmente interessante: a Inteligência Artificial está transformando profundamente o papel dos profissionais de tecnologia, mas talvez não da maneira como muitos imaginam.

Sejamos francos. Analistas de infraestrutura, desenvolvedores, administradores de sistemas e arquitetos de Cloud que trabalham apenas reproduzindo procedimentos, sem compreender os fundamentos das tecnologias que utilizam, provavelmente enfrentarão dificuldades cada vez maiores para justificar seu papel no mercado.

Não estou afirmando que essas profissões desaparecerão. Pelo contrário. Acredito que profissionais verdadeiramente qualificados se tornarão ainda mais importantes. Entretanto, aqueles que estão apenas turistando pela tecnologia, executando tarefas mecanicamente e sem aprofundamento técnico, encontrarão um cenário bastante desafiador.

Afinal, quando uma ferramenta consegue gerar scripts, desenvolver aplicações, propor arquiteturas de nuvem, configurar serviços e identificar problemas em poucos minutos, qual passa a ser o diferencial do profissional que anteriormente dedicava dias a essas mesmas atividades?

Na minha opinião, a resposta está no conhecimento.

A IA pode construir uma infraestrutura, mas ainda precisamos de alguém que compreenda se aquela infraestrutura deveria ter sido construída daquela maneira.

E essa diferença é gigantesca.

Da infraestrutura tradicional à infraestrutura construída com IA

Vou propor um exercício.

Você já experimentou utilizar o GitHub Copilot, integrado ao seu ambiente de desenvolvimento e às ferramentas apropriadas de administração do Azure, para solicitar a construção de uma arquitetura completa de aplicação web?

Imagine o seguinte cenário: sua empresa precisa disponibilizar um frontend corporativo no Microsoft Azure, com alta disponibilidade, balanceamento de carga, redundância entre duas Zonas de Disponibilidade, monitoramento, políticas de segurança e um processo automatizado de implantação.

Em um modelo tradicional, essa atividade envolveria diversas etapas de planejamento e execução. Seria necessário selecionar os serviços, definir a topologia da rede, preparar a infraestrutura, configurar os recursos de segurança, estabelecer a estratégia de distribuição de tráfego, implementar o monitoramento e testar o comportamento da aplicação diante de possíveis falhas.

Dependendo da complexidade do projeto, esse trabalho poderia consumir vários dias.

Agora imagine descrever os requisitos a um assistente de IA com contexto técnico suficiente:

Desenvolva uma arquitetura para disponibilizar uma aplicação frontend no Microsoft Azure, utilizando duas Zonas de Disponibilidade, balanceamento de carga, políticas de segurança, monitoramento centralizado e implantação automatizada. Gere a infraestrutura como código, documente as dependências e apresente uma estimativa de custos operacionais.

A IA poderá propor a arquitetura, gerar templates Bicep ou Terraform, estruturar scripts, preparar pipelines e produzir documentação inicial.

Com integrações e permissões adequadas, agentes especializados também podem participar das etapas de validação e implantação. A própria Microsoft disponibiliza orientações para utilizar GitHub Copilot na geração de Bicep, comandos de Azure CLI e pipelines de infraestrutura.

Uma atividade que anteriormente exigiria vários dias de trabalho pode, em determinados cenários, ter grande parte de sua implementação inicial concluída em horas ou até minutos.

E aqui existe um detalhe fundamental: gerar rapidamente uma arquitetura não significa que ela esteja pronta para produção.

O profissional ainda precisa validar as permissões, os custos, a disponibilidade regional dos serviços, a resiliência, as políticas de segurança e os requisitos de continuidade de negócio.

A IA acelera a construção. O conhecimento técnico determina a qualidade do resultado.

E o Google Cloud Platform? A lógica é semelhante

O mesmo conceito pode ser aplicado ao Google Cloud Platform (GCP).

Imagine solicitar a criação de uma aplicação web conteinerizada utilizando Cloud Run, com imagens armazenadas no Artifact Registry, controle de acesso por IAM, registros centralizados no Cloud Logging e implantação automatizada por Terraform.

Podemos avançar ainda mais e solicitar uma arquitetura multirregional, com balanceamento global, integração com banco de dados, gerenciamento de segredos e escalabilidade orientada à demanda.

Nesse cenário, uma IA pode auxiliar desde o desenho inicial até a geração dos arquivos de infraestrutura como código.

O Google Cloud também disponibiliza projetos e arquiteturas de referência baseados em Terraform, demonstrando como a infraestrutura pode ser definida de maneira declarativa, reutilizável e alinhada às práticas de segurança.

Observe que não estamos falando simplesmente de pedir para uma IA criar uma máquina virtual.

Estamos falando de transformar uma necessidade de negócio em uma arquitetura técnica, descrevendo requisitos e utilizando modelos generativos para acelerar a implementação.

Naturalmente, isso exige conhecimento para identificar quando utilizar Cloud Run em vez de GKE, quando adotar um balanceador global, como distribuir serviços geograficamente e como estabelecer políticas adequadas de identidade e acesso.

É justamente nesse ponto que o profissional experiente continua fazendo a diferença.

BitNet: quando a Inteligência Artificial deixa de depender exclusivamente dos grandes datacenters

Toda essa evolução me levou a outra reflexão: será que realmente precisamos recorrer a grandes modelos hospedados em datacenters para executar qualquer tarefa que envolva Inteligência Artificial?

Foi a partir dessa pergunta que comecei a explorar o BitNet.

Para quem ainda não conhece, BitNet é uma família de arquiteturas de modelos de linguagem desenvolvida com foco em eficiência computacional, utilizando representações numéricas extremamente compactas para seus parâmetros.

Uma de suas variantes mais conhecidas, o BitNet b1.58, utiliza pesos ternários, representados pelos valores -1, 0 e 1. Isso permite uma representação teórica de aproximadamente 1,58 bit por peso, diferentemente dos formatos de maior precisão tradicionalmente empregados em modelos de linguagem.

Na prática, essa abordagem procura reduzir o consumo de memória, a movimentação de dados e o custo computacional das operações de inferência.

A Microsoft também desenvolveu o projeto aberto bitnet.cpp, um mecanismo otimizado para executar modelos compatíveis em processadores convencionais e, em determinadas configurações, GPUs.

O modelo oficial BitNet-b1.58-2B-4T possui aproximadamente 2,4 bilhões de parâmetros e foi treinado com 4 trilhões de tokens. Resultados publicados pela Microsoft demonstram ganhos expressivos de eficiência em cenários específicos de avaliação, embora os resultados reais dependam do hardware, do modelo e da carga de trabalho.

Isso abre possibilidades interessantes.

Estamos falando de executar modelos de linguagem localmente, sem que cada solicitação precise obrigatoriamente ser encaminhada para um serviço externo.

Um notebook, uma estação de trabalho ou um servidor local pode funcionar como ambiente de inferência, atendendo a aplicações específicas, inclusive em redes com acesso restrito à internet.

É importante esclarecer que o BitNet não oferece automaticamente a mesma capacidade de raciocínio ou geração de código de modelos muito maiores. Entretanto, quando combinado com uma base de conhecimento bem estruturada e ferramentas especializadas, pode atender a diversas necessidades práticas com uma infraestrutura significativamente mais modesta.

E foi justamente essa possibilidade que despertou meu interesse.

Minha experiência: construindo um assistente local de cibersegurança

Resolvi transformar essa curiosidade em um experimento prático.

A ideia inicial era relativamente simples: construir um assistente local para apoiar atividades básicas de Pentest, consultas técnicas e análises de infraestrutura.

Não estava interessado em desenvolver um concorrente para os grandes modelos comerciais. Meu objetivo era compreender até onde conseguiria chegar utilizando uma arquitetura leve, processamento local, um consumo computacional reduzido e uma base de conhecimento direcionada.

E, para minha surpresa, os resultados começaram a aparecer.

De maneira bastante humilde, admito que a solução ainda possui limitações. Existem problemas de interpretação, respostas que precisam de refinamento e situações nas quais um modelo maior certamente apresentaria resultados superiores.

Ainda assim, o experimento demonstrou algo importante: um modelo relativamente pequeno pode se tornar bastante útil quando recebe contexto adequado e consegue consultar ferramentas e informações especializadas.

Em vez de depender exclusivamente do conhecimento adquirido durante o treinamento do modelo, comecei a estruturar mecanismos para fornecer informações diretamente relacionadas às atividades que desejava executar.

Foi nesse momento que entrei no universo das RAGs.

O que é uma RAG e por que ela muda o comportamento de uma IA?

RAG é a sigla para Retrieval-Augmented Generation, ou Geração Aumentada por Recuperação.

Trata-se de uma abordagem que combina um modelo generativo com um mecanismo de recuperação de informações externas.

Em termos mais simples, em vez de esperar que a IA tenha todas as respostas armazenadas em seus parâmetros, podemos permitir que ela consulte documentos, bases de dados e outras fontes de conhecimento antes de responder a uma pergunta.

Imagine que você tenha centenas de livros, manuais técnicos, documentações, procedimentos operacionais e artigos sobre cibersegurança.

Seria pouco eficiente tentar retreinar um modelo de linguagem toda vez que um novo documento fosse adicionado à biblioteca.

Com uma arquitetura RAG, podemos extrair e organizar o conteúdo dos documentos, dividir textos extensos em trechos menores, criar índices de pesquisa e recuperar as informações mais relevantes para cada consulta.

Essas informações são então enviadas ao modelo como contexto para a elaboração da resposta.

A Microsoft descreve essa abordagem como uma forma de fundamentar respostas em informações específicas, inclusive dados privados e conteúdos que mudam com frequência.

Microsoft Learn

O fluxo básico pode ser representado assim:

É importante observar que uma RAG não é simplesmente um arquivo PDF convertido em conhecimento permanente do modelo. O documento precisa ser processado, indexado e recuperado quando necessário. O desempenho depende diretamente da qualidade dessas etapas.

Outro aspecto interessante é que a recuperação não precisa ocorrer exclusivamente por pesquisa vetorial. Podemos combinar busca semântica, palavras-chave, filtros por metadados e consultas estruturadas em bancos de dados.

Para minhas necessidades, essa possibilidade abriu um leque considerável de aplicações.

Transformando minha biblioteca técnica em conhecimento consultável

Tenho um acervo bastante rico de livros e materiais técnicos em PDF, especialmente relacionados à cibersegurança, infraestrutura, sistemas operacionais e administração de ambientes corporativos.

Minha primeira ideia foi transformar esse material em uma base de conhecimento local, organizada por assuntos e disponível para consulta por meio de linguagem natural.

O objetivo não era simplesmente perguntar a uma IA qual é a finalidade de um determinado protocolo.

Eu queria ir além.

Imagine fazer perguntas como:

Quais técnicas de reconhecimento de rede estão documentadas na minha biblioteca?
Como interpretar o resultado de uma descoberta de serviços utilizando Nmap?
Quais são as principais diferenças entre determinadas configurações de segurança do Windows Server?
Quais recomendações documentadas podem ajudar a analisar uma configuração incorreta do Active Directory?
Que procedimentos de diagnóstico estão disponíveis para investigar problemas de conectividade entre servidores?

Uma base RAG bem estruturada permite recuperar referências específicas e fornecer contexto ao modelo para responder a essas perguntas.

Também comecei a explorar a integração com ferramentas locais de análise de redes e segurança, sempre pensando em ambientes próprios ou nos quais exista autorização para a realização dos testes.

Nesse tipo de arquitetura, o modelo não precisa necessariamente conhecer todos os parâmetros de cada ferramenta. Ele pode interpretar a solicitação, identificar a operação necessária e encaminhar a execução para um componente especializado.

Existe, portanto, uma diferença entre utilizar um modelo de linguagem para responder perguntas e desenvolver um agente capaz de realizar tarefas.

O modelo interpreta a intenção. A RAG fornece conhecimento. As ferramentas executam operações. A aplicação controla o fluxo.

Essa combinação, mesmo em um ambiente relativamente modesto, pode produzir resultados surpreendentes.

O ponto mais intrigante: quem define as regras de uma IA local?

Durante meus experimentos, um aspecto chamou particularmente minha atenção.

Ao executar um modelo local, percebi que não estava necessariamente submetido aos mesmos mecanismos de moderação, limites de utilização e políticas operacionais impostos por plataformas comerciais de IA.

Isso não significa que uma IA local seja automaticamente livre de qualquer limitação. O próprio modelo pode apresentar comportamentos de recusa decorrentes de seu treinamento, e a aplicação pode implementar mecanismos de controle adicionais.

Entretanto, existe uma diferença importante: em uma arquitetura local, o responsável pela solução possui muito mais autonomia para determinar como o sistema será configurado, quais informações serão utilizadas e quais operações estarão disponíveis.

E essa autonomia me fez lembrar de uma cena do filme Matrix Revolutions.

Existe um momento em que Neo se encontra preso na estação de trem Mobil Ave, um ambiente situado entre dois mundos e controlado pelo programa conhecido como Homem do Trem.

Naquele espaço, as regras convencionais não funcionam exatamente como em outros ambientes da Matrix. O controle pertence a quem administra aquele sistema.

Naturalmente, trata-se de uma analogia, mas considero que ela representa uma reflexão interessante sobre a Inteligência Artificial local.

Quando executamos um modelo em nossa própria infraestrutura, podemos definir políticas de acesso, limites de execução, fontes de conhecimento, integrações e mecanismos de segurança sem depender necessariamente das configurações de uma plataforma externa.

Isso proporciona autonomia, mas também transfere responsabilidade.

Um agente capaz de executar comandos, consultar sistemas ou interagir com ferramentas administrativas precisa de controles adequados. Sem mecanismos de autorização, isolamento e auditoria, erros de interpretação ou instruções maliciosas presentes em documentos podem produzir consequências reais.

Portanto, a ausência de filtros externos não deve ser confundida com uma vantagem absoluta.

A liberdade de controlar uma IA local exige maturidade técnica para estabelecer seus próprios limites.

Essa é uma discussão que, na minha opinião, merece muito mais atenção.

Será que precisamos de grandes modelos para tudo?

Depois de explorar modelos locais, bases RAG e integrações com ferramentas, comecei a questionar a necessidade de recorrer a grandes modelos comerciais para todas as atividades.

Precisamos realmente utilizar um modelo de enorme capacidade computacional para consultar um procedimento interno de suporte?

É necessário consumir tokens em uma API externa para localizar informações em uma documentação SQL?

Faz sentido enviar dados operacionais para um serviço remoto apenas para descobrir quantos equipamentos utilizam determinada versão do Windows?

Talvez não.

Imagine um ambiente corporativo que possua uma base de inventário alimentada por Microsoft Configuration Manager, Active Directory e ferramentas de segurança de endpoint.

Uma IA local poderia interpretar perguntas em linguagem natural, consultar os dados disponíveis e apresentar respostas consolidadas.

Por exemplo:

"Quantos equipamentos com Windows 11 estão registrados no inventário mais recente?"

"Quais máquinas não possuem informações de TPM?"

"Existe alguma diferença entre o inventário do Active Directory e o inventário do SCCM?"

"Quais alterações ocorreram no parque de equipamentos nos últimos três meses?"

Nesse cenário, não precisamos necessariamente de um modelo gigantesco.

Precisamos de uma boa estrutura de dados, consultas confiáveis, mecanismos de interpretação e regras claras sobre quais informações podem ser acessadas.

Aliás, em determinadas situações, uma consulta SQL tradicional continua sendo a melhor maneira de obter um resultado exato. O papel da IA pode ser simplesmente interpretar a pergunta e acionar a consulta correta, sem inventar números ou tentar realizar cálculos sobre grandes volumes de texto.

Esse é um exemplo de aplicação na qual o conhecimento de arquitetura, bancos de dados e engenharia de software se torna tão importante quanto o próprio modelo de linguagem.

IA local versus IA em nuvem: não se trata de escolher um vencedor

Não acredito que modelos locais substituirão completamente as grandes plataformas de Inteligência Artificial.

Também não acredito que seja racional utilizar serviços de alta capacidade computacional para resolver indiscriminadamente qualquer problema.

Os dois modelos possuem características diferentes.

Característica	IA local	IA em nuvem
Processamento	Hardware próprio	Infraestrutura do provedor
Custos	Equipamentos, energia e manutenção	Consumo, assinaturas e serviços
Privacidade	Dados podem permanecer no ambiente local	Depende do serviço e das configurações
Capacidade	Limitada pelo modelo e hardware disponíveis	Acesso a modelos geralmente mais poderosos
Disponibilidade offline	Possível	Normalmente depende de conectividade
Escalabilidade	Exige planejamento de capacidade própria	Pode utilizar serviços gerenciados e escaláveis
Administração	Responsabilidade da equipe local	Responsabilidade compartilhada com o provedor

O que considero particularmente promissor é a possibilidade de construir arquiteturas híbridas.

Podemos utilizar um modelo local para interpretar perguntas simples, pesquisar documentos e consultar informações internas, recorrendo a modelos maiores somente quando a complexidade da tarefa justificar.

Essa abordagem exige mecanismos de classificação de solicitações, controle de contexto e encaminhamento inteligente, mas pode oferecer um equilíbrio interessante entre custos, privacidade e capacidade computacional.

Também precisamos considerar que executar um modelo local não significa eliminar custos. Existe investimento em hardware, armazenamento, energia elétrica, manutenção e desenvolvimento da aplicação.

A economia precisa ser avaliada a partir da carga de trabalho real, não apenas da ausência de cobrança por tokens.

O futuro não pertence a quem apenas sabe escrever prompts

Existe uma percepção cada vez mais comum de que saber escrever bons prompts será suficiente para transformar alguém em especialista em tecnologia.

Discordo parcialmente dessa ideia.

Saber formular uma solicitação clara é importante, mas isso representa apenas uma parte do processo.

Se uma pessoa solicita a uma IA que crie um ambiente de alta disponibilidade no Azure, precisa compreender o conceito de Zona de Disponibilidade, os limites de cada serviço, as dependências de rede, as permissões necessárias e os riscos de concentrar componentes críticos em um único ponto de falha.

Se solicita a criação de uma infraestrutura no GCP, precisa compreender elementos como IAM, redes VPC, políticas de firewall, escalabilidade, observabilidade e gestão de custos.

Se desenvolve uma IA local conectada a ferramentas de segurança, precisa compreender os limites de execução, o tratamento de credenciais, o isolamento dos processos e a validação das respostas.

Sem esse conhecimento, a pessoa corre o risco de construir soluções visualmente impressionantes, mas tecnicamente frágeis.

A Inteligência Artificial pode reduzir drasticamente o tempo necessário para executar determinadas atividades, mas não elimina a necessidade de compreender o problema.

Na realidade, acredito que estamos assistindo a uma valorização de algo que sempre foi fundamental na tecnologia: a capacidade de relacionar diferentes áreas do conhecimento.

Infraestrutura, programação, redes, segurança, Cloud, automação e dados estão cada vez mais próximos.

O profissional que conseguir conectar esses conhecimentos terá condições de utilizar a IA não apenas como um assistente, mas como uma ferramenta de engenharia.

Considerações finais

Quando comecei a experimentar o BitNet, minha intenção era compreender os limites de uma Inteligência Artificial executada localmente.

Queria descobrir até que ponto seria possível construir algo funcional sem depender continuamente de modelos hospedados em grandes datacenters.

Acabei encontrando perguntas muito mais interessantes do que imaginava.

Até onde podemos simplificar uma arquitetura de IA sem comprometer sua utilidade? Quais atividades realmente necessitam de modelos de grande porte? Como transformar documentação técnica em conhecimento consultável? Qual é o equilíbrio entre autonomia, custo computacional e segurança?

Meu pequeno assistente local de cibersegurança ainda está longe de ser uma solução perfeita. Entretanto, ele demonstra que não precisamos necessariamente começar com uma infraestrutura complexa para experimentar aplicações práticas de Inteligência Artificial.

Às vezes, um modelo compacto, uma base de conhecimento bem construída e algumas integrações cuidadosamente desenvolvidas são suficientes para entregar valor.

E talvez essa seja uma das transformações mais importantes deste momento.

Durante muitos anos, aprendemos a dimensionar servidores, configurar sistemas operacionais, desenvolver aplicações e administrar redes.

Agora estamos aprendendo a construir sistemas capazes de nos ajudar a executar todas essas tarefas.

Isso não representa o fim da engenharia de tecnologia. Representa uma mudança profunda na maneira como ela será praticada.

A pergunta deixou de ser apenas o que conseguimos construir com Inteligência Artificial. Agora precisamos entender o que realmente vale a pena construir, quanto custa manter essa inteligência e quanto controle desejamos ter sobre ela.

E, para mim, essa discussão está apenas começando.

Referências técnicas para aprofundamento

As reflexões e a experiência relatadas neste artigo são autorais. Para aprofundar os conceitos e tecnologias mencionados, recomendo as seguintes referências oficiais:

Microsoft — BitNet e bitnet.cpp: arquitetura, modelos e framework de inferência local.
Microsoft Learn — Retrieval-Augmented Generation: conceitos, indexação e recuperação de conhecimento.
Microsoft Learn — GitHub Copilot para operações em Cloud: geração de infraestrutura como código e automação no Azure.
Microsoft Learn — Infrastructure as Code: Bicep, Terraform e implantação de recursos.
Google Cloud — GenAI Factory: arquiteturas de referência e automação de infraestrutura no GCP.

Controle de acesso a custos no Microsoft Azure: RBAC, Billing Account, Enterprise Agreement e acesso somente leitura

2026-10-09T11:11:00.000-03:00

Área de tecnologia principal: Azure | Microsoft Azure
Áreas de tecnologia adicionais: Azure | Powershell
Dados do autor: https://linktr.ee/edupopov

A governança financeira em ambientes de nuvem depende diretamente da correta separação entre funções administrativas, funções de cobrança e funções de visualização de custos. No Microsoft Azure, essa separação é especialmente importante porque diferentes mecanismos de controle de acesso coexistem dentro da plataforma, como Microsoft Entra ID, Azure Role-Based Access Control — Azure RBAC — e funções administrativas específicas de contratos de faturamento.

Este artigo apresenta uma abordagem detalhada para concessão de acesso a informações de custos, orçamentos, previsões e consumo em ambientes Microsoft Azure. O cenário utiliza o domínio fictício popovici.lab e considera uma organização que utiliza um Enterprise Agreement — EA.

Além da configuração prática, serão abordadas as diferenças entre funções do Microsoft Entra ID, Azure RBAC, Cost Management Reader, Enterprise Administrator, Enterprise Administrator Read-Only e os diferentes níveis de escopo disponíveis no Azure.

1. Introdução

À medida que ambientes em nuvem crescem, o gerenciamento financeiro passa a fazer parte da rotina das equipes de infraestrutura, FinOps, governança, arquitetura e gestão.

Em um ambiente Azure corporativo, é comum existir a necessidade de permitir que determinados profissionais visualizem:

custos acumulados;
consumo mensal;
previsão de custos;
tendências;
orçamento;
compromissos financeiros;
consumo por assinatura;
consumo por grupo de recursos;
custos por serviço;
reservas;
Savings Plans;
detalhes de faturamento.

Entretanto, permitir a visualização dessas informações não significa que o usuário deva ter permissão para administrar recursos, excluir máquinas virtuais, modificar redes, criar serviços ou alterar configurações de produção.

Essa distinção é fundamental.

O Microsoft Azure possui diferentes mecanismos de autorização para resolver exatamente esse tipo de necessidade.

2. Cenário do laboratório

Considere o seguinte ambiente fictício:

Empresa: Popovici Lab
Domínio Microsoft Entra ID: popovici.lab
Contrato Azure: Enterprise Agreement
Billing Account: Popovici Lab
Usuário financeiro: finops@popovici.lab

O objetivo será permitir que o usuário:

finops@popovici.lab

consiga visualizar os custos corporativos do ambiente Azure, sem receber permissões administrativas sobre os recursos.

O requisito é:

O usuário deve conseguir consultar custos, consumo, previsões e informações financeiras do ambiente, mas não deve possuir privilégios administrativos sobre máquinas virtuais, redes, bancos de dados ou demais recursos Azure.

3. O primeiro conceito importante: existem diferentes tipos de função no Azure

Um dos erros mais comuns é imaginar que todas as permissões do Azure são gerenciadas da mesma forma.

Não são.

Dentro do ecossistema Microsoft existem diferentes modelos de controle de acesso.

Cada modelo possui uma finalidade diferente.

4. Microsoft Entra ID Roles não são funções de custos do Azure

O Microsoft Entra ID possui funções como:

Global Administrator;
Global Reader;
Security Reader;
User Administrator;
Groups Administrator;
Teams Administrator;
Directory Reader.

Essas funções controlam principalmente a administração do diretório e serviços associados.

Exemplo:

Microsoft Entra ID

Global Administrator
Global Reader
Security Reader
Directory Reader
User Administrator

Elas não foram projetadas para controlar diretamente a visualização de custos das assinaturas Azure.

Isso é importante porque um administrador pode acessar:

Microsoft Entra ID
→ Users
→ Roles and administrators

e procurar por uma função relacionada a custos.

Nesse local, normalmente ela não aparecerá.

Isso ocorre porque Cost Management Reader não é uma função do diretório Microsoft Entra.

Ela é uma função do Azure RBAC. Microsoft Learn

5. O que é Azure RBAC?

Azure RBAC significa:

Azure Role-Based Access Control.

6. Entendendo o conceito de escopo

Um dos conceitos mais importantes no Azure é o scope.

A documentação da Microsoft confirma que atribuições de funções em escopos superiores são aplicadas aos escopos filhos. Microsoft Learn

7. A função Cost Management Reader

Quando o objetivo é permitir a visualização de custos em um escopo Azure RBAC, uma das funções mais importantes é:

Cost Management Reader

Em português:

Leitor do Gerenciamento de Custos

Essa função foi criada especificamente para usuários que precisam consultar dados de custos sem possuir privilégios administrativos sobre os recursos. Microsoft Learn

Entre as capacidades estão:

visualizar Cost Analysis;
visualizar Forecast;
visualizar detalhes de custos;
visualizar budgets;
visualizar exports;
visualizar recomendações de economia;
visualizar configurações relacionadas ao Cost Management.

Entretanto, o usuário não pode criar ou gerenciar:

budgets;
exports;
shared views;
alertas de orçamento.

A Microsoft diferencia claramente Cost Management Reader e Cost Management Contributor. Microsoft Learn

8. Cost Management Reader versus Cost Management Contributor

Uma comparação simplificada:

Recurso	Cost Management Reader	Cost Management Contributor
Visualizar custos	Sim	Sim
Cost Analysis	Sim	Sim
Forecast	Sim	Sim
Visualizar budgets	Sim	Sim
Criar budget	Não	Sim
Alterar budget	Não	Sim
Criar export	Não	Sim
Gerenciar export	Não	Sim
Criar shared view	Não	Sim

Para usuários cuja responsabilidade seja exclusivamente análise financeira, o Cost Management Reader tende a atender melhor ao princípio de menor privilégio.

A Microsoft documenta inclusive que a função permite visualizar dados e configurações de custos, enquanto alterações exigem funções com privilégios adicionais. Microsoft Learn

9. Exemplo: concedendo Cost Management Reader em uma assinatura

Considere:

Subscription:
SUB-PRODUCAO

Usuário:
finops@popovici.lab

O caminho seria:

Azure Portal
→ Subscriptions
→ SUB-PRODUCAO
→ Access Control (IAM)
→ Add
→ Add role assignment

Pesquisar:

Cost Management Reader

Selecionar:

Members
→ User, group or service principal
→ finops@popovici.lab

Depois:

Review + assign

Nesse cenário, o usuário passa a visualizar os custos daquela assinatura específica.

10. Mas isso é suficiente em um Enterprise Agreement?

Nem sempre.

Em ambientes corporativos que utilizam Enterprise Agreement, existe uma camada adicional de gerenciamento financeiro.

O EA utiliza uma estrutura própria de funções.

Entre elas:

Enterprise Administrator
Enterprise Administrator (Read Only)
Department Administrator
Department Administrator (Read Only)
Account Owner

A Microsoft documenta essas funções especificamente para clientes Enterprise Agreement. Microsoft Learn

11. Estrutura lógica de um Enterprise Agreement

Um ambiente EA pode ser representado da seguinte maneira:

No topo da estrutura existe o Enrollment / Billing Account.

12. Enterprise Administrator

A função:

Enterprise Administrator

possui um nível elevado de controle sobre o Enterprise Agreement.

Ela pode:

gerenciar contas;
gerenciar Account Owners;
gerenciar outros Enterprise Administrators;
gerenciar Department Administrators;
visualizar consumo de todas as contas;
visualizar cobranças;
visualizar detalhes de custos;
administrar diversas configurações relacionadas ao EA.

A Microsoft classifica essa função como o nível mais elevado dentro da administração do Enrollment. Microsoft Learn

Por esse motivo, não é recomendável conceder essa função completa para alguém que apenas precisa visualizar custos.

13. Enterprise Administrator Read-Only

Para solucionar exatamente esse problema, o Azure permite criar:

Enterprise Administrator
+
Read Only

Em outras palavras:

Enterprise Administrator (Read Only)

Esse usuário mantém visibilidade financeira ampla sobre o Enterprise Agreement, mas não possui as mesmas capacidades administrativas do Enterprise Administrator completo.

A Microsoft documenta explicitamente que Enterprise Administrators podem receber acesso somente leitura. Microsoft Learn

14. O que o Enterprise Administrator Read-Only pode visualizar?

Dentro de um EA, essa função pode visualizar informações como:

saldo de crédito;
Azure Prepayment;
cotas de departamentos;
tabela de preços da organização;
uso;
detalhes de custos;
reservas;
Savings Plans;
consumo das contas.

A matriz de permissões da Microsoft mostra que Enterprise Administrator e Enterprise Administrator Read-Only conseguem visualizar uso e detalhes de custo, enquanto somente a versão completa consegue realizar diversas operações administrativas. Microsoft Learn

15. Enterprise Administrator Read-Only não administra os recursos Azure

Esse ponto é extremamente importante.

Possuir uma função financeira no Enterprise Agreement não significa automaticamente possuir acesso administrativo às máquinas virtuais, redes, bancos ou outros recursos Azure.

Por exemplo:

Enterprise Administrator Read Only

não equivale a:

Azure Subscription Owner

São modelos diferentes de permissão.

Um usuário pode possuir:

Visibilidade financeira ampla

sem conseguir:

Parar VM
Excluir VM
Modificar NSG
Criar Storage Account
Alterar VNet
Modificar SQL Server

A própria matriz da Microsoft diferencia administração de billing de gerenciamento de recursos Azure. Microsoft Learn

16. Configuração prática no laboratório popovici.lab

Agora podemos reproduzir a configuração.

Considere:

Billing Account:
Popovici Lab

Usuário:
finops@popovici.lab

Acesse:

Azure Portal

Depois:

Cost Management + Billing

Selecione:

Billing Account
→ Popovici Lab

Depois:

Access Control

17. Adicionando um Enterprise Administrator

Na tela de controle de acesso:

Add
→ Enterprise Administrator

O Azure solicitará algumas informações.

Exemplo:

Role:
Enterprise Administrator

Email:
finops@popovici.lab

Confirm email:
finops@popovici.lab

18. Tipo de autenticação

Dependendo da interface e do contrato, podem aparecer opções relacionadas ao tipo de conta.

Por exemplo:

Microsoft Account

ou:

Work or School Account

Em ambientes empresariais com Microsoft Entra ID, normalmente deve-se utilizar:

Work or School Account

para contas corporativas.

Exemplo:

finops@popovici.lab

estaria associado ao tenant corporativo.

19. Configurando o acesso somente leitura

O ponto mais importante da configuração é habilitar:

Provide read-only access

ou, dependendo do idioma:

Fornecer acesso somente leitura

O resultado será conceitualmente:

Role:
Enterprise Administrator

Read-only:
Enabled

O que corresponde a:

Enterprise Administrator (Read Only)

20. Exemplo de configuração final

Uma configuração típica seria:

Billing Account:
Popovici Lab

Role:
Enterprise Administrator

User:
finops@popovici.lab

Authentication:
Work or School Account

Read-only:
Enabled

21. Resultado esperado

Após a atribuição, o usuário poderá acessar:

Azure Portal
→ Cost Management + Billing

e visualizar:

Cost Analysis
Forecast
Usage
Charges
Budgets
Reservations
Savings Plans
Price information
Billing information

de acordo com o nível de acesso disponibilizado pelo EA.

22. Exemplo de arquitetura de acesso

Uma arquitetura recomendada poderia ser:

O usuário visualiza informações financeiras corporativas sem necessariamente possuir privilégios sobre os recursos.

23. Diferença entre Billing Role e Azure RBAC

Um dos conceitos mais importantes deste artigo é a separação entre:

Billing Authorization

Resource Authorization

Um exemplo ajuda a visualizar.

Imagine:

finops@popovici.lab

com:

Enterprise Administrator Read-Only

e sem qualquer função RBAC sobre uma VM.

Nesse cenário:

Visualizar custo da VM: SIM

mas:

Desligar VM: NÃO

24. Outro exemplo

Agora considere:

infraadmin@popovici.lab

com:

Virtual Machine Contributor

sobre um Resource Group.

Esse usuário pode:

Criar VM
Alterar VM
Reiniciar VM
Gerenciar configurações relacionadas

mas talvez não possua visibilidade completa sobre os custos corporativos do Enterprise Agreement.

Ou seja:

Gerenciar recursos
≠
Gerenciar faturamento

25. Escopo é tão importante quanto a função

Ao atribuir uma permissão, não basta perguntar:

Qual função devo utilizar?

Também é necessário perguntar:

Em qual escopo essa função será aplicada?

Por exemplo:

Cost Management Reader

em:

Resource Group

tem impacto diferente de:

Cost Management Reader

em:

Management Group

Da mesma forma:

Enterprise Administrator Read-Only

atua em um contexto de billing e EA.

26. Exemplo de menor privilégio

Imagine três profissionais.

Analista de aplicação

Precisa visualizar custo somente de uma assinatura:

Cost Management Reader
Scope:
Subscription

Gerente de infraestrutura

Precisa visualizar custos de várias assinaturas:

Cost Management Reader
Scope:
Management Group

Equipe de FinOps

Precisa analisar todo o contrato Enterprise Agreement:

Enterprise Administrator
Read-only

Cada usuário recebe apenas o acesso necessário.

27. Princípio de Least Privilege

O princípio de menor privilégio determina que:

Um usuário deve receber apenas as permissões necessárias para executar sua função.

Evite utilizar:

Owner

ou:

Contributor

somente porque um usuário precisa visualizar custos.

Essas funções possuem capacidades muito maiores.

Por exemplo:

Owner

pode gerenciar recursos e permissões.

Isso representa um nível de privilégio desnecessário para um analista financeiro.

28. Cost Management Reader é geralmente preferível em escopos RBAC

Se o requisito for:

O usuário precisa apenas visualizar custos de uma assinatura.

Utilize:

Cost Management Reader

A função foi criada justamente para visibilidade financeira sem administração de recursos. Microsoft Learn

29. Cost Management Contributor

Quando o usuário precisa também administrar elementos financeiros, pode-se avaliar:

Cost Management Contributor

Essa função permite:

criar budgets;
modificar budgets;
criar exports;
modificar exports;
gerenciar alertas;
criar shared views.

Por isso ela é apropriada para profissionais FinOps que efetivamente administram os controles financeiros. Microsoft Learn

30. Reader tradicional versus Cost Management Reader

Outro detalhe interessante é que o Azure possui:

Reader

Cost Management Reader

Apesar de ambos permitirem determinados tipos de leitura, Cost Management Reader é uma função especializada em dados financeiros.

Suas permissões incluem operações como:

Microsoft.Consumption/*/read
Microsoft.CostManagement/*/read
Microsoft.Billing/billingPeriods/read

entre outras permissões relacionadas. Microsoft Learn

31. Orçamentos no Azure

Budgets permitem estabelecer limites financeiros.

Exemplo:

Monthly Budget:
US$ 50,000

Pode-se criar alertas como:

50%
75%
90%
100%

Quando o consumo atinge determinado percentual, notificações podem ser disparadas.

A Microsoft diferencia leitura e administração de budgets:

Cost Management Reader
→ visualizar

Cost Management Contributor
→ criar e administrar
``` :chatgpt-content-reference{index="13"}


---

# 32. Forecast

Forecast utiliza os dados de consumo existentes para estimar o gasto futuro dentro do período.

Por exemplo:

```text
Gasto atual:
US$ 32.000

Estimativa até o final do mês:
US$ 47.800

Isso permite que uma equipe FinOps identifique tendências antes do fechamento financeiro.

33. Cost Analysis

Cost Analysis é uma das ferramentas mais importantes do Azure Cost Management.

Permite analisar custos por:

assinatura;
resource group;
serviço;
localização;
tag;
recurso;
período;
departamento;
tipo de cobrança.

Por exemplo:

Cost by Service

poderia mostrar:

Virtual Machines       42%
Azure SQL              21%
Storage                 14%
Networking               9%
Other                   14%

34. Tags e FinOps

Uma boa estratégia de governança financeira envolve tags.

Exemplo:

Environment=Production
Department=Infrastructure
Project=ERP
Owner=CloudTeam
CostCenter=CC001

Isso permite posteriormente analisar:

Cost by CostCenter

ou:

Cost by Project

35. Enterprise Agreement e visibilidade financeira

Em contratos Enterprise Agreement, administradores corporativos possuem uma visão centralizada do consumo.

A Microsoft define funções como:

Enterprise Administrator
Enterprise Administrator Read-Only
Department Administrator
Department Administrator Read-Only
Account Owner

Cada uma possui um conjunto diferente de responsabilidades. Microsoft Learn

36. Department Administrator

Se a empresa possuir departamentos separados:

Infrastructure
Development
Data
Security

pode ser desnecessário fornecer visão de todo o Enterprise Agreement.

Nesse cenário pode-se utilizar:

Department Administrator

ou:

Department Administrator Read-Only

permitindo uma segmentação mais granular.

37. Account Owner

O Account Owner está associado a contas dentro do Enterprise Agreement.

Dependendo das políticas configuradas pelo Enterprise Administrator, o Account Owner pode visualizar custos associados à sua conta.

A Microsoft documenta que a visibilidade de custos para Account Owners pode depender da política de visualização de charges habilitada pelo Enterprise Administrator. Microsoft Learn

38. DA View Charges e AO View Charges

Em Enterprise Agreements existem políticas importantes relacionadas à exposição de custos.

Entre elas:

DA View Charges

AO View Charges

Essas políticas controlam se:

Department Administrators

Account Owners

podem visualizar custos.

A documentação da Microsoft indica que essas permissões dependem da habilitação pelo Enterprise Administrator. Microsoft Learn

39. Uma possível estratégia de governança

Uma organização pode estruturar acessos da seguinte forma:

Esse modelo reduz privilégios desnecessários.

40. Diagrama conceitual

41. Erro comum: procurar Cost Management Reader no Microsoft Entra ID

Um erro recorrente é acessar:

Microsoft Entra ID
→ Users
→ Assigned Roles

e pesquisar:

Cost Management Reader

Essa função não aparecerá.

Isso ocorre porque ela pertence ao:

Azure RBAC

e não ao:

Microsoft Entra Directory Roles

42. Local correto para Cost Management Reader

Acesse o escopo desejado.

Por exemplo:

Subscription
→ Access Control (IAM)
→ Add role assignment

ou:

Management Group
→ Access Control (IAM)

ou:

Resource Group
→ Access Control (IAM)

43. Local correto para Enterprise Administrator Read-Only

No caso de Enterprise Agreement:

Cost Management + Billing
→ Billing Account
→ Access Control

Depois:

Add
→ Enterprise Administrator

e marque:

Provide read-only access

44. Verificação pós-configuração

Após a atribuição, recomenda-se validar o acesso utilizando uma conta separada.

Exemplo:

finops@popovici.lab

Entrar no Azure Portal e acessar:

Cost Management + Billing

Verificar:

Cost Analysis
Budgets
Forecast
Usage
Billing Account
Reservations

45. Teste de segurança

Também é importante verificar o que o usuário não consegue fazer.

Por exemplo:

Virtual Machines
→ VM-PROD-01

O usuário financeiro não deve conseguir:

Stop
Restart
Delete
Resize
Modify networking

caso não possua função Azure RBAC adicional.

46. Modelo de teste

Uma matriz simples pode ser utilizada:

Operação	Resultado esperado
Visualizar custo mensal	Permitido
Visualizar Forecast	Permitido
Visualizar consumo por serviço	Permitido
Visualizar orçamento	Permitido
Administrar VM	Negado
Excluir Resource Group	Negado
Modificar VNet	Negado
Alterar RBAC	Negado

47. Auditoria de permissões

Ambientes corporativos devem revisar periodicamente:

Quem possui acesso?

Qual função possui?

Em qual escopo?

O acesso ainda é necessário?

Uma política comum é realizar revisão trimestral.

48. Uso de grupos em vez de usuários

Em ambientes maiores, uma prática recomendável é evitar atribuições individuais.

Em vez de:

finops01@popovici.lab
finops02@popovici.lab
finops03@popovici.lab

pode-se criar:

GRP-Azure-FinOps-Readers

e adicionar os usuários ao grupo.

Depois atribuir:

Cost Management Reader

ao grupo.

Isso simplifica a governança.

49. Separação de funções

Um modelo maduro pode utilizar grupos como:

GRP-Azure-Cost-Readers

GRP-Azure-Cost-Contributors

GRP-Azure-EA-Readers

GRP-Azure-Subscription-Owners

Isso cria uma estrutura clara e auditável.

50. Considerações de segurança

Informações financeiras também são informações sensíveis.

Um usuário com acesso ao Cost Management pode inferir:

tamanho da infraestrutura;
volume de consumo;
tecnologias utilizadas;
crescimento do ambiente;
serviços críticos;
investimentos em cloud.

Portanto, acesso financeiro também deve seguir controles de segurança.

51. MFA

Contas com acesso financeiro corporativo devem possuir autenticação multifator.

Exemplo:

Microsoft Entra Conditional Access

com:

Require multifactor authentication

para grupos responsáveis por billing e FinOps.

52. Conditional Access

Uma política pode ser estruturada como:

Users:
GRP-Azure-EA-Readers

Cloud Apps:
Microsoft Azure Management

Grant:
Require MFA

Dependendo da política corporativa, outras condições também podem ser aplicadas.

53. Privileged Identity Management

Para funções administrativas mais sensíveis, pode-se avaliar o uso do:

Microsoft Entra Privileged Identity Management

quando tecnicamente aplicável ao tipo de função.

A ideia é evitar privilégios permanentemente ativos.

54. Diferença entre FinOps e administração de infraestrutura

FinOps possui objetivos diferentes da administração tradicional.

Uma equipe de infraestrutura normalmente preocupa-se com:

Availability
Performance
Security
Networking
Compute
Storage

Enquanto FinOps concentra-se em:

Cost
Forecast
Budget
Optimization
Allocation
Chargeback
Showback

As permissões devem refletir essa separação.

55. Showback

Showback consiste em demonstrar para cada área quanto ela consumiu.

Exemplo:

Infrastructure: US$ 75.000
Development:    US$ 31.000
Analytics:      US$ 18.000
Security:       US$ 12.000

Sem necessariamente cobrar internamente esses valores.

56. Chargeback

Chargeback vai além.

Os custos são efetivamente atribuídos aos centros de custo internos.

Exemplo:

CC1001 → Infrastructure
CC1002 → Development
CC1003 → Data

Isso exige boa organização de subscriptions, tags e billing scopes.

57. Recomendações práticas

Para ambientes corporativos, considere:

utilizar Cost Management Reader quando somente leitura for necessária;
evitar Owner para usuários financeiros;
evitar Contributor sem justificativa;
utilizar grupos para delegação;
documentar os escopos;
revisar acessos periodicamente;
utilizar MFA;
separar billing de administração de recursos;
utilizar read-only em funções EA sempre que possível;
revisar budgets e exports regularmente.

58. Fluxo de decisão

Uma árvore de decisão simples pode ajudar.

pode ser mais apropriado em escopos RBAC.

59. Comparativo final

Cenário	Função
Ver custos de Resource Group	Cost Management Reader
Ver custos de Subscription	Cost Management Reader
Ver custos de Management Group	Cost Management Reader
Criar budgets	Cost Management Contributor
Criar exports	Cost Management Contributor
Administrar toda a estrutura financeira EA	Enterprise Administrator
Visualizar estrutura financeira EA	Enterprise Administrator Read-Only
Administrar departamento EA	Department Administrator
Visualizar departamento EA	Department Administrator Read-Only

60. Conclusão

A correta configuração de permissões de custos no Microsoft Azure exige compreender que Microsoft Entra ID, Azure RBAC e Billing Roles são mecanismos diferentes.

Para acesso financeiro em escopos de recursos, a função:

Cost Management Reader

é uma das opções mais adequadas para permitir visualização de custos sem administração de recursos. Microsoft Learn

Em ambientes baseados em Enterprise Agreement, quando o requisito é fornecer visibilidade ampla sobre o contrato corporativo, pode-se utilizar:

Enterprise Administrator
+
Read-only

resultando em:

Enterprise Administrator (Read Only)

A Microsoft documenta que esse papel possui visibilidade sobre uso e detalhes de custo em todo o Enrollment, sem os mesmos privilégios de administração da função Enterprise Administrator completa. Microsoft Learn

A principal recomendação permanece a mesma utilizada em outros domínios de segurança:

conceder o menor privilégio necessário, no menor escopo necessário e pelo período necessário.

Essa abordagem melhora simultaneamente segurança, governança, auditoria e maturidade FinOps do ambiente Azure.

Referências

Microsoft Learn — Understand admin roles for Enterprise Agreements in Azure. Microsoft Learn

Microsoft Learn — Understand and work with Cost Management scopes. Microsoft Learn

Microsoft Learn — Azure built-in roles for Management and governance. Microsoft Learn

Microsoft Learn — Get started with your Enterprise Agreement billing account. Microsoft Learn

Microsoft Learn — Create and manage budgets. Microsoft Learn

Versão nova do EntraID e você precisa atualizar [Dica do MVP]

2026-10-05T15:37:00.000-03:00

Área de tecnologia principal: Security | Intune
Áreas de tecnologia adicionais: Azure | Powershell
Dados do autor: https://linktr.ee/edupopov

O que é o Microsoft Entra ID?

Documentação Oficial (versões):

https://learn.microsoft.com/pt-br/entra/identity/hybrid/connect/reference-connect-version-history

O Microsoft Entra ID (antigo Azure Active Directory) é o serviço de gerenciamento de identidades e controle de acesso em nuvem da Microsoft. Ele é responsável por autenticar usuários, dispositivos e aplicações, permitindo o acesso seguro aos recursos corporativos, como Microsoft 365, Azure, aplicações SaaS e sistemas internos. O Entra ID também centraliza a administração de usuários, grupos, permissões e políticas de segurança.

Em ambientes híbridos, o Entra ID trabalha em conjunto com o Active Directory local por meio do Microsoft Entra Connect Sync, permitindo que identidades sejam sincronizadas entre o ambiente on-premises e a nuvem.

Importância de manter o Entra ID atualizado

Manter o ambiente de identidade atualizado é uma prática essencial para garantir a segurança, a estabilidade e a continuidade operacional da organização.

Entre os principais benefícios da atualização estão:

Correções de segurança para mitigar vulnerabilidades e reduzir a superfície de ataque.
Compatibilidade com os serviços Microsoft 365 e Azure, evitando falhas causadas por versões obsoletas.
Melhorias de desempenho e escalabilidade, garantindo sincronizações mais rápidas e confiáveis.
Acesso a novos recursos de proteção de identidade, como autenticação multifator (MFA), acesso condicional e mecanismos avançados de detecção de risco.
Suporte oficial da Microsoft, reduzindo riscos operacionais associados ao uso de versões fora do ciclo de suporte.

Além dos benefícios técnicos, a atualização do Microsoft Entra Connect garante a continuidade da integração híbrida entre o Active Directory local e o Entra ID, evitando interrupções na sincronização de usuários, grupos e atributos. Em iniciativas internas de modernização de identidade, a atualização para versões suportadas foi tratada como uma ação estratégica para manter a estabilidade da autenticação e a confiabilidade dos serviços corporativos.

Resumo Executivo

O Microsoft Entra ID é hoje o principal repositório de identidade do ecossistema Microsoft. Ele controla quem pode acessar quais recursos, em qual dispositivo e sob quais condições. Manter o ambiente atualizado não é apenas uma recomendação técnica, mas uma medida fundamental de segurança, governança e continuidade dos serviços digitais da organização.

Passo a passo:

Figura 1. Representação ilustrativa do acesso ao Microsoft Entra Connect no ambiente lab.test.

Tipo de documento	Procedimento operacional padrão
Classificação	Uso técnico / Laboratório
Versão do documento	1.0
Data de revisão	22/09/2026

1. Objetivo

Estabelecer um procedimento padronizado para atualizar o Microsoft Entra Connect Sync, preservando a continuidade da sincronização de identidades entre o Active Directory Domain Services (AD DS) local e o Microsoft Entra ID.

Importante: A atualização reduz a exposição a falhas conhecidas e mantém compatibilidade, estabilidade e suporte do componente de sincronização. A versão mínima e a versão mais recente devem ser confirmadas no histórico oficial antes de cada manutenção.

2. Escopo

Aplica-se aos servidores que hospedam o Microsoft Entra Connect Sync no ambiente lab.test. O procedimento considera uma atualização in-place de uma instalação existente e funcional.

3. Impacto previsto

· Os serviços de sincronização ficam temporariamente indisponíveis durante o upgrade.

· Alterações realizadas em usuários, grupos e atributos podem permanecer pendentes até a retomada do ciclo.

· A autenticação de identidades já sincronizadas não depende da execução contínua do mecanismo de sincronização.

· A atividade deve ocorrer em janela de manutenção aprovada e com baixa taxa de alterações no diretório.

4. Pré-requisitos

Item	Validação	Evidência esperada
1	Conta administrativa	Conta autorizada para concluir a configuração no Microsoft Entra ID.
2	Backup	Backup ou snapshot válido do servidor, conforme política vigente.
3	Configuração	Exportação da configuração atual armazenada em local seguro.
4	Conectividade	Acesso aos endpoints Microsoft necessários.
5	Plataforma	TLS 1.2, .NET Framework e sistema operacional suportados.
6	Saúde da sincronização	Ausência de erros críticos antes do início da manutenção.
7	Instalador	Arquivo MSI obtido no portal do Microsoft Entra.

5. Preparação e cópia de segurança

1. Abra o Microsoft Entra Connect no servidor atual.

2. Selecione Configure e acesse View or Export Current Configuration.

3. Exporte a configuração e armazene o arquivo em local protegido.

4. Registre a versão instalada e o estado atual do scheduler.

5. Confirme a existência e a validade do backup do servidor.

6. Download do instalador

6. Acesse o Portal Microsoft Entra: https://entra.microsoft.com/.

Figura 1.1. Acessando o portal.

7. No menu de gerenciamento híbrido, selecione Microsoft Entra Connect e, em seguida, Connect Sync.

8. Selecione a opção para baixar a versão mais recente, aceite os termos e inicie o download.

9. Valide a origem do arquivo antes de transferi-lo ao servidor de sincronização.

Figura 2. Fluxo ilustrativo de download do Microsoft Entra Connect Sync no ambiente lab.test.

7. Preparação do instalador

Crie uma pasta temporária local e copie o instalador para o diretório definido:

C:\Temp\01-EntraConnect

Abra o PowerShell com privilégios administrativos e execute:

cd "C:\Temp\01-EntraConnect"
.\AzureADConnect.msi

Figura 2.1. Comando de instalação pelo Powershell.

Figura 3. Preparação do instalador e execução do MSI com PowerShell elevado.

8. Execução do upgrade

10. Na tela inicial, marque I agree to the license terms and privacy notice e selecione Continue.

11. Aguarde o instalador identificar a instalação existente.

12. Selecione Upgrade.

13. Quando solicitado, autentique-se com a conta administrativa autorizada.

14. Revise a configuração apresentada pelo assistente.

15. Mantenha selecionada a opção Start the synchronization process when configuration completes.

16. Selecione Upgrade e aguarde a conclusão.

17. Ao final, selecione Exit.

Figura 4. Etapas ilustrativas do assistente de atualização: termos, upgrade e retomada da sincronização.

Atenção: Não reinicie o servidor nem interrompa o processo enquanto o assistente estiver aplicando a atualização. Registre qualquer mensagem de erro apresentada.

9. Validação pós-atualização

18. Abra o Synchronization Service como administrador.

19. Na guia Operations, confirme a execução bem-sucedida das operações de Import, Synchronization e Export.

20. Verifique se o serviço ADSync está em execução.

21. No PowerShell, execute Get-ADSyncScheduler e confirme SyncCycleEnabled : True.

22. Registre a nova versão instalada.

23. Valide uma alteração controlada de laboratório, quando prevista no plano de teste.

Figura 5. Painel ilustrativo de validação pós-atualização no ambiente lab.test.

Figura 6. Painel real de validação pelo Synchronization Services Manager no ambiente lab.test.

Figura 7. Verificação de versionamento e sync de delta através do Powershell.

10. Critérios de sucesso

· O instalador foi concluído sem erro.

· A versão atualizada está registrada no servidor.

· O serviço ADSync encontra-se em execução.

· O scheduler está habilitado.

· Um ciclo completo foi concluído com sucesso.

· Não existem erros críticos de importação, sincronização ou exportação.

· Usuários, grupos e atributos continuam sendo sincronizados conforme o escopo configurado.

11. Plano de reversão

24. Interrompa novas alterações administrativas relacionadas à sincronização.

25. Registre o erro, a etapa e os eventos relacionados.

26. Caso a instalação permaneça indisponível, restaure o servidor conforme o mecanismo de backup aprovado.

27. Utilize a configuração exportada para apoiar a recuperação, quando aplicável.

28. Valide a sincronização antes de liberar o encerramento da contingência.

Observação: A estratégia de reversão deve respeitar a arquitetura do ambiente. Ambientes com servidor em staging mode podem utilizar procedimento de alternância controlada em vez da restauração do servidor.

12. Registro da mudança

Número da mudança
Servidor	LAB-ENTRA-01
Versão anterior
Versão instalada
Início / término
Responsável técnico
Resultado	☐ Sucesso ☐ Sucesso com ressalvas ☐ Falha

13. Referências oficiais

· Microsoft Entra Connect: atualizar de uma versão anterior: https://learn.microsoft.com/pt-br/entra/identity/hybrid/connect/how-to-upgrade-previous-version

· Histórico de versões do Microsoft Entra Connect: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/reference-connect-version-history

· Portal de administração do Microsoft Entra: https://entra.microsoft.com/

Ataques de Indisponibilização por Encerramento no Windows [a velha e boa força bruta] - MVP Blue Team

2026-10-02T14:17:00.000-03:00

Área de tecnologia principal: Security | Intune
Áreas de tecnologia adicionais: Azure | Powershell
Dados do autor: https://linktr.ee/edupopov

Ataques de Indisponibilização por Encerramento Forçado de Processos Críticos no Windows

Uma análise do uso do comando Taskkill contra o Svchost.exe

taskkill /S hostname /F /fi "imagename eq svchost.exe"

Material didático para formação em Cybersecurity - Blue Team

Foco: disponibilidade, telemetria, detecção e mitigação

Resumo

A disponibilidade é um dos pilares fundamentais da segurança da informação. Embora grande parte dos programas de defesa esteja voltada para ataques de malware, ransomware e exploração de vulnerabilidades, existe uma categoria de ameaça frequentemente negligenciada: a interrupção deliberada de serviços críticos do sistema operacional utilizando ferramentas nativas do próprio Windows. Entre essas técnicas, destaca-se o uso indevido do comando taskkill para finalizar processos essenciais hospedados pelo svchost.exe.

Este artigo apresenta uma análise aprofundada dessa técnica sob a perspectiva de Blue Team, abordando o funcionamento do comando, os componentes envolvidos, os impactos operacionais decorrentes do encerramento dos serviços, os mecanismos que podem levar a instabilidades ou telas azuis (BSOD), além de estratégias de monitoramento, detecção e mitigação.

1. Introdução

Muitos profissionais associam ataques cibernéticos à execução de códigos maliciosos complexos. Entretanto, diversas ações destrutivas podem ser executadas utilizando apenas ferramentas legítimas do sistema operacional. O Powershell e comandos do antigo prompt são ferramentas excelentes para ataques que provocam indisponibilidade. Uma credencial com permissão indevida e o conhecimento de elementos de linha de comando podem causar um estrago considerável.

Esse conceito é conhecido como:

Living Off The Land (LotL)

Nessa abordagem, o atacante utiliza utilitários já presentes no ambiente para evitar a detecção por soluções de segurança.

O comando abaixo é um exemplo simples:

taskkill /S hostname /F /fi "imagename eq svchost.exe"

À primeira vista, trata-se apenas de um comando administrativo. Contudo, quando utilizado de forma maliciosa, ele pode provocar interrupções severas em serviços críticos, indisponibilidade de sistemas e, em determinadas circunstâncias, a paralisação completa do sistema operacional.

2. O que é o Taskkill?

O taskkill.exe é uma ferramenta nativa do Windows destinada ao encerramento de processos em ambientes locais ou remotos.

Sua função original é auxiliar administradores na gestão operacional dos sistemas.

A sintaxe básica é:

taskkill [opções]

Alguns exemplos legítimos incluem:

taskkill /PID 1234

Encerrar um processo pelo PID.

taskkill /IM notepad.exe

Encerrar todas as instâncias do Bloco de Notas.

taskkill /F /IM chrome.exe

Forçar o encerramento de todos os processos do Google Chrome.

Sob a ótica da segurança, trata-se de uma ferramenta dual-use:

· Possui finalidade legítima.

· Pode ser utilizada para fins maliciosos.

3. Entendendo os Componentes do Comando

Considere novamente:

taskkill /S hostname /F /fi "imagename eq svchost.exe"

Vamos analisar cada elemento.

3.1 Taskkill

O executável responsável pela finalização de processos.

taskkill

3.2 /S hostname

O parâmetro /S informa que a ação será realizada em um computador remoto.

Exemplo:

/S SRV-APP01

ou

/S 10.0.0.15

Isso permite que o operador atue à distância sem acesso interativo ao equipamento.

3.3 /F

Significa:

Force

Ou seja, o processo não receberá oportunidade de encerramento gracioso.

O Windows simplesmente ordenará sua finalização imediata.

3.4 /FI

Representa:

Filter

Permite selecionar os processos que serão afetados.

Exemplo:

/FI "IMAGENAME eq svchost.exe"

3.5 IMAGENAME EQ

Consiste na condição de filtragem.

IMAGENAME

Nome do executável.

Operador lógico "igual a".

Portanto:

IMAGENAME eq svchost.exe

significa:

"Selecione todos os processos cujo nome seja svchost.exe."

4. O que é o Svchost.exe?

Para compreender a gravidade do ataque, é necessário entender o papel do svchost.exe.

O nome significa:

Service Host

ou

Hospedeiro de Serviços

Seu objetivo é carregar e executar serviços do Windows.

Historicamente, vários serviços compartilhavam uma mesma instância do svchost.exe para reduzir o consumo de memória.

Nas versões modernas do Windows existem diversas instâncias simultâneas.

Exemplo:

svchost.exe
├─ DNS Client
├─ DHCP Client
├─ Windows Update
├─ Event Log
├─ RPC
├─ DCOM
└─ dezenas de outros serviços

É comum encontrar dezenas de processos svchost.exe ativos em uma única estação.

5. Por que o Comando é Perigoso?

Quando o filtro identifica todos os processos svchost.exe, o comando tenta encerrar múltiplos serviços críticos simultaneamente.

Entre eles podem estar:

RPC (Remote Procedure Call)

Responsável pela comunicação entre componentes internos do Windows.

Sem RPC, o sistema operacional perde parte significativa de sua funcionalidade.

Event Log

Responsável pelo registro dos eventos do sistema.

Sua interrupção compromete a auditoria.

DHCP Client

Gerencia a obtenção de endereços IP.

Sua parada pode causar perda de conectividade.

DNS Client

Fundamental para resolução de nomes.

Sua interrupção afeta a comunicação da máquina.

Windows Management Instrumentation (WMI)

Amplamente utilizado por SCCM, Intune e ferramentas de inventário.

Sua indisponibilidade afeta operações corporativas.

6. Como a Tela Azul Pode Acontecer?

É importante compreender que:

o taskkill não gera diretamente uma BSOD.

O que ocorre é uma cadeia de eventos.

Etapa 1

O comando encerra um processo svchost.exe.

Etapa 2

Um ou mais serviços críticos deixam de existir.

Etapa 3

Dependências internas do sistema deixam de funcionar.

Etapa 4

Drivers, serviços ou componentes do kernel tentam acessar recursos indisponíveis.

Etapa 5

O sistema entra em estado inconsistente.

Etapa 6

O Windows executa um mecanismo de proteção que pode resultar em:

· Reinicialização automática;

· Travamento completo;

· Falha fatal (BugCheck);

· Tela Azul (BSOD).

Em ambientes específicos, principalmente servidores com agentes de segurança, monitoramento ou drivers proprietários, a interrupção abrupta de dependências críticas pode aumentar a probabilidade desse comportamento.

7. Classificação da Ameaça

Do ponto de vista de Blue Team, essa técnica pode ser classificada como:

Ataque de Negação de Serviço (DoS)

Objetivo:

Interromper funcionalidades do sistema.

Sabotagem Operacional

Objetivo:

Reduzir a disponibilidade de ativos corporativos.

Living Off The Land Attack

Objetivo:

Utilizar ferramentas legítimas para causar impacto.

8. Como Detectar Esse Ataque

Segurança do Windows

Monitorar eventos:

4688

Criação de processos.

Indicadores:

taskkill.exe

ou

svchost.exe

presentes na linha de comando.

Sysmon

Evento:

Event ID 1

Process Create.

Exemplo suspeito:

Image: taskkill.exe
CommandLine:
taskkill /F /FI "IMAGENAME eq svchost.exe"

Microsoft Defender for Endpoint

Consultas devem buscar:

ProcessCommandLine has "taskkill"

ProcessCommandLine has "svchost.exe"

CrowdStrike Falcon

Indicadores relevantes:

· Taskkill executado remotamente.

· Encerramento massivo de processos.

· Comandos administrativos incomuns.

· Atividade iniciada por scripts automatizados.

9. Medidas de Defesa

Princípio do Menor Privilégio

Usuários comuns não devem possuir privilégios administrativos locais.

Isso reduz drasticamente a superfície de ataque.

Monitoramento de Linha de Comando

Registrar:

Process Creation Events

com captura completa da linha de comando.

AppLocker ou WDAC

Permitir controle sobre:

taskkill.exe

em ambientes sensíveis.

Alertas para Svchost

Criar regras para:

taskkill

+

svchost.exe

na mesma execução.

Esse comportamento raramente possui justificativa operacional legítima.

EDR

Ferramentas modernas devem gerar alertas quando houver:

· Encerramento em massa de serviços;

· Finalização de processos protegidos;

· Comandos administrativos incomuns;

· Uso remoto de utilitários nativos.

10. Considerações Finais

Ataques modernos nem sempre dependem de exploits sofisticados ou malware avançado. Em muitos casos, o adversário obtém resultados expressivos explorando funcionalidades legítimas do sistema operacional.

O uso indevido do comando taskkill contra instâncias do svchost.exe exemplifica perfeitamente esse cenário. Uma única linha de comando pode interromper serviços essenciais, degradar a capacidade operacional de uma estação ou servidor e, em situações específicas, desencadear condições que culminam na paralisação completa do sistema.

Para equipes de Blue Team, compreender não apenas as vulnerabilidades tradicionais, mas também o abuso de ferramentas administrativas nativas, é fundamental para aumentar a capacidade de detecção e resposta. A combinação de monitoramento de processos, auditoria de linha de comando, restrição de privilégios e telemetria de EDR constitui a principal defesa contra esse tipo de técnica destrutiva.

O estudo desse cenário reforça uma lição importante para profissionais de defesa: nem todo ataque se manifesta através de malware. Muitas vezes, o próprio sistema operacional oferece ao atacante os mecanismos necessários para comprometer a disponibilidade do ambiente.

Coletando hardware com o SCCM

2026-09-28T09:30:00.000-03:00

Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

Esta semana, durante uma aula de Windows Server, um aluno me fez uma pergunta interessante sobre como realizar a coleta, o inventário e a gestão das informações de hardware dos equipamentos de uma empresa. A dúvida abriu espaço para uma discussão bastante prática sobre como esse tipo de informação pode ser utilizado pela equipe de TI para conhecer melhor o parque computacional, apoiar processos de atualização, identificar limitações de hardware e até mesmo ajudar em decisões relacionadas ao ciclo de vida dos dispositivos.

Expliquei que a Microsoft possui soluções que atendem muito bem esse cenário, principalmente o Microsoft Configuration Manager (SCCM) e o Microsoft Intune. Cada um possui características e abordagens diferentes, mas ambos permitem ampliar significativamente a visibilidade sobre os dispositivos corporativos e centralizar informações importantes para administração, segurança e planejamento.

Como muitas empresas de médio e grande porte ainda utilizam o SCCM como uma das principais plataformas de gerenciamento de estações de trabalho e servidores, decidi aproveitar o tema e transformar a discussão em um laboratório prático. A ideia foi demonstrar, passo a passo, como habilitar e personalizar o Hardware Inventory, selecionar as classes que serão coletadas e posteriormente consultar essas informações dentro do ambiente.

O objetivo deste artigo é justamente compartilhar esse laboratório e mostrar que a coleta de hardware vai muito além de simplesmente descobrir quanto de memória RAM ou qual processador existe em um computador. Quando bem estruturados, esses dados podem se transformar em uma importante fonte de informação para inventário, troubleshooting, atualização de sistemas operacionais, planejamento de upgrades, renovação do parque, segurança e tomada de decisão.

Ao longo do artigo, vamos explorar como o SCCM realiza essa coleta, quais informações podem ser obtidas e como podemos utilizar consultas personalizadas para transformar os dados armazenados no Configuration Manager em informações realmente úteis para a administração do ambiente.

Em ambientes corporativos, conhecer detalhadamente os equipamentos que fazem parte da infraestrutura é fundamental para manter o ambiente organizado, seguro e preparado para evoluções tecnológicas. O Microsoft Configuration Manager (SCCM) oferece recursos de inventário de hardware capazes de coletar automaticamente informações dos dispositivos gerenciados, reduzindo a necessidade de levantamentos manuais e permitindo que a equipe de TI mantenha uma visão centralizada do parque computacional.

Por meio do Hardware Inventory, é possível coletar informações como fabricante, modelo do equipamento, processador, quantidade de memória RAM, armazenamento, versão de BIOS ou UEFI, interfaces de rede, dispositivos instalados e diversas outras características disponibilizadas pelo Windows por meio de classes de gerenciamento do sistema. Essas informações são armazenadas na base de dados do Configuration Manager e podem posteriormente ser utilizadas em consultas, coleções, relatórios e processos de automação.

A disponibilidade desses dados facilita atividades importantes do dia a dia da infraestrutura. Uma organização pode, por exemplo, identificar computadores que não atendem aos requisitos para uma atualização de sistema operacional, localizar equipamentos com pouca memória ou armazenamento, analisar modelos que precisam ser substituídos e acompanhar características relacionadas à segurança, como presença de TPM, Secure Boot e versões de firmware.

Além do aspecto operacional, o inventário de hardware também contribui diretamente para o planejamento do ciclo de vida dos dispositivos. Em vez de tomar decisões com base em estimativas, a equipe de TI passa a trabalhar com informações reais do ambiente, permitindo planejar renovações de equipamentos, projetos de modernização, migrações de sistema operacional e investimentos em infraestrutura com maior precisão.

Quando combinado com consultas personalizadas, relatórios e dashboards, o SCCM deixa de ser apenas uma ferramenta de gerenciamento de estações e passa a funcionar como uma importante fonte de inteligência sobre o parque computacional. A coleta estruturada dessas informações permite transformar dados técnicos dispersos em informações úteis para administração, segurança, governança e tomada de decisão.

Neste artigo, veremos como utilizar os recursos de inventário do SCCM para coletar informações de hardware dos dispositivos gerenciados e como explorar esses dados para obter uma visão mais completa e estratégica do ambiente.

Para realizar essa coleta, siga a seguinte rota:

Administration
Overview
Client Settings

Nesta etapa, é realizada a configuração do Hardware Inventory nas configurações de cliente do Microsoft Configuration Manager. Em Administration > Client Settings, a opção Hardware Inventory permite habilitar ou desabilitar a coleta de informações de hardware nos dispositivos gerenciados, além de definir a periodicidade com que esse inventário será executado.

O campo Hardware inventory schedule determina a frequência de execução da coleta. Essa configuração deve ser planejada de acordo com o tamanho do ambiente e com a necessidade de atualização das informações, evitando execuções excessivamente frequentes que possam gerar tráfego e processamento desnecessários. O SCCM também permite configurar um atraso aleatório, utilizado para distribuir a comunicação dos clientes ao longo do tempo e evitar que milhares de equipamentos enviem dados simultaneamente para a infraestrutura.

O botão Set Classes... é um dos principais elementos dessa configuração. Por meio dele, o administrador define quais classes WMI/CIM e respectivas propriedades serão incluídas no inventário de hardware. É justamente nesse ponto que podem ser selecionadas informações como processador, memória, BIOS, armazenamento, TPM, interfaces de rede e diversos outros componentes existentes no Windows.

É importante destacar que as configurações apresentadas na figura correspondem às Default Client Settings, que são aplicadas aos clientes da hierarquia quando não existe uma configuração personalizada com prioridade superior. Em ambientes maiores, uma boa prática é criar Custom Client Settings para grupos específicos de dispositivos, permitindo aplicar diferentes configurações de inventário conforme a necessidade de servidores, estações de trabalho, laboratórios ou outros conjuntos de equipamentos.

Figura — Configuração do Hardware Inventory nas Client Settings do Microsoft Configuration Manager, incluindo agendamento da coleta e definição das classes de hardware por meio da opção Set Classes.

Aqui, o Configuration Manager (SCCM) permite definir exatamente quais classes e propriedades do Windows serão utilizadas durante o processo de Hardware Inventory. A janela Hardware Inventory Classes apresenta as classes disponíveis por meio do WMI/CIM e possibilita selecionar somente as informações que realmente precisam ser coletadas dos dispositivos gerenciados. Essa flexibilidade é importante porque permite adaptar o inventário às necessidades da organização, evitando a coleta desnecessária de dados que não serão utilizados em consultas ou relatórios.

No exemplo da figura, está selecionada a classe Physical Memory (Win32_PhysicalMemory), responsável por fornecer informações detalhadas sobre os módulos de memória RAM instalados no computador. Entre os atributos disponíveis estão Capacity (MB), fabricante ou identificação do módulo, Bank Label, Device Locator, formato físico, largura de dados e outras características relacionadas à memória. Com essas informações, é possível identificar não apenas a quantidade total de memória instalada, mas também analisar cada módulo individualmente, facilitando atividades de inventário, troubleshooting e planejamento de upgrades.

A seleção das propriedades também permite tornar a coleta mais eficiente. Em ambientes com milhares de dispositivos, habilitar somente os atributos realmente necessários ajuda a reduzir o volume de informações enviadas pelos clientes e armazenadas na base de dados do SCCM. Depois de coletados, esses dados podem ser utilizados em queries, collections, relatórios SSRS e dashboards, permitindo, por exemplo, localizar computadores com menos de determinada quantidade de RAM ou identificar equipamentos que precisam de expansão de memória antes de uma atualização de sistema operacional.

Figura — Seleção da classe Win32_PhysicalMemory e das propriedades de memória física que serão coletadas pelo Hardware Inventory do Configuration Manager.

Para facilitar a utilização prática dessas informações, montei uma Query personalizada para o Microsoft Configuration Manager (SCCM), com o objetivo de consultar e organizar os dados de hardware já coletados pelo Hardware Inventory. A ideia é simplificar o acesso às informações armazenadas na base do Configuration Manager e permitir que administradores obtenham rapidamente uma visão consolidada dos equipamentos gerenciados.

A consulta pode ser utilizada como ponto de partida para inventários, auditorias, relatórios, análises de ciclo de vida e projetos de atualização de hardware. Dependendo das classes habilitadas no Hardware Inventory, ela pode ajudar a reunir informações como fabricante, modelo, processador, memória RAM, BIOS, armazenamento, TPM e outras características relevantes do dispositivo.

Para contribuir com outros profissionais que trabalham com SCCM, Endpoint Management e administração de ambientes Windows, deixei o código disponível publicamente em meu GitHub. A Query pode ser utilizada, adaptada e evoluída de acordo com as necessidades de cada ambiente.

O objetivo é justamente compartilhar uma base funcional com a comunidade, permitindo que outros administradores aproveitem o código em seus próprios projetos e, se desejarem, contribuam com melhorias e novas funcionalidades.

powershell/ColetaSCCM-Hardware.sql at main · edupopov/powershell

Configurações avançadas de energia do adaptador de rede, controlado por SCCM e GPO

2026-09-25T15:13:00.000-03:00

Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Azure | Powershell
Dados do autor: https://linktr.ee/edupopov

A importância da padronização das interfaces de rede em ambientes corporativos

Em ambientes corporativos modernos, a estabilidade da conectividade é um requisito fundamental para garantir o funcionamento adequado de serviços críticos, como autenticação 802.1X, acesso a recursos de rede, Microsoft Intune, Configuration Manager (SCCM/MECM), sistemas de monitoramento, aplicações corporativas e ferramentas de suporte remoto. Nesse contexto, a configuração padronizada das propriedades avançadas dos adaptadores de rede torna-se uma prática recomendada para reduzir incidentes relacionados à conectividade e aumentar a previsibilidade do ambiente.

Fabricantes como Realtek, Intel e Broadcom disponibilizam recursos voltados à economia de energia, tais como Energy Efficient Ethernet (EEE), Green Ethernet e outras funcionalidades que ajustam dinamicamente o comportamento da interface de rede. Embora esses recursos sejam benéficos em cenários domésticos ou de baixo consumo energético, em ambientes corporativos podem introduzir efeitos colaterais indesejados, incluindo:

Perda intermitente de conectividade;
Renegociação frequente do link de rede;
Lentidão na autenticação 802.1X;
Desconexões temporárias de aplicações;
Falhas em ferramentas de gerenciamento e inventário;
Instabilidade em processos de Wake-on-LAN (WoL).

Para mitigar esses problemas, é recomendável a aplicação de configurações padronizadas por meio de um script PowerShell, garantindo que todas as estações sigam o mesmo padrão operacional independentemente do fabricante da placa de rede.

Configurações avançadas do adaptador Realtek PCIe GBE Family Controller

As imagens apresentadas abaixo mostram algumas das propriedades avançadas disponíveis em adaptadores de rede Realtek PCIe GBE Family Controller. Essas configurações estão relacionadas principalmente à eficiência energética, Wake-on-LAN (WoL) e otimização do consumo elétrico da interface de rede.

Para ambientes corporativos, especialmente quando se utiliza 802.1X, Intune, SCCM, monitoramento remoto, Wake-on-LAN ou ferramentas de gerenciamento centralizado, é importante compreender os impactos dessas opções na disponibilidade e estabilidade da conexão de rede.

1. Ethernet Verde (Green Ethernet)

Descrição

A funcionalidade Ethernet Verde (Green Ethernet) é uma tecnologia desenvolvida para reduzir o consumo de energia do adaptador de rede quando determinadas condições são detectadas, como:

Baixa utilização da interface;
Comprimento reduzido do cabo de rede;
Períodos prolongados de inatividade.

Quando habilitada, a placa de rede pode reduzir automaticamente sua potência de transmissão.

Benefícios

Menor consumo de energia.
Redução da dissipação térmica do equipamento.
Menor impacto energético em grandes parques computacionais.

Possíveis impactos

Em ambientes corporativos já foram observados cenários de:

Perda intermitente de conectividade.
Demora na autenticação 802.1X.
Interrupções em sessões RDP.
Problemas em soluções de monitoramento e inventário.
Queda temporária do link após o retorno de estados de economia de energia.

Recomendação corporativa

Para estações que utilizam:

802.1X;
Wake-on-LAN;
SCCM/MECM;
Microsoft Intune;
Monitoramento contínuo;

é comum a recomendação de manter esta funcionalidade desabilitada, priorizando a estabilidade da conectividade.

2. Desligar Despertar Aguando de LAN

(Wake on LAN Shutdown Link Speed)

Descrição

Esta configuração define o comportamento da interface de rede quando o computador é desligado, mas permanece energizado para suportar o recebimento de pacotes Wake-on-LAN.

Enquanto o equipamento está desligado, a placa de rede continua energizada e pode permanecer operando em uma velocidade específica para aguardar o pacote de ativação.

Funcionalidade

Permite que o computador:

Seja ligado remotamente.
Receba pacotes Magic Packet.
Mantenha serviços de gerenciamento remoto.

Dependendo do driver, os valores normalmente encontrados são:

Not Speed Down
10 Mbps First
100 Mbps First
Auto

Benefícios

Garantia de funcionamento do Wake-on-LAN.
Maior previsibilidade para ferramentas de gerenciamento remoto.

Possíveis impactos

Em alguns modelos de switches ou ambientes 802.1X podem ocorrer:

Renegociação de link após o boot.
Pequeno atraso na autenticação.
Perda momentânea do estado da porta.

Recomendação corporativa

Manter habilitado somente quando houver necessidade de:

Wake-on-LAN;
Gerenciamento remoto;
Ativação remota através de SCCM ou ferramentas equivalentes.

3. Energia Eficiente Ethernet (Energy Efficient Ethernet - EEE)

Descrição

O recurso Energy Efficient Ethernet (IEEE 802.3az) permite que a interface de rede entre em estado de baixo consumo energético quando não está transmitindo ou recebendo dados.

O funcionamento baseia-se no conceito de Low Power Idle (LPI), no qual a comunicação continua estabelecida, porém o consumo elétrico é reduzido.

Benefícios

Economia de energia.
Menor utilização elétrica da placa de rede.
Adequação a iniciativas de TI Sustentável (Green IT).

Possíveis impactos

Embora seja um padrão amplamente suportado, existem relatos de incompatibilidade entre determinados:

Drivers de rede;
Switches;
Soluções de autenticação 802.1X;
Equipamentos VoIP;
Aplicações sensíveis à latência.

Os sintomas mais comuns são:

Perda ocasional de pacotes.
Lentidão para restabelecimento da comunicação.
Oscilações de link.
Eventos de desconexão e reconexão da interface.

Recomendação corporativa

Em ambientes empresariais críticos, é comum desabilitar o EEE quando são identificados:

Problemas de estabilidade;
Falhas de autenticação;
Reconexões frequentes da interface;
Incidentes envolvendo 802.1X.

Considerações para Ambientes com 802.1X

As três configurações apresentadas possuem um objetivo comum: reduzir o consumo energético da interface de rede. Entretanto, em ambientes que utilizam autenticação baseada em portas (IEEE 802.1X), essas otimizações podem interferir na manutenção do estado de autenticação entre cliente e switch.

Por esse motivo, uma prática amplamente adotada em ambientes corporativos é:

Configuração	Recomendação para estabilidade
Ethernet Verde	Desabilitado
Energia Eficiente Ethernet (EEE)	Desabilitado
Wake-on-LAN	Conforme necessidade operacional

Essa abordagem reduz a possibilidade de perda de link, renegociação de velocidade e falhas intermitentes de autenticação, especialmente em estações conectadas a infraestruturas de rede corporativas que utilizam políticas de segurança baseadas em identidade.

Exemplo prático

Durante a investigação de falhas de autenticação 802.1X, um equipamento pode apresentar desconexões periódicas sem perda aparente da conectividade física. Nesses casos, a desativação das funcionalidades Green Ethernet e Energy Efficient Ethernet (EEE) costuma ser uma das primeiras ações de troubleshooting, uma vez que elimina mecanismos automáticos de economia de energia que podem impactar a estabilidade da sessão de rede autenticada.

Benefícios da utilização do script

A automação da configuração das interfaces de rede oferece diversos benefícios operacionais:

Elimina configurações manuais e inconsistências entre equipamentos.
Reduz o tempo de atendimento de chamados relacionados à rede.
Melhora a estabilidade da autenticação 802.1X.
Padroniza o ambiente independentemente do fabricante do adaptador.
Facilita auditorias e processos de conformidade.
Reduz erros operacionais durante a implantação de novos dispositivos.

Além disso, o script pode identificar automaticamente adaptadores Intel, Broadcom e Realtek e aplicar as configurações apropriadas para cada fabricante, assegurando maior compatibilidade e reduzindo a necessidade de intervenção manual da equipe de suporte.

Script: powershell/DesativarEconomiaDeEnergiaEmPlacaDeRede.ps1 at main · edupopov/powershell

Deixo o script utilizado disponível em meu GitHub para quem se interessar. Se você utilizar um controlador de domínio, é importante deixar o script no caminho da NETLOGON.

Utilização através de Política de Grupo (GPO)

Nem todas as organizações possuem licenciamento ou infraestrutura para utilizar o Configuration Manager. Nesses casos, a Política de Grupo (Group Policy Objects - GPO) representa uma excelente alternativa para a distribuição do script.

A utilização de uma GPO de inicialização (Startup Script) permite que a configuração seja aplicada automaticamente quando o computador iniciar, sem a necessidade de intervenção do usuário.

Entre os principais benefícios estão:

Não requer licenciamento adicional.
Fácil implementação em ambientes Active Directory.
Distribuição automática para computadores pertencentes à Unidade Organizacional (OU) desejada.
Baixo custo operacional.
Facilidade de manutenção.

Embora a GPO não ofereça o mesmo nível de controle, auditoria e relatórios encontrados no SCCM, ela é perfeitamente capaz de sustentar a padronização das interfaces de rede em ambientes corporativos.

Note que a configuração da GPO utiliza o script de startup, com foco na configuração Run Windows PowerShell scripts firt.

Distribuição utilizando Microsoft Configuration Manager (SCCM/MECM)

Quando disponível, o Microsoft Configuration Manager (SCCM/MECM) é a solução mais robusta para a distribuição desse tipo de configuração.

Sua utilização oferece vantagens significativas:

Execução centralizada e controlada dos scripts.
Criação de coleções direcionadas por departamento, localização ou modelo de equipamento.
Monitoramento detalhado da execução.
Relatórios de conformidade em tempo real.
Reaplicação automática em caso de falha.
Integração com inventário de hardware e software.
Histórico de execução e auditoria.

Com o Configuration Manager, é possível identificar exatamente quais dispositivos receberam a configuração, quais apresentaram falha e quais permanecem fora de conformidade. Esse nível de governança torna a solução particularmente adequada para ambientes de médio e grande porte.

Por esses motivos, do ponto de vista operacional e de gerenciamento, o SCCM é considerado a alternativa mais completa e recomendada para implantações em larga escala.

Considerações finais

A padronização das configurações avançadas das interfaces de rede deve ser encarada como uma prática de governança da infraestrutura, especialmente em ambientes que dependem de autenticação 802.1X, gerenciamento centralizado e alta disponibilidade dos serviços de rede.

A utilização de um script PowerShell garante consistência entre os dispositivos, reduzindo falhas causadas por configurações divergentes entre fabricantes de hardware. Para distribuição em larga escala, o Microsoft Configuration Manager (SCCM/MECM) é a solução mais completa devido aos seus recursos avançados de gerenciamento, monitoramento e conformidade. Entretanto, organizações que não possuem esse licenciamento podem utilizar Políticas de Grupo (GPO) com excelentes resultados, mantendo um ambiente padronizado, estável e alinhado às boas práticas de administração de estações de trabalho corporativas.

Configurando e refinando o registro de dispositivos no Intune [Registro Automático]

2026-09-21T12:09:00.000-03:00

Área de tecnologia principal: Security | Intune
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

Quando iniciamos a implementação do Microsoft Intune, um dos aspectos mais relevantes e frequentemente subestimados é a definição da estratégia de registro de dispositivos. O método de registro adotado impacta diretamente a forma como os equipamentos serão gerenciados, monitorados e protegidos ao longo de seu ciclo de vida. Além disso, influencia a experiência do usuário durante o provisionamento, a aplicação de políticas corporativas, os controles de conformidade e a integração com outros serviços da plataforma Microsoft.

Neste post o foco estará voltado para dispositivos Windows, plataforma predominante na maioria dos ambientes corporativos e aquela que apresenta a maior variedade de cenários de integração com o Intune. Entretanto, limitar o planejamento exclusivamente ao Windows pode representar uma visão incompleta da solução. Organizações modernas frequentemente operam em ambientes heterogêneos, nos quais dispositivos macOS, iOS/iPadOS e Android coexistem e acessam recursos corporativos. Por esse motivo, compreender as alternativas de registro para diferentes sistemas operacionais deve fazer parte do processo de aprendizado e planejamento desde o início.

Na prática, o registro de dispositivos pode ocorrer por diferentes métodos, cada um adequado a necessidades específicas. Um notebook corporativo recém adquirido, por exemplo, pode ser provisionado por meio do Windows Autopilot, permitindo que o usuário receba o equipamento diretamente do fabricante e realize todo o processo de configuração utilizando apenas suas credenciais corporativas. Em outro cenário, um computador já existente no ambiente pode ser registrado automaticamente no Intune após ingressar no Microsoft Entra ID ou em uma configuração híbrida com Active Directory local. Há ainda situações em que dispositivos pessoais são registrados manualmente por meio da funcionalidade Acessar trabalho ou escola, possibilitando a aplicação de políticas de segurança sem que o equipamento seja totalmente incorporado ao patrimônio da organização.

Em ambientes que utilizam o Configuration Manager (SCCM), também é comum a adoção do modelo de Co gerenciamento, no qual determinadas cargas de trabalho permanecem sob responsabilidade do SCCM enquanto outras passam a ser gerenciadas pelo Intune. Essa abordagem permite uma transição gradual para um modelo de gerenciamento baseado em nuvem, minimizando impactos operacionais e preservando investimentos já realizados em infraestrutura.

Da mesma forma, dispositivos móveis apresentam cenários específicos de registro. Um smartphone Android corporativo pode ser inscrito como dispositivo totalmente gerenciado, permitindo controle integral por parte da organização. Já um dispositivo pessoal pode utilizar um perfil de trabalho separado, mantendo a privacidade do colaborador e, simultaneamente, protegendo os dados corporativos. No ecossistema Apple, a integração com o Apple Business Manager possibilita a inscrição automatizada e o provisionamento padronizado de equipamentos pertencentes à empresa.

Dessa forma, antes mesmo da criação das primeiras políticas de conformidade ou configuração, recomenda-se dedicar tempo à compreensão dos diferentes métodos de registro disponíveis. Uma estratégia bem definida nesta etapa tende a reduzir retrabalho, simplificar operações futuras e garantir que os dispositivos sejam incorporados ao ambiente de maneira segura, consistente e alinhada aos objetivos de governança e segurança da informação da organização.

Para facilitar o processo de aprendizado e a evolução das configurações do Microsoft Intune, selecionei alguns componentes fundamentais que merecem atenção nas etapas iniciais da implementação. Embora a plataforma ofereça uma ampla variedade de recursos voltados ao gerenciamento moderno de dispositivos, aplicações e identidades, todo o processo tem início com uma das etapas mais importantes da jornada: o registro dos dispositivos.

O registro representa o mecanismo por meio do qual um dispositivo passa a ser reconhecido e gerenciado pela organização. É a partir desse momento que o Intune estabelece uma relação de confiança com o equipamento, permitindo a aplicação de políticas de configuração, controles de conformidade, recursos de segurança, distribuição de aplicativos e outras capacidades administrativas. Em outras palavras, sem uma estratégia adequada de registro, torna-se inviável exercer governança efetiva sobre os dispositivos que acessam os recursos corporativos.

Nesse contexto, é importante compreender que o gerenciamento moderno não se limita apenas a computadores Windows. Smartphones, tablets e outros dispositivos móveis também fazem parte do ecossistema corporativo e, consequentemente, exigem mecanismos apropriados de registro e gerenciamento. Portanto, ao planejar a adoção do Intune, é necessário considerar como a organização pretende integrar e administrar os diferentes tipos de dispositivos que ingressam em seu ambiente.

Como ponto de partida, abordaremos o Registro Automático (Automatic Enrollment), uma das formas mais eficientes e amplamente utilizadas para incorporar dispositivos ao Intune. Esse modelo permite que equipamentos Windows sejam registrados automaticamente durante processos como o Microsoft Entra ID Join, Hybrid Join ou Windows Autopilot, reduzindo a intervenção manual, simplificando o provisionamento e garantindo maior padronização operacional. A compreensão desse recurso constitui a base para a construção de uma estratégia sólida de gerenciamento de dispositivos em ambientes corporativos modernos.

Registro Automático

Quando usar:

Dispositivos Microsoft Entra ID Join.
Microsoft Entra Hybrid Join.
Windows Autopilot.
Migração de SCCM para Intune.
Provisionamento em massa de notebooks.

Recomendação: Na maioria dos ambientes corporativos modernos, esta opção deve estar habilitada para evitar registros manuais

Configuração de Registro Automático do Microsoft Intune (MDM User Scope)

Nota: Todas as informações sensíveis, URLs e identificadores visíveis nas capturas de tela foram anonimizados para fins didáticos. Embora as configurações apresentadas pertençam a um ambiente de laboratório não produtivo, a anonimização foi mantida como boa prática de segurança e governança da informação. Tomei o cuidado de deixar referenciado o material oficial Microsoft sobre as configurações.

A configuração apresentada corresponde ao recurso de Registro Automático (Automatic Enrollment) do Microsoft Intune, responsável por determinar quais usuários terão seus dispositivos inscritos automaticamente na plataforma durante processos de associação ao Microsoft Entra ID. Trata-se de um dos componentes mais importantes da arquitetura de gerenciamento moderno de dispositivos, uma vez que estabelece a ponte entre a identidade do usuário e os serviços de gerenciamento disponibilizados pelo Intune. [learn.microsoft.com]

De forma conceitual, quando um usuário ingressa um dispositivo no Microsoft Entra ID ou realiza o registro de uma conta corporativa no Windows, o serviço verifica se aquele usuário está contemplado pelo escopo de gerenciamento definido nesta configuração. Caso esteja, o dispositivo é automaticamente inscrito no Intune e passa a receber políticas de conformidade, configurações de segurança, aplicações corporativas e demais recursos de administração centralizada. [learn.microsoft.com]

Escopo do Usuário do MDM

O elemento central da configuração é o campo Escopo do usuário do MDM, que pode assumir três valores distintos: Nenhum, Algum ou Tudo.

A opção Nenhum impede que o registro automático ocorra. Neste cenário, os dispositivos podem ingressar no Microsoft Entra ID normalmente, mas não serão inscritos automaticamente no Intune. Essa configuração é frequentemente utilizada durante fases iniciais de implantação, ambientes de laboratório ou situações em que o gerenciamento dos dispositivos ainda não foi planejado. [learn.microsoft.com]

A opção Algum, observada na captura de tela, limita o registro automático aos usuários pertencentes a grupos específicos. Trata-se da abordagem mais recomendada para projetos corporativos, pois permite validar o ambiente de maneira controlada antes da expansão para toda a organização. [learn.microsoft.com]

Um exemplo prático seria a criação dos seguintes grupos:

Intune-Pilot
Intune-TI
Intune-Gestores
Intune-Corporativo

Inicialmente, somente os profissionais de tecnologia seriam incluídos no grupo piloto. Após a validação dos processos de provisionamento, distribuição de aplicações e aplicação de políticas, outros grupos poderiam ser incorporados gradativamente à solução.

Por fim, a opção Tudo habilita o registro automático para todos os usuários licenciados da organização. Nessa configuração, qualquer dispositivo que realize Microsoft Entra Join, Hybrid Join ou processos de provisionamento utilizando Windows Autopilot será automaticamente registrado no Intune. Esse modelo é geralmente adotado em ambientes já maduros e com governança consolidada. [learn.microsoft.com]

Associação com Cenários de Registro

A relevância desta configuração torna-se mais evidente quando analisamos alguns cenários reais de utilização.

No contexto de um equipamento novo adquirido pela organização, o administrador pode utilizar o Windows Autopilot para provisionar o dispositivo. Durante a primeira inicialização, o usuário informa suas credenciais corporativas e, após a autenticação, o dispositivo ingressa no Microsoft Entra ID. Se o usuário estiver contemplado pelo escopo MDM, o equipamento será automaticamente inscrito no Intune e receberá todas as configurações definidas pela organização. [learn.microsoft.com]

Em ambientes híbridos, onde coexistem Active Directory local e Microsoft Entra ID, o mesmo comportamento pode ser obtido por meio do Hybrid Join. Nesse caso, dispositivos tradicionalmente associados ao domínio local passam a ser inscritos automaticamente no Intune, permitindo uma coexistência controlada entre o gerenciamento tradicional e o gerenciamento baseado em nuvem. [learn.microsoft.com]

URLs de Serviço do MDM

A configuração também apresenta três campos relacionados às URLs de serviço do Intune:

URL dos Termos de Uso do MDM
URL de Descoberta MDM
URL de Conformidade do MDM

Embora normalmente sejam preenchidos automaticamente pela Microsoft, esses elementos possuem funções importantes.

A URL de Descoberta MDM é utilizada pelo sistema operacional para localizar o serviço responsável pelo gerenciamento do dispositivo. Durante o processo de inscrição, o Windows consulta esse endereço para identificar qual plataforma MDM deverá assumir o gerenciamento do equipamento. [learn.microsoft.com]

A URL de Conformidade do MDM participa das verificações realizadas entre o Microsoft Entra ID e o Intune. É por meio desse mecanismo que o serviço consegue determinar se um dispositivo atende aos requisitos corporativos definidos em políticas de conformidade. [learn.microsoft.com]

Por sua vez, a URL dos Termos de Uso do MDM pode direcionar o usuário para documentos institucionais, como políticas de uso aceitável, termos de responsabilidade sobre ativos corporativos ou regulamentos relacionados à segurança da informação.

Controle de Registro ao Adicionar Contas Corporativas

Outro parâmetro relevante é a opção Desabilitar o registro de MDM ao adicionar uma conta corporativa ou de estudante no Windows.

Quando configurada como Não, conforme observado na imagem, o Windows pode iniciar automaticamente o processo de inscrição no Intune quando o usuário adiciona uma conta corporativa em:

Configurações → Contas → Acessar trabalho ou escola

Esse comportamento simplifica significativamente o onboarding de usuários e reduz a necessidade de intervenções manuais por parte da equipe de suporte. [learn.microsoft.com]

Escopo do Usuário da Proteção de Informações do Windows (WIP)

A segunda parte da tela refere-se ao Windows Information Protection (WIP), tecnologia originalmente desenvolvida para separar dados corporativos e pessoais em dispositivos Windows.

Historicamente, o WIP permitia aplicar controles de proteção sobre informações corporativas sem exigir o gerenciamento completo do dispositivo. Entretanto, a própria Microsoft informa que novos cenários de implantação dessa tecnologia deixaram de receber evolução e suporte para novos projetos. [learn.microsoft.com]

Em arquiteturas modernas, recomenda-se priorizar recursos mais recentes, tais como:

Microsoft Purview Information Protection;
Sensitivity Labels;
Data Loss Prevention (DLP);
App Protection Policies (MAM). [learn.microsoft.com]

Importância do Grupo Selecionado no Escopo de Registro Automático do Intune

Um dos elementos mais importantes da configuração de Registro Automático (Automatic Enrollment) do Microsoft Intune é a definição dos grupos associados ao Escopo do Usuário do MDM. Embora muitas vezes essa configuração receba pouca atenção durante as etapas iniciais da implantação, ela exerce papel fundamental no controle, na governança e na previsibilidade do processo de registro de dispositivos. [learn.microsoft.com],

Quando a opção"Algum" é selecionada no escopo do MDM, o Intune passa a verificar se o usuário que está realizando o registro do dispositivo pertence a um dos grupos configurados. Somente usuários membros desses grupos terão seus dispositivos inscritos automaticamente na plataforma. Na prática, isso transforma o grupo em um mecanismo de autorização para o processo de gerenciamento de dispositivos. [learn.microsoft.com]

Sob uma perspectiva de arquitetura, esse grupo funciona como uma camada de controle operacional. Em vez de permitir que todos os usuários da organização registrem dispositivos automaticamente, a equipe de tecnologia pode estabelecer quais pessoas ou departamentos participarão da iniciativa de gerenciamento moderno. Essa abordagem reduz riscos, facilita testes e permite a identificação antecipada de problemas antes da expansão da solução para toda a organização. [learn.microsoft.com],

Papel do Grupo Durante uma Implantação

Em um cenário de implantação corporativa, recomenda-se que o registro automático seja introduzido de forma gradual. Considere, por exemplo, uma organização que está migrando de um modelo tradicional baseado exclusivamente em Active Directory e SCCM para um ambiente híbrido com Microsoft Intune.

Uma estratégia comum consiste em criar inicialmente um grupo denominado Intune-Pilot. Esse grupo normalmente é composto por:

Administradores de infraestrutura;
Analistas de suporte;
Especialistas de endpoint management;
Profissionais responsáveis pela implantação do projeto.

Ao ingressarem seus dispositivos no Microsoft Entra ID, apenas esses usuários terão seus equipamentos registrados automaticamente no Intune. Isso permite validar processos como:

Aplicação de políticas de conformidade;
Distribuição de aplicativos corporativos;
Configurações de segurança;
Implantação de atualizações;
Integração com Microsoft Defender;
Processos de Windows Autopilot. [learn.microsoft.com],

Após a validação inicial, novos grupos podem ser incorporados ao escopo de gerenciamento, ampliando gradativamente a adoção da solução.

O Que Deve Conter Esse Grupo

A composição do grupo deve refletir a estratégia de implantação adotada pela organização.

Durante a fase de testes, recomenda-se incluir apenas usuários tecnicamente preparados para lidar com eventuais falhas ou comportamentos inesperados. Nessa etapa, não é aconselhável adicionar usuários finais de áreas críticas ao negócio.

Um grupo piloto normalmente contém:

Equipe de infraestrutura;
Equipe de segurança da informação;
Equipe de suporte de segundo e terceiro nível;
Responsáveis pelo projeto de Intune;
Usuários-chave que aceitaram participar dos testes.

À medida que a solução amadurece, o grupo pode ser expandido para contemplar:

Gestores;
Equipes administrativas;
Usuários de escritório;
Dispositivos compartilhados;
Dispositivos corporativos recém-adquiridos.

Em uma fase de produção consolidada, muitas organizações optam por migrar da opção"Algum" para"Tudo", permitindo que qualquer usuário licenciado seja registrado automaticamente. Entretanto, mesmo nesses cenários, é comum manter grupos específicos para controle de funcionalidades avançadas, testes de novas políticas ou distribuição controlada de recursos. [learn.microsoft.com]

Boas Práticas de Governança

Do ponto de vista de governança, recomenda-se evitar a utilização de grupos genéricos ou sem critério de associação. O ideal é que o grupo represente claramente o público autorizado a utilizar o gerenciamento moderno de dispositivos.

Também é recomendável que esses grupos sejam dinâmicos ou possuam processos formais de inclusão e remoção de membros, evitando que usuários não licenciados ou não autorizados sejam inscritos inadvertidamente na plataforma.

Considerações Finais

Sob a perspectiva arquitetural, o Escopo do Usuário do MDM pode ser considerado o principal mecanismo de controle do processo de inscrição automática no Intune. Ele define quais usuários poderão ter seus dispositivos gerenciados automaticamente, além de influenciar diretamente iniciativas relacionadas a Microsoft Entra Join, Hybrid Join, Windows Autopilot e estratégias de migração de SCCM para Intune.

Em razão de sua importância, recomenda-se que essa configuração seja inicialmente implantada utilizando grupos piloto e expandida gradualmente à medida que os processos operacionais, de suporte e governança forem amadurecendo.

BitNet: Microsoft mostra como executar IA de até 100 bilhões de parâmetros usando uma única CPU

2026-09-18T16:05:00.000-03:00

Área de tecnologia principal: Azure | Microsoft Azure
Áreas de tecnologia adicionais: M365 | Copilot
Dados do autor: https://linktr.ee/edupopov

A Microsoft Research vem trabalhando em uma abordagem que pode mudar significativamente a forma como pensamos sobre a infraestrutura necessária para executar modelos de Inteligência Artificial.

O projeto chama-se BitNet e uma das peças mais interessantes desse ecossistema é o bitnet.cpp, framework de inferência desenvolvido especificamente para modelos de linguagem de aproximadamente 1,58 bit.

A proposta é relativamente simples de explicar, mas bastante impactante: permitir que grandes modelos de linguagem sejam executados utilizando muito menos memória, processamento e energia — inclusive em CPUs convencionais, sem a obrigatoriedade de utilizar GPUs de alto desempenho ou infraestrutura especializada em nuvem.

O que torna o BitNet diferente?

Grande parte dos modelos de linguagem tradicionais trabalha com pesos representados em formatos como FP32, FP16 ou BF16.

FP32, FP16 e BF16 não são tipos de parâmetros do modelo; são formatos numéricos usados para armazenar valores, como os pesos de uma rede neural.

Em um LLM, existem bilhões de valores matemáticos representando os pesos do modelo. Esses números precisam ser armazenados na memória de alguma forma. É aí que entram esses formatos.

FP32 — Floating Point 32 bits: usa 32 bits, ou 4 bytes, para armazenar cada valor. Tem boa precisão, mas consome mais memória e processamento.
FP16 — Floating Point 16 bits: usa 16 bits, ou 2 bytes. Consome metade da memória do FP32 e é muito utilizado em GPUs para treinamento e inferência.
BF16 — BFloat16: também usa 16 bits, mas distribui esses bits de forma diferente. Ele preserva uma faixa numérica semelhante ao FP32, porém com menor precisão nos detalhes. É muito usado em treinamento de IA em GPUs e aceleradores modernos.

Um exemplo ajuda bastante. Imagine um modelo com 100 bilhões de parâmetros. Considerando apenas os pesos, sem contar memória adicional necessária para execução:

Isso significa que cada parâmetro do modelo precisa de vários bits para ser armazenado e processado.

O BitNet b1.58 propõe uma abordagem completamente diferente.

Seus pesos são ternários, podendo assumir apenas três valores:

-1, 0 ou +1

Matematicamente, três estados podem ser representados com aproximadamente 1,58 bit de informação, daí o nome BitNet b1.58.

Essa simplificação permite desenvolver kernels de inferência altamente otimizados, reduzindo significativamente a quantidade de dados movimentados pela memória e diminuindo o custo computacional das operações realizadas durante a geração dos tokens.

Não significa que as operações matriciais simplesmente deixaram de existir. A grande diferença está na maneira como os pesos são representados e processados, permitindo substituir diversas operações mais caras de ponto flutuante por implementações extremamente eficientes voltadas para modelos ternários.

Um modelo de 100 bilhões de parâmetros em uma única CPU?

Este talvez seja o dado que mais chama atenção no projeto.

Segundo os resultados publicados pela Microsoft Research, o bitnet.cpp consegue executar experimentalmente um modelo BitNet b1.58 de 100 bilhões de parâmetros em uma única CPU, atingindo aproximadamente:

5 a 7 tokens por segundo.

É uma velocidade que os pesquisadores comparam aproximadamente ao ritmo de leitura humana.

Os resultados foram obtidos em cenários de pesquisa e variam conforme arquitetura, tamanho do modelo, hardware e configuração utilizada. Portanto, não devemos interpretar esses números como garantia de que qualquer notebook executará automaticamente um modelo 100B a 7 tokens por segundo.

Ainda assim, a demonstração é extremamente relevante porque mostra que CPU pode voltar a desempenhar um papel importante na inferência de grandes modelos de IA.

Um ponto importante sobre o modelo de 100B

Aqui existe uma distinção que considero importante.

A Microsoft não disponibilizou um BitNet oficial de 100 bilhões de parâmetros como seu principal modelo público.

O cenário de 100B apresentado no projeto está relacionado aos experimentos utilizados para demonstrar a capacidade e a escalabilidade do framework de inferência.

O modelo oficial disponibilizado pela Microsoft é o BitNet b1.58 2B4T, atualmente apresentado no repositório como um modelo de aproximadamente 2,4 bilhões de parâmetros, treinado com nada menos que 4 trilhões de tokens.

Essa distinção é importante para não transformar um resultado de pesquisa em uma afirmação comercial.

E a qualidade do modelo?

Naturalmente surge uma pergunta:

reduzir tanto a precisão numérica não destrói a qualidade do modelo?

Os resultados apresentados pelos pesquisadores indicam que não necessariamente.

O BitNet b1.58 2B4T foi treinado nativamente utilizando essa arquitetura e avaliado em diferentes tipos de benchmarks, envolvendo compreensão de linguagem, raciocínio matemático, programação e conversação.

Segundo o relatório técnico, o modelo consegue apresentar resultados competitivos quando comparado a outros modelos abertos de precisão completa e tamanho semelhante.

Este detalhe é fundamental.

Não estamos falando simplesmente de pegar qualquer modelo tradicional treinado em FP16 e comprimi-lo agressivamente depois.

O conceito do BitNet envolve treinar modelos desde o início considerando a representação ternária dos pesos.

É uma mudança de arquitetura, e não apenas uma técnica convencional de compressão aplicada no final do processo.

Por que isso pode ser tão importante?

Durante os últimos anos, a evolução dos LLMs esteve diretamente associada à necessidade de GPUs cada vez mais poderosas.

Quanto maior o modelo, maior normalmente é a necessidade de:

Projetos como o BitNet tentam atacar justamente essa relação.

Se modelos cada vez mais eficientes puderem executar localmente utilizando CPU, uma nova categoria de aplicações torna-se possível.

IA completamente offline

Um dos cenários mais interessantes é executar modelos de Inteligência Artificial sem conexão permanente com a Internet.

Isso permite que prompts, documentos e informações processadas permaneçam dentro do próprio equipamento.

Para empresas preocupadas com privacidade, soberania de dados, compliance e proteção de informações corporativas, este modelo de utilização é particularmente interessante.

Naturalmente, executar um LLM localmente não elimina sozinho todos os riscos de segurança, mas reduz a necessidade de enviar cada interação para uma infraestrutura externa.

Edge Computing e IoT

Outro possível impacto está no chamado Edge Computing.

Imagine modelos de IA executando diretamente em:

notebooks;
servidores locais;
dispositivos embarcados;
equipamentos industriais;
sistemas de automação;
dispositivos IoT;
estações localizadas em regiões com pouca conectividade.

Modelos menores e computacionalmente eficientes tornam muito mais viável colocar Inteligência Artificial próxima da origem dos dados.

Em vez de:

Dispositivo → Internet → Cloud → LLM → Internet → Dispositivo

podemos começar a trabalhar em determinados cenários com:

Dispositivo → LLM local

Isso reduz dependência de conectividade, latência e, dependendo da aplicação, também custos operacionais.

Menos dependência do custo de inferência em nuvem

Outro aspecto interessante é econômico.

Hoje, muitas aplicações baseadas em Inteligência Artificial trabalham com APIs onde o custo está diretamente associado à quantidade de tokens processados.

Quanto maior a utilização, maior a conta.

Executar determinados modelos localmente permite mudar essa equação.

O custo deixa de estar necessariamente associado a:

cada prompt + cada token + cada resposta

e passa a estar relacionado principalmente à infraestrutura já disponível.

Não significa que a nuvem deixará de ser necessária.

Muito pelo contrário.

Modelos gigantes, treinamento de IA e grandes cargas corporativas continuarão utilizando GPUs, aceleradores e datacenters especializados.

Mas podemos começar a ter uma arquitetura híbrida muito mais interessante:

IA local para determinadas tarefas + IA em nuvem para tarefas mais complexas.

ARM e x86

Outro ponto bastante relevante é o suporte às duas principais arquiteturas presentes atualmente no mercado.

O BitNet trabalha com plataformas:

x86

presentes em grande parte dos computadores e servidores Intel e AMD;

ARM

cada vez mais presente em notebooks, dispositivos móveis, equipamentos de borda e computadores baseados em Apple Silicon.

O projeto atualmente oferece inferência otimizada em CPU e também já recebeu suporte oficial para GPU, enquanto suporte a NPU continua fazendo parte da evolução do projeto.

Código aberto

Talvez outro elemento que ajude a explicar o interesse da comunidade seja o fato de o projeto estar disponível publicamente.

O bitnet.cpp é open source e distribuído sob licença MIT.

Em agosto de 2026, o repositório oficial da Microsoft já ultrapassava aproximadamente 40 mil estrelas e 3,7 mil forks no GitHub, demonstrando o interesse crescente da comunidade em torno da ideia de modelos extremamente eficientes.

Estamos entrando na era dos LLMs de 1 bit?

Ainda é cedo para dizer que modelos tradicionais serão simplesmente substituídos por arquiteturas de 1 bit.

Existem inúmeros desafios relacionados a treinamento, compatibilidade, hardware, ecossistema, qualidade dos modelos e desenvolvimento das aplicações.

Mas o BitNet mostra algo extremamente importante:

O futuro da Inteligência Artificial não depende apenas de construir modelos maiores.

Também depende de descobrir maneiras muito mais eficientes de executá-los.

Durante anos, uma das principais discussões do mercado foi:

Quantas GPUs precisamos para executar este modelo?

Talvez uma pergunta igualmente importante comece a ganhar espaço:

Quanto conseguimos reduzir o custo computacional desse modelo sem comprometer sua capacidade?

Se pesquisas como o BitNet continuarem evoluindo, poderemos ver modelos bastante poderosos executando em equipamentos que hoje sequer consideramos adequados para grandes cargas de Inteligência Artificial.

Isso pode significar IA privada, local, offline, distribuída e muito mais próxima do usuário.

E talvez essa seja uma das evoluções mais interessantes da Inteligência Artificial nos próximos anos.

Fontes e referências

Microsoft — BitNet / bitnet.cpp
Repositório oficial Microsoft Research no GitHub: microsoft/BitNet

Microsoft Research — The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits
Relatório que apresenta os fundamentos da arquitetura BitNet b1.58.

Microsoft Research — 1-bit AI Infra: Fast and Lossless BitNet b1.58 Inference on CPUs
Trabalho técnico responsável pelos benchmarks do framework bitnet.cpp.

Microsoft Research — BitNet b1.58 2B4T Technical Report
Relatório técnico do modelo treinado com 4 trilhões de tokens.

Fonte original utilizada como referência para este artigo:
https://lnkd.in/eebehapK

Os resultados de desempenho apresentados neste artigo são baseados nos benchmarks publicados pelos pesquisadores da Microsoft. O desempenho real pode variar de acordo com processador, quantidade de memória, arquitetura, modelo e configuração utilizada.

O Renascimento do Aprendizado em Active Directory - A Microsoft Resgata a Profundidade Técnica das Certificações Clássicas em formato de novas trilhas

2026-09-14T17:08:00.000-03:00

Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

Para quem viveu a era de ouro das certificações Microsoft, especialmente durante os tempos do MCSE clássico no Windows 2000 Server e Windows Server 2003, é impossível não sentir uma certa nostalgia ao analisar a nova trilha de treinamento sobre Active Directory Domain Services (AD DS) disponibilizada pela Microsoft Learn. Durante muitos anos, o conteúdo oficial priorizou uma abordagem mais fragmentada e focada em cenários específicos. Agora, a Microsoft parece estar retomando um modelo muito mais estruturado e progressivo, semelhante ao que formou gerações de administradores de infraestrutura no final dos anos 1990 e início dos anos 2000.

O resultado é uma jornada educacional extremamente completa, organizada desde os conceitos fundamentais até temas avançados de arquitetura, recuperação de desastres, segurança, replicação e migração. Trata-se, sem dúvida, de uma das trilhas mais abrangentes já disponibilizadas gratuitamente para quem deseja dominar Active Directory.

Nível Iniciante: Construindo os Fundamentos

A trilha começa apresentando os conceitos essenciais do serviço de diretório da Microsoft.

1. Introdução ao Active Directory Domain Services

Nível: Iniciante

O primeiro módulo estabelece toda a base conceitual necessária para compreender o ecossistema do Active Directory. São abordados elementos fundamentais como florestas, domínios, controladores de domínio, sites, unidades organizacionais (OUs), grupos, usuários e computadores. Além dos conceitos, o treinamento demonstra como os objetos do diretório são estruturados e administrados.

Link:
Introdução ao Active Directory Domain Services

2. Gerenciamento de Usuários e Grupos

Nível: Iniciante

Após compreender a estrutura do diretório, o aluno passa a conhecer a administração das identidades. O curso explora o gerenciamento de usuários e grupos, apresenta as diferenças entre o AD DS e o Microsoft Entra ID e detalha o funcionamento dos processos de autenticação e logon em ambientes corporativos.

Link:
Gerenciar Usuários e Grupos

Nível Intermediário: Administração Operacional

Com os fundamentos estabelecidos, a trilha avança para as atividades administrativas do dia a dia.

3. Criação e Gerenciamento de Objetos do Active Directory

Nível: Intermediário

Este módulo transforma teoria em prática. O profissional aprende a criar, modificar e administrar usuários, grupos, computadores e unidades organizacionais, além de realizar operações em massa e tarefas básicas relacionadas aos controladores de domínio.

Link:
Criar e Gerenciar Objetos do Active Directory

4. Administração do Active Directory com PowerShell

Nível: Intermediário

A automação é um tema indispensável para administradores modernos. Neste treinamento, são apresentados os cmdlets específicos do Active Directory, permitindo automatizar a criação, modificação e manutenção dos objetos do diretório.

Link:
Gerenciar AD DS com PowerShell

5. Implantação e Administração de Controladores de Domínio

Nível: Intermediário

O foco passa a ser a infraestrutura que suporta o Active Directory. O módulo explora a implantação de controladores de domínio, a topologia entre sites, o posicionamento dos servidores e os conceitos relacionados à estrutura lógica do ambiente.

Link:
Implantar e Gerenciar Controladores de Domínio

6. Administração de FSMO e Controladores de Domínio

Nível: Intermediário

Aqui o aluno aprofunda seus conhecimentos sobre manutenção dos controladores de domínio, posicionamento do Catálogo Global (Global Catalog), backup, recuperação e gerenciamento das funções FSMO (Flexible Single Master Operations).

Link:
Gerenciar FSMO e Controladores de Domínio

7. Implementação de Objetos de Política de Grupo (GPO)

Nível: Intermediário

As Políticas de Grupo continuam sendo uma das ferramentas mais poderosas do Active Directory. Este módulo apresenta conceitos como herança, escopo, processamento, templates administrativos e Central Store.

Link:
Implementar Group Policy Objects

8. Criação e Configuração Avançada de GPOs

Nível: Intermediário

Complementando o módulo anterior, esta etapa aprofunda o uso das políticas de grupo, incluindo políticas de senha tradicionais e políticas de senha granular.

Link:
Criar e Configurar GPOs no Active Directory

9. Segurança no Active Directory

Nível: Intermediário

O treinamento aborda boas práticas modernas de proteção do diretório, contemplando delegação de permissões, restrições de acesso, Credential Guard, bloqueio do NTLM e proteção de contas privilegiadas.

Link:
Gerenciar Segurança no Active Directory

10. Active Directory Certificate Services (AD CS)

Nível: Intermediário

Nesta fase, a trilha introduz conceitos de infraestrutura de chaves públicas (PKI), autoridades certificadoras, emissão e revogação de certificados e modelos de confiança.

Link:
Implementar e Gerenciar AD CS

Nível Avançado: Arquitetura, Segurança e Recuperação

É nesse ponto que a trilha realmente lembra os antigos currículos MCSE. Os módulos avançados mergulham profundamente nos mecanismos internos do Active Directory.

Principais tópicos abordados

Segurança Avançada e Hardening

O conteúdo aprofunda o funcionamento de políticas de segurança, auditoria, Kerberos, controles de acesso, grupos protegidos e baselines de configuração do Windows Server.

Links:

DNS Integrado ao Active Directory

Um dos tópicos mais críticos para qualquer administrador. O módulo detalha registros SRV, descoberta de controladores de domínio, zonas integradas ao AD e resolução de problemas.

Link:

Como o Active Directory Utiliza DNS

Replicação e Topologia

A replicação sempre foi um dos assuntos mais importantes e desafiadores do Active Directory. A Microsoft explora profundamente conceitos como KCC, ISTG, Site Links, custos de replicação e diagnóstico de falhas.

Links:

Banco de Dados do Active Directory e SYSVOL

Um dos módulos mais interessantes da trilha. O treinamento mostra em detalhes como funcionam o banco de dados NTDS.DIT, a replicação lógica do diretório e os mecanismos de replicação do SYSVOL.

Link:

Banco de Dados do Active Directory e SYSVOL

Schema do Active Directory

Tema tradicionalmente tratado apenas em cursos avançados, o Schema recebe uma cobertura completa, incluindo extensões, replicação, indexação e impactos organizacionais.

Link:

Entendendo o Schema do Active Directory

Arquitetura e Design

Os conceitos de arquitetura aparecem em dois módulos extremamente relevantes para arquitetos e administradores seniores:

Esses treinamentos discutem isolamento administrativo, trusts, namespaces, replicação, governança de schema e cenários corporativos complexos.

Recursos Avançados e Ambientes Híbridos

A trilha também aborda:

Recuperação e Troubleshooting

Para fechar a jornada, a Microsoft dedica módulos completos à recuperação de desastres e resolução de problemas.

Links:

Considerações Finais

Artigo original de Orin Thomas, em 17 de Agosto de 2026

Active Directory Domain Services modules on Microsoft Learn | Microsoft Community Hub

Windows Hardening

Some tools and techniques for hardening Windows Server | Microsoft Community Hub

O que mais chama a atenção nessa iniciativa não é apenas a quantidade de conteúdo, mas a forma como ele foi organizado. Pela primeira vez em muitos anos, a Microsoft disponibiliza uma trilha de aprendizado que conduz o profissional por uma progressão lógica de conhecimento, começando pelos conceitos fundamentais e avançando gradualmente até arquitetura corporativa, replicação, segurança avançada e recuperação de ambientes críticos.

Como alguém que estudou Active Directory na época das certificações MCSE clássicas, confesso que essa abordagem me causou uma excelente impressão. Há uma sensação familiar de retorno ao aprendizado estruturado que marcou o final dos anos 1990 e o início dos anos 2000, quando os cursos não ensinavam apenas a clicar em assistentes gráficos, mas buscavam explicar o funcionamento interno das tecnologias.

Para administradores de infraestrutura, engenheiros de sistemas, arquitetos de identidade e profissionais que desejam dominar verdadeiramente o Active Directory, esta trilha representa provavelmente uma das melhores oportunidades de capacitação gratuita oferecidas pela Microsoft nos últimos anos. Ela demonstra que, mesmo em uma era fortemente orientada à nuvem, compreender profundamente os fundamentos do Active Directory continua sendo um diferencial valioso para qualquer especialista em identidade e infraestrutura corporativa.

Palestra confirmada MVPConf - 26 Setembro de 2026

2026-09-14T16:38:26.380-03:00

Palestrantes: MVPConf 2026 | 260 Palestras, 12 Trilhas e 44 Salas

Geração de ATAs por IA - Habilite o Transcript API Access no Teams para permitir que o Microsoft Graph acesse a trascrição das calls

2026-09-11T16:05:00.000-03:00

Área de tecnologia principal: M365 | Teams
Áreas de tecnologia adicionais: Security | Identity & Access
Dados do autor: https://linktr.ee/edupopov

Introdução

A transformação digital das organizações deixou de estar concentrada apenas na automação de processos e passou a incorporar mecanismos avançados de inteligência artificial capazes de compreender linguagem natural, identificar padrões e gerar conhecimento a partir de interações humanas. Nesse contexto, as reuniões corporativas tornaram-se uma das mais relevantes fontes de informação organizacional, contendo decisões estratégicas, definições de projetos, distribuição de responsabilidades e debates que frequentemente não são registrados em documentos formais.

O avanço das plataformas colaborativas permitiu que as reuniões fossem gravadas, transcritas e armazenadas digitalmente. Mais recentemente, a possibilidade de disponibilizar essas transcrições por meio de APIs transformou um simples recurso de acessibilidade em um ativo de elevado valor para iniciativas de inteligência artificial, automação documental e gestão do conhecimento. A Microsoft passou a disponibilizar controles específicos para governar o acesso às transcrições das reuniões por meio do Microsoft Graph, incluindo a possibilidade de fornecer ou ocultar a atribuição dos participantes que realizaram cada intervenção.

Essa mudança reflete uma tendência crescente: organizações estão deixando de utilizar a transcrição apenas como registro histórico e passando a tratá-la como matéria-prima para sistemas inteligentes capazes de gerar valor operacional e estratégico.

A evolução da ata de reunião tradicional

Durante décadas, a elaboração de atas dependeu da tomada manual de notas por um participante designado. Embora esse método tenha sido amplamente utilizado, ele apresenta limitações significativas:

Perda de detalhes importantes.
Interpretação subjetiva do responsável pela documentação.
Dificuldade para identificar decisões implícitas.
Ausência de rastreabilidade sobre quem assumiu determinada responsabilidade.
Elevado consumo de tempo administrativo.

Com a popularização dos modelos de linguagem de grande escala (LLMs), tornou-se possível automatizar praticamente todo o processo de documentação de reuniões. Entretanto, para que uma IA produza uma ata confiável, ela precisa ter acesso ao conteúdo completo da discussão.

As transcrições deixaram de ser apenas um registro textual e passaram a representar uma fonte estruturada de dados conversacionais, apta para alimentar algoritmos de análise semântica, mineração de conhecimento e automação documental.

O papel da atribuição de participantes

Entre as funcionalidades mais relevantes encontra-se a chamada speaker attribution, ou atribuição de participantes. Quando habilitada, a transcrição não informa apenas o conteúdo discutido, mas também identifica quem realizou cada intervenção durante a reunião.

Sob a perspectiva da inteligência artificial, essa informação agrega um contexto extremamente valioso.

Considere os dois cenários abaixo:

Cenário sem atribuição

"O relatório deve ser entregue até sexta-feira."

Nesse exemplo, existe uma decisão registrada, porém não é possível identificar o responsável pela execução.

Cenário com atribuição

"Carlos: O relatório deve ser entregue até sexta-feira."
"Ana: Ficarei responsável pela entrega."

Nesse segundo cenário, um sistema inteligente consegue identificar:

A ação a ser executada;
O prazo;
O responsável;
O contexto da decisão.

Essa diferença é fundamental para sistemas modernos de geração de atas e acompanhamento de atividades.

Para que as ferramentas funcione corretamente e consigam ler as transcrições das reuniões, é necessário habilitar esse acesso no painel de controle.

Abaixo, deixo o passo a passo simplificado para realizar o ajuste:

Guia para habilitação do acesso (Teams Admin Center)

Acesse o Microsoft Teams Admin Center.
No menu lateral, vá em Meetings > Meeting settings.
Localize a seção Transcript API access.
Ative a seguinte opção:

Microsoft Graph access = On

(Opcional, mas recomendado) Ative também:

Include speaker attribution = On

Inteligência Artificial além do resumo automático

Existe uma percepção comum de que a principal utilização das transcrições consiste na criação de resumos automáticos. Embora essa seja uma aplicação relevante, ela representa apenas uma pequena fração das possibilidades atualmente disponíveis.

Modelos de IA modernos podem executar tarefas mais sofisticadas, como:

Identificar decisões tomadas durante uma reunião;
Detectar riscos mencionados pelos participantes;
Extrair compromissos assumidos;
Construir cronogramas automaticamente;
Gerar listas de tarefas;
Mapear responsáveis e dependências;
Alimentar bases de conhecimento corporativas.

Para que esses resultados possuam valor operacional, a identificação do participante que realizou determinada fala torna-se um elemento essencial. Sem ela, a IA é capaz de compreender o conteúdo, mas tem limitações na construção de relações de responsabilidade e rastreabilidade.

Exemplo 1: Comitê de Projetos

Imagine um comitê executivo responsável pelo acompanhamento de iniciativas estratégicas.

Durante uma reunião, são discutidos:

orçamento;
cronograma;
riscos;
recursos humanos;
dependências técnicas.

Ao final do encontro, uma plataforma baseada em IA pode analisar automaticamente a transcrição e produzir uma ata estruturada contendo:

Decisões

Aprovação da expansão do projeto para a próxima fase.

Ações

Atualizar cronograma.
Revisar orçamento.
Publicar relatório executivo.

Responsáveis

João → revisão do orçamento.
Maria → cronograma.
Paulo → comunicação executiva.

Sem a identificação dos participantes, a IA continuaria capaz de identificar tarefas, porém não conseguiria associá-las com precisão aos respectivos responsáveis.

Consequentemente, a qualidade da governança do projeto seria reduzida.

Exemplo 2: Reuniões de Atendimento ao Cliente

Considere uma organização que realiza centenas de reuniões semanais com clientes.

Tradicionalmente, um colaborador precisaria elaborar relatórios após cada encontro.

Com acesso às transcrições e aos recursos de inteligência artificial, torna-se possível:

Identificar demandas dos clientes;
Classificar oportunidades de negócio;
Detectar reclamações recorrentes;
Gerar follow-ups automaticamente;
Produzir registros de atendimento.

Quando a atribuição de participantes está habilitada, o sistema consegue diferenciar claramente as falas do cliente das falas da equipe interna.

Isso permite análises que seriam impossíveis em uma transcrição anônima, tais como:

percentual do tempo de fala do cliente;
principais dúvidas apresentadas;
objeções comerciais recorrentes;
compromissos assumidos pela organização.

O resultado é uma documentação mais precisa e uma melhor experiência de relacionamento.

A formação de uma memória organizacional

Outro aspecto frequentemente negligenciado é o papel das transcrições na construção da memória corporativa.

Organizações produzem diariamente uma enorme quantidade de conhecimento tácito. Muitas decisões são discutidas verbalmente e jamais registradas em documentos formais.

Quando as transcrições são disponibilizadas para agentes inteligentes, surge a possibilidade de criar sistemas capazes de responder perguntas como:

"Quando essa decisão foi tomada?"
"Quem propôs essa alteração?"
"Em qual reunião o risco foi identificado?"
"Quais ações foram definidas para esse projeto?"

Nesse cenário, a IA deixa de atuar apenas como uma ferramenta de produtividade individual e passa a funcionar como um mecanismo institucional de preservação e recuperação do conhecimento.

Os desafios de privacidade e conformidade

Apesar dos benefícios, a disponibilização das transcrições exige atenção especial à governança de dados.

A própria Microsoft alerta que a identificação de participantes pode expor informações pessoais ou sensíveis quando compartilhada com aplicações externas.

Portanto, não basta habilitar o acesso técnico às transcrições. É necessário estabelecer políticas que definam:

quais aplicações poderão consumir as informações;
quais finalidades são permitidas;
quais grupos possuem autorização para acesso;
quais períodos de retenção serão adotados;
como serão conduzidas auditorias e revisões periódicas.

A adoção responsável dessas práticas permite equilibrar inovação e conformidade.

Em resumo:

Para que uma aplicação utilize o Microsoft Graph para ler transcrições e gerar atas automaticamente, você deve habilitar os dois itens:

Microsoft Graph access
Permite que aplicativos e agentes acessem as transcrições das reuniões através do Microsoft Graph. Se esta opção estiver desativada, nenhuma aplicação conseguirá ler a transcrição, mesmo possuindo permissões concedidas no Entra ID.

Include speaker attribution
Permite que a transcrição contenha a identificação de quem falou cada trecho da conversa. Sem essa opção, a IA consegue ler o texto da reunião, mas não consegue saber quem disse cada frase.

Na prática:

Configuração	Resultado
Graph Access = OFF	O Graph não consegue acessar a transcrição.
Graph Access = ON + Speaker Attribution = OFF	A IA lê a conversa, mas não sabe quem falou.
Graph Access = ON + Speaker Attribution = ON	A IA lê a conversa e sabe quem falou cada trecho. Ideal para atas e extração de ações.

Sem a atribuição de participantes, a IA normalmente conseguiria identificar a decisão e o prazo, mas teria dificuldade para determinar com segurança quem assumiu a responsabilidade.

Entretanto, existe um terceiro requisito que muitas vezes é esquecido:

A aplicação também precisa ter as permissões apropriadas no Microsoft Entra ID (API Permissions do Graph). Habilitar essas opções no Teams não concede acesso automaticamente; elas apenas liberam que aplicações autorizadas possam consumir as transcrições.

Resumo executivo:

Se o objetivo é utilizar IA, Copilot Studio, Power Automate ou uma aplicação própria para gerar atas automáticas a partir das reuniões do Teams, o caminho recomendado é habilitar Microsoft Graph Access e Speaker Attribution, além de conceder as permissões Graph necessárias para a aplicação que fará a leitura da transcrição.

Conclusão

A crescente utilização de inteligência artificial nas organizações está transformando as transcrições de reuniões em uma das mais valiosas fontes de dados corporativos. O acesso controlado a esses conteúdos por meio de APIs deixa de ser um recurso meramente técnico e passa a representar um elemento estratégico para iniciativas de automação, gestão do conhecimento e produtividade.

A possibilidade de associar cada trecho da conversa ao seu respectivo participante amplia significativamente o potencial analítico dos sistemas de IA, permitindo a geração de atas mais precisas, o acompanhamento automatizado de ações e a construção de bases de conhecimento corporativas cada vez mais inteligentes.

Em um cenário no qual o conhecimento é um dos principais ativos das organizações, controlar o acesso às transcrições e preservar a autoria das interações não representa apenas uma questão tecnológica. Trata-se de um mecanismo fundamental para transformar conversas em informação estruturada e informação estruturada em inteligência organizacional.

Fontes utilizadas para contextualização técnica: Microsoft Learn sobre acesso a transcrições via Microsoft Graph e controles de atribuição de participantes

Habilite o consentimento explícito para gravação, transcrição e Copilot no Microsoft Teams

2026-09-07T16:22:00.000-03:00

Área de tecnologia principal: M365 | Teams
Áreas de tecnologia adicionais: Azure | Powershell
Dados do autor: https://linktr.ee/edupopov

Introdução

A consolidação do Microsoft Teams como plataforma de colaboração corporativa ampliou significativamente o uso de reuniões virtuais, gravações, transcrições automáticas e recursos baseados em inteligência artificial. Reuniões que anteriormente eram essencialmente temporárias passaram a produzir registros digitais que podem ser armazenados, pesquisados, compartilhados e utilizados posteriormente pelo Microsoft 365 Copilot.

Essa evolução oferece benefícios importantes para a produtividade. Uma gravação permite revisar decisões, enquanto a transcrição facilita a localização de informações específicas. O Copilot, por sua vez, pode analisar o conteúdo discutido para produzir resumos, identificar assuntos relevantes e organizar os principais pontos de uma reunião.

Entretanto, o processamento de voz, imagem e conteúdo compartilhado também exige transparência. Os participantes precisam compreender quando suas manifestações estão sendo registradas ou processadas e, dependendo das políticas organizacionais, devem ter a possibilidade de concordar explicitamente com essa utilização.

Para atender a esse cenário, o Microsoft Teams disponibiliza a configuração Require participant agreement for recording, transcription, and Copilot, apresentada em algumas interfaces como Require participant agreement for recording and transcription. Essa política permite exigir uma manifestação explícita dos participantes antes que seus conteúdos sejam incluídos na gravação ou na transcrição de uma reunião.

O que é o consentimento explícito no Microsoft Teams

Em uma reunião configurada sem consentimento explícito, o Microsoft Teams normalmente apresenta uma notificação informando que a gravação ou a transcrição foi iniciada. Nesse modelo, a continuidade da participação ocorre após o aviso, sem que cada pessoa tenha de responder formalmente a uma solicitação.

A configuração de consentimento explícito modifica esse comportamento. Quando a gravação ou a transcrição é iniciada, os demais participantes são colocados em estado restrito: o microfone permanece desativado, a câmera é desligada e o compartilhamento de conteúdo não fica disponível.

Quando alguém tenta ativar o microfone, ligar a câmera ou compartilhar sua tela, o Teams apresenta uma solicitação de concordância. O participante deve escolher se aceita ou não que seu conteúdo seja incluído no processamento realizado durante a reunião.

A pessoa que inicia a gravação ou a transcrição é considerada como tendo fornecido consentimento e, por isso, permanece com seus recursos de comunicação ativos. Nas reuniões configuradas para iniciar a gravação automaticamente, os participantes ingressam inicialmente com microfone e câmera desabilitados, sendo solicitado o consentimento quando tentam participar de maneira ativa.

O que acontece quando o participante não concorda

Caso o participante escolha não fornecer consentimento, ele não é necessariamente removido da reunião. Em vez disso, permanece em uma experiência de participação somente para visualização.

Nesse estado, a pessoa pode acompanhar a reunião, mas não consegue:

ativar o microfone;
ligar a câmera;
compartilhar a tela ou outros conteúdos;
iniciar uma gravação;
iniciar uma transcrição.

Esse comportamento representa uma separação entre acompanhar uma comunicação e contribuir com conteúdo que seria incorporado ao registro digital da reunião. Dessa maneira, o participante preserva a possibilidade de assistir ao encontro sem que sua voz, imagem ou compartilhamento sejam adicionados à gravação e à transcrição.

Relação entre consentimento, transcrição e Microsoft 365 Copilot

O funcionamento do Copilot em reuniões do Microsoft Teams está diretamente relacionado à captura e ao processamento das informações discutidas. Dependendo da configuração escolhida pelo organizador, o Copilot pode operar apenas durante a reunião ou continuar disponível após seu encerramento.

Na opção Only during the meeting, o Copilot utiliza processamento temporário de voz para texto. Esses dados não permanecem disponíveis depois que a reunião termina. Já na modalidade During and after the meeting, o funcionamento posterior do Copilot depende da existência de uma transcrição salva.

A documentação do cmdlet Set-CsTeamsMeetingPolicy descreve o parâmetro ExplicitRecordingConsent como responsável pelo acordo e pela notificação relacionados à gravação, à transcrição e ao Copilot nas reuniões do Teams.

Portanto, essa política deve ser compreendida como parte de uma estratégia mais ampla de governança do conteúdo processado durante as reuniões. Ela não controla isoladamente todas as funcionalidades do Copilot, mas estabelece um mecanismo de transparência e concordância antes que o conteúdo dos participantes seja utilizado nos recursos associados à captura da reunião.

Importância da utilização dessa configuração

Transparência no tratamento das informações

O primeiro benefício está relacionado à transparência. Uma notificação simples pode passar despercebida, principalmente em reuniões com muitos participantes ou durante apresentações. A solicitação explícita exige uma ação consciente, reduzindo a possibilidade de que uma pessoa participe sem perceber que seu conteúdo está sendo processado.

Proteção da privacidade dos participantes

Reuniões corporativas podem conter informações pessoais, estratégicas, financeiras, técnicas ou contratuais. O consentimento explícito ajuda a demonstrar que a organização reconhece a sensibilidade desse conteúdo e adota medidas para tornar o processo de captura mais claro.

A configuração, isoladamente, não garante conformidade com a legislação ou com todas as obrigações regulatórias. Entretanto, pode integrar um programa de privacidade e governança, desde que seja combinada com políticas de retenção, classificação, acesso, auditoria e descarte das informações.

Evidência para auditoria

A escolha realizada por cada participante pode ser registrada no relatório de presença e engajamento da reunião. Mesmo quando esse relatório não está disponível para organizadores ou coorganizadores, os administradores podem consultar os dados de consentimento nos registros de auditoria do Microsoft Purview.

Esse registro contribui para investigações internas, análise de incidentes, comprovação de procedimentos e revisão das práticas organizacionais.

Maior controle em reuniões sensíveis

A configuração é especialmente relevante em áreas como:

Recursos Humanos;
Jurídico;
Saúde ocupacional;
Finanças;
Auditoria;
Segurança da Informação;
pesquisas internas;
reuniões com clientes e fornecedores;
discussões envolvendo propriedade intelectual.

Nesses contextos, a simples presença de um aviso pode não ser suficiente para o modelo de governança adotado pela organização. A manifestação explícita oferece uma camada adicional de controle.

Uso responsável da inteligência artificial

A adoção do Copilot não deve ser tratada apenas como uma implantação tecnológica. Ela também envolve comunicação, responsabilidade e definição clara de como as informações serão utilizadas.

Ao exigir concordância, a organização demonstra que o uso de inteligência artificial em reuniões está sendo acompanhado por controles administrativos. Essa abordagem contribui para aumentar a confiança dos usuários e reduz a percepção de que o processamento ocorre de maneira oculta ou indiscriminada.

Como habilitar pelo Centro de Administração do Microsoft Teams

A configuração é aplicada por meio de uma política de reunião. Isso significa que seu comportamento é determinado pela política atribuída ao organizador. As reuniões criadas por esse usuário, inclusive reuniões de canal, herdam a exigência de consentimento.

Para habilitar a funcionalidade:

Acesse o Centro de Administração do Microsoft Teams.
No menu lateral, expanda Meetings.
Selecione Meeting policies.
Escolha uma política existente ou crie uma nova política.
Acesse a seção Recording & transcription.
Localize a opção Require participant agreement for recording and transcription ou Require participant agreement for recording, transcription, and Copilot.
Altere a configuração para On.
Selecione Save.
Atribua a política aos usuários ou grupos que deverão organizar reuniões com consentimento explícito.

A política Global pode ser modificada quando a exigência precisa alcançar todos os usuários que não possuem outra política atribuída. Para uma implantação controlada, recomenda-se criar uma política personalizada e aplicá-la inicialmente a um grupo piloto.

Habilitação por meio do PowerShell

A mesma configuração pode ser administrada pelo módulo Microsoft Teams PowerShell. Para habilitar o consentimento explícito na política global, utilize:

Connect-MicrosoftTeams

Set-CsTeamsMeetingPolicy `
    -Identity Global `
    -ExplicitRecordingConsent Enabled

Para habilitar a funcionalidade em uma política existente, substitua Global pelo nome da política:

Set-CsTeamsMeetingPolicy `
    -Identity "Reunioes-Consentimento-Explicito" `
    -ExplicitRecordingConsent Enabled

A configuração pode ser validada com o seguinte comando:

Get-CsTeamsMeetingPolicy `
    -Identity "Reunioes-Consentimento-Explicito" |
    Select-Object Identity, ExplicitRecordingConsent

O valor Enabled exige a concordância do participante. O valor Disabled utiliza o modelo de consentimento implícito, no qual os participantes recebem uma notificação, mas não precisam responder individualmente antes de serem incluídos. A documentação do PowerShell também apresenta o valor LegitimateInterest, destinado a cenários organizacionais específicos e menos restritivos, cuja utilização deve ser previamente avaliada pelas áreas jurídica, de privacidade e de conformidade.

Personalização da mensagem de consentimento

Além de exigir a concordância, o Teams permite que administradores personalizem determinadas mensagens apresentadas durante o início da gravação ou da transcrição.

No Centro de Administração do Teams, essa configuração pode ser encontrada em:

Meetings > Meeting policies > Recording & transcription > Show customized in-meeting notification for recording and transcription

A personalização pode incluir uma explicação organizacional e um endereço para a política de privacidade. As mensagens podem ser configuradas para diferentes idiomas e situações, como o aviso apresentado ao iniciador, a comunicação exibida aos participantes e a caixa de diálogo de consentimento.

Uma mensagem corporativa pode informar, por exemplo, a finalidade da gravação, o prazo esperado de retenção, o canal de contato do encarregado de privacidade e onde consultar as políticas internas.

A personalização deve ser objetiva. Textos excessivamente longos podem dificultar a compreensão e estimular os participantes a aceitarem a solicitação sem realmente analisar seu conteúdo.

Reuniões e chamadas individuais são controladas separadamente

É importante diferenciar uma reunião do Teams de uma chamada individual. A configuração apresentada em Meeting policies controla reuniões e chamadas em grupo associadas à política de reunião.

Para chamadas individuais, incluindo determinadas chamadas VoIP e PSTN, o administrador deve revisar as configurações existentes em:

Voice > Calling policies

A Microsoft recomenda alinhar as políticas de reuniões e chamadas para evitar experiências diferentes para o mesmo usuário. Caso apenas a política de reunião seja configurada, o consentimento explícito poderá ser exigido em reuniões, mas não necessariamente em chamadas individuais.

Recomendações para implantação

A habilitação técnica deve ser acompanhada por um processo de governança. Antes de aplicar a política para toda a organização, é recomendável:

Identificar quais departamentos realizam reuniões com informações sensíveis.
Validar a configuração com as áreas jurídica, de privacidade e de segurança.
Criar uma política personalizada para um grupo piloto.
Testar reuniões internas, externas, de canal e com participantes por telefone.
Avaliar o comportamento em clientes Windows, macOS, Web e dispositivos móveis.
Personalizar a mensagem de consentimento com orientações claras.
Verificar o registro das decisões nos relatórios e no Microsoft Purview.
Documentar como gravações, transcrições e informações produzidas pelo Copilot serão armazenadas, compartilhadas e eliminadas.

Alguns dispositivos, como Microsoft Teams Rooms e determinados equipamentos de videoconferência, podem utilizar um comportamento de consentimento automático acompanhado de notificação. Por esse motivo, testes com os dispositivos utilizados pela organização são essenciais antes da implantação definitiva.

Conclusão

A configuração Require participant agreement for recording, transcription, and Copilot representa um importante mecanismo de governança para reuniões no Microsoft Teams. Seu objetivo não é impedir o uso de gravações, transcrições ou inteligência artificial, mas assegurar que esses recursos sejam utilizados de maneira mais transparente e controlada.

Ao exigir uma resposta explícita, o Teams permite que cada participante compreenda que seu conteúdo poderá ser registrado ou processado. Caso não concorde, ele ainda pode acompanhar a reunião, embora permaneça limitado à experiência somente para visualização.

Para organizações que adotam o Microsoft 365 Copilot, essa configuração se torna ainda mais relevante. O conteúdo de uma reunião deixou de ser apenas um registro audiovisual e passou a constituir uma fonte de dados capaz de alimentar resumos, análises e outros recursos inteligentes.

A implementação adequada deve combinar configuração técnica, comunicação com os usuários, auditoria, políticas de retenção e avaliação jurídica. Dessa maneira, a organização pode aproveitar os benefícios da colaboração digital e da inteligência artificial sem deixar de lado os princípios de transparência, responsabilidade e proteção das informações.

Ferramenta de diagnóstico para ambientes de domínio Windows Server - By Popovici no Powershell [Dica do MVP]

2026-09-04T12:08:00.000-03:00

Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

Depois de muito trabalho, testes e várias evoluções, decidi disponibilizar para a comunidade técnica Microsoft uma ferramenta que desenvolvi para auxiliar no diagnóstico e na análise de ambientes Active Directory Domain Services (AD DS).

O AD Health Check v8 é um script PowerShell criado para ajudar administradores, analistas e arquitetos a obterem uma visão mais ampla da saúde dos seus Controladores de Domínio.

Um dos principais objetivos deste projeto é apoiar profissionais que estão avaliando, modernizando ou migrando suas infraestruturas para o Windows Server 2025.

Entre as verificações realizadas pela ferramenta estão:

🔹 Conectividade dos Domain Controllers
🔹 Portas Kerberos, LDAP, LDAPS, Global Catalog, NTLM e DNS
🔹 Resolução DNS A, PTR e registros SRV do Active Directory
🔹 Testes com DCDiag
🔹 Serviços essenciais do AD DS
🔹 Compartilhamentos SYSVOL e NETLOGON
🔹 FSMO Roles
🔹 Functional Levels
🔹 Sites e Site Links
🔹 Inventário e versão dos Windows Servers
🔹 Último HotFix/KB e último reboot
🔹 Interfaces de rede e servidores DNS configurados
🔹 Replicação detalhada entre Domain Controllers
🔹 Última tentativa e último sucesso de replicação
🔹 Falhas consecutivas de replicação
🔹 Sincronismo de horário e W32Time
🔹 Identificação do PDC Emulator
🔹 Integridade do SYSVOL e DFSR
🔹 Backlog de replicação do SYSVOL
🔹 Eventos relevantes do DFS Replication
🔹 Consistência das GPOs através do GPT.INI e hash SHA256

Ao final da execução, o script gera um relatório HTML consolidado, facilitando a visualização do ambiente e destacando possíveis falhas encontradas durante a análise.

A ideia não é substituir o conhecimento do administrador ou as ferramentas nativas da Microsoft, mas centralizar evidências e acelerar o processo de troubleshooting.

E o mais importante:

O projeto está disponível gratuitamente para a comunidade.

Repositório: AD-Health-Check-v8.ps1

Baixem, testem em seus laboratórios e ambientes, estudem o código e contribuam com sugestões.

Se a ferramenta ajudar alguém a identificar uma falha de DNS, replicação, SYSVOL, DFSR ou qualquer outro problema antes de uma migração para o Windows Server 2025, o projeto já terá cumprido seu objetivo.

Compartilhar conhecimento fortalece a comunidade então use, divulgue e sinta-se a vontade para melhorar o script.

Nova trilha para Windows Server 2025 no Microsoft Learn olha para autenticação com Kerberos

2026-08-31T10:45:00.000-03:00

Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

A muito tempo bato na tecla da segurança dos ambientes corporativos, em especial observando características de autenticação.

A segurança de uma infraestrutura baseada em Active Directory Domain Services não depende apenas da proteção dos controladores de domínio ou da aplicação periódica de atualizações. Grande parte da confiança estabelecida dentro de um domínio está diretamente relacionada aos mecanismos utilizados para autenticar usuários, computadores, serviços e aplicações.

Com o Windows Server 2025, a Microsoft vem ampliando o processo de modernização desses mecanismos e estabelecendo uma postura de segurança mais rigorosa para ambientes corporativos. Dentro desse contexto, uma nova trilha disponibilizada no Microsoft Learn merece atenção dos administradores de infraestrutura e profissionais responsáveis por identidade e segurança: Active Directory Domain Services authentication and Kerberos hardening.

Link da trilha: Active Directory Domain Services Authentication and Kerberos Hardening - Training | Microsoft Learn

O módulo é classificado pela Microsoft como conteúdo avançado, direcionado principalmente a administradores e profissionais de identidade e acesso. Sua proposta é ensinar como diagnosticar e fortalecer os processos de autenticação utilizados em ambientes Active Directory, com especial atenção ao Kerberos, ao NTLM e às modificações introduzidas ou reforçadas pelo Windows Server 2025.

Mais do que uma introdução ao Kerberos, a trilha aborda um problema extremamente atual: como modernizar a autenticação de um domínio sem interromper aplicações e serviços que ainda dependem de mecanismos legados.

Autenticação como elemento central da segurança do Active Directory

O Active Directory Domain Services permanece como um dos principais componentes de identidade utilizados em infraestruturas corporativas. Quando um usuário acessa um compartilhamento de arquivos, uma aplicação integrada ao domínio, um servidor web, um banco de dados ou algum outro recurso protegido por autenticação Windows, diferentes componentes trabalham em conjunto para validar sua identidade e estabelecer o contexto de segurança utilizado posteriormente para autorizar o acesso.

Um dos pontos importantes apresentados pela nova trilha consiste justamente em compreender essa cadeia de autenticação.

As aplicações Windows normalmente não precisam implementar diretamente Kerberos ou NTLM. Elas podem utilizar a Security Support Provider Interface — SSPI, uma interface responsável por disponibilizar diferentes provedores de segurança ao sistema operacional e às aplicações.

Entre esses provedores encontra-se o mecanismo Negotiate, amplamente utilizado nas aplicações integradas ao Windows. Sua função é selecionar um protocolo de autenticação compatível com o cenário apresentado. Quando as condições necessárias estão disponíveis, o Kerberos normalmente é utilizado. Entretanto, problemas envolvendo nomes, Service Principal Names, contas de serviço, confiança entre domínios, tipos de criptografia ou conectividade com o Key Distribution Center podem resultar na utilização de NTLM como alternativa.

Esse comportamento é particularmente importante porque pode mascarar problemas existentes.

Uma aplicação pode aparentemente funcionar normalmente enquanto utiliza NTLM devido a uma falha na configuração necessária para utilização do Kerberos. O usuário consegue acessar o recurso e, consequentemente, o problema permanece invisível para a equipe responsável pela infraestrutura.

Quando políticas mais restritivas são posteriormente aplicadas, aquilo que parecia ser um ambiente saudável pode começar a apresentar falhas.

Compreendendo o fluxo do Kerberos

Outro mérito da trilha é apresentar o Kerberos como um processo que pode ser analisado e diagnosticado em diferentes etapas.

Em uma autenticação típica, um usuário ou computador solicita inicialmente ao Key Distribution Center — KDC um Ticket Granting Ticket, conhecido como TGT. Após sua emissão, esse ticket pode ser utilizado para solicitar tickets destinados a serviços específicos.

Quando o usuário precisa acessar determinado recurso, o cliente solicita ao KDC um ticket relacionado ao Service Principal Name correspondente ao serviço. Posteriormente, esse ticket é apresentado ao servidor de destino, que precisa ser capaz de validá-lo antes da construção do contexto de segurança utilizado na autorização.

Essa sequência permite compreender por que problemas de Kerberos nem sempre representam simplesmente uma falha de senha.

Um incidente pode estar relacionado, por exemplo, à emissão inicial do TGT, à solicitação de um ticket de serviço, ao SPN utilizado, à identidade responsável pelo serviço, ao tipo de criptografia disponível ou até mesmo ao processo de autorização executado depois que a autenticação foi concluída.

A trilha também relaciona essas etapas a evidências disponíveis nos logs de segurança do Windows, incluindo eventos como 4768, relacionado à solicitação de TGT, e 4769, associado à solicitação de tickets para serviços.

Essa abordagem é particularmente útil em processos de troubleshooting porque substitui a investigação baseada apenas em tentativa e erro por uma metodologia orientada por evidências.

Service Principal Names e a identidade dos serviços

Um dos elementos fundamentais para o funcionamento adequado do Kerberos são os Service Principal Names — SPNs.

Um SPN relaciona determinado serviço à conta do Active Directory responsável pela identidade utilizada para executá-lo. Em outras palavras, Kerberos não autentica simplesmente um nome de servidor; ele precisa identificar corretamente o principal de segurança responsável pelo serviço que será acessado.

Problemas envolvendo SPNs são relativamente comuns em ambientes corporativos, principalmente quando aplicações utilizam contas de serviço específicas, aliases DNS, servidores web, SQL Server ou arquiteturas compostas por diferentes camadas.

SPNs ausentes, duplicados ou registrados em contas incorretas podem impedir a utilização normal do Kerberos.

O problema torna-se ainda mais difícil de detectar quando o mecanismo Negotiate permite que a aplicação utilize NTLM posteriormente. Nesse cenário, a aplicação continua funcionando, mas o Kerberos encontra-se tecnicamente mal configurado.

Por essa razão, comandos como:

setspn -Q
setspn -X
setspn -S

continuam sendo importantes instrumentos de diagnóstico e administração.

A própria trilha recomenda atenção especial ao uso do parâmetro -S, pois ele realiza uma verificação de duplicidade antes de registrar um novo SPN.

A migração de NTLM para Kerberos

Um dos capítulos mais relevantes do módulo é dedicado ao planejamento da migração de NTLM para Kerberos.

A Microsoft deixa clara uma ideia que considero essencial para qualquer projeto de modernização: bloquear NTLM não deve ser o primeiro passo do processo.

Antes da aplicação de restrições é necessário descobrir onde NTLM ainda está sendo utilizado, compreender por que determinado fluxo depende dele e identificar qual será a estratégia de correção.

Essa abordagem é extremamente importante em ambientes corporativos de maior porte.

Aplicações antigas, tarefas agendadas, equipamentos embarcados, sistemas de backup, ferramentas de gerenciamento, clusters, appliances, integrações entre florestas e aplicações desenvolvidas internamente podem apresentar dependências que não são imediatamente conhecidas pelos administradores.

Uma política de bloqueio aplicada indiscriminadamente pode, portanto, transformar uma iniciativa de segurança em uma indisponibilidade operacional.

A estratégia recomendada consiste inicialmente em realizar auditoria.

Os administradores devem identificar conexões que ainda utilizam NTLM e correlacioná-las com informações como cliente de origem, conta utilizada, servidor de destino, serviço acessado, processo responsável pela comunicação, nome utilizado para acessar o recurso e proprietário da aplicação.

Somente depois dessa descoberta é possível determinar a verdadeira causa da dependência.

Nem toda utilização de NTLM possui a mesma origem

Esse aspecto é particularmente interessante na nova trilha.

O administrador não deve simplesmente observar a presença de NTLM e classificá-la automaticamente como um problema isolado. É necessário determinar por que o Kerberos não foi utilizado.

Entre as causas possíveis encontram-se:

acesso ao servidor utilizando endereço IP;
utilização de aliases sem SPNs adequados;
SPNs inexistentes ou duplicados;
SPNs associados à conta de serviço incorreta;
aplicações configuradas explicitamente para utilizar NTLM;
bibliotecas que não implementam Negotiate corretamente;
problemas relacionados a DNS;
falhas de confiança entre domínios ou florestas;
incompatibilidade dos tipos de criptografia;
configurações incorretas de delegação;
dispositivos ou aplicações legadas sem suporte adequado ao Kerberos moderno.

O aprendizado mais importante aqui é que reduzir NTLM exige corrigir a causa que impede o uso do Kerberos.

Não se trata simplesmente de habilitar uma GPO.

Windows Server 2025 e o endurecimento do Kerberos

A terceira parte técnica do módulo concentra-se diretamente no Windows Server 2025.

A Microsoft apresenta diversas alterações que precisam ser consideradas durante projetos de implantação ou atualização de controladores de domínio.

Entre elas está uma mudança particularmente relevante: controladores de domínio Windows Server 2025 não emitem TGTs utilizando RC4.

Essa mudança representa um importante avanço na postura criptográfica do ambiente, mas também expõe dependências anteriormente mascaradas.

Contas de serviço antigas, equipamentos legados ou aplicações que ainda dependam de RC4 podem apresentar problemas quando começarem a depender de controladores de domínio executando Windows Server 2025.

Portanto, a atualização dos controladores de domínio não deve ser tratada exclusivamente como um procedimento de atualização de sistema operacional.

Ela deve incluir uma análise do ecossistema de autenticação.

O problema das contas antigas e das chaves AES

Existe ainda um detalhe técnico extremamente relevante.

Simplesmente permitir AES através de uma política não significa que todas as contas existentes no domínio possuem automaticamente material criptográfico adequado para utilizá-lo.

Contas de serviço antigas podem não possuir chaves AES apropriadas, principalmente quando suas senhas permanecem inalteradas há muitos anos.

A trilha demonstra que a escolha do tipo de criptografia utilizada pelo Kerberos depende de diferentes fatores, entre eles os tipos anunciados pelo cliente, as chaves disponíveis na conta, o atributo msDS-SupportedEncryptionTypes, as políticas aplicadas, as configurações existentes em relações de confiança e o suporte oferecido pelas aplicações envolvidas.

Por esse motivo, projetos de hardening precisam considerar também o ciclo de vida das contas utilizadas pelos serviços.

Em determinadas situações, a atualização ou redefinição da senha de uma conta pode ser necessária para que novas chaves criptográficas sejam geradas.

Também pode ser apropriado modernizar a identidade utilizada pelo serviço por meio de Group Managed Service Accounts — gMSA ou, quando os requisitos forem atendidos, delegated Managed Service Accounts — dMSA.

Identificando RC4 por meio dos eventos do Windows

Uma das partes que considero mais úteis para administradores é a abordagem prática de auditoria.

Os eventos 4768 e 4769, registrados nos controladores de domínio quando as políticas correspondentes de auditoria estão habilitadas, permitem investigar como os tickets Kerberos estão sendo emitidos.

Entre as informações que podem ser analisadas estão os tipos de criptografia anunciados pelo cliente, os algoritmos disponíveis para determinada conta, o tipo de criptografia utilizado no ticket e os códigos associados a uma eventual falha.

Por exemplo, um ticket de serviço identificado com o tipo 0x17 indica utilização de RC4.

Da mesma forma, erros relacionados à ausência de um tipo de criptografia compatível podem ajudar a identificar aplicações, contas ou dispositivos que precisam ser corrigidos antes de uma política criptográfica mais restritiva ser aplicada.

Essa metodologia transforma os próprios controladores de domínio em importantes fontes de telemetria para o processo de modernização.

SMB e o bloqueio de NTLM

O Windows Server 2025 também amplia as possibilidades relacionadas à redução do NTLM em conexões SMB.

O cliente SMB pode bloquear NTLM em conexões remotas de saída. Nesse modelo, uma conexão que anteriormente funcionava por meio de fallback para NTLM precisará utilizar Kerberos ou estar contemplada por uma exceção explicitamente definida.

Esse recurso possui duas funções importantes.

A primeira é diretamente relacionada à segurança, pois reduz a utilização de um mecanismo legado de autenticação.

A segunda é operacional: bloquear o fallback torna visíveis problemas de Kerberos que anteriormente permaneciam escondidos.

Assim, o bloqueio pode funcionar também como instrumento de validação durante um projeto controlado de migração.

Delegação e aplicações com múltiplas camadas

A trilha também aborda um cenário frequentemente associado a problemas complexos de autenticação: o conhecido double hop.

Imagine uma aplicação web na qual o usuário se autentica em um servidor de front-end. Posteriormente, esse servidor precisa acessar um banco de dados em outro equipamento utilizando a identidade do próprio usuário.

Nesse cenário, a simples autenticação no primeiro servidor não significa que a identidade poderá ser reutilizada automaticamente no segundo.

É necessário avaliar corretamente o modelo de delegação Kerberos utilizado.

A Microsoft apresenta conceitos relacionados à delegação irrestrita, delegação restrita, transição de protocolo e Resource-Based Constrained Delegation — RBCD, destacando que a delegação irrestrita oferece riscos maiores e deve ser evitada em novos projetos.

Compreender esse processo é fundamental para arquiteturas compostas por servidores web, bancos de dados, APIs e diferentes camadas de aplicação.

PKINIT e autenticação baseada em certificados

Outra evolução importante relacionada ao Windows Server 2025 envolve PKINIT, mecanismo utilizado quando a autenticação Kerberos inicial depende de criptografia de chave pública.

Isso inclui, por exemplo, determinados cenários de autenticação por certificados e smart cards.

O Windows Server 2025 amplia a agilidade criptográfica do PKINIT, permitindo que o mecanismo seja menos dependente de pressupostos rígidos relacionados aos algoritmos utilizados.

Entretanto, essa evolução não elimina a necessidade de uma infraestrutura PKI corretamente configurada.

Certificados dos controladores de domínio, cadeias de certificação, autoridades certificadoras confiáveis, templates, algoritmos utilizados e mapeamento dos certificados continuam sendo componentes fundamentais do processo.

Hardening precisa ser gradual

Talvez um dos ensinamentos mais importantes dessa trilha seja que segurança não deve ser implementada de forma desconectada da compatibilidade operacional.

A Microsoft recomenda uma abordagem progressiva e baseada em evidências.

Inicialmente, deve-se habilitar a auditoria e coletar informações sobre eventos Kerberos, utilização de NTLM, RC4 e autenticações dos serviços. Posteriormente, as dependências identificadas precisam ser classificadas e corrigidas.

Somente depois dessa etapa devem ser aplicadas políticas mais restritivas, preferencialmente começando por laboratórios e grupos piloto antes de atingir toda a organização.

Esse modelo reduz significativamente o risco de indisponibilidade.

Um bom projeto de hardening não é aquele que simplesmente bloqueia um protocolo antigo. É aquele que consegue demonstrar que as aplicações continuam funcionando utilizando os mecanismos de autenticação planejados pela organização.

Por que recomendo essa nova trilha

A nova trilha Active Directory Domain Services authentication and Kerberos hardening é especialmente interessante porque aborda autenticação de maneira integrada.

Ela não apresenta Kerberos apenas como um protocolo teórico.

O conteúdo conecta:

SSPI → Negotiate → Kerberos → NTLM → SPN → KDC → tickets → criptografia → delegação → auditoria → migração → hardening.

O módulo possui seis unidades e seus objetivos incluem compreender a interação entre SSPI, Negotiate, NTLM e Kerberos; acompanhar o fluxo de autenticação desde a emissão do TGT até a autorização; diagnosticar problemas envolvendo SPNs, delegação, PAC e criptografia; planejar a migração progressiva de NTLM para Kerberos; identificar e corrigir dependências de RC4; e preparar o ambiente para as mudanças introduzidas pelo Windows Server 2025.

Para administradores de Active Directory, esse conhecimento torna-se cada vez mais necessário.

Windows Server 2025 representa também uma mudança de postura

Durante muitos anos, ambientes Windows precisaram preservar elevada compatibilidade com tecnologias e aplicações desenvolvidas em gerações anteriores.

O problema é que essa compatibilidade frequentemente mantém ativos protocolos, algoritmos e configurações que já não representam o nível de segurança esperado de uma infraestrutura moderna.

O Windows Server 2025 demonstra uma evolução dessa postura.

A introdução de controles mais rígidos para Kerberos, a redução progressiva das dependências de NTLM, as mudanças relacionadas ao RC4, a possibilidade de bloqueio de NTLM no SMB e o fortalecimento dos métodos associados à alteração remota de senhas indicam uma direção clara: a compatibilidade legada não pode continuar sendo tratada como justificativa permanente para manter mecanismos fracos de autenticação.

Entretanto, essa modernização exige planejamento.

Conclusão

Administrar Active Directory no Windows Server 2025 significa compreender muito mais do que criação de usuários, grupos, GPOs ou controladores de domínio.

É necessário entender como a autenticação realmente acontece.

Saber identificar quando Kerberos está sendo utilizado, reconhecer um fallback para NTLM, compreender SPNs, analisar tickets, investigar eventos 4768 e 4769, avaliar tipos de criptografia e identificar contas ou aplicações que ainda dependem de RC4 tornou-se parte importante do trabalho de quem administra ou protege uma infraestrutura Microsoft.

Por esse motivo, considero a nova trilha do Microsoft Learn extremamente bem-vinda.

Ela não ensina apenas como fortalecer o Kerberos.

Ela ajuda o profissional a compreender como preparar um domínio Active Directory para uma arquitetura de autenticação mais moderna, auditável e resistente a mecanismos legados.

Para quem administra ambientes Windows Server 2025, trabalha com Active Directory, identidade ou segurança da informação, é uma trilha que merece entrar na lista de estudos.

E existe ainda uma reflexão importante: antes de simplesmente desabilitar NTLM ou RC4 em um ambiente de produção, precisamos ser capazes de responder a uma pergunta aparentemente simples:

Temos certeza de que nossas aplicações realmente estão utilizando Kerberos?

Essa resposta pode revelar muito sobre a maturidade da autenticação dentro de um ambiente Active Directory.

Governança de Agentes de IA no Power Platform: O Papel do Global Secure Access (GSA) na Segurança e Controle do Copilot Studio

2026-08-28T17:10:00.000-03:00

Área de tecnologia principal: Business Applications | Copilot Studio
Áreas de tecnologia adicionais: Security
Dados do autor: https://linktr.ee/edupopov

Introdução

A rápida adoção de agentes de inteligência artificial transformou a forma como organizações acessam informações, automatizam processos e interagem com sistemas corporativos. O que antes dependia exclusivamente de aplicações tradicionais e da intervenção humana passou a ser executado por agentes capazes de consultar bases de conhecimento, acessar APIs, interagir com sistemas externos e realizar ações de forma autônoma.

Nesse contexto, surge um novo desafio: como garantir que esses agentes operem dentro dos mesmos padrões de segurança, conformidade e governança exigidos para usuários humanos?

A tela apresentada abaixo ilustra justamente esse cenário. Nela, observa-se o Centro de Administração do Power Platform, responsável pela administração centralizada de ambientes, aplicações, fluxos, conectores e agentes desenvolvidos no ecossistema Microsoft. A recomendação destacada refere-se à ativação do Global Secure Access (GSA) para agentes do Copilot Studio, uma funcionalidade destinada a ampliar a visibilidade e o controle sobre as comunicações realizadas por agentes de inteligência artificial.

O que é o Centro de Administração do Power Platform?

O Centro de Administração do Power Platform representa a camada de governança da plataforma de baixo código da Microsoft. É por meio dele que administradores definem políticas, monitoram ambientes, controlam recursos e acompanham o comportamento dos componentes que formam o ecossistema Power Platform.

A partir desse portal é possível administrar:

Power Apps;
Power Automate;
Power Pages;
Microsoft Copilot Studio;
Ambientes de desenvolvimento, homologação e produção;
Conectores personalizados;
Recursos de segurança e conformidade.

Mais do que uma ferramenta operacional, o portal atua como um centro de governança, permitindo equilibrar inovação e controle corporativo.

Na imagem analisada, o administrador está visualizando recomendações relacionadas aos ambientes que hospedam agentes do Copilot Studio, demonstrando uma preocupação crescente com a governança dos recursos de inteligência artificial.

O Copilot Studio e a nova geração de agentes corporativos

O Microsoft Copilot Studio foi concebido para permitir a criação de agentes conversacionais e agentes autônomos capazes de interagir com diferentes fontes de informação.

Esses agentes podem:

Consultar documentos corporativos;
Utilizar informações disponibilizadas pelo Microsoft Graph;
Executar chamadas para APIs externas;
Consumir serviços em nuvem;
Interagir com plataformas de terceiros;
Utilizar conectores personalizados;
Integrar-se a servidores MCP (Model Context Protocol).

Esse modelo amplia significativamente a capacidade operacional dos agentes, mas também cria um novo vetor de risco. Diferentemente de um colaborador humano, um agente pode executar milhares de requisições em um curto intervalo de tempo, acessar múltiplos sistemas simultaneamente e consumir recursos externos de forma automatizada.

Sem mecanismos adequados de supervisão, torna-se difícil compreender exatamente quais destinos estão sendo acessados e quais informações estão trafegando entre o agente e os sistemas externos.

O que é o Global Secure Access (GSA)?

O Global Secure Access pode ser entendido como uma camada de segurança intermediária entre os agentes de IA e os recursos externos que eles acessam.

Em vez de permitir que o agente se comunique diretamente com a Internet ou com serviços externos, o tráfego passa por uma infraestrutura de inspeção e controle que possibilita a aplicação de políticas de segurança corporativas.

Quando utilizar o GSA?

Embora o recurso possa ser habilitado em qualquer ambiente que utilize agentes do Copilot Studio, sua adoção torna-se especialmente importante quando os agentes realizam comunicações externas.

Alguns exemplos incluem:

Consultas a APIs públicas;
Integrações com fornecedores externos;
Acesso a plataformas SaaS;
Consumo de serviços hospedados em nuvens distintas;
Uso de conectores personalizados;
Comunicação com sistemas legados expostos por APIs.

Nesses cenários, existe uma dependência crescente de recursos que estão fora da fronteira tradicional de segurança da organização.

O GSA passa a fornecer uma camada de observabilidade e controle que normalmente não estaria disponível para um agente operando de forma direta.

Você pode habilitar o GSA em Workspaces específicos (não precisa habilitar para todo o ambiente). A figura abaixo demonstra o processo de ativação do GSA para 04 ambientes específicos.

Por que utilizar o GSA?

A importância do GSA está relacionada à evolução do conceito de segurança corporativa.

Historicamente, as políticas de segurança foram desenvolvidas pensando em pessoas. Usuários autenticados acessavam sistemas, faziam downloads, enviavam arquivos e navegavam na Internet.

Com a popularização dos agentes de IA, surge uma nova entidade operacional dentro das organizações: o agente autônomo.

Embora não seja uma pessoa, ele também:

Consome dados;
Compartilha informações;
Realiza consultas;
Interage com sistemas externos.

Consequentemente, torna-se necessário aplicar aos agentes os mesmos princípios de controle já utilizados para usuários humanos.

Nesse sentido, o GSA permite que a organização:

Monitore o tráfego gerado pelos agentes;
Registre acessos e comunicações;
Detecte comportamentos anormais;
Aplicque políticas consistentes de segurança;
Amplie sua capacidade de auditoria.

A relação entre GSA e o modelo Zero Trust

Um dos aspectos mais relevantes do Global Secure Access é seu alinhamento com a arquitetura Zero Trust.

O princípio fundamental do Zero Trust consiste em não confiar automaticamente em nenhum elemento da infraestrutura, independentemente de sua origem.

Sob essa perspectiva, um agente de IA também não deve ser considerado confiável apenas por ter sido criado dentro da organização.

As ações executadas pelo agente precisam ser verificadas, monitoradas e registradas da mesma forma que ocorre com usuários, dispositivos e aplicações.

Ao encaminhar o tráfego dos agentes por meio do GSA, a organização passa a tratar esses componentes como entidades sujeitas às mesmas políticas de inspeção e validação utilizadas em sua estratégia de segurança corporativa.

A importância estratégica para a governança de IA

Organizações que estão construindo agentes especializados para áreas como atendimento, jurídico, tecnologia, recursos humanos, marketing ou análise de dados precisam pensar além da simples funcionalidade da solução.

A pergunta deixa de ser apenas:

"O agente consegue executar a tarefa?"

e passa a incluir outras questões fundamentais:

O agente está acessando apenas os recursos autorizados?
Existe rastreabilidade das ações executadas?
É possível identificar incidentes de segurança?
Existe capacidade de auditoria?
O tráfego está aderente às políticas corporativas?

O Global Secure Access surge justamente para responder essas perguntas.

Sua função não é tornar o agente mais inteligente. Sua finalidade é tornar o agente mais governável.

Em ambientes corporativos maduros, a governança de inteligência artificial tende a se tornar tão importante quanto a própria inteligência artificial. À medida que os agentes assumem atividades cada vez mais críticas para o negócio, mecanismos de visibilidade, controle e segurança deixam de ser diferenciais e passam a ser requisitos fundamentais.

Conclusão

O crescimento do uso de agentes de IA impõe novos desafios às áreas de tecnologia, segurança e governança. O Microsoft Copilot Studio fornece uma plataforma poderosa para criação desses agentes, enquanto o Centro de Administração do Power Platform oferece os mecanismos necessários para seu gerenciamento operacional.

Entretanto, à medida que os agentes passam a interagir com sistemas externos, APIs e recursos distribuídos, a necessidade de monitoramento e controle torna-se inevitável.

Nesse cenário, o Global Secure Access representa uma evolução natural da estratégia de governança corporativa. Ao criar uma camada de inspeção entre os agentes e os recursos externos, o GSA amplia a visibilidade operacional, fortalece os controles de segurança e contribui para a implementação de uma arquitetura alinhada aos princípios modernos de confiança zero.

Mais do que um recurso técnico, o GSA deve ser entendido como um componente estratégico para organizações que desejam escalar o uso de inteligência artificial mantendo elevados níveis de conformidade, rastreabilidade e proteção da informação.

Fontes utilizadas: Microsoft Learn sobre Global Secure Access para agentes do Copilot Studio e documentação técnica Microsoft relacionada à integração entre GSA, Secure Web e AI Gateway.

Arquitetura Inteligente para Verificação de Imagens, Vídeos e Conteúdo Visual na Era da Inteligência Artificial

2026-08-24T16:38:00.000-03:00

Área de tecnologia principal: Azure | Microsoft Azure
Áreas de tecnologia adicionais: M365 | Copilot
Dados do autor: https://linktr.ee/edupopov

Gostaria de propor aqui um desenho base para trabalhar com análise de imagens e vídeos. Esta arquitetura utiliza recursos já conhecidos do Microsoft Azure e abordados por exames de certificação como AZ-104, AI-103, AB-900, etc...

É importante reforçar que meus artigos são escritos com base em experiência vivida no dia a dia de minhas atividades.

Introdução

A evolução acelerada dos modelos de Inteligência Artificial Generativa trouxe benefícios significativos para a produção de conteúdo digital. Entretanto, a mesma tecnologia que facilita a criação de imagens, vídeos e documentos também amplia os desafios relacionados à autenticidade, confiabilidade e rastreabilidade das informações. Em um cenário onde conteúdos sintéticos podem ser produzidos com elevado grau de realismo, torna-se imprescindível a adoção de arquiteturas capazes de validar a origem, a integridade e o histórico dos ativos digitais.

A arquitetura apresentada na figura propõe uma abordagem moderna para a verificação automatizada de imagens, vídeos e documentos. Mais do que um simples fluxo de processamento, ela estabelece uma cadeia de confiança baseada em armazenamento estruturado, validação de metadados, indexação inteligente e agentes especializados de Inteligência Artificial. O objetivo é permitir que cada conteúdo recebido seja submetido a uma série de verificações antes de ser considerado confiável para consumo humano ou utilização em processos corporativos.

Proposta de arquitetura

Visão Geral da Arquitetura

A solução está organizada em quatro grandes blocos:

Interface do Usuário
Núcleo de Processamento (Core Application)
Camada de Busca e Persistência
Camada de Agentes Inteligentes e Serviços Cognitivos

Cada componente possui uma responsabilidade específica dentro do processo de validação.

O fluxo inicia com o envio de um conteúdo pelo usuário e termina com uma análise detalhada sobre autenticidade, procedência e consistência das informações encontradas.

1. Interface do Usuário: O Ponto de Entrada da Confiança

O primeiro componente da arquitetura é representado por um agente conversacional, identificado na figura como Copilot Agent Chat.

Sua função vai muito além de uma simples interface de upload.

Neste modelo, o usuário pode:

Enviar imagens;
Submeter vídeos;
Fornecer documentos;
Consultar análises anteriores;
Solicitar verificações complementares.

A experiência conversacional permite que uma investigação complexa seja conduzida de forma natural.

Em vez de navegar por múltiplas ferramentas, o usuário pode interagir com o sistema utilizando linguagem natural, recebendo respostas contextualizadas sobre o conteúdo analisado.

2. Azure Storage: O Repositório Inicial

Depois do envio, o conteúdo é direcionado para uma camada de armazenamento.

O Azure Storage assume o papel de repositório primário dos ativos digitais.

Essa decisão arquitetural oferece diversas vantagens:

Persistência

Todo conteúdo enviado permanece armazenado para futuras análises ou auditorias.

Escalabilidade

Imagens de alta resolução, vídeos extensos e grandes volumes documentais podem ser armazenados sem impacto significativo na aplicação principal.

Separação de Responsabilidades

O armazenamento fica desacoplado do mecanismo de validação, permitindo maior flexibilidade operacional.

Essa abordagem também possibilita a criação de históricos e linhas do tempo relacionadas aos materiais recebidos, algo fundamental em investigações de autenticidade.

3. Validação Inicial do Conteúdo

O próximo estágio ocorre dentro da aplicação principal por meio de uma Azure Function.

A figura destaca três atividades fundamentais realizadas nesta etapa:

Identificação do Tipo de Conteúdo

O sistema determina automaticamente se o arquivo recebido corresponde a:

Documento;
Imagem;
Vídeo.

Essa classificação é necessária porque cada formato exige mecanismos distintos de verificação.

Um vídeo contém características temporais e sequenciais inexistentes em imagens estáticas.

Um documento possui metadados diferentes daqueles encontrados em arquivos multimídia.

Verificação de Existência Prévia

Antes de iniciar novas análises, o sistema verifica se aquele conteúdo já foi processado anteriormente.

Essa etapa evita:

Consumo desnecessário de recursos computacionais;
Processamento duplicado;
Armazenamento redundante.

Em ambientes onde milhares de conteúdos são recebidos diariamente, essa simples validação pode representar uma economia significativa de processamento.

Validação de Proveniência (C2PA)

A figura menciona especificamente a aplicação de validação C2PA quando necessária.

O padrão C2PA (Coalition for Content Provenance and Authenticity) foi criado para fornecer mecanismos de rastreabilidade e procedência de conteúdo digital.

Conceitualmente, essa validação busca responder perguntas como:

Quem gerou o conteúdo?
Qual ferramenta foi utilizada?
O arquivo sofreu alterações posteriores?
Existe uma cadeia de custódia registrada?

Caso essas informações estejam presentes, o sistema pode utilizá-las como um dos elementos de confiança durante a análise.

É importante observar que a ausência desses registros não significa necessariamente que o conteúdo seja falso. Ela apenas indica que verificações adicionais serão necessárias.

4. Azure Function como Motor de Orquestração

A Azure Function atua como o elemento de automação do processo.

Seu papel é coordenar os fluxos de execução sem exigir intervenção humana.

Ela pode:

Acionar mecanismos de busca;
Invocar agentes especializados;
Encaminhar informações para bancos de dados;
Atualizar índices de pesquisa;
Registrar eventos de auditoria.

Ao adotar um modelo orientado a eventos, a arquitetura consegue processar grandes quantidades de conteúdo de maneira paralela e eficiente.

5. AI Foundry Orchestrator Agent

Após as validações iniciais, entra em cena o elemento central da inteligência da solução: o AI Foundry Orchestrator Agent.

Pode-se entender esse componente como um coordenador capaz de decidir quais análises precisam ser executadas para cada conteúdo.

Sua responsabilidade não é necessariamente realizar todas as verificações, mas determinar:

O que precisa ser validado;
Em qual ordem;
Quais agentes devem ser acionados;
Quando uma evidência é suficiente ou quando análises adicionais são necessárias.

Essa abordagem evita processamento excessivo e permite que a arquitetura opere de forma adaptativa.

6. Camada de Busca e Armazenamento Inteligente

A arquitetura incorpora uma camada dedicada à recuperação contextual das informações.

Essa camada é composta por três elementos.

Azure AI Search

O Azure AI Search funciona como a principal plataforma de indexação.

Todo conteúdo analisado pode ser enriquecido com:

Metadados;
Resultados de validação;
Características extraídas automaticamente;
Descrições geradas por IA.

Isso permite pesquisas avançadas sobre grandes volumes de conteúdo visual.

Por exemplo:

"Mostrar todas as imagens semelhantes analisadas nos últimos seis meses."

"Localizar vídeos contendo determinado objeto ou cenário."

Cosmos DB

O Cosmos DB funciona como a base de persistência dos metadados estruturados.

Nele podem ser armazenados:

Informações das verificações;
Resultados das análises;
Relacionamentos entre conteúdos;
Histórico de processamento.

Sua baixa latência favorece consultas rápidas realizadas pelos agentes inteligentes.

Indexação Vetorial

Um dos aspectos mais relevantes da arquitetura é o uso de buscas vetoriais.

Em vez de procurar apenas palavras-chave, o sistema passa a compreender características semânticas.

Isso possibilita identificar:

Imagens visualmente semelhantes;
Vídeos com contextos equivalentes;
Conteúdos relacionados mesmo quando possuem descrições diferentes.

Na prática, isso amplia significativamente a capacidade de detectar reutilização de imagens, conteúdo republicado ou materiais visualmente relacionados.

7. Agentes Especializados de Inteligência Artificial

A camada inferior da arquitetura representa um ambiente multiagente baseado em Azure AI Foundry.

Esse é provavelmente o componente mais sofisticado da solução.

Em vez de concentrar toda a inteligência em um único modelo, a arquitetura distribui responsabilidades entre agentes especializados.

Cada agente pode assumir funções específicas, como:

Análise de Metadados

Verificação de informações técnicas associadas ao conteúdo.

Verificação de Proveniência

Validação de registros de origem e histórico.

Análise Visual

Extração de características presentes nas imagens e vídeos.

Correlação de Evidências

Comparação entre resultados provenientes de múltiplas fontes.

Investigação Complementar

Execução de etapas adicionais quando as evidências iniciais são insuficientes.

Esse modelo aumenta a precisão das conclusões e reduz a dependência de uma única técnica de validação.

Cognitive Services: A Base Analítica

Os agentes podem consumir capacidades cognitivas especializadas para enriquecer suas análises.

Essa camada oferece recursos para:

Reconhecimento de objetos;
Descrição automática de imagens;
Extração de texto;
Classificação de conteúdo;
Processamento visual avançado.

Essas informações transformam conteúdo não estruturado em dados pesquisáveis e analisáveis.

Conclusão

A arquitetura apresentada representa uma abordagem moderna para enfrentar um dos maiores desafios da era digital: estabelecer confiança em conteúdos visuais cada vez mais sofisticados e difíceis de validar.

Ao combinar armazenamento estruturado, validação de procedência, indexação vetorial, busca semântica e agentes especializados de Inteligência Artificial, a solução cria uma cadeia de verificação capaz de aumentar significativamente a transparência e a rastreabilidade de imagens, vídeos e documentos.

Mais importante do que determinar se um conteúdo é verdadeiro ou falso, essa arquitetura busca acumular evidências técnicas que permitam compreender sua origem, histórico e contexto. Em um mundo onde a informação visual é produzida em velocidade sem precedentes, sistemas capazes de validar procedência e autenticidade deixam de ser um diferencial tecnológico e passam a ser um requisito fundamental para a confiança digital.

Nova trilha de Backup e recuperação do Active Directory com Windows Server 2025

2026-08-21T17:49:00.000-03:00

Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

Link da trilha:

https://learn.microsoft.com/pt-br/training/modules/active-directory-backup-recovery/

E temos mais uma trilha sobre Windows Server que vale a pena fazer. Agora é sobre Backup e recuperação de Active Directory. Me lembrei dos bons tempos dos exames relacionados ao MCSA e MCSE... os exames eram fortemente direcionados ao modo "divertido" de tratar a resiliência do Active Directory.

O Active Directory Domain Services continua sendo um dos componentes mais críticos de uma infraestrutura baseada em Windows Server.

Mesmo em organizações que avançaram significativamente na adoção de serviços em nuvem, Microsoft Entra ID e aplicações SaaS, o Active Directory local permanece responsável por autenticação, autorização, políticas de grupo, serviços corporativos e diversas integrações que sustentam a operação diária das empresas.

Por esse motivo, falar sobre backup e recuperação do Active Directory não deveria significar apenas discutir a execução periódica de uma tarefa de backup.

Uma estratégia realmente madura precisa responder questões mais complexas:

Quanto tempo a organização consegue permanecer sem o Active Directory?
Quanto de informação pode ser perdido durante uma recuperação?
Os backups existentes são realmente utilizáveis?
O SYSVOL está íntegro?
A replicação entre os controladores de domínio estava saudável quando o backup foi realizado?
As cópias estão protegidas contra comprometimento administrativo ou ransomware?
Existe um procedimento documentado para recuperar apenas um objeto, um controlador de domínio, um domínio ou uma floresta inteira?

É justamente nesse contexto que a Microsoft disponibiliza no Microsoft Learn o módulo “Backup e recuperação de Active Directory avançados”, destinado a profissionais que já possuem experiência com administração do AD DS.

O conteúdo é classificado como Avançado, possui 9 unidades e é direcionado principalmente a administradores, engenheiros de segurança da informação e arquitetos de solução.

Mais do que ensinar a executar comandos de backup, a proposta chama atenção para algo extremamente importante: backup e recuperação devem fazer parte do projeto de resiliência e segurança do Active Directory.

Backup não significa necessariamente recuperação

Um dos erros mais comuns encontrados em ambientes corporativos é considerar uma rotina de backup bem-sucedida como evidência suficiente de que o ambiente pode ser recuperado.

Não é.

Uma tarefa pode terminar sem erros e ainda assim não representar uma estratégia de recuperação adequada.

No Active Directory essa discussão se torna ainda mais importante porque não estamos trabalhando apenas com arquivos. O AD DS envolve diferentes componentes que precisam permanecer consistentes, incluindo:

banco de dados do Active Directory;
SYSVOL;
Registro do Windows;
arquivos necessários ao sistema;
configurações do controlador de domínio;
informações relacionadas aos serviços instalados.

A própria documentação da Microsoft estabelece procedimentos específicos para backup e restauração do Active Directory e ressalta a relação entre o AD DS e os componentes do System State.

Portanto, o objetivo de uma estratégia moderna não deveria ser simplesmente:

“Meu backup terminou com sucesso.”

A pergunta correta deveria ser:

“Consigo recuperar o Active Directory dentro dos requisitos estabelecidos pelo negócio?”

Essa mudança de perspectiva é um dos pontos mais interessantes da nova trilha.

Em fim... vale a pena usar e abusar dos recursos de backup relacionados ao Active Directory e sua estratégia cotidiana.

Gerenciador de Pacotes do Windows no Windows Server 2025: automação de aplicações com WinGet, Configuration Manager e Microsoft Intune

2026-08-17T13:50:00.000-03:00

Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

Introdução

A administração de servidores Windows tradicionalmente exige que os profissionais de infraestrutura localizem instaladores, validem versões, identifiquem parâmetros de instalação silenciosa e desenvolvam métodos próprios para atualizar aplicações. Embora ferramentas corporativas como o Microsoft Configuration Manager permitam centralizar esse processo, a preparação dos pacotes continua demandando planejamento, testes e manutenção constante.

Com o Windows Server 2025, a Microsoft passou a incluir nativamente o Windows Package Manager, acessado pela ferramenta de linha de comando winget. Essa mudança aproxima a administração do Windows Server de modelos de gerenciamento de software há muito utilizados em sistemas Linux, nos quais aplicações podem ser localizadas, instaladas, atualizadas e removidas diretamente por meio de um gerenciador de pacotes.

No Windows Server 2025, o WinGet está disponível por padrão nas instalações com Desktop Experience. O recurso não está disponível nativamente no Windows Server 2022 e em versões anteriores, nem deve ser considerado uma solução padrão para instalações Server Core.

A presença do WinGet no sistema operacional não elimina a necessidade de plataformas como o Configuration Manager. Na prática, ele acrescenta uma nova camada de automação que pode ser utilizada por scripts, tarefas agendadas, pipelines de implantação e ferramentas de gerenciamento corporativo.

O que é um gerenciador de pacotes?

Um gerenciador de pacotes é uma solução responsável por organizar o ciclo de vida de aplicações instaladas em um sistema operacional. Em vez de o administrador acessar manualmente o site de cada fabricante, baixar um instalador e executar parâmetros específicos, o gerenciador utiliza informações previamente estruturadas para localizar e processar o software.

No Windows Package Manager, essas informações são armazenadas em manifestos. Um manifesto descreve elementos como:

nome e identificação do aplicativo;
fabricante;
versão disponível;
arquitetura suportada;
endereço do instalador;
hash de integridade;
tipo de instalador;
parâmetros de instalação silenciosa;
requisitos e dependências.

O WinGet atua como cliente do Windows Package Manager. Por meio dele, o administrador pode pesquisar, instalar, listar, atualizar, reparar, remover, importar e exportar aplicações. A ferramenta suporta diferentes formatos de instaladores, incluindo MSI, EXE, MSIX, APPX, ZIP, Inno Setup, Nullsoft e WiX.

Essa abordagem reduz a dependência de procedimentos manuais, mas não elimina a responsabilidade administrativa. Antes de utilizar um pacote em produção, a organização ainda deve avaliar o fabricante, a origem, o comportamento do instalador, os impactos da nova versão e a compatibilidade com os serviços executados no servidor.

A importância do WinGet no Windows Server 2025

Servidores também utilizam aplicações que não fazem parte diretamente do sistema operacional. Entre os exemplos estão agentes de monitoramento, ferramentas de compactação, módulos administrativos, componentes de linha de comando, runtimes, clientes de banco de dados e utilitários de diagnóstico.

Sem um mecanismo padronizado, cada aplicativo pode exigir um processo diferente de atualização. Um fabricante distribui um arquivo MSI, outro utiliza um instalador EXE e um terceiro publica uma versão compactada. Essa diversidade dificulta a criação de um modelo uniforme de manutenção.

O WinGet oferece uma interface comum para trabalhar com esses diferentes formatos. O comando utilizado pelo administrador permanece praticamente o mesmo, enquanto o manifesto do pacote informa ao Windows Package Manager como o instalador deve ser processado.

Isso permite que o Windows Server 2025 seja integrado a processos de automação mais amplos, como:

instalação inicial de ferramentas administrativas;
preparação de servidores de laboratório;
atualização controlada de aplicações;
criação de imagens de referência;
padronização de servidores com a mesma função;
execução de scripts pelo Configuration Manager;
validação periódica de versões instaladas;
recuperação de ambientes de teste.

Essa capacidade é particularmente relevante em organizações que precisam manter dezenas ou centenas de servidores com conjuntos semelhantes de ferramentas.

Comandos fundamentais do WinGet

A primeira validação deve confirmar se o WinGet está disponível:

winget --version

Para visualizar informações sobre a instalação, os diretórios de log e as políticas aplicadas:

winget --info

Para consultar as fontes configuradas:

winget source list

A pesquisa de um aplicativo pode ser realizada pelo nome:

winget search PowerShell

Entretanto, em scripts corporativos, é mais seguro utilizar o identificador exato do pacote:

winget search --id Microsoft.PowerShell --exact

A instalação do PowerShell pode ser realizada da seguinte maneira:

winget install `
    --id Microsoft.PowerShell `
    --exact `
    --source winget `
    --scope machine `
    --silent `
    --accept-source-agreements `
    --accept-package-agreements `
    --disable-interactivity

O uso de --id e --exact reduz o risco de o WinGet selecionar um pacote com nome semelhante. Os parâmetros de aceitação de contratos e desativação da interatividade são importantes em execuções automatizadas, nas quais não existe um usuário disponível para responder às perguntas do instalador.

Para visualizar aplicações que possuem atualizações disponíveis:

winget list --upgrade-available

Para atualizar uma aplicação específica:

winget upgrade `
    --id Microsoft.PowerShell `
    --exact `
    --source winget `
    --scope machine `
    --silent `
    --accept-source-agreements `
    --accept-package-agreements `
    --disable-interactivity

Também é possível atualizar todas as aplicações reconhecidas:

winget upgrade --all

Embora seja conveniente, o comando upgrade --all não deve ser aplicado indiscriminadamente em servidores de produção. Uma atualização coletiva pode modificar diferentes aplicações na mesma janela, dificultar a análise de falhas e provocar impactos simultâneos em serviços distintos. O comando é mais apropriado para laboratórios, estações administrativas ou ambientes previamente avaliados. A documentação do WinGet recomenda executar inicialmente winget upgrade sem argumentos para revisar quais aplicações serão alteradas.

Script para atualização controlada de aplicações

O exemplo a seguir recebe o identificador de um pacote e solicita sua atualização. O script procura o executável do WinGet mesmo quando a execução ocorre em contexto de sistema, situação comum no Configuration Manager e no Microsoft Intune.

param(
    [Parameter(Mandatory = $true)]
    [string]$PackageId,

    [ValidateSet("machine", "user")]
    [string]$Scope = "machine"
)

$ErrorActionPreference = "Stop"

$LogDirectory = "C:\ProgramData\Empresa\Logs"
$LogFile = Join-Path $LogDirectory "WinGet-Update.log"

if (-not (Test-Path $LogDirectory)) {
    New-Item -Path $LogDirectory -ItemType Directory -Force | Out-Null
}

function Write-Log {
    param(
        [string]$Message
    )

    $Date = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    Add-Content -Path $LogFile -Value "$Date - $Message"
}

function Get-WinGetPath {

    $Command = Get-Command "winget.exe" -ErrorAction SilentlyContinue

    if ($Command) {
        return $Command.Source
    }

    $AppInstaller = Get-AppxPackage `
        -AllUsers `
        -Name "Microsoft.DesktopAppInstaller" |
        Sort-Object { [version]$_.Version } -Descending |
        Select-Object -First 1

    if ($AppInstaller) {

        $Candidate = Join-Path $AppInstaller.InstallLocation "winget.exe"

        if (Test-Path $Candidate) {
            return $Candidate
        }
    }

    throw "O executável winget.exe não foi localizado."
}

try {

    $WinGetPath = Get-WinGetPath

    Write-Log "Iniciando atualização do pacote $PackageId."
    Write-Log "Executável utilizado: $WinGetPath"

    $Arguments = @(
        "upgrade"
        "--id", $PackageId
        "--exact"
        "--source", "winget"
        "--scope", $Scope
        "--silent"
        "--accept-source-agreements"
        "--accept-package-agreements"
        "--disable-interactivity"
    )

    $Result = & $WinGetPath @Arguments 2>&1
    $ExitCode = $LASTEXITCODE

    $Result | ForEach-Object {
        Write-Log $_
    }

    if ($ExitCode -ne 0) {
        throw "O WinGet retornou o código de saída $ExitCode."
    }

    Write-Log "Processo concluído para o pacote $PackageId."
    exit 0
}
catch {

    Write-Log "Falha: $($_.Exception.Message)"
    exit 1
}

A execução para atualização do PowerShell seria:

.\Atualizar-AplicativoWinGet.ps1 `
    -PackageId "Microsoft.PowerShell"

Em um ambiente corporativo, recomenda-se manter uma lista explícita de identificadores aprovados. Essa prática impede que um administrador ou processo automatizado atualize aplicações que ainda não passaram por homologação.

Utilização com o Microsoft Configuration Manager

O Microsoft Configuration Manager, ainda frequentemente chamado de SCCM, continua sendo uma das soluções mais adequadas para gerenciamento de servidores Windows em ambientes locais.

O Windows Server 2025 é suportado como sistema operacional cliente a partir do Configuration Manager versão 2409. O suporte abrange as edições Standard, Datacenter, Datacenter: Azure Edition e Server Core, embora o Software Center não seja suportado nas instalações Server Core.

A integração entre WinGet e Configuration Manager pode seguir dois modelos principais.

Modelo de atualização direta

Nesse modelo, o Configuration Manager distribui apenas o script PowerShell. Quando executado, o script solicita que o WinGet consulte a fonte configurada e obtenha o instalador diretamente.

A linha de instalação do tipo de implantação pode ser:

powershell.exe -NoProfile `
    -ExecutionPolicy Bypass `
    -File ".\Atualizar-AplicativoWinGet.ps1" `
    -PackageId "Microsoft.PowerShell"

Esse modelo reduz a necessidade de armazenar cada instalador nos pontos de distribuição, mas cria dependência de conectividade externa, proxy, disponibilidade da fonte e comportamento do instalador publicado.

Ele é mais apropriado para:

laboratórios;
servidores de desenvolvimento;
ferramentas de baixo impacto;
aplicações que não exigem uma versão rigidamente controlada;
ambientes com acesso autorizado às fontes do WinGet.

Modelo com conteúdo controlado

Em servidores de produção, pode ser preferível utilizar o WinGet apenas para localizar e baixar o instalador. Depois disso, o arquivo é armazenado na biblioteca de conteúdo do Configuration Manager e distribuído pelos pontos de distribuição.

Exemplo:

winget download `
    --id Microsoft.PowerShell `
    --exact `
    --source winget `
    --architecture x64 `
    --installer-type wix `
    --download-directory "D:\SCCMSource\PowerShell" `
    --accept-source-agreements `
    --accept-package-agreements

O Configuration Manager passa a controlar o conteúdo, a versão, os limites de rede, as janelas de manutenção e o processo de implantação. A documentação do PowerShell considera o MSI uma alternativa adequada para servidores e cenários corporativos, especialmente quando é necessário integrar a instalação com WSUS, Microsoft Update ou Configuration Manager.

Esse modelo oferece maior previsibilidade porque a aplicação testada é exatamente a mesma que será distribuída aos servidores.

Método de detecção no Configuration Manager

No modelo de aplicações do Configuration Manager, o método de detecção deve verificar se a versão desejada está instalada.

O exemplo abaixo pesquisa o PowerShell nas áreas de desinstalação do Registro:

$MinimumVersion = [version]"7.6.0"

$RegistryPaths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*"
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

$Application = Get-ItemProperty `
    -Path $RegistryPaths `
    -ErrorAction SilentlyContinue |
    Where-Object {
        $_.DisplayName -like "PowerShell 7*"
    } |
    Sort-Object {
        try {
            [version](($_.DisplayVersion -replace "[^\d\.].*$", ""))
        }
        catch {
            [version]"0.0"
        }
    } -Descending |
    Select-Object -First 1

if ($Application) {

    try {
        $InstalledVersion = [version](
            $Application.DisplayVersion -replace "[^\d\.].*$", ""
        )

        if ($InstalledVersion -ge $MinimumVersion) {
            Write-Output "Aplicação detectada."
        }
    }
    catch {
        # Não produz saída quando a versão não pode ser validada.
    }
}

exit 0

Nos métodos personalizados de detecção do Configuration Manager, a existência de uma saída no fluxo padrão indica que a aplicação foi detectada. Quando a condição não for atendida, o script deve encerrar sem produzir texto.

A versão mínima deve ser alterada a cada nova revisão aprovada. Dessa forma, o Configuration Manager consegue identificar quais servidores ainda precisam receber a atualização.

Execução como script administrativo pelo Configuration Manager

Outra possibilidade consiste em utilizar o recurso Run Scripts para executar a atualização em uma coleção de dispositivos.

Nesse cenário, o administrador pode:

criar uma coleção piloto;
executar o script somente nessa coleção;
revisar os códigos de saída;
validar os serviços afetados;
ampliar gradualmente a execução;
aplicar o script na coleção de produção.

O Configuration Manager permite executar scripts PowerShell diretamente em coleções de dispositivos, inclusive por meio dos cmdlets Invoke-CMScript e Get-CMCollection.

Essa abordagem é útil para uma atualização emergencial, mas não substitui o modelo de aplicação quando a organização precisa de detecção permanente, histórico de conformidade e reinstalação automática.

Utilização com o Microsoft Intune

O Microsoft Intune deve ser contextualizado de forma diferente. As plataformas Windows diretamente suportadas para gerenciamento incluem principalmente as edições do Windows 11 e dispositivos Windows 365. O Windows Server não aparece na relação de sistemas Windows com suporte para inscrição e gerenciamento MDM pelo Intune. Portanto, o exemplo desta seção deve ser aplicado às estações Windows 10 ou Windows 11 que fazem parte do mesmo ambiente corporativo, e não diretamente aos servidores Windows Server 2025.

Em um modelo híbrido, a organização pode utilizar:

Configuration Manager para o Windows Server 2025;
Intune para notebooks e estações Windows 11;
WinGet como interface de automação comum;
grupos de homologação separados para servidores e endpoints.

Para aplicações Win32, o Intune também oferece mecanismos nativos de substituição de versões por meio de Supersedence. Aplicações obtidas pelo Microsoft Store podem ser mantidas atualizadas automaticamente, enquanto o Enterprise App Catalog possui seu próprio mecanismo de distribuição pela Intune Management Extension e não utiliza diretamente o WinGet.

Ainda assim, o WinGet pode ser utilizado em scripts de Remediações quando a organização precisa controlar aplicações que não estão adequadamente representadas nos modelos nativos.

Script de detecção para Remediações do Intune

O script de detecção verifica se existe uma atualização disponível para um pacote específico.

$PackageId = "Microsoft.PowerShell"

function Get-WinGetPath {

    $Command = Get-Command "winget.exe" -ErrorAction SilentlyContinue

    if ($Command) {
        return $Command.Source
    }

    $AppInstaller = Get-AppxPackage `
        -AllUsers `
        -Name "Microsoft.DesktopAppInstaller" |
        Sort-Object { [version]$_.Version } -Descending |
        Select-Object -First 1

    if ($AppInstaller) {

        $Candidate = Join-Path $AppInstaller.InstallLocation "winget.exe"

        if (Test-Path $Candidate) {
            return $Candidate
        }
    }

    return $null
}

$WinGetPath = Get-WinGetPath

if (-not $WinGetPath) {
    Write-Output "WinGet não localizado."
    exit 1
}

$Result = & $WinGetPath `
    list `
    --id $PackageId `
    --exact `
    --upgrade-available `
    --accept-source-agreements `
    --disable-interactivity 2>&1 |
    Out-String

if ($Result -match [regex]::Escape($PackageId)) {
    Write-Output "Atualização disponível para $PackageId."
    exit 1
}

Write-Output "Nenhuma atualização necessária."
exit 0

Nas Remediações do Intune, o script corretivo somente é executado quando o script de detecção retorna exit 1. Os scripts devem ser armazenados em UTF-8, e a Microsoft recomenda que comandos de reinicialização não sejam incorporados diretamente aos scripts de detecção ou correção.

Script de correção para Remediações do Intune

$PackageId = "Microsoft.PowerShell"

function Get-WinGetPath {

    $Command = Get-Command "winget.exe" -ErrorAction SilentlyContinue

    if ($Command) {
        return $Command.Source
    }

    $AppInstaller = Get-AppxPackage `
        -AllUsers `
        -Name "Microsoft.DesktopAppInstaller" |
        Sort-Object { [version]$_.Version } -Descending |
        Select-Object -First 1

    if ($AppInstaller) {

        $Candidate = Join-Path $AppInstaller.InstallLocation "winget.exe"

        if (Test-Path $Candidate) {
            return $Candidate
        }
    }

    throw "WinGet não localizado."
}

try {

    $WinGetPath = Get-WinGetPath

    $Result = & $WinGetPath `
        upgrade `
        --id $PackageId `
        --exact `
        --source winget `
        --scope machine `
        --silent `
        --accept-source-agreements `
        --accept-package-agreements `
        --disable-interactivity 2>&1

    $ExitCode = $LASTEXITCODE

    $Result | ForEach-Object {
        Write-Output $_
    }

    if ($ExitCode -ne 0) {
        throw "O WinGet retornou o código $ExitCode."
    }

    Write-Output "Atualização concluída."
    exit 0
}
catch {

    Write-Output "Falha na atualização: $($_.Exception.Message)"
    exit 1
}

No Intune, o pacote pode ser configurado para executar semanalmente ou em outro intervalo compatível com a política de manutenção da empresa. Aplicações críticas devem ser direcionadas inicialmente a grupos de teste.

Segurança e governança

A facilidade de instalação não deve transformar o WinGet em um mecanismo irrestrito dentro da organização. Um gerenciador de pacotes amplia a capacidade de automação, mas também exige regras de governança.

Utilizar identificadores exatos

Scripts devem empregar --id e --exact. Pesquisas baseadas somente no nome podem retornar diferentes aplicações ou fabricantes.

Manter uma lista de aplicações autorizadas

A organização deve definir quais pacotes podem ser instalados ou atualizados. A aprovação pode considerar:

criticidade do servidor;
reputação do fabricante;
licenciamento;
necessidade operacional;
impacto sobre serviços;
dependências;
necessidade de reinicialização;
compatibilidade com soluções de segurança.

Não ignorar a validação de hash

O parâmetro --ignore-security-hash não deve ser adotado para contornar falhas. Uma divergência de hash pode indicar que o instalador foi alterado, substituído ou publicado incorretamente.

Utilizar anéis de implantação

Uma estratégia recomendada é dividir os dispositivos em grupos:

laboratório;
equipe de tecnologia;
homologação;
produção não crítica;
produção crítica.

O mesmo conceito pode ser implementado com coleções no Configuration Manager e grupos do Microsoft Entra ID no Intune.

Controlar versões com pinning

O comando winget pin permite limitar a atualização de um pacote ou impedir que ele seja atualizado pelo WinGet. Esse recurso pode ser útil quando uma aplicação precisa permanecer temporariamente em uma versão homologada. O bloqueio realizado pelo WinGet, entretanto, não impede que o próprio aplicativo ou outra ferramenta de gerenciamento faça a atualização.

Gerenciar fontes

Organizações que não desejam permitir acesso irrestrito ao repositório comunitário podem controlar as fontes por Política de Grupo, restringir a inclusão de novos repositórios ou implementar uma fonte privada baseada em REST.

A Microsoft disponibiliza modelos administrativos ADMX e ADML específicos para o Windows Package Manager. Eles podem ser adicionados ao repositório central de políticas do Active Directory para controlar o comportamento do WinGet nos dispositivos do domínio.

Manter registros de execução

O WinGet produz logs próprios, e o diretório pode ser localizado com:

winget --info

Também é possível habilitar informações mais detalhadas com:

winget upgrade `
    --id Microsoft.PowerShell `
    --exact `
    --verbose-logs

Os logs auxiliam na identificação de problemas relacionados a fontes, CDN, argumentos, instaladores e códigos de saída.

A trilha do Microsoft Learn

Para profissionais que desejam compreender o funcionamento da solução antes de utilizá-la em produção, a Microsoft disponibiliza o módulo Explorar a ferramenta Gerenciador de Pacotes do Windows.

O conteúdo é classificado como introdutório e possui dez unidades. Entre os assuntos apresentados estão:

finalidade do Windows Package Manager;
instalação e remoção de aplicações;
atualização de software;
funcionamento do repositório;
contribuição de novos pacotes;
criação de repositórios privados;
controle do WinGet por Política de Grupo;
avaliação de conhecimentos.

Ao concluir o módulo, o profissional deve ser capaz de utilizar o Windows Package Manager para instalar, remover e atualizar aplicações, avaliar a utilização de fontes comunitárias ou privadas e controlar a ferramenta dentro de uma organização.

A trilha é especialmente relevante para administradores de servidores, profissionais de suporte, engenheiros de redes, arquitetos de soluções e equipes responsáveis pela gestão de endpoints.

URL: Explorar a ferramenta Gerenciador de Pacotes do Windows - Training | Microsoft Learn

Considerações finais

A inclusão do WinGet no Windows Server 2025 representa uma evolução no gerenciamento de aplicações no ecossistema Windows. A ferramenta oferece uma interface padronizada para operações que anteriormente dependiam de processos manuais e instaladores com comportamentos distintos.

Entretanto, seu maior valor não está apenas na possibilidade de executar um comando de instalação. O benefício mais significativo surge quando o WinGet é incorporado a processos controlados de automação, homologação e conformidade.

No Windows Server 2025, o Configuration Manager pode utilizar o WinGet para executar atualizações específicas ou auxiliar na obtenção de instaladores. Nos endpoints Windows 11, o Microsoft Intune pode utilizar Remediações, aplicações Win32, Microsoft Store ou recursos do Enterprise App Management, conforme o nível de controle necessário.

O WinGet não substitui essas plataformas. Ele funciona como uma camada adicional de automação que pode simplificar a administração, reduzir tarefas repetitivas e ampliar a padronização do ambiente.

Sua adoção deve ser acompanhada por políticas de segurança, listas de aplicações autorizadas, grupos de homologação, controle de versões, registros de execução e procedimentos de reversão. Quando implementado dessa forma, o Windows Package Manager torna-se um componente relevante para a modernização da administração do Windows Server 2025.

Criando alerta de deleção de arquivos no Sharepoint - use o Power Automate

2026-08-12T10:38:33.350-03:00

Área de tecnologia principal: M365 | Teams
Áreas de tecnologia adicionais: Security | Identity & Access
Dados do autor: https://linktr.ee/edupopov

A crescente adoção do SharePoint Online como plataforma central para armazenamento e colaboração de documentos trouxe novos desafios relacionados à governança da informação, rastreabilidade e proteção de ativos digitais.

Entre esses desafios, destaca-se a necessidade de monitorar exclusões de arquivos em tempo real, permitindo que equipes de TI, segurança da informação e governança documental sejam notificadas imediatamente quando conteúdos são removidos.

Este artigo apresenta uma arquitetura baseada em Microsoft Power Automate para monitoramento de exclusões em bibliotecas do SharePoint Online, abordando conceitos de contas de serviço, caixas compartilhadas, listas de distribuição e requisitos de licenciamento. Também são discutidas as limitações da solução e as melhores práticas para implantação em ambientes corporativos.

O SharePoint Online tornou-se um dos principais repositórios corporativos para documentos, registros operacionais, evidências de auditoria e conteúdo colaborativo. Entretanto, a exclusão acidental ou indevida de arquivos continua sendo uma das ocorrências mais comuns observadas em ambientes empresariais.

Embora o SharePoint possua recursos nativos como Lixeira e Versionamento, muitas organizações necessitam de mecanismos proativos capazes de alertar administradores, gestores de conteúdo e equipes de conformidade imediatamente após a remoção de um documento.

Nesse contexto, o Microsoft Power Automate oferece uma alternativa de baixo código (Low-Code) para implementação de fluxos automatizados capazes de reagir a eventos de exclusão e enviar notificações para destinatários previamente definidos.

O Evento de Exclusão no SharePoint Online

O conector nativo do SharePoint disponível no Power Automate oferece o gatilho:

Quando um arquivo é excluído
(When a file is deleted)

Esse gatilho inicia automaticamente a execução de um fluxo sempre que um documento é removido de uma biblioteca monitorada.

A principal característica desse mecanismo é seu funcionamento orientado a eventos. Não existe necessidade de varreduras periódicas ou tarefas agendadas para identificar exclusões. A automação é disparada imediatamente após a ação realizada pelo usuário.

Contudo, existe uma limitação importante:

O gatilho opera em nível de biblioteca documental. Em outras palavras, não é possível monitorar todas as bibliotecas de um site SharePoint utilizando um único gatilho nativo. Cada biblioteca monitorada necessita possuir seu próprio gatilho ou, alternativamente, a organização deve recorrer aos registros de auditoria do Microsoft 365 para obtenção de uma visão mais abrangente.

Arquitetura Recomendada

Uma arquitetura corporativa típica pode ser composta pelos seguintes elementos:

Camada de Origem

SharePoint Online
Bibliotecas documentais corporativas

Camada de Automação

Microsoft Power Automate
Fluxos automatizados baseados em eventos

Camada de Notificação

Caixa compartilhada (Shared Mailbox)
Grupo de Distribuição Microsoft 365
Canal Microsoft Teams

Camada de Governança

Microsoft Purview Audit
SharePoint Audit Logs
Centro de Administração do Microsoft 365

O fluxo passa a operar da seguinte forma:

Um usuário exclui um documento.
O SharePoint gera o evento.
O Power Automate captura a ocorrência.
Um e-mail é enviado automaticamente.
O evento pode ser registrado em uma lista de auditoria.
Equipes responsáveis recebem a notificação.

Essa abordagem reduz o tempo de identificação de exclusões e aumenta significativamente a capacidade de rastreabilidade organizacional.

Utilização de Caixa Compartilhada

Em ambientes corporativos maduros, recomenda-se evitar o envio de notificações a partir da conta pessoal de administradores.

As vantagens são evidentes:

Centralização das notificações.
Continuidade operacional.
Independência em relação a mudanças de colaboradores.
Facilidade de auditoria.
Histórico único de comunicação.

Além disso, várias equipes podem receber permissão de acesso à mesma caixa, permitindo análise colaborativa dos alertas.

Utilização de Listas de Distribuição

Outra prática recomendada consiste em direcionar as notificações para uma lista de distribuição ou grupo Microsoft 365.

sse modelo permite que:

Segurança da Informação receba os alertas.
Governança documental acompanhe as exclusões.
Administradores SharePoint monitorem ocorrências.
Gestores das áreas possuam visibilidade dos eventos.

O gerenciamento dos destinatários torna-se mais simples, pois novas pessoas podem ser adicionadas ao grupo sem necessidade de alteração no fluxo.

Conta de Serviço para Execução dos Fluxos

Em ambientes corporativos, recomenda-se fortemente que o Power Automate seja executado utilizando uma conta de serviço dedicada.

Benefícios:

Rastreabilidade

Todos os fluxos ficam associados a uma identidade conhecida.

Continuidade

Mudanças de equipe não afetam a execução das automações.

Governança

Permite inventariar e controlar todas as automações corporativas.

Segregação de Funções

As credenciais utilizadas pelos fluxos permanecem separadas das contas administrativas.

Trata-se de uma prática amplamente adotada em ambientes de produção.

Licenciamento: E1 ou E3?

Uma dúvida recorrente é se uma conta de serviço baseada em Microsoft 365 E1 é suficiente para executar esse tipo de automação.

A documentação de licenciamento do Power Automate informa que os usuários licenciados com planos Microsoft 365 possuem acesso aos conectores padrão (Standard Connectors), incluindo SharePoint Online e Outlook, embora com capacidades mais limitadas quando comparadas às licenças Power Automate Premium. [learn.microsoft.com], [learn.microsoft.com]

Como o cenário descrito neste artigo utiliza apenas:

SharePoint Online
Outlook
Fluxo de nuvem automatizado
Envio de e-mails

não há utilização de:

Conectores Premium
RPA
AI Builder
Dataverse avançado
Process Mining

Consequentemente, uma conta de serviço licenciada com Office 365 E1 normalmente possui os recursos necessários para hospedar esse tipo de fluxo baseado exclusivamente em conectores padrão. A documentação de licenciamento também informa que licenças Microsoft 365 incluem capacidades limitadas do Power Automate para automações utilizando conectores padrão.

Por outro lado, caso a organização deseje utilizar:

Conectores Premium;
Integração com sistemas externos;
AI Builder;
Processamento avançado;
RPA assistido ou não assistido;

será necessária a adoção de licenças Power Automate Premium ou Process, conforme o cenário.

Limitações da Solução

Apesar de eficiente, a solução apresenta algumas restrições importantes.

O gatilho de exclusão é executado após a remoção do arquivo, o que significa que parte dos metadados originais pode não estar mais disponível no momento da execução.

Além disso:

Nem todas as propriedades do documento são retornadas.
A recuperação do documento não é realizada pelo fluxo.
O monitoramento ocorre por biblioteca documental.
Grandes volumes de exclusões podem gerar muitas notificações.

Por essa razão, organizações que necessitam de auditoria corporativa abrangente normalmente complementam a solução com os logs do Microsoft Purview Audit.

Vamos aos passos para a configuração:

Acesse o https://make.powerautomate.com/

Clique em Criar e em seguida em Sharepoint

Na sequencia escolha a opção, Quando um arquivo for excluído.

Você vai precisar configurar o endereço do site do Sharepoint e o nome da Biblioteca. Depois use o Enviar um e-mail (V2), que permite adição de estrutura HTML e vínculo de campos

Adicione as informações de mensagem, salve o rascunho )para não perder) e publique se quiser já testar.

O e-mail chega neste molde aqui depois de alguns minutos.

Conclusão

A utilização do Microsoft Power Automate para monitorar exclusões em bibliotecas do SharePoint Online representa uma estratégia eficaz para fortalecer a governança da informação e aumentar a capacidade de auditoria dos ambientes Microsoft 365.

A adoção de contas de serviço dedicadas, associadas a caixas compartilhadas ou listas de distribuição, contribui significativamente para a continuidade operacional e para a gestão centralizada dos alertas. Em cenários baseados exclusivamente nos conectores padrão do ecossistema Microsoft 365, uma conta licenciada com Office 365 E1 tende a atender aos requisitos da solução, mantendo baixo custo operacional e simplicidade administrativa. [learn.microsoft.com], [learn.microsoft.com]

À medida que os ambientes corporativos evoluem em direção a modelos mais rigorosos de conformidade e segurança, mecanismos automatizados de monitoramento como esse passam a desempenhar papel fundamental na proteção dos ativos informacionais e na construção de uma cultura organizacional orientada à governança digital.

Microsoft Purview para PMEs: Você Está Aproveitando Tudo o Que Já Pagou?

2026-08-10T13:50:00.000-03:00

Área de tecnologia principal: Security | Identity & Access
Áreas de tecnologia adicionais: Security | Microsoft Purview
Dados do autor: https://linktr.ee/edupopov

Introdução

Quando o assunto é proteção de dados, muitas pequenas e médias empresas acreditam que somente organizações de grande porte conseguem implementar controles avançados de conformidade, classificação de dados, prevenção contra vazamento de informações e investigação de incidentes internos.

Essa percepção geralmente leva a uma conclusão equivocada: para utilizar o Microsoft Purview de forma eficiente, seria obrigatório migrar para licenças Microsoft 365 E5, elevando significativamente os custos da organização.

Obs: Segue a trilha do Microsoft Purview - https://learn.microsoft.com/pt-br/training/purview/

Entretanto, a realidade atual é diferente.

Muitas empresas que utilizam o Microsoft 365 Business Premium já possuem recursos relevantes do Microsoft Purview disponíveis em sua assinatura e, em diversos casos, tais funcionalidades permanecem totalmente subutilizadas.

Antes de considerar uma expansão de licenciamento, é fundamental entender quais recursos já estão disponíveis, quais riscos permanecem sem proteção e qual é o caminho mais econômico para ampliar a maturidade de governança e proteção de dados.

O Novo Desafio da Segurança: Os Dados se Tornaram o Principal Alvo

Durante muitos anos, os investimentos em segurança concentraram-se na proteção da infraestrutura, servidores, dispositivos e redes corporativas. Embora esses elementos continuem importantes, os atacantes mudaram seu foco.

Hoje, o ativo mais valioso não é o servidor, mas a informação armazenada nele.

Dados financeiros, informações de clientes, documentos estratégicos, contratos, projetos confidenciais e registros de colaboradores são constantemente alvo de ameaças externas e internas. Além disso, regulamentações como a LGPD exigem que as organizações sejam capazes de demonstrar controle sobre o uso, armazenamento e compartilhamento dessas informações.

Nesse cenário, não possuir mecanismos adequados de proteção pode resultar em:

Vazamento de dados confidenciais;
Compartilhamento inadequado de informações;
Falta de rastreabilidade durante investigações;
Dificuldade para atender auditorias e requisitos regulatórios;
Aumento do impacto financeiro e reputacional após incidentes.

O Microsoft Purview foi criado justamente para auxiliar as organizações a identificar, classificar, proteger e monitorar seus dados ao longo de todo o ciclo de vida da informação.

O Que Já Está Incluso no Microsoft 365 Business Premium?

Um dos maiores equívocos observados em projetos de adoção do Purview é imaginar que usuários do Business Premium não possuem qualquer funcionalidade de conformidade.

Na prática, a licença já inclui diversos recursos importantes, entre eles:

Classificação e Rotulagem de Informações

As organizações podem utilizar rótulos de sensibilidade (Sensitivity Labels) para identificar conteúdos confidenciais e aplicar proteção aos documentos e e-mails corporativos.

Data Loss Prevention (DLP)

O Business Premium oferece recursos de prevenção contra perda de dados para Exchange Online, SharePoint Online e OneDrive, permitindo bloquear ou alertar sobre o compartilhamento inadequado de informações sensíveis.

Auditoria Básica

Também estão disponíveis logs de auditoria que auxiliam no rastreamento de atividades realizadas pelos usuários dentro do ambiente Microsoft 365.

eDiscovery Básico

As funcionalidades básicas de busca e retenção de conteúdo permitem atender investigações simples e demandas jurídicas iniciais.

Em muitas empresas, esses recursos permanecem desativados ou configurados parcialmente, o que significa que a organização está pagando por uma proteção que simplesmente não está sendo utilizada.

O Que Falta Para Uma Estratégia Mais Avançada?

Embora o Business Premium entregue uma excelente base de proteção, existem cenários mais avançados que exigem funcionalidades adicionais.

Entre elas destacam-se:

Insider Risk Management

Permite identificar comportamentos potencialmente perigosos realizados por usuários internos, como cópia excessiva de arquivos, movimentação incomum de informações ou atividades associadas ao risco de vazamento de dados.

Communication Compliance

Monitora comunicações corporativas para auxiliar no atendimento de requisitos regulatórios e políticas internas.

eDiscovery Premium

Oferece capacidades avançadas de investigação, análise e correlação de evidências digitais.

Audit Premium

Amplia significativamente as capacidades de auditoria e retenção de registros para investigações e requisitos regulatórios mais complexos.

DLP Avançado e Proteção de Endpoints

Permite aplicar controles de proteção diretamente em dispositivos, reduzindo riscos relacionados à cópia de dados para mídias removíveis ou aplicações não autorizadas.

Business Premium + Purview ou Microsoft 365 E5?

Essa é uma das perguntas mais frequentes entre gestores de TI.

Historicamente, muitas organizações acreditavam que a única forma de acessar capacidades avançadas do Purview seria migrando todos os usuários para o Microsoft 365 E5.

Contudo, o modelo de licenciamento da Microsoft evoluiu e atualmente existem opções de aquisição de recursos adicionais do Purview por meio de complementos (add-ons), permitindo que empresas utilizem funcionalidades avançadas sem necessariamente realizar uma "migração" completa para E5.

Isso abre espaço para estratégias mais inteligentes de investimento:

Manter usuários com Business Premium;
Adicionar recursos avançados somente para grupos específicos;
Expandir a proteção de forma gradual;
Reduzir custos em comparação com uma migração total para E5.

A análise correta depende do perfil da empresa, dos requisitos regulatórios e do risco associado aos dados processados pela organização.

Erros Comuns na Implantação do Purview

Mesmo quando as licenças estão disponíveis, alguns erros são recorrentes:

1. Habilitar Recursos Sem Classificação de Dados

Muitas empresas implementam DLP sem antes identificar quais informações precisam ser protegidas.

2. Ignorar Sensitivity Labels

Sem classificação adequada, torna-se difícil aplicar políticas consistentes de proteção.

3. Não Envolver Áreas de Negócio

Proteção de dados não é apenas responsabilidade da TI. Jurídico, RH, Financeiro e áreas operacionais precisam participar da definição das políticas.

4. Tratar Conformidade Como Projeto Único

Governança de dados é um processo contínuo e não uma implementação que termina após a configuração inicial.

5. Comprar Novas Licenças Antes de Explorar as Existentes

Este talvez seja o erro mais caro. Muitas empresas adquirem novas assinaturas sem aproveitar completamente os recursos já inclusos em sua licença atual.

Uma Ação Prática Para Esta Semana

Independentemente da licença utilizada atualmente, existe uma iniciativa simples capaz de gerar valor imediato.

Realize um levantamento dos recursos Purview já habilitados no tenant Microsoft 365 da organização e responda às seguintes perguntas:

Os rótulos de sensibilidade estão configurados?
Existem políticas de DLP ativas?
Os logs de auditoria estão sendo revisados?
Há políticas de retenção para informações críticas?
Os usuários conhecem as classificações de dados existentes?

Se a resposta for "não" para a maioria dessas perguntas, provavelmente o maior ganho não está em comprar novas licenças, mas sim em utilizar corretamente os recursos já disponíveis.

Conclusão

A proteção de dados deixou de ser uma preocupação exclusiva das grandes corporações. Qualquer organização que manipule informações de clientes, colaboradores ou processos financeiros precisa de mecanismos adequados de governança, conformidade e prevenção contra vazamentos.

A boa notícia é que muitas PMEs já possuem uma base sólida de proteção através do Microsoft 365 Business Premium. Antes de investir em uma migração para E5 ou em novos componentes de segurança, vale a pena avaliar os recursos que já estão disponíveis e verificar se eles estão efetivamente entregando valor para o negócio.

No fim das contas, a verdadeira pergunta não é quanto custa o Microsoft Purview.

A pergunta correta é: quanto custa não utilizar a proteção que sua empresa já está pagando?

Nova trilha de Troubleshooting do Active Directory [Servço de Replicação]

2026-08-07T10:07:00.000-03:00

Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

Link da Trilha: Troubleshoot Active Directory Domain Services Replication - Training | Microsoft Learn

Nova trilha do Microsoft Learn aborda diagnóstico de problemas de replicação do Active Directory

A replicação constitui um dos principais mecanismos de sustentação do Active Directory Domain Services. É por meio dela que alterações realizadas em um controlador de domínio são distribuídas aos demais servidores responsáveis por armazenar as diferentes partições do diretório. Contas de usuários, grupos, computadores, políticas, configurações de sites, registros integrados ao DNS e outros objetos dependem desse processo para permanecer disponíveis e consistentes em toda a infraestrutura.

A trilha leva pouco tempo para ser percorrida (cerca de 40 min de leitura) e possui uma carga de conhecimento extremamente valiosa aos administradores de controlador de domínio. São técnicas clássicas de manejo de replicação e troubleshooting para o dia a dia.

Apesar de sua importância, a replicação nem sempre recebe a atenção necessária nas rotinas de administração. Em muitos ambientes, os controladores de domínio são considerados saudáveis enquanto continuam autenticando usuários e respondendo às consultas mais comuns. Entretanto, um servidor pode aparentemente funcionar de maneira normal e, ao mesmo tempo, apresentar atrasos ou falhas na atualização de determinados objetos.

Com o objetivo de fortalecer o conhecimento técnico nessa área, o Microsoft Learn disponibilizou o módulo avançado Troubleshoot Active Directory Domain Services replication. O conteúdo foi organizado em sete unidades e apresenta uma metodologia de diagnóstico baseada na interpretação de evidências, na identificação das dependências envolvidas, na aplicação de correções específicas e na posterior validação da convergência da replicação.

Mais do que ensinar comandos isolados, o material procura desenvolver uma forma estruturada de investigar incidentes. Essa abordagem é especialmente relevante porque uma mensagem de erro nem sempre revela diretamente a origem do problema. Um erro relacionado a RPC, por exemplo, pode ter sido provocado por resolução incorreta de nomes, indisponibilidade de rede, bloqueio de portas, falha de serviço ou tentativa de comunicação com um endereço IP desatualizado.

A replicação como fundamento da disponibilidade do Active Directory

O Active Directory adota um modelo de replicação multimaster. Isso significa que diferentes controladores de domínio graváveis podem originar alterações no diretório. Essas modificações são posteriormente encaminhadas aos demais servidores que mantêm uma réplica da mesma partição.

Esse modelo oferece disponibilidade e distribuição geográfica, mas também exige que os administradores acompanhem a saúde dos controladores de domínio e compreendam o funcionamento da topologia de replicação. Quando uma alteração deixa de chegar ao destino esperado, os efeitos podem surgir em diferentes pontos da operação.

Entre os sintomas mais comuns estão:

usuários que não conseguem utilizar uma senha recentemente alterada;
contas criadas que não são encontradas por determinadas aplicações;
alterações em grupos que não produzem o efeito esperado;
inconsistências na aplicação de políticas de grupo;
falhas de autenticação entre sites;
registros DNS desatualizados;
problemas em serviços que consultam controladores de domínio diferentes.

A documentação técnica da Microsoft aponta a conectividade de rede, a resolução DNS, a autenticação, a sincronização de horário, a integridade da base do diretório, a topologia e o próprio mecanismo de replicação como dependências importantes desse processo.

Por essa razão, manter os controladores de domínio saudáveis não deve ser entendido apenas como uma tarefa de manutenção de servidores. Trata-se de uma atividade diretamente relacionada à continuidade dos processos corporativos.

Uma trilha orientada pela análise de evidências

Um dos principais méritos do novo conteúdo é não apresentar o troubleshooting como uma sequência automática de comandos. O diagnóstico começa pela coleta e correlação de evidências.

O administrador precisa identificar o controlador de domínio de origem, o controlador de destino, a partição envolvida, o horário da última replicação bem-sucedida, a quantidade de falhas consecutivas e o código retornado. Sem esse contexto, existe o risco de interpretar um evento secundário como se ele fosse a causa principal.

A trilha aborda a utilização conjunta de ferramentas tradicionais e recursos do Windows PowerShell, entre eles:

repadmin /replsummary
repadmin /showrepl * /csv
repadmin /showrepl <ControladorDeDominio> /all /verbose

Get-ADReplicationFailure
Get-ADReplicationPartnerMetadata

dcdiag /test:replications /e /v
dcdiag /test:dns /e /v

O Repadmin permite observar o estado das relações de replicação sob a perspectiva dos controladores de destino. Já os cmdlets do Windows PowerShell fornecem informações estruturadas que podem ser filtradas, organizadas e incorporadas a rotinas de monitoramento. O DCDiag, por sua vez, amplia a investigação ao executar testes relacionados à saúde dos controladores de domínio, conectividade, DNS, serviços e replicação.

Entretanto, nenhum desses recursos deve ser analisado de forma isolada. O resultado de um comando precisa ser relacionado aos eventos registrados nos logs Directory Service, System, DNS Server e, quando aplicável, DFS Replication.

Essa correlação ajuda a responder a uma pergunta essencial: o erro observado representa a causa do incidente ou apenas uma consequência de uma falha anterior?

Diferenciar falhas reais de estados esperados

Outro ponto importante do módulo é a necessidade de distinguir falhas acionáveis de situações esperadas na operação do Active Directory.

Nem todo intervalo elevado entre replicações significa que o serviço está indisponível. Em ambientes com vários sites, a comunicação pode seguir horários e intervalos configurados nos links de site. Um controlador de domínio também pode estar temporariamente desligado por manutenção, em processo de implantação ou aguardando sua transferência para uma unidade remota.

Da mesma maneira, alterações recentes na topologia podem produzir estados transitórios. A promoção ou remoção de um controlador de domínio, a alteração de um link de site ou a inclusão de uma nova partição pode exigir algum tempo até que as informações sejam conhecidas por todos os servidores.

O módulo ensina que o administrador deve conhecer o comportamento esperado do ambiente antes de classificar determinado resultado como falha. Uma diferença temporal expressiva somente se torna significativa quando ultrapassa a janela prevista de replicação, manutenção e tolerância operacional.

Também existem códigos que podem representar erros secundários. O status 1256, por exemplo, pode ocorrer quando o controlador de destino cancela tarefas posteriores depois que uma falha anterior impediu o estabelecimento da comunicação. Nesse cenário, o diagnóstico deve se concentrar no primeiro erro capaz de explicar os demais resultados.

Esse cuidado evita intervenções desnecessárias e reduz a possibilidade de o administrador aplicar uma correção em um componente que estava funcionando adequadamente.

Identificação da dependência que realmente falhou

Depois de delimitar o problema, o próximo passo consiste em identificar a dependência responsável pela interrupção.

As principais categorias analisadas pela trilha são:

Resolução de nomes

O Active Directory depende fortemente do DNS. Os controladores de domínio utilizam registros de host, registros de serviço e registros CNAME baseados no GUID para localizar parceiros e serviços necessários à replicação.

Um registro desatualizado pode direcionar o controlador de destino para um endereço IP que não pertence mais ao servidor de origem. Nesse caso, a mensagem apresentada pelo Repadmin pode indicar indisponibilidade de RPC, embora a causa efetiva esteja no DNS.

Ferramentas como Resolve-DnsName, Get-DnsServerResourceRecord e os testes específicos de DNS do DCDiag auxiliam na validação dessa camada.

Resolve-DnsName DC01.contoso.com

dcdiag /test:dns /s:DC01 /v /DnsBasic

dcdiag /test:dns /s:DC01 /v /DnsRecordRegistration

Os testes básicos do DCDiag verificam aspectos como conectividade, serviços essenciais, configuração do cliente DNS, registros necessários e disponibilidade das zonas relacionadas ao domínio.

Conectividade de rede e RPC

O erro 1722 informa que uma operação RPC não pôde ser concluída, mas não determina sozinho qual camada falhou. O destino pode ter resolvido um endereço incorreto, encontrado uma rota inválida, sido bloqueado por um firewall ou tentado acessar um serviço indisponível.

O teste da porta 135 pode ajudar na investigação:

Test-NetConnection DC01.contoso.com -Port 135

Contudo, o sucesso desse teste demonstra apenas que uma conexão TCP foi estabelecida com a porta consultada. Isso não comprova que o RPC Endpoint Mapper processou corretamente a solicitação, que o endpoint do serviço de replicação está registrado ou que a replicação funcionará de ponta a ponta.

Autenticação, identidade e horário

A replicação também depende da autenticação Kerberos, da identidade correta dos controladores de domínio, dos Service Principal Names e da sincronização de horário.

Problemas nessa camada podem envolver diferença excessiva de horário, registros SPN incorretos, contas de computador inconsistentes ou falhas no canal seguro.

Entre os comandos que podem apoiar a investigação estão:

w32tm /query /status
w32tm /query /source
w32tm /monitor
nltest /dsgetdc:contoso.com /force
setspn -F -Q <SPN>

A orientação central é investigar a identidade e o contexto de autenticação antes de executar procedimentos como redefinição de contas, alteração de permissões ou remoção de registros SPN.

Topologia e consistência dos dados

A topologia de replicação é construída pelo Knowledge Consistency Checker com base nos sites, sub-redes, links de site, custos, horários, servidores bridgehead e condições atuais da infraestrutura.

Quando existe uma falha de desenho ou configuração, criar manualmente uma conexão pode até restabelecer temporariamente determinado caminho. Entretanto, essa ação pode apenas ocultar a origem do problema.

O módulo apresenta ferramentas para verificar conexões, sites, sub-redes e links:

repadmin /showconn <ControladorDeDominio>
repadmin /options <ControladorDeDominio>

Get-ADReplicationConnection -Filter *
Get-ADReplicationSite -Filter *
Get-ADReplicationSubnet -Filter *
Get-ADReplicationSiteLink -Filter *

Alguns erros de topologia podem ser transitórios. O código 8452, por exemplo, pode surgir enquanto uma partição está sendo adicionada ou removida, durante a alteração de um parceiro pelo KCC ou antes que mudanças recentes tenham convergido.

Nessas situações, forçar amplamente a replicação com comandos como repadmin /syncall pode ser inadequado. Primeiro, é necessário confirmar se o destino realmente deve armazenar aquela partição e se a origem continua sendo um parceiro válido.

Existem ainda condições mais sensíveis, relacionadas à consistência dos dados. Eventos como 1988, 2042 e 2095 podem indicar objetos persistentes, tempo superior ao tombstone lifetime ou rollback de USN. Nesses casos, as proteções impostas pelo Active Directory não devem ser removidas de forma improvisada.

O correto é preservar as evidências, identificar uma réplica gravável reconhecidamente íntegra e encaminhar o incidente para um procedimento de recuperação controlado.

Saber quando interromper uma intervenção também faz parte do trabalho de um administrador experiente.

Correções específicas e controladas

A trilha reforça que uma correção somente deve ser aplicada quando as evidências indicarem uma causa suficientemente demonstrada.

Em vez de reiniciar diversos serviços, modificar a topologia ou forçar uma sincronização completa, deve-se realizar a alteração de menor impacto capaz de corrigir o componente identificado.

Quando o problema está em um registro DNS desatualizado, por exemplo, a intervenção deve se limitar à correção desse registro, à atualização das cópias autoritativas relevantes e à limpeza do cache do resolvedor afetado.

Além disso, o estado anterior à mudança deve ser registrado. Essa prática permite comparar os resultados, reverter a alteração quando necessário e demonstrar tecnicamente o motivo da intervenção.

O próprio módulo diferencia ações somente de leitura de operações capazes de modificar o estado do ambiente. Uma consulta com Repadmin pode ser apenas diagnóstica, enquanto repadmin /replicate inicia uma replicação direcionada. Da mesma forma, determinados testes completos do DCDiag podem realizar uma criação e remoção temporária de registro para validar atualizações dinâmicas no DNS.

Essa consciência sobre o impacto de cada comando é fundamental em ambientes de produção.

Verificar a convergência e o problema de negócio

Um dos ensinamentos mais relevantes da trilha é que a ausência de mensagens de erro não encerra o diagnóstico.

Depois da correção, é necessário confirmar que:

uma nova tentativa de replicação foi concluída com sucesso;
o horário da última replicação bem-sucedida foi atualizado;
o número de falhas consecutivas deixou de crescer;
as partições afetadas voltaram a convergir;
os eventos relacionados ao incidente não continuam sendo registrados;
o sintoma percebido pelos usuários ou aplicações foi efetivamente resolvido.

Suponha que o incidente tenha sido aberto porque um usuário recém-adicionado a um grupo não recebeu acesso a determinada aplicação. Após corrigir a replicação, o administrador deve consultar diretamente o controlador de domínio que anteriormente apresentava dados desatualizados e verificar se o membro já aparece no grupo.

Get-ADGroupMember `
    -Identity "Grupo-Acesso-Financeiro" `
    -Server "DC-Destino.contoso.com"

Se a alteração estiver presente no diretório, mas o usuário continuar sem acesso, talvez seja necessário renovar o token de autenticação. Nesse caso, o problema de replicação pode ter sido resolvido, enquanto o sintoma remanescente pertence a outra camada.

No caso de políticas de grupo, a validação exige atenção adicional. O objeto da política é replicado pelo Active Directory, enquanto seus arquivos são normalmente distribuídos pelo DFS Replication por meio do SYSVOL. Portanto, verificar apenas a replicação do diretório não comprova que todo o conteúdo da política convergiu.

Por que percorrer esta trilha

O conteúdo foi classificado como avançado e pressupõe experiência com domínios, florestas, controladores de domínio, sites, sub-redes, DNS, Kerberos, PowerShell, Política de Grupo, controle de mudanças e procedimentos de backup e recuperação.

Apesar desse perfil, a trilha também pode ser útil para profissionais que estão ampliando sua atuação em infraestrutura de identidade. Ela organiza conceitos que muitas vezes são aprendidos de maneira fragmentada, normalmente durante incidentes reais.

Percorrer o módulo contribui para desenvolver competências importantes:

interpretar corretamente os resultados do Repadmin e do DCDiag;
trabalhar com dados estruturados de replicação no PowerShell;
correlacionar comandos com eventos do sistema;
reconhecer erros primários e secundários;
separar falhas reais de atrasos esperados;
avaliar DNS, rede, RPC, autenticação e topologia;
aplicar mudanças de maneira controlada;
reconhecer situações que exigem escalonamento;
validar tanto a infraestrutura quanto o impacto no negócio.

Essa combinação transforma o troubleshooting em um processo técnico, documentado e reproduzível, reduzindo decisões baseadas exclusivamente em tentativa e erro.

Considerações finais

A saúde do Active Directory não deve ser avaliada apenas pela disponibilidade aparente dos controladores de domínio. Um servidor pode aceitar autenticações e responder a consultas enquanto determinadas partições permanecem desatualizadas.

Falhas prolongadas de replicação podem comprometer a uniformidade das informações, dificultar a aplicação de políticas, afetar processos de autenticação e criar condições delicadas de consistência de dados. Por isso, o acompanhamento da replicação deve fazer parte das atividades regulares de administração, e não apenas das ações executadas durante uma indisponibilidade.

O módulo Troubleshoot Active Directory Domain Services replication, disponível no Microsoft Learn, oferece uma oportunidade relevante de atualização para administradores de identidade, profissionais de suporte, arquitetos e responsáveis por ambientes Windows Server.

Mais do que conhecer ferramentas, o desafio está em interpretar os sinais apresentados pelo ambiente, identificar a dependência realmente afetada, aplicar uma correção proporcional ao problema e comprovar que a replicação voltou a convergir.

Para quem administra Active Directory, compreender esse processo não representa apenas uma habilidade adicional. Trata-se de um conhecimento essencial para proteger a disponibilidade, a segurança e a consistência de uma das infraestruturas mais importantes da organização.

Ao término da trilha, você pode testar seus conhecimentos e alcançar a badge da conquista.

Eduardo Popovici

Ollama com Windows Server 2025 Server Core em uma IaaS no Azure, será que compensa?

1. Chatbot no Azure IaaS — Windows Server 2025 Core + Ollama

2. O que muda em relação ao servidor local?

3. O grande diferencial: escolher uma VM com GPU

4. O que muda na autenticação corporativa?

6. O ponto mais importante: custo do Azure IaaS

Um benefício possível para a empresa

7. Comparação final das três arquiteturas

8. Minha recomendação

Evento presencial na Casa Nina, em Guarulhos: tecnologia, inovação e inteligência artificial!

Muito além da teoria: tecnologia aplicada ao mundo real

A importância de compartilhar conhecimento

Nos encontramos em Guarulhos!

Evento Tech Week da FATEC de Bauru, falando sobre IA aplicada ao mundo real.

Quando uma ideia se transforma em software

GitHub Copilot e Codex: a IA como parceira no desenvolvimento

Gemini e Google AI Studio: explorando novas possibilidades

Criando jogos com Lovable

A IA não elimina a necessidade de conhecimento técnico

O futuro do desenvolvimento também passa pela capacidade de fazer boas perguntas

Uma experiência de troca de conhecimento

Por trás do console do Hyper-V: compreendendo os processos VMConnect, VMMS e VMWP no Windows Server

Introdução

1. A arquitetura do Hyper-V e a separação de responsabilidades

2. VMConnect.exe: a interface de acesso ao console virtual

2.1 Executando o VMConnect

2.2 Modo básico e modo de sessão aprimorada

3. VMMS.exe: o serviço responsável pelo gerenciamento das máquinas virtuais

3.1 Identificando o serviço VMMS

4. VMWP.exe: o processo de trabalho das máquinas virtuais

4.1 Identificando processos VMWP

5. Como VMConnect, VMMS e VMWP trabalham em conjunto

6. VMBus: comunicação entre a partição raiz e as máquinas virtuais

7. Segurança: o hipervisor como fronteira de isolamento

7.1 A importância do controle de acesso ao VMConnect

7.2 A exposição de recursos no modo de sessão aprimorada

8. Diagnóstico e investigação utilizando PowerShell

8.1 Eventos relacionados ao Hyper-V

9. Windows Server Core e a administração remota do Hyper-V

10. Considerações sobre desempenho e disponibilidade

11. Boas práticas para ambientes corporativos

Conclusão

Referências técnicas

O que consegui criar com BitNet - Projeto Boris - Inteligência Artificial Local, BitNet e RAG: estamos diante de uma nova era da infraestrutura de TI?

Da infraestrutura tradicional à infraestrutura construída com IA

E o Google Cloud Platform? A lógica é semelhante

BitNet: quando a Inteligência Artificial deixa de depender exclusivamente dos grandes datacenters

Minha experiência: construindo um assistente local de cibersegurança

O que é uma RAG e por que ela muda o comportamento de uma IA?

Transformando minha biblioteca técnica em conhecimento consultável

O ponto mais intrigante: quem define as regras de uma IA local?

Será que precisamos de grandes modelos para tudo?

IA local versus IA em nuvem: não se trata de escolher um vencedor

O futuro não pertence a quem apenas sabe escrever prompts

Considerações finais

Referências técnicas para aprofundamento

Controle de acesso a custos no Microsoft Azure: RBAC, Billing Account, Enterprise Agreement e acesso somente leitura

Área de tecnologia principal: Azure | Microsoft AzureÁreas de tecnologia adicionais: Azure | PowershellDados do autor: https://linktr.ee/edupopov

1. Introdução

2. Cenário do laboratório

3. O primeiro conceito importante: existem diferentes tipos de função no Azure

4. Microsoft Entra ID Roles não são funções de custos do Azure

5. O que é Azure RBAC?

6. Entendendo o conceito de escopo

7. A função Cost Management Reader

8. Cost Management Reader versus Cost Management Contributor

9. Exemplo: concedendo Cost Management Reader em uma assinatura

10. Mas isso é suficiente em um Enterprise Agreement?

11. Estrutura lógica de um Enterprise Agreement

12. Enterprise Administrator

13. Enterprise Administrator Read-Only

14. O que o Enterprise Administrator Read-Only pode visualizar?

15. Enterprise Administrator Read-Only não administra os recursos Azure

16. Configuração prática no laboratório popovici.lab

17. Adicionando um Enterprise Administrator

18. Tipo de autenticação

19. Configurando o acesso somente leitura

20. Exemplo de configuração final

21. Resultado esperado

Área de tecnologia principal: Azure | Microsoft Azure
Áreas de tecnologia adicionais: Azure | Powershell
Dados do autor: https://linktr.ee/edupopov

Figura 6. Painel real de validação pelo Synchronization Services Manager no ambiente lab.test.

Figura 7. Verificação de versionamento e sync de delta através do Powershell.