Windows Autopatch: Actualizações Automáticas com Intune

O Windows Autopatch é um serviço cloud que automatiza as actualizações de Windows, Microsoft 365 Apps, Edge e Teams em frotas geridas. Em vez de o sysadmin desenhar anéis de deployment e decidir semanalmente o que aprovar, o serviço gere o ciclo — com anéis sequenciais, pausas automáticas por sinais de fiabilidade e relatórios no Intune. Este artigo cobre requisitos de licenciamento, o que fica sob gestão do serviço, o que mantém em causa própria e como integrar num ambiente PME que já usa Intune.

O que o serviço faz (e o que não faz)

Conforme a documentação oficial, o Windows Autopatch gere estas cargas de trabalho em dispositivos registados:

  • Windows quality updates — actualizações cumulativas mensais, com objectivo de serviço de pelo menos 95% dos dispositivos actualizados. Instala-se sem restart com hotpatching, onde disponível.
  • Windows feature updates — rollout anual controlado, com políticas multi-fase por grupos Autopatch.
  • Driver e firmware updates — automáticos ou self-managed, com aprovação por tenant ou por grupo.
  • Microsoft 365 Apps — canal Monthly Enterprise Channel com objectivo de 90% dos dispositivos elegíveis.
  • Microsoft Edge e Teams — rollouts progressivos no canal Stable.

Não faz: updates de software de terceiros (antivírus, 7-Zip, Adobe), SQL/Exchange, nem gestão de servers — é um serviço de endpoints Windows modernos (Windows 10/11 e Enterprise multi-session). Fica no tenant o controlo fino: pausar um anel, excluir um grupo, expedir um update crítico via políticas de expedite.

O modelo de anéis e o rollback automático

O serviço distribui cada release em anéis de deployment sequenciais. Um release entra no primeiro anel, os sinais de fiabilidade (crashes, falhas de instalação, compatibilidade) são monitorizados e — quando aparecem problemas — o release pausa automaticamente antes de chegar aos anéis seguintes. O admin recebe a comunicação do estado e decide: pausar manualmente, ignorar, ou deixar o serviço prosseguir.

Para PME, a implicação prática: o “sábado negro” de update que parte aplicações fica mitigado por design — uma regressão detectada no anel 1 não chega aos 90% da frota. O preço é menos controlo fino sobre timing (o serviço decide quando cada anel recebe o update), com pausas manuais disponíveis.

Nota: os grupos Autopatch são o mecanismo central — cada grupo junta Microsoft Entra groups + políticas de update rings + feature updates. Por omissão, cada Autopatch group cria automaticamente dois anéis de deployment fixos — Test e Last (ambos só aceitam atribuição manual de grupos Entra). Os anéis intermédios (Ring 1, Ring 2, …, até um máximo de 15 por grupo) são adicionados livremente pelo admin e distribuem dispositivos por percentagem — a distribuição dinâmica por percentagem é o mecanismo de progressão entre anéis.

Requisitos e licenciamento

Em Abril de 2025 o serviço mudou de modelo: feature activation foi removida e as features ficaram disponíveis para Business Premium e A3+ — antes exigia Enterprise E3+/F3. Requisitos actuais:

  • Licenciamento: Microsoft 365 E3/E5/F3, ou Business Premium (as features base). E3+/F3 acrescenta suporte com a Service Engineering Team. Uma licença por utilizador cobre até 10 dispositivos.
  • Entra ID: dispositivos Entra-joined ou híbridos.
  • Intune: gestão de dispositivos por Intune (o Intune admin center é a consola do Autopatch).
  • Windows: Windows 10/11 Pro+/Enterprise nas builds suportadas. Windows 11 Enterprise multi-session para AVD.
  • Canal de updates: dispositivos devem receber updates do Windows Update (sem bloqueio a WUfB).

O onboarding é reversível: os dispositivos podem sair do serviço e retornar à gestão manual de updates sem reinstalação — o Autopatch apenas gere políticas, não instala agentes extra.

O que muda vs WSUS tradicional

Aspecto WSUS Windows Autopatch
Infraestrutura Servidor on-premise + consola Cloud service, sem infra
Aprovações Manual (KB a KB) Automática por anéis
Rollback Manual (uninstall + verificação) Pausa automática por sinais de fiabilidade
Microsoft 365 Apps Não cobre (por omissão) Cobre (MEC 90% target)
Edge/Teams Não cobre Cobre
Drivers Manual (importação WUfB) Gestão incluída
Relatórios Consola WSUS básica Intune reports (compliance, uptime, falhas)
Windows Server Cobre Não cobre

A leitura prática para PME: se a frota já é Entra-joined com Intune, o WSUS deixa de ter razão de ser para os endpoints — o Autopatch cobre o ciclo com menos trabalho. Se ainda há servers no WSUS (Server 2016/2019/2022), esse segmento mantém o WSUS ou migra para Azure Arc + Update Management.

Onboarding passo a passo

  1. Intune admin center → Tenant administration → Windows Autopatch — o serviço aparece no menu de tenant.
  2. Enrollment: aceitar os pré-requisitos e inscrever o tenant (o serviço valida licenciamento, Intune e Entra automaticamente).
  3. Device readiness: usar o Device readiness report para ver que dispositivos cumprem os requisitos — dispositivos fora (SO antigo, sem licença, híbrido mal registado) ficam visíveis com a razão.
  4. Grupos: rever a estrutura de grupos Autopatch por omissão e atribuir os Entra groups da organização (Test = estações de TI, Broad = resto da frota).
  5. Políticas: rever update rings por omissão (deferral days) e ajustar a janela de manutenção — as políticas podem ser editadas ou substituídas por políticas próprias.
  6. Comunicação: activar as notificações do Message Center — o serviço comunica cada release e pausa por lá.

O rollout inicial demora dias a estabilizar. Os primeiros ciclos servem para validar as atribuições de grupos. Recomendação: começar com o anel Test pequeno e real — estações de TI com as apps críticas da organização, não máquinas virgens.

Monitorização e operação mensal

O dia-a-dia pós-onboarding é leve, mas não nulo:

  • Reports no Intune admin center: Windows quality update compliance, feature update status, M365 Apps versions, falhas de instalação por anel.
  • Pauses: rever pausas automáticas na página do release — decidir se a pausa continua ou se o release avança.
  • Expedite: para vulnerabilidades críticas (ex.: zero-day com patch de emergência), usar as políticas de expedite do Windows quality updates — não esperar o anel seguinte.
  • Message Center: o canal oficial de comunicações do serviço (mudanças de calendário, incidentes).

Integração com a stack PME típica

Num ambiente PME realista (Entra + Intune + alguns servers on-premise), a arquitetura recomendada:

  • Endpoints Windows: Windows Autopatch gere quality/feature/driver/M365/Edge/Teams.
  • Servers: WSUS ou Azure Arc + Update Manager — o Autopatch não cobre.
  • Software de terceiros nos endpoints: winget + Intune Win32 apps, ou RMM de terceiros — coordenar janelas com o Autopatch para evitar reboots em conflito.
  • AVD/multi-session: Enterprise multi-session é suportado — as VMs do AVD entram nos anéis como endpoints normais.
  • Compliance: as políticas de update rings do Autopatch contam para as policies de compliance do Intune — alinhar os targets de compliance com os anéis.

Erros comuns

Problema Causa Solução
Dispositivos não entram nos anéis Sem licença elegível ou não Entra-joined Verificar o Device readiness report; corrigir join/licença
Update nunca chega ao anel Broad Pausa automática activa no release anterior Rever a página do release; resolver ou avançar manualmente
Reboots em horário de trabalho Janela de manutenção por omissão Definir active hours e janelas de manutenção nas políticas de anel
M365 Apps em canal errado Canal forçado por política anterior Remover a política antiga de update channel; deixar o Autopatch gerir
Conflito com GPO de updates herdada Políticas WSUS/deferral ainda activas Migrar para MDM security baseline; limpar GPOs de updates
Expedite não aplica Política de expedite mal atribuída Atribuir a política ao grupo Autopatch correcto; validar no report

Checklist rápido

  • ✓ Licenciamento verificado (Business Premium/E3+/F3+ conforme features desejadas)
  • ✓ Device readiness report revisto — sem dispositivos fora por razões corrigíveis
  • ✓ Grupos Autopatch mapeados aos Entra groups reais (Test com estações de TI reais)
  • ✓ Janelas de manutenção e active hours definidas nas políticas de anel
  • ✓ Message Center monitorizado (canal oficial de comunicações)
  • ✓ Políticas de update antigas (GPO/WSUS deferral) removidas dos endpoints
  • ✓ Plano de expedite definido para zero-days
  • ✓ Reports revistos no primeiro ciclo pós-onboarding

Como evitar no futuro

  • Revisão mensal dos reports de compliance por anel — deriva de versões é o primeiro sinal de dispositivo abandonado.
  • Manter o anel Test fiel: estações com as apps críticas reais, sempre a receber releases primeiro.
  • Subscrever o feed do Message Center para o tenant — mudanças do serviço chegam lá primeiro.
  • Revisão trimestral dos grupos: movimentos de departamentos alteram o perfil de risco dos anéis.
  • Coordenar as janelas de manutenção do Autopatch com as do software de terceiros — reboots em conflito são o problema operacional mais comum.

Artigos Relacionados