Luiz Henrique Lima Campos – Microsoft MVP

Neste artigo, mostro um fluxo objetivo para validar a instalação do Windows Admin Center 2410 e revisar um ponto que costuma gerar dúvida em muitas implantações: quando usar a opção Manage As. Em ambiente Windows Server, esse detalhe faz diferença porque o acesso ao gateway não é a mesma coisa que a credencial usada no servidor de destino.
A instalação do Windows Admin Center continua sendo uma forma muito prática de centralizar tarefas do Windows Server em uma interface web. Depois que o setup termina, o primeiro cuidado não deve ser apenas “abrir a ferramenta”, mas confirmar se o gateway ficou acessível, se a versão foi aplicada corretamente e se a administração remota está coerente com o modelo de acesso do ambiente.
A Figura 1 mostra a tela final de instalação da versão 2410. Esse ponto é importante porque confirma que o componente principal foi implantado e que a instância já está pronta para a etapa seguinte, que é o primeiro acesso e a revisão inicial do gateway.

Figura 1 — Tela de confirmação da instalação do Windows Admin Center 2410.

O que eu valido logo depois da instalação
Depois da instalação, eu costumo validar quatro pontos bem rápidos: se o gateway abre normalmente no navegador, se o certificado e o acesso estão coerentes com o ambiente, se a página All connections carrega sem erro e se a conta usada no gateway realmente precisa das mesmas permissões no servidor gerenciado.
Essa última verificação evita um erro comum: assumir que a conta que entra no Windows Admin Center deve obrigatoriamente ser a mesma conta administrativa do servidor de destino. Em muitos cenários, isso não é necessário. O gateway pode ser acessado por uma identidade, enquanto a administração do host remoto usa outra credencial, aplicada apenas no momento necessário.
A Figura 2 destaca a opção Manage As. É justamente esse recurso que permite separar a autenticação no Windows Admin Center da credencial usada para executar tarefas no servidor ou cluster de destino. Essa separação melhora a organização operacional e ajuda a reduzir uso excessivo de contas mais privilegiadas no dia a dia.

Figura 2 — Manage As para usar credenciais específicas no servidor de destino.

Quando faz sentido usar Manage As
Na prática, eu vejo o Manage As fazer mais sentido quando o time usa uma conta para acessar o gateway, mas precisa de outra conta para tarefas administrativas pontuais no servidor. Isso é útil em cenários com separação entre acesso operacional, suporte e administração elevada.
Também é uma boa prática quando o objetivo é evitar sessões persistentes com credenciais altamente privilegiadas. Em vez de abrir tudo com uma conta mais sensível desde o começo, o administrador mantém um acesso mais controlado e só eleva a operação quando realmente precisa.
Depois dessa configuração, a validação final é simples: abrir o servidor de destino, testar uma ferramenta administrativa e confirmar se a ação está sendo executada com a credencial correta. Quando isso funciona, a instalação deixa de ser apenas técnica e passa a ficar realmente pronta para uso operacional.
Conclusão
O Windows Admin Center 2410 continua sendo uma forma eficiente de administrar Windows Server. Quando a instalação já nasce com revisão de acesso e uso correto do Manage As, o ambiente fica mais organizado e mais seguro para a operação diária.

O Windows LAPS consolidou uma forma mais moderna de gerenciar a senha da conta de administrador local em dispositivos Windows. Na prática, a dúvida mais comum não é a rotação em si, mas a origem da política. Em ambientes atuais, principalmente quando existem servidores no Active Directory e estações gerenciadas por Intune, a escolha entre Intune e GPO precisa ser feita com critério.
A decisão correta começa pelo tipo de ingresso do dispositivo. Quando o cenário é Microsoft Entra joined ou híbrido com gerenciamento moderno, o caminho mais natural é usar Intune. Já para servidores e equipamentos fortemente dependentes do Active Directory tradicional, a GPO continua sendo a forma mais direta de administração. O erro mais comum é tentar tratar as duas origens como se fossem complementares no mesmo dispositivo.
Boa prática: manter apenas uma origem principal de política por dispositivo. Quando o endpoint recebe configurações concorrentes, a validação pós-implantação tende a virar troubleshooting.

Configuração por Intune
Quando a prioridade é gerenciar dispositivos modernos com política baseada em CSP, o Intune tende a ser a primeira escolha. O ponto central nessa etapa é decidir onde a senha será armazenada: sem backup, no Microsoft Entra ID ou no Active Directory.

Figura 1 — Definição do Backup Directory em uma política de Windows LAPS no Intune.

A Figura 1 destaca um ponto importante de arquitetura. A definição de Backup Directory estabelece se a senha será apenas gerenciada localmente, enviada ao Microsoft Entra ID ou enviada ao Active Directory. Essa decisão define a forma de recuperação da senha, o modelo de auditoria e a experiência do suporte operacional.
Em dispositivos gerenciados por Intune, a tendência é usar uma política única e bem definida, evitando sobreposição com outras origens administrativas. Quando o ambiente já está inscrito e recebe políticas modernas, insistir em GPO para o mesmo conjunto de parâmetros costuma trazer mais ruído do que benefício.
Configuração por GPO no Active Directory
Quando o ambiente ainda depende fortemente de domínio tradicional, a GPO continua sendo extremamente relevante. Isso vale principalmente para servidores ingressados no Active Directory e para estruturas em que o controle administrativo ainda gira em torno do Group Policy Management Editor.

Figura 2 — Políticas de Windows LAPS no Group Policy Management Editor.

A Figura 2 mostra esse cenário mais tradicional. Para Windows Server 2025, essa abordagem continua válida quando a administração do servidor está centrada no domínio e quando a recuperação da senha precisa obedecer ao fluxo operacional já consolidado no Active Directory.
O ponto principal aqui é evitar conflito de origem. Em termos práticos, a melhor estratégia costuma ser esta: Intune para dispositivos que já vivem no modelo moderno de gestão; GPO para servidores e equipamentos em administração clássica de domínio. Misturar as duas origens no mesmo dispositivo, com parâmetros equivalentes, normalmente aumenta a chance de inconsistência na aplicação da política.
O que vale revisar depois da aplicação da política
• conta gerenciada — confirmar se a conta definida realmente existe no dispositivo
• tipo de backup — validar se Microsoft Entra ou Active Directory foi escolhido de forma coerente com o ambiente
• origem da política — revisar se o dispositivo está recebendo Intune ou GPO, sem sobreposição desnecessária
• rotação — confirmar se a política de expiração e troca de senha foi aplicada
• permissões de leitura — garantir que apenas o time autorizado tenha acesso à recuperação da senha
Conclusão
O Windows LAPS funciona melhor quando a origem da política é definida logo no início do projeto. Para Windows Server 2025, separar com clareza o que será gerenciado por Intune e o que continuará sob GPO reduz conflito, simplifica a validação e melhora a governança da conta administrativa local.

O Azure Arc Setup no Windows Server 2025 simplifica bastante o início da integração com o Azure. Antes mesmo de pensar no onboarding completo, vale fazer uma validação rápida para confirmar se o recurso está disponível, se o servidor está no contexto certo e se a equipe não vai entrar em um fluxo de conexão sem os pré-requisitos mínimos já definidos.
No dia a dia, esse cuidado evita retrabalho. Em vez de iniciar o assistente e descobrir problemas no meio do caminho, o melhor cenário é confirmar primeiro se o atalho está visível, se a conectividade de saída já foi tratada e se assinatura, grupo de recursos e padrão de organização já estão alinhados com a governança do ambiente.
A Figura 1 mostra o ponto de entrada do Azure Arc Setup na bandeja do sistema. Esse é o primeiro sinal de que o recurso está disponível no servidor e pronto para ser usado como porta de entrada do onboarding.

Figura 1 — Atalho do Azure Arc Setup visível na bandeja do Windows Server 2025.

Quando esse atalho aparece, a validação seguinte deve ser mais administrativa do que visual. O ideal é revisar se o servidor realmente deve ser conectado ao Azure Arc, se existe saída liberada pela TCP 443 e se o destino administrativo já foi definido corretamente. Também vale confirmar se o host não está rodando dentro do próprio Azure, porque nesse caso o onboarding para Azure Arc normalmente não é necessário.
Depois dessa checagem inicial, o próximo passo é abrir o assistente e observar se a experiência de entrada corresponde ao que se espera para um servidor pronto para onboarding. A tela inicial ajuda a confirmar se o fluxo gráfico está operacional e se a máquina já está apta a seguir para a próxima etapa.
A Figura 2 mostra a tela inicial do wizard. Nessa etapa, o administrador já consegue confirmar se o fluxo foi iniciado corretamente e se o servidor está pronto para avançar com uma preparação mais completa.

Quando esse atalho aparece, a validação seguinte deve ser mais administrativa do que visual. O ideal é revisar se o servidor realmente deve ser conectado ao Azure Arc, se existe saída liberada pela TCP 443 e se o destino administrativo já foi definido corretamente. Também vale confirmar se o host não está rodando dentro do próprio Azure, porque nesse caso o onboarding para Azure Arc normalmente não é necessário.
Depois dessa checagem inicial, o próximo passo é abrir o assistente e observar se a experiência de entrada corresponde ao que se espera para um servidor pronto para onboarding. A tela inicial ajuda a confirmar se o fluxo gráfico está operacional e se a máquina já está apta a seguir para a próxima etapa.
A Figura 2 mostra a tela inicial do wizard. Nessa etapa, o administrador já consegue confirmar se o fluxo foi iniciado corretamente e se o servidor está pronto para avançar com uma preparação mais completa.

Figura 2 — Tela inicial do Azure Arc Setup no Windows Server 2025.
Antes de prosseguir com o onboarding, a validação mínima que costumo considerar suficiente é esta:
• o atalho do Azure Arc Setup está visível e funcional;
• a saída pela porta 443 já foi considerada na política de rede;
• assinatura e resource group já foram definidos;
• o padrão de nome e tags do recurso já está claro;
• o escopo de administração do servidor já foi alinhado.
Essa validação é simples, rápida e evita que o onboarding comece sem contexto. Em ambientes maiores, isso faz diferença porque reduz erros de organização, evita conexões em escopo incorreto e melhora a consistência da operação híbrida desde o primeiro passo.
Em resumo, o Azure Arc Setup no Windows Server 2025 não deve ser visto apenas como um assistente gráfico conveniente. Ele funciona melhor quando é usado dentro de um fluxo de preparação mínimo, em que o servidor já entra no onboarding com conectividade, organização e responsabilidade administrativa bem definidas.

No Windows Server 2025, o modelo Pay-as-you-go chama atenção porque muda a conversa sobre licenciamento em cenários híbridos. Em vez de tratar o servidor apenas pelo modelo perpétuo tradicional, passa a existir a opção de ativar o licenciamento por consumo por meio do Azure Arc. Na prática, vejo esse recurso como algo interessante principalmente para ambientes que precisam ganhar agilidade em projetos, laboratórios, transições de infraestrutura ou servidores que não justificam um ciclo clássico de licenciamento logo no início.
O ponto mais importante é este: o Pay-as-you-go não começa no licenciamento em si. Ele começa na preparação correta do servidor para o Azure Arc. Sem isso, não existe base operacional para habilitar o modelo de cobrança de forma organizada.
A Figura 1 mostra o ponto de entrada do Azure Arc Setup no Windows Server 2025. Esse detalhe é útil porque simplifica o início do onboarding e reduz esforço operacional quando a equipe precisa conectar vários servidores fora do Azure à mesma camada de gerenciamento.

Figura 1 — Ponto de entrada do Azure Arc Setup na bandeja do Windows Server 2025.

O que vale revisar antes de ativar
• se o servidor realmente ficará fora do Azure e se esse modelo faz sentido para aquele caso de uso
• se a máquina está em Windows Server 2025 Standard ou Datacenter
• se o servidor já está habilitado no Azure Arc e com o Connected Machine agent em versão suportada
• se a conectividade de saída e os endpoints necessários para Arc e validação de licença estão liberados
• se o time já definiu assinatura, resource group, tags e responsáveis pela administração do recurso
Esse cuidado evita um erro comum: habilitar a cobrança antes de estruturar a governança do recurso. Quando isso acontece, o servidor até entra em produção, mas fica sem organização adequada, sem padrão de identificação e, em alguns casos, sem rotina clara para desligamento da cobrança quando o host deixa de ser necessário.
A Figura 2 mostra a tela inicial do assistente Azure Arc Setup. É a partir desse fluxo que o servidor ganha a base necessária para recursos posteriores, incluindo o próprio Pay-as-you-go. Depois do onboarding, o gerenciamento passa a ficar centralizado no Azure, o que torna mais simples acompanhar status do recurso, organização administrativa e etapa de licenciamento.

Figura 2 — Tela inicial do assistente Azure Arc Setup.

Como eu enxergo esse modelo na prática
O Pay-as-you-go do Windows Server 2025 funciona como uma alternativa ao licenciamento perpétuo tradicional para servidores implantados fora do Azure. Isso abre espaço para cenários em que a empresa precisa subir um host com mais rapidez, testar uma carga, manter um ambiente temporário ou evitar uma decisão de licenciamento definitiva logo no primeiro momento.
Outro ponto importante é que esse modelo não deve ser confundido com direitos amplos de virtualização. Mesmo em servidores host, o benefício vale para o dispositivo em que foi habilitado. Por isso, em ambientes com múltiplas VMs, a análise de custo e arquitetura precisa ser feita com cuidado para evitar expectativa errada sobre direitos de uso.
Também vale atenção para o aspecto operacional da cobrança. Se o servidor for desligado ou desprovisionado sem a desativação correta do Pay-as-you-go, a cobrança pode continuar. Em outras palavras, habilitar é fácil; governar bem o ciclo de vida é a parte realmente importante.
Validações que considero essenciais depois da habilitação
• Conferir o status do recurso no Azure Arc: o servidor precisa aparecer conectado, saudável e no escopo administrativo esperado.
• Revisar a organização lógica: resource group, nome e tags devem seguir o padrão definido pela equipe.
• Validar o modelo de acompanhamento financeiro: o time precisa saber quem acompanha habilitação, desabilitação e uso do recurso.
• Documentar o desligamento: deve existir um passo claro para encerrar o Pay-as-you-go quando o servidor sair de uso.
Conclusão
No meu ponto de vista, o Windows Server 2025 Pay-as-you-go é um recurso interessante quando o ambiente precisa de flexibilidade e velocidade, mas ele só faz sentido quando entra acompanhado de governança. A base dessa discussão continua sendo o Azure Arc: conectar bem, organizar bem e controlar bem. Quando isso é feito da forma certa, o modelo de consumo deixa de ser apenas uma novidade de licenciamento e passa a ser uma opção prática para operação real.