Se você é fã de tecnologia, com certeza já ouviu falar do Microsoft Copilot — o assistente de IA que está dominando ferramentas como Word, Excel, Teams e tantas outras. Mas tem uma parte dessa revolução que muita gente ainda não conhece: os Agentes do Copilot Studio. Mas, afinal, o que é um agente? 🤖 Pense no agente como um robô inteligente que trabalha por você. Ele entende comandos, toma decisões, conversa com usuários e ainda faz tudo isso de maneira autônoma, sem depender que você diga o tempo todo o que deve ser feito. É como criar seu próprio assistente virtual, pronto para agir em diferentes situações — seja para responder perguntas, executar processos ou automatizar tarefas do seu dia a dia. Agente vs. Chatbot tradicional: qual a diferença? 🤔 Essa é clássica! Enquanto os chatbots tradicionais costumam seguir roteiros engessados, os agentes do Copilot Studio vão muito além: Entendem o contexto da conversa (nada de respostas robóticas e fora de hora), Tomam decisões com base em regras ou dados em tempo real, Executam ações em sistemas externos (mandar e-mails, atualizar planilhas, integrar com APIs... você decide!), Sabem lidar com situações complexas, como exceções ou encaminhamentos automáticos. Resumindo? O agente não só conversa, ele age. Ele é capaz de pensar e agir sozinho dentro dos fluxos que você definir. Como eles funcionam na prática? ⚙️ O melhor de tudo é que você não precisa ser um programador hardcore para criar agentes no Copilot Studio. A ferramenta oferece uma interface visual e intuitiva — bem no estilo do Power Automate ou Power Apps — onde você monta seus agentes conectando blocos de lógica, definindo comportamentos e integrando com outras ferramentas e sistemas. Você decide o que o agente faz, quando faz, como responde e com quem interage. E claro, se você for desenvolvedor, dá pra ir além, adicionando customizações e integrações avançadas. Onde posso usar agentes? 🌍 As possibilidades são quase infinitas! Aqui vão alguns exemplos: Atendimento ao cliente automatizado (sem filas de espera), Suporte interno de TI (ajudando colaboradores 24/7), Guias interativos em sites e apps, Assistentes virtuais para eventos, RH, vendas, E qualquer outro cenário onde automação inteligente e respostas rápidas fazem diferença. Por que você deveria se importar com isso? 🚀 Simples: porque a era da IA chegou para o ambiente profissional. Saber usar agentes no Copilot Studio pode te colocar na frente — seja para otimizar processos no seu trabalho, criar soluções incríveis para empresas ou até tirar aquela ideia do papel sem precisar desenvolver tudo do zero. É IA no mundo real, trabalhando ao seu favor. Quer saber mais: Confira a documentação oficial do Copilot Studio:

Olá Pessoal! Manter o Windows 365 atualizado parece simples — e de fato é — mas não deveria ser totalmente automático. Atualizações mal controladas podem afetar produtividade, quebrar aplicações legadas ou causar reinícios inesperados bem no meio do expediente. A boa notícia é que o Windows Update for Business (WUfB), integrado ao Microsoft Intune, dá controle fino sobre como, quando e em que ritmo as atualizações chegam aos seus Cloud PCs. Neste artigo, vamos mostrar como usar o WUfB para criar políticas de atualização seguras, previsíveis e alinhadas à operação, sem precisar de WSUS ou infraestrutura local. O que é o Windows Update for Business (WUfB)? O Windows Update for Business permite gerenciar atualizações do Windows diretamente pelo Intune, usando políticas baseadas em nuvem. Adiar atualizações de qualidade (security e cumulative updates) Controlar atualizações de funcionalidade (feature updates) Definir janelas de manutenção Evitar reinícios inesperados Acompanhar o status real de atualização dos dispositivos E sim, funciona perfeitamente com os Cloud PCs do Windows 365. Por que usar WUfB no Windows 365? Porque, mesmo sendo um serviço gerenciado, o Windows 365 não elimina a responsabilidade operacional sobre: Estabilidade do ambiente Compatibilidade de aplicações Experiência do usuário O WUfB permite aplicar o mesmo rigor que você já usa em notebooks físicos, só que agora em desktops na nuvem. Como configurar o WUfB no Intune para Windows 365 Acesse o portal do Intune: 🔗 https://intune.microsoft.com Vá para: Dispositivos (Devices) > Windows > Anéis de atualização (Update rings) para Windows 10 e posterior (and later) Clique em + Criar perfil (+ Create profile) Etapas de configuração do perfil Nome da política: UpdateRing-W365-Prod ✓ Configurações recomendadas: Essas são algumas das melhores práticas: Servicing channel Semi-Annual Channel (Release Preview só se você souber exatamente por quê) Defer quality updates: 7 dias Defer feature updates: 30 dias Pause updates: Não (use apenas em incidentes críticos) Auto-restart before deadline: Não Active hours (horário ativo): Início: 08:00 Fim: 18:00 Restart checks: Enable Deadline for updates: 7 dias ✓✓Esse conjunto de configurações reduz riscos, dá tempo para testes e evita impactos durante o horário comercial. Atribuindo a política aos Cloud PCs Depois de criar o Update Ring: Vá até Assignments Selecione: Um grupo de usuários ou um grupo de dispositivos que represente seus Cloud PCs Salve a política Monitorando o status das atualizações Depois que a política está em produção, monitorar é obrigatório. Onde acompanhar No Intune, vá em: Relatórios (Reports) > Atualizações do Windows (Windows Updates). Aqui poderá ver: O estado (status) de cada atualização Dispositivos com falhas Pendências e tempo de aplicação Considere combinar esta monitorização com alertas automáticos para não ser apanhado desprevenido.

Olá Pessoal! Em muitos ambientes de Azure Virtual Desktop (AVD), o monitoramento ainda se resume ao básico: CPU, memória e disco das VMs. Esses números são importantes, claro — mas sozinhos não dizem quase nada sobre a experiência real do usuário. Já vimos inúmeros casos em que: CPU estava em 20% Memória sobrando Disco tranquilo …e mesmo assim o usuário reclamava que “o sistema está impraticável”. Em VDI, infraestrutura saudável não garante experiência boa. É, pode acreditar - é verdade! Se você quer fazer troubleshooting de verdade e operar AVD como um real especialista precisa mudar o foco: sair da visão de máquina e ir para a visão de sessão e experiência e se colocar no lugar do usuário final. É exatamente para isso que existe o Azure Virtual Desktop Insights, o painel oficial de observabilidade do AVD, baseado em Workbooks do Azure Monitor. Abaixo estão algumas métricas que utilizamos em produção. Aquelas que explicam o que o usuário sente na ponta. O que você realmente precisa monitorar no AVD 1. User Input Delay (Atraso de Entrada) Essa é, sem exagero, a métrica mais honesta do AVD. O Input Delay mede quanto tempo o sistema leva para responder a uma ação do usuário: Clique de mouse Digitação no teclado Interações na interface No AVD Insights, o contador Input Delay per Process envia dados a cada 30 segundos, registrando: O pior caso da janela A mediana O p%95 (p95) Se o usuário diz que “está tudo arrastado”, esse gráfico é o primeiro lugar onde você deve olhar. CPU baixa não significa nada se o input delay estiver alto. 2. Time to Connect (tempo e fases do logon) Saber que o usuário conseguiu logar é o mínimo. O que importa é quanto tempo isso levou e onde esse tempo foi gasto. O AVD Insights quebra o Time to Connect em duas grandes fases: Conexão: roteamento, gateway e rede Logon: autenticação e carregamento da sessão no host E é na fase de logon que mora o ouro. Ela é subdividida em quatro métricas críticas: Profile Tempo gasto carregando o perfil do usuário. FSLogix (Frxsvc) Quanto tempo o serviço do FSLogix levou para montar o VHD/VHDX. Perfis gigantes ou file shares lentos aparecem claramente aqui. GPOs Tempo de aplicação das Políticas de Grupo. Picos aqui normalmente indicam GPO demais, GPO pesada ou DC distante. Shell Start Tempo para iniciar o explorer.exe (a interface do Windows). Isso acaba com o mito do “logon lento misterioso”. O dado mostra exatamente onde está o gargalo. 3. Latência de rede (Round-Trip Time – RTT) O RTT mede o tempo de ida e volta entre o usuário final e a região do Azure onde o session host está rodando. Como regra prática: RTT abaixo de 150 ms → experiência aceitável Acima disso → o usuário começa a sentir atraso perceptível Monitorar RTT ajuda a responder rapidamente aquela pergunta clássica: “O problema está no Azure ou na internet do usuário?” Em muitos casos, o vilão é Wi‑Fi ruim, VPN instável ou rota internacional e não o host pool. Ai também vem um bom ponto relacionado a telemetria de dados! 4. Diagnóstico de falhas (origem e tipo de erro) Quando uma conexão falha, o AVD não deixa você no escuro desde que você saiba onde olhar... Os logs de diagnóstico indicam onde a falha ocorreu, classificando a origem (Source): Client – problema no cliente do usuário RDGateway – camada de tráfego de rede RDBroker – orquestração da sessão RDStack – agente instalado na VM Além disso, existe a flag ServiceError: ServiceError = TRUE → falha no backend gerenciado pela Microsoft ServiceError = FALSE → problema do seu lado (VM, rede, identidade, imagem) Essa simples distinção economiza horas de troubleshooting na camada errada. 5. Operações de Autoscale Se você usa Autoscale nativo do AVD (e deveria), precisa monitorar se ele está funcionando de verdade. No Log Analytics, a tabela WVDAutoscaleEvaluationPooled mostra: Tentativas de ligar/desligar VMs Logoffs forçados Decisões tomadas pelo mecanismo de escala O campo ScalingReasonMessage explica por que uma VM não foi ligada mesmo com pico de usuários e informações essenciais quando alguém reclama de falta de capacidade. Exemplo do Insights do Azure Virtual Desktop: Ir para Azure Portal > Azure Virtual Desktop > Monitoramento > Insights Tabela de monitoramento VDI Área Por que importa... Pergunta que responde... Input Delay Mede o “lag” real percebido pelo usuário “O ERP está lento ou é só impressão?” Time to Connect Expõe gargalos ocultos no logon “É FSLogix, GPO ou rede?” RTT Valida a saúde da conexão do usuário “É o host ou o Wi‑Fi da casa dele?” Origem do erro Direciona o troubleshooting corretamente “É problema da Microsoft ou meu?” Autoscale Evita falta de capacidade no horário de pico “Por que novas VMs não subiram?” Checklist final de telemetria Antes de confiar nos dados, valide: O AVD Insights usa um Log Analytics Workspace dedicado aos session hosts Contadores como User Input Delay, Terminal Services e RemoteFX Network estão habilitados Diagnostic Settings dos Host Pools e Workspaces estão coletando Connections, Errors, Checkpoints e Management O Azure Monitor Agent está instalado e enviando eventos corretamente

Olá Pessoal! Quem trabalha com arquitetura e infraestrutura sabe o quanto o Windows 365 facilita a vida. Provisionar um Cloud PC é rápido, simples e elegante. Mas essa facilidade tem um preço: se você não desenhar segurança desde o início, o ambiente nasce frágil e a consequencia pode vir logo em seguida... A gente ve com frequência ambientes onde “segurança” significa apenas ativar MFA. E sim, o MFA é obrigatório. Ele protege a porta de entrada. Mas e depois que o usuário entra? E se o dispositivo físico do usuário estiver comprometido? E se ele tentar copiar dados confidenciais do Cloud PC para um pen drive local? O MFA valida quem acessa, mas precisamos de uma arquitetura Zero Trust (Confiança Zero) para controlar de onde acessam e o que podem fazer. Uma arquitetura Zero Trust precisa controlar também de onde acessa e o que pode ser feito lá dentro. Para ajudar a evitar esses buracos desde o dia zero, montamos este checklist mínimo de segurança, pensado do ponto de vista de arquitetura em camadas, não de configuração isolada. Checklist de seguranca em cadas - visão para arquitetura Valide a postura do seu ambiente nestas seis camadas: Camada O que validar Por que isso é crítico Identidade MFA + Acesso Condicional baseado em risco. Menor privilégio sempre. Identidade virou o novo perímetro. Se a credencial vazar, o acesso condicional segura o estrago. Dispositivo Exigir conformidade via Intune antes da conexão. Usar Token Protection. Garante que o PC físico do usuário não esteja comprometido e reduz ataques de roubo de sessão. Endpoint (Cloud PC) Defender for Endpoint ativo. Validar VBS, HVCI e Credential Guard. Protege o SO contra malware e impede acesso a segredos do sistema. Rede / Acesso Usar Reverse Connect. Sem portas de entrada abertas. Restringir tráfego de saída com Firewall ou NSGs. O Windows 365 não precisa de inbound. Controlar outbound reduz comunicação com C2. Monitoramento Enviar logs de diagnóstico para um Log Analytics Workspace e monitorar pelo Defender for Cloud. Sem visibilidade, não existe segurança. Auditoria e postura contínua são obrigatórias. Governança Aplicar Microsoft Purview para Prevenção contra Perda de Dados (DLP), Customer Key (Criptografia) e auditoria forense. Evita a exfiltração de dados confidenciais e atende a requisitos pesados de compliance regulatório. 1 . Dar administrador local para o usuário Esse é clássico!!! Conceder admin local em Cloud PCs: Quebra o isolamento do sistema Permite instalar qualquer coisa Facilita bypass de controles de segurança Se o usuário precisa de admin local, isso deve ser: Justificado Temporário Auditável Admin local “porque sempre foi assim” é dívida técnica de segurança. 2. Deixar a porta RDP (3389) aberta O Windows 365 usa Reverse Connect. Isso significa que: A conexão sai de dentro para fora O tráfego ocorre sobre HTTPS Não há necessidade de porta RDP exposta Manter 3389 aberta: Não agrega valor Aumenta superfície de ataque A própria Microsoft já passou a fechar essa porta por padrão em novos Cloud PCs. Isso não é coincidência. 3. Não restringir redirecionamentos de dispositivos Clipboard, drive local, USB, impressora… Tudo isso pode virar canal de exfiltração de dados. Pergunta simples que quase ninguém faz: “O negócio realmente precisa disso?” Se não precisar: Bloqueie Ou limite por grupo Ou registre tudo via auditoria ✓Por padrão, novas instâncias já vêm mais restritivas - e isso é uma evolução, não um problema!!! Principais aprendizados (o que realmente importa) Segurança começa na imagem As imagens mais recentes do Windows 11 no Windows 365 já vêm com: Credential Guard VBS HVCI Se você usa imagem customizada, precisa garantir: Suporte a Trusted Launch VBS habilitado Nada de “otimização” quebrando isolamento Imagem mal feita compromete todo o ambiente. Em Windows 365, o foco é tráfego de saída Não existe inbound tradicional. Logo, o papel do arquiteto de rede muda: Menos preocupação com portas de entrada Mais foco em para onde o Cloud PC pode sair Azure Firewall, NSGs ou NVA bem configurados: Reduzem o raio de explosão Limitam comunicação com servidores maliciosos Ajudam muito na contenção de incidentes Defesa em profundidade não é opcional Uma única barreira sempre falha. Quando você combina: Conditional Access protegendo identidade Intune validando o dispositivo físico Defender for Endpoint protegendo o Cloud PC …você cria um ambiente onde: Se uma camada cair, as outras seguram o impacto. Isso é Zero Trust de verdade! Para Concluir Windows 365 é simples de usar e provisionar, mas não pode ser simples demais de proteger. Quem desenha segurança depois do go-live normalmente está correndo atrás do prejuízo. Se quiser, os próximos bons aprofundamentos seriam: Hardening específico para imagens customizadas Estratégias de DLP no Windows 365 Alertas práticos de Defender + Log Analytics

Olá Pessoal! Sabemos que fazer o deployment do Windows 365 é extremamente simples e intuitivo. É aquele tipo de serviço que, quando você olha a demo, parece simples demais pra dar problema. Tipo… clica aqui, atribui ali e pronto: Cloud PC funcionando! Só que, na prática… não é bem assim... A experiência do usuário é simples, mas a engrenagem por trás é cheia de detalhes. E se você é a pessoa que provisiona, normalmente é você quem vai apanhar quando alguma coisa sai fora do lugar. Então resolvemos juntar aquialguns erros que mais vemos na nossa jornada com o Windows 365, coisa de mundo real mesmo, e mostrar como evitar antes que o usuário venha com o famoso “não consigo acessar”. 1. Bloquear saída de rede e esquecer que a ANC existe Em empresas de grande escala, o padrão é bloquear tudo que sai. Totalmente normal! O problema é que a Azure Network Connection (ANC) depende de saída para vários endpoints da Microsoft para validar se o ambiente está saudável. E ela não negocia. O que acontece na prática? Se o firewall ou o proxy barrar os FQDNs exigidos, a ANC reprova no health check. Quando isso acontece, o Windows 365 simplesmente para de provisionar Cloud PC. Não tem meio-termo. Como evitar dor de cabeça? Antes de criar a ANC, alinhe com o time de redes e segurança a liberação dos endpoints exigidos pelo Windows 365 (como .windows.cloud.microsoft e .windows.static.microsoft), sem inspeção TLS. Isso não é ajuste fino. É pré-requisito. 2. Criar sub-rede pequena achando que “depois a gente vê” Se você usa Windows 365 com vNet própria (BYON via ANC), o tamanho da sub-rede é responsabilidade sua. E aqui rola um erro clássico: criar uma sub-rede /24 achando que “isso deve ser suficiente”. O que acontece na prática? A política tenta criar o Cloud PC, mas não tem mais IP disponível. Resultado: provisionamento falha sem muito aviso. Como evitar? Hoje o Intune já mostra a capacidade de IP da ANC. Vale muito a pena olhar isso antes de fazer rollout em massa. Regra simples: → Se existe chance de crescimento, crie a sub-rede já com folga. → IP sobrando não quebra projeto → IP faltando quebra. 3. Não entender a diferença entre “Pending” e “Not provisioned” Esse aqui confunde muita gente, inclusive quem já trabalha com o serviço há um tempo. Cloud PC não nasce só porque você atribuiu uma licença. Ele só é criado quando licença e provisioning policy se encontram. Quando isso não acontece, o portal mostra alguns status que geram dúvida. Na prática funciona assim: Not provisioned O usuário tem licença, mas não está no grupo do Entra ID vinculado à provisioning policy. Pending A policy foi aplicada, mas não existe licença disponível suficiente no tenant naquele momento. Como evitar? Consumo real de licenças Grupos do Entra ID (principalmente os dinâmicos) Se um desses falhar, o Cloud PC simplesmente não é provissionado. 4. Reaproveitar imagem de AVD e esquecer de limpar o agente Esse erro é mais comum do que parece, principalmente em ambientes que já usam Azure Virtual Desktop. A ideia geralmente é boa: “Já temos uma imagem customizada de AVD, vamos usar no Windows 365”. O problema começa quando essa imagem já tem o agente do AVD instalado. O que acontece na prática? O Cloud PC até é criado, mas não consegue se registrar corretamente em segundo plano. O token da imagem base já expirou. Resultado: o usuário não consegue conectar, e o troubleshooting vira uma dor de cabeça desnecessária. Como evitar? Golden image de Windows 365 precisa ser limpa: Nada de ingressar a VM em host pool Nada de instalar agente do AVD manualmente antes do sysprep O Windows 365 cuida da injeção do agente no momento do provisionamento. ✓ Confia no serviço. 5. Errar a matemática no Windows 365 Frontline O Windows 365 Frontline é excelente para cenários de turno, mas não perdoa erro de conta. Em modo dedicated: 1 licença Frontline permite até 3 Cloud PCs Apenas 1 sessão ativa por vez → O que acontece na prática? Se o grupo do Entra ID tiver mais usuários do que o limite (licenças × 3), os usuários “sobrando” simplesmente não recebem Cloud PC. Sem erro claro - apenas aquele genérico... Só não provisiona. Como evitar? A conta é direta: Quantidade de licenças Frontline × 3 = tamanho máximo do grupo ✓ Aqui não tem elasticidade. É matemática e gerenciamento!

Olá Pessoal! Se você trabalha com arquitetura de TI, endpoints ou digital workplace, provavelmente já caiu no dilema clássico da Microsoft: Windows 365 ou Azure Virtual Desktop (AVD)? Alias, já falamos sobre isso em outro post, mas é um conteúdo um pouco mais antigo e muita coisa aconteceu desde então... Os dois entregam Desktop como Serviço (DaaS). Os dois funcionam bem. Mas dai vem o famoso - pulo do gato! A engenharia por trás, o impacto no custo, na operação e no dia a dia do time de TI são bem diferentes. De forma simples: AVD é extremamente flexível, poderoso e escalável — mas cobra essa liberdade em complexidade. Windows 365 aposta na simplicidade: um “PC na nuvem”, com preço fixo e operação previsível. Para evitar decisões baseadas em "achismos" ou preferência pessoal, vamos usar essas 7 perguntas práticas. Se você responder essas perguntas com honestid, a arquitetura praticamente se decide sozinha. As 7 perguntas que podem definir o caminho 1 - Como você prefere lidar com custos? Essa é quase sempre a primeira trava. Windows 365 trabalha com preço fixo mensal por usuário. Você sabe exatamente quanto vai pagar no fim do mês. Sem surpresas. AVD segue o modelo pay‑as‑you‑go. Dá para gastar muito pouco — ou muito dinheiro — dependendo de como você desenha autoscale, horários e uso real. → Se previsibilidade financeira é prioridade absoluta, o W365 tende a ganhar. → Se você consegue otimizar desligando máquinas fora do horário comercial, o AVD pode ser bem mais barato. 2 - Sua equipe tem maturidade real para gerenciar o Microsoft Azure? Aqui mora uma verdade que muita gente ignora. AVD exige engenharia: Sizing, imagens, FSLogix, autoscale, storage, rede, monitoramento, segurança. Windows 365 é quase plug‑and‑play: O time gerencia os Cloud PCs como se fossem notebooks físicos, usando Intune. → Se você não tem (ou não quer depender de) “AVD Ninjas”, o W365 reduz muito o risco operacional. 3 - Você precisa de multi‑session? Essa pergunta é decisiva. AVD suporta Windows 10/11 Enterprise multi‑session, permitindo vários usuários na mesma VM. Windows 365 é, por natureza, 1:1 (usuário ↔ Cloud PC). O Frontline existe, mas não é multi‑session simultâneo. → Se o objetivo é reduzir custo por usuário compartilhando recursos, AVD é praticamente obrigatório. 3 - Quanto controle de infraestrutura você precisa? Pergunta simples, resposta nem tanto. No AVD, você controla: Tamanho de VM Tipo de disco IOPS Região (40+) Topologia de rede Integrações complexas No Windows 365, você escolhe entre SKUs pré‑definidas. Menos flexibilidade, menos decisões e menos erro. → Se você precisa de liberdade total, vá de AVD. → Se você quer evitar engenharia desnecessária, W365 resolve. 5 - Você precisa publicar só aplicativos (RemoteApp)? Isso elimina metade das dúvidas. AVD tem suporte nativo e maduro a RemoteApps. Windows 365 entrega o desktop inteiro (o app vem junto). Se o cenário é: ERP App legado Publicação seletiva → AVD é a escolha natural. 6 - Quem vai manter a infraestrutura no dia a dia? Essa pergunta separa arquitetura bonita de arquitetura sustentável. No Windows 365, a Microsoft cuida da infraestrutura base. No AVD, a responsabilidade é sua: Patches Atualizações Saúde das VMs Monitoramento Incidentes → Se sua equipe já está sobrecarregada, o W365 tira muito peso operacional. 7- Você tem trabalhadores em turno (frontline)? Aqui os dois resolvem, mas de formas diferentes. Windows 365 Frontline 1 licença → até 3 Cloud PCs não simultâneos Excelente para call centers, hospitais, chão de fábrica. AVD multi‑session Vários usuários simultâneos na mesma VM, com custo bem agressivo. → A decisão aqui costuma ser financeira + operacional, não técnica. Quando o Windows 365 costuma ser a melhor escolha O Windows 365 brilha quando vale a regra do “menos é mais”. É ideal quando: Custos previsíveis são prioridade A equipe já domina Intune Os usuários precisam de desktops dedicados Você quer evitar engenharia pesada de Azure → Funciona muito bem para: Trabalho remoto/híbrido Executivos Usuários administrativos Ambientes que valorizam simplicidade Quando o Azure Virtual Desktop costuma ganhar? O AVD é o campeão da flexibilidade. Ele faz mais sentido quando: Você precisa de multi‑session Quer publicar RemoteApps Tem horários de pico bem definidos Consegue usar autoscale de forma agressiva Já tem expertise em Azure É comum em: Ambientes grandes Cenários legados TI mais madura em nuvem Quando usar os dois juntos (e isso é mais comum do que parece) Em empresas maiores, não existe obrigação de escolher só um. Arquiteturas híbridas são extremamente comuns: Windows 365 Para usuários padrão, executivos e quem precisa de simplicidade. AVD Para desenvolvedores, RemoteApps, workloads pesados ou multi‑session. Essa combinação costuma equilibrar: Custo Complexidade Experiência do usuário Esforço operacional Análise de decisão Critério Windows 365 Azure Virtual Desktop Modelo de preço Fixo mensal Pay‑as‑you‑go Complexidade Baixa Alta Multi‑session Não (Frontline ≠ simultâneo) Sim Infraestrutura Gerenciada pela Microsoft Gerenciada pelo cliente Melhor para Simplicidade e previsibilidade Flexibilidade e escala Checklist final antes de decidir Precisamos de custo fixo ou aceitamos variação mensal? Temos expertise interna para sustentar AVD no longo prazo? Usuários precisam de desktop inteiro ou só apps? Temos trabalhadores em turno? Queremos reduzir esforço operacional ou maximizar otimização de custo?

Olá Pessoal! A grande promessa do Windows 365 é entregar uma experiência fluida e familiar, idêntica à de um PC físico. Historicamente, isso incluía permitir que o usuário conectasse pendrives, usasse a impressora de casa e copiasse textos entre o computador físico e o Cloud PC. Isso inclui algo que os usuários valorizam bastante: acesso a dispositivos locais, como impressoras, pendrives, microfone, câmera e até o clássico copiar/colar entre a máquina local e o Cloud PC. Mas aqui entra o ponto crítico: → nem tudo deve ser liberado! Dependendo do nível de segurança do ambiente, permitir redirecionamento de dispositivos pode significar: risco de exfiltração de dados, quebra de compliance, ou até entrada de malware via USB. Além disso, do ponto de vista de arquitetura de segurança e Zero Trust, abrir esses canais sem critério é o caminho mais rápido para a exfiltração de dados corporativos ou injeção de malware. Neste post, vamos revisar como o gerenciamento desses redirecionamentos evoluiu e como você deve projetar essa camada para equilibrar produtividade e segurança. O Novo Padrão: "Secure by Default" Se você está provisionando Cloud PCs hoje, saiba que a Microsoft mudou as regras do jogo. Para se alinhar aos princípios do Secure Future Initiative (SFI), os redirecionamentos de área de transferência (clipboard), drives locais, impressoras e USBs de baixo nível (opaque USB) agora vêm desabilitados por padrão em Cloud PCs recém-provisionados ou reprovisionados. O objetivo é simples: minimizar o risco desde o dia zero. Se o seu usuário precisar desses recursos, você, como administrador, terá que habilitá-los conscientemente. O que pode (e o que não pode) ser redirecionado Redirecionamento vs. Alternativas Antes de simplesmente criar uma política no Intune permitindo tudo, avalie se você não pode usar as soluções em nuvem que eliminam a necessidade de tráfego de redirecionamento via RDP. Recurso Solicitado O Risco do Redirecionamento RDP Alternativa Recomendada Drives Locais (C:, D:) Permite cópia de dados confidenciais para fora da empresa ou entrada de arquivos maliciosos. Bloquear o redirecionamento de drive e usar o OneDrive for Business para a transferência segura e auditada de arquivos. Área de Transferência (Clipboard) Copiar CPFs ou cartões de crédito do ERP na nuvem para o bloco de notas do PC pessoal. Habilitar o Clipboard Unidirecional (ex: permitir colar para dentro do Cloud PC, mas bloquear a cópia para fora) e restringir tipos de dados. Impressoras Locais Impressão de dados sigilosos em ambientes não controlados (home office). Bloquear o redirecionamento RDP e publicar impressoras gerenciadas via Universal Print. Dispositivos USB Perda de controle sobre dispositivos de armazenamento em massa conectados. A maioria dos periféricos comuns (mouse, teclado, webcams) não exige redirecionamento USB de baixo nível (opaque USB) para funcionar perfeitamente. Mantenha bloqueado. Onde controlar o redirecionamento de dispositivos? No Windows 365, você pode controlar isso em três níveis diferentes: Pelo cliente do Windows 365 (lado do usuário) Centralmente via Microsoft Intune Via GPO, em ambientes híbridos ou legados Intune MAM (Mobile Application Management) para BYOD E se o usuário estiver acessando o Cloud PC do seu iPad pessoal ou notebook particular? Agora você pode usar políticas de proteção de aplicativos (MAM) do Intune. O MAM permite verificar a postura de segurança do dispositivo local e desabilitar o redirecionamento de drives, impressoras e clipboard quando o usuário acessa o serviço pelo Windows App no iOS, Android, macOS ou até mesmo pelo navegador Edge em dispositivos Windows pessoais. É o controle ideal para cenários onde você não gerencia o hardware. 1. Configurações no cliente do Windows 365 (lado do usuário) Se o usuário acessa o Cloud PC pelo Remote Desktop Client (MSRDC): Caminho Abrir o aplicativo do Windows 365 Clicar com o botão direito no Cloud PC Selecionar Configurações Ir em Dispositivos e recursos Ali o usuário pode ativar ou desativar: Áudio Clipboard Drives locais Impressoras USB 2. Controlando redirecionamento via Microsoft Intune (recomendado) Esse é o método mais moderno e recomendado para Windows 365. a) Acessar o Intune → https://endpoint.microsoft.com b) Criar um perfil de configuração Devices → Configuration profiles → + Create profile Platform: Windows 10 and later Profile type: Settings catalog c) Procurar por: Device and Resource Redirection → Exemplos de políticas comuns Do not allow clipboard redirection → Enabled Do not allow drive redirection → Enabled Do not allow printer redirection → Enabled Do not allow COM port redirection → Enabled 3. Usando GPO (ambientes híbridos ou legados) Se o seu Windows 365 usa Hybrid Join com Active Directory local, você também pode usar GPO. Caminho da política Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Device and Resource Redirection → As opções são praticamente as mesmas do Intune. Monitoramento e auditoria Se você libera redirecionamento, monitorar é obrigatório. Algumas opções práticas: Microsoft Defender for Endpoint Registro de uso de periféricos Alertas de comportamento suspeito Logs de eventos do RDP Identificar sessões com redirecionamento ativo Conditional Access Bloquear acesso a Cloud PCs dependendo do tipo de dispositivo do usuário ✓ Isso fecha o ciclo entre experiência, segurança e governança. » Checklist de Arquitetura de Redirecionamento « Antes de liberar o acesso aos seus usuários, valide sua configuração: Os redirecionamentos de drive e USB de baixo nível estão bloqueados, incentivando o uso do OneDrive? A política de área de transferência (clipboard) está configurada como unidirecional para evitar exfiltração de dados (Data Loss)? Foram criadas políticas de MAM no Intune para bloquear redirecionamentos caso o usuário acesse o Cloud PC via Windows App em um dispositivo pessoal não gerenciado? O Microsoft Purview Data Loss Prevention (DLP) foi ativado no endpoint virtualizado para garantir uma camada extra de proteção sobre o dado? Links úteis Redirecionamento de dispositivos no Remote Desktop Configurações de segurança no Windows 365 Windows 365 – configurações do cliente Principais aprendizados (Key Takeaways) Segurança por padrão exige intenção: Como o Windows 365 agora bloqueia recursos locais em novas máquinas, a TI deixa de ser reativa e passa a habilitar o acesso apenas para grupos de usuários que tenham uma justificativa de negócio clara. Controle o app, não apenas a máquina: Com a evolução do Windows App e a integração com o Intune MAM, você pode garantir que dados não vazem para um disco rígido ou impressora local, mesmo quando o usuário acessa o Cloud PC do computador de casa. O Clipboard Unidirecional é um divisor de águas: A capacidade de permitir que o usuário traga dados de fora para dentro do Cloud PC, mas seja impedido de levar dados corporativos de dentro para fora, entrega o equilíbrio perfeito entre usabilidade e governança de dados. O redirecionamento de dispositivos no Windows 365 entrega muita praticidade — mas precisa ser usado com consciência. Com Intune ou GPO, você define exatamente: o que o usuário pode redirecionar, quando, e em que contexto. » A regra é simples e continua válida: Dê liberdade onde faz sentido. Controle onde o risco começa.

Um guia prático, direto e sem cliques desnecessários Criar e gerenciar Cloud PCs manualmente funciona no começo. Mas quando o Windows 365 começa a escalar - mais usuários, mais ambientes, mais cobrança por eficiência fica claro que clicar no portal não é estratégia. É aqui que entram PowerShell e Microsoft Graph API. Com eles, você consegue: listar Cloud PCs, monitorar provisionamento, restaurar máquinas, gerar relatórios, integrar com runbooks e automações, e transformar tarefas operacionais em código repetível. Neste artigo, vamos mostrar como preparar o ambiente e como automatizar tarefas reais do Windows 365, com exemplos práticos e foco em escala. O que dá para automatizar no Windows 365? Antes de entrar em código, vale alinhar expectativas. Hoje, com Graph + PowerShell, você consegue automatizar principalmente operações de gestão, não o clique inicial no Intune. Exemplos reais: Listar todos os Cloud PCs ativos Obter status de provisionamento Reiniciar ou reprovisionar Cloud PCs Restaurar Cloud PCs para um estado anterior Gerar relatórios de uso, falhas e planos Integrar ações com: Azure Automation Power Automate Logic Apps Runbooks agendados PowerShell e Microsoft Graph: quem faz o quê? PowerShell É a sua ferramenta de automação: executa comandos, orquestra fluxos, integra com outros serviços, roda localmente ou em automação. Microsoft Graph API É a porta de entrada para os dados e ações da Microsoft Cloud: usuários, grupos, dispositivos, Windows 365 (Cloud PCs). O PowerShell apenas consome a Graph. Quem manda é a API. Pré-requisitos (sem isso nada funciona) Antes de escrever qualquer script, você precisa de três coisas: Acesso ao Microsoft Entra ID Permissões administrativas para Windows 365 Módulo Microsoft.Graph instalado Instalando o módulo Microsoft.Graph Registrando um aplicativo no Entra ID (passo obrigatório) Para automação de verdade (scripts, runbooks, tarefas agendadas), não use login interativo. Use um App Registration. Passo a passo: Acesse: https://entra.microsoft.com Vá em: Applications → App registrations → New registration Configure: Name: W365-Automation-App Supported account types: Single tenant Redirect URI: pode deixar em branco Após criar, anote: Application (Client) ID Directory (Tenant) ID Criar Client Secret Vá em Certificates & secrets Crie um Client Secret Guarde o valor (não aparece novamente) Permissões necessárias na Graph API Em API permissions, adicione: Depois disso: → Conceda consentimento de administrador Sem esse passo, nada funciona. Conectando no Microsoft Graph via PowerShell Com App Registration (modelo ideal para automação): ✓ Esse método é o mais seguro e o mais usado em automação corporativa. Exemplo 1 – Listar todos os Cloud PCs Use isso para: inventário, validação de ambiente, relatórios iniciais Exemplo 2 – Obter status e detalhes dos Cloud PCs Ótimo para: troubleshooting, dashboards, validação pós-provisionamento. Exemplo 3 – Restaurar (reprovisionar) um Cloud PC Esse comando: remove o estado atual, reaplica a política, entrega um Cloud PC “limpo”. Use com cuidado - isso pode impactar o usuário. Exemplo 4 – Gerar relatório e exportar para CSV Perfeito para: auditoria, gestão, acompanhamento executivo. E desligar Cloud PCs fora do horário? Aqui entra arquitetura, não só comando. Hoje, o Windows 365 não tem “power off” direto como VM do Azure. Mas você pode: acionar reprovisionamento, aplicar scripts via Intune, integrar com: Azure Automation Logic Apps Power Automate horários e eventos Links úteis Referência da API Graph para Windows 365 Microsoft Graph Explorer Documentação do módulo Microsoft.Graph Conclusão Automatizar o Windows 365 com PowerShell e Microsoft Graph não é um "capricho" - é escala, controle e maturidade operacional. Seja para monitorar, restaurar, reportar ou integrar com pipelines, o código vira seu melhor aliado. Em ambientes de grande escala, automação não é opcional. É arquitetura e sobrevivência!

Olá Pessoal! Se tem uma coisa que sempre tirou o sono de arquitetos, engenheiros de infraestrutura e segurança foi a bendita porta 3389 exposta para a internet.😒 Durante anos, esse foi um mal necessário em ambientes de virtualização de desktops e também uma das maiores superfícies de ataque. A boa notícia é que, com Azure Virtual Desktop (AVD) e Windows 365, esse modelo ficou para trás...espero que já saibam! 😊 O jogo mudou completamente por causa de um conceito fundamental (e ainda mal compreendido): o Reverse Connect (Conexão Reversa). Mesmo assim, ainda vejo muita gente tentando: Criar NAT Abrir inbound no firewall Liberar RDP “só para teste” - Sim, existe mesmo!!! Tudo isso vai contra o desenho do serviço. Neste post, vamos explicar como o Reverse Connect funciona de verdade, na prática, e por que ele muda completamente a forma como você deve pensar na rede e segurança em seus ambientes. Antigamente ou historicamente, lá dos tempos de RDS eles funcionavam assim: A VM ficava parada, com uma porta aberta, esperando alguém da "internet bater". ✌️ Isso exigia: Portas inbound abertas Regras de firewall expostas Muito cuidado (e mesmo assim, risco) No AVD e no Windows 365, esse modelo simplesmente não existe mais. SIM, NÃO existe mais! Com Reverse Connect, nenhuma porta de entrada precisa ser aberta para o usuário se conectar. Não há listener TCP aguardando conexões externas na VM. A conexão nasce dentro do ambiente e vai em direção à nuvem da Microsoft. → Como isso funciona na prática O Reverse Connect estabelece duas conexões de saída, independentes e seguras: Do dispositivo do usuário → Gateway do serviço Do session host ou Cloud PC → Gateway do serviço Essas duas pontas nunca se conectam diretamente entre si. O Gateway gerenciado pela Microsoft atua como intermediário, “costurando” as sessões de forma segura. Se sua VM consegue sair para a internet (ou para os endpoints da Microsoft), ela consegue receber conexões. O impacto real na arquitetura de segurança Esse modelo muda completamente o desenho de rede e segurança e e para melhor. Superfície de ataque drasticamente menor Sem portas de entrada abertas: Não existe força bruta em RDP Não existe scanner encontrando desktops expostos Não existe “acesso direto” ao host (Tinha muito disso)!!! A VM simplesmente não está ouvindo ninguém. Adeus, porta 3389 👋 A recomendação arquitetural é clara: Não abra 3389. Nunca. Exemplo de Porta 2289 aberta outbound e inbound - Alto risco! Mesmo em ambientes AVD, ainda é comum encontrar NSGs com RDP e HTTPS abertos para a internet. Essas regras não são apenas desnecessárias, mas também elas vão contra o modelo de Reverse Connect e aumentam a superfície de ataque sem nenhum ganho funcional. Todo o acesso de usuário deve acontecer via: AVD Windows 365 Reverse Connect ✓A própria Microsoft já passou a bloquear 3389 por padrão em novos Cloud PCs e e isso não é detalhe, é direção de produto. Tráfego criptografado por padrão Como tudo roda sobre HTTPS: O tráfego já é criptografado de ponta a ponta Não há necessidade de proxy com inspeção TLS Inspeção, além de desnecessária, degrada a experiência Se você tentar “quebrar” esse tráfego no meio, o efeito colateral normalmente é: Input Delay alto Latência perceptível Usuário reclamando de lentidão Principais aprendizados Pense de dentro para fora... No AVD e no Windows 365: O firewall não é para proteger entrada Ele serve para controlar saída Seu trabalho como arquiteto e engenheiro é: Permitir outbound apenas para os endpoints necessários Bloquear destinos desnecessários Reduzir o raio de explosão em caso de incidente Troubleshooting não justifica abrir RDP Se você precisar acessar um host para manutenção ou diagnóstico: Vamos abrir a porta 3389? Não, não...use: Azure Bastion Just-in-Time (JIT) Acesso administrativo via rede privada Abrir RDP “temporariamente” quase nunca é temporário, sabemos disso! Dá para ir além com Private Link Para ambientes mais exigentes, o Reverse Connect ainda pode: Trafegar exclusivamente pela rede privada da Microsoft Usar Azure Private Link Eliminar até a dependência da internet pública Isso é comum em: Ambientes regulados Setores financeiros Órgãos governamentais Se você entende que: A conexão nasce no session host e vai para a nuvem …você evita praticamente todos os erros clássicos de rede em AVD e Windows 365. Reverse Connect não pode ser considerado um detalhe técnico, mas sim um pilar de segurança e arquitetura.ão de rede em seus projetos.

Manter uma boa performance no Azure Virtual Desktop é essencial para garantir a experiência do usuário e a eficiência operacional. Um ambiente lento ou instável pode impactar diretamente a produtividade. Veja a seguir as principais práticas recomendadas para otimizar o desempenho do seu ambiente AVD.   Escolha o tamanho ideal das máquinas virtuais   Nem sempre a maior VM oferece o melhor custo-benefício. Avalie a carga de trabalho dos usuários e escolha tamanhos de VM que equilibrem desempenho e custo.   Usuários leves : Standard B2s ou D2as v4   Usuários médios : D4s v3 ou superiores   Usuários pesados : Séries E ou F para tarefas gráficas ou processamento intensivo   Use FSLogix para perfis de usuário   O FSLogix é a tecnologia recomendada pela Microsoft para gerenciamento de perfis no AVD. Ele cria um contêiner de perfil que carrega rapidamente ao iniciar a sessão, reduzindo o tempo de login e evitando problemas de sincronização.   Habilite balanceamento de carga   Distribuir os usuários de forma equilibrada entre as VMs evita sobrecarga em um único host.   Configure a política de balanceamento nos pools de host   Use depth-first (preenche uma VM por vez) ou breadth-first (distribui uniformemente)   Monitoramento e diagnóstico   Use o Azure Monitor e o Log Analytics para acompanhar métricas importantes como:   Tempo de login   Uso de CPU e memória   Latência de rede   Erros de conexão

Uma das atualizações mais práticas no Azure Virtual Desktop é o recurso de escalonamento automático (autoscale) nativo. Agora, é possível configurar a expansão e redução de VMs com base na demanda real, sem precisar de scripts personalizados ou automações complexas.   Como funciona o autoscale no AVD?   Com o autoscale, o Azure pode:   Ativar novas VMs automaticamente quando o número de sessões ativas atingir um limite definido   Desligar VMs inativas fora do horário comercial   Definir limites mínimos e máximos para cada pool de hosts   Respeitar políticas de uso e horários configuráveis   Vantagens   Economia direta : evita deixar máquinas ligadas sem uso   Experiência contínua : novas sessões são distribuídas sem impacto para o usuário   Menos esforço de gestão : tudo configurável via portal, sem scripts PowerShell ou Azure Automation.   Como configurar   Acesse o pool de hosts no portal do Azure   Vá em Escalonamento automático   Ative o recurso e defina os parâmetros:   Horário de pico   Número mínimo/máximo de VMs   Tempo de inatividade antes de desliga

O Azure Virtual Desktop oferece grande flexibilidade, mas sem controle, os custos podem crescer rapidamente. Felizmente, a plataforma oferece diversas formas de otimizar os gastos sem comprometer a qualidade do serviço.   Use escalonamento automático   Configure políticas de escalonamento automático para desligar ou reduzir o número de VMs durante horários de baixa demanda.   Ideal para empresas com turnos definidos ou horários comerciais fixos   Pode ser feito com scripts do Azure Automation ou ferramentas de terceiros   Aproveite licenças existentes   Se sua organização já usa Microsoft 365 E3/E5, você pode economizar aproveitando a licença de Windows 10/11 Enterprise incluída nesses planos.   Isso reduz os custos por usuário em comparação com modelos tradicionais de VDI   Use instâncias reservadas   Para cargas de trabalho previsíveis, opte por instâncias reservadas de máquinas virtuais.   Contratos de 1 ou 3 anos com descontos de até 72% em relação à tarifa sob demanda   Acompanhe gastos com Azure Cost Management   Monitore o consumo com o Azure Cost Management + Billing , definindo alertas e orçamentos mensais.   Identifique quais recursos estão gerando mais custo   Ajuste conforme necessário para manter o controle