Uma terça-feira de patches, o anúncio de uma nova versão do Windows 11 e o WSUS deprecado a ocupar um servidor que já ninguém quer manter. O Windows Update for Business — o nome oficial actual é Windows Update client policies, e a sub-pasta do GPO mantém o nome antigo — resolve exactamente este nó: os equipamentos vão buscar as actualizações directamente ao serviço do Windows Update e a segmentação por grupos passa a ser feita localmente, com deferrals e pausas, em vez de aprovações num servidor.

Duas decisões sustentam tudo o resto: a divisão da frota em três anéis (teste, trabalho e crítico) e os valores de deferral de cada anel. Depois há mecanismos pontuais — o TargetReleaseVersion para travar a versão em uso, a pausa de 35 dias para travar o lançamento quando a actualização falha, e os update rings do Intune para quem já gere a frota por MDM. A escolha entre GPO puro e update rings depende só do que já pagas.

💡 TL;DR

Cria três anéis e atribui a cada um deferrals: quality 0 / 7 / 14 dias e feature 30 / 60 / 90 dias. As duas políticas de GPO fazem isso — Select when Preview Builds and feature updates are received e Select when Quality Updates are received — e o Intune replica-as com update rings. Trava a versão com TargetReleaseVersion quando a aplicação de facturação ainda não validou a nova versão do Windows 11, e pausa (35 dias, expira sozinha) só quando o anel de teste acusa uma regressão real.

1. Do WSUS às políticas do cliente Windows Update

O Windows Server Update Services foi deprecado — o servidor continua a servir actualizações, mas já não recebe evolução — e a rota de migração passa por deixar os clientes a falar directamente com o serviço do Windows Update. O que o WSUS dava na prática — aprovação KB a KB e segmentação por grupos — reparte-se em dois planos: a segmentação passa a viver nas políticas do cliente e a aprovação fina, quando é realmente indispensável, continua como trabalho do Configuration Manager.

As políticas do cliente são um serviço gratuito incluído nas edições Pro (e Pro for Workstations), Education e Enterprise — Enterprise LTSC e IoT Enterprise incluídos. Uma frota com equipamentos Home comprados a retalho fica fora destas políticas, e é um motivo real para normalizar as compras de portáteis e máquinas no Pro.

As políticas controlam quatro tipos de oferta: feature updates (a versão anual do Windows 11), quality updates — o acumulativo mensal, publicado tipicamente na segunda terça-feira do mês —, drivers (activos por omissão) e actualizações de outros produtos Microsoft (desligadas por omissão — activa-as na política Configure Automatic Updates com a opção Install updates for other Microsoft products). Três limites fixam o que podes desenhar: deferral de feature até 365 dias, deferral de quality até 30 dias e pausa até 35 dias a partir da data de início que definires.

A data de oferta conta sempre a partir do lançamento no Windows Update — data de oferta = data de lançamento + deferral — e não da tua terça-feira. Uma deferral de 7 dias empurra qualquer patch 7 dias corridos depois de a Microsoft o publicar no serviço, o que dá um calendário de lançamento estável sem ajustes manuais mês a mês.

2. Desenhar os anéis antes de tocar nas políticas

Um anel é um grupo de equipamentos que recebe o patch com o mesmo atraso convencionado. O mínimo funcional são três anéis: testadores antecipados, lançamento alargado e equipamentos críticos em releases maduras. Numa PME traduz-se numa atribuição concreta:

  • Anel Teste — as máquinas do sysadmin e uma máquina por perfil de software (uma com o cliente do ERP, um portátil de campo, uma com a impressora antiga). Nunca o PC da facturação.
  • Anel Trabalho — a maioria dos máquinas: e-mail, Office, navegador e aplicações de linha.
  • Anel Crítico — o PC do contabilista, o posto da recepção que corre o terminal do ERP, a máquina do balcão que não pode parar no fim do mês.
Anel Quem entra Decisão a tomar
Teste Máquinas do sysadmin e uma por perfil de aplicação Recebe quality no dia do lançamento (deferral 0) — é aqui que se decide pausar ou avançar
Trabalho Postos comuns — Office, e-mail, aplicações de linha Deferral curto de 7 dias, uma terça-feira de separação do Teste
Crítico Facturação, ERP, terminais que não podem parar no fim do mês Deferral de 14 dias e pausa imediata de quality se o Trabalho acusar sintomas

A segmentação vive nos grupos, não nas políticas: no domínio Active Directory cria grupos de segurança com a nomenclatura dos anéis e filtra a GPO de cada um por esse grupo. No Intune o mesmo desenho passa a grupos do Entra ID atribuídos ao update ring. Um equipamento entregue já entra directamente no grupo certo e herda o atraso do anel sem editares qualquer política.

3. Deferral por GPO: quality e feature

Abre a consola de Gestão de Políticas de Grupo (gpmc.msc) e cria uma GPO por anel — WUFB — Anel Teste, WUFB — Anel Trabalho, WUFB — Anel Crítico — linkada ao nível do domínio. Remove os Authenticated Users do Security Filtering e deixa apenas o grupo do anel (o SYSTEM não precisa de estar aí): o que conta é o grupo de contas de computador ter Read e Apply. Sem esta limpeza, a GPO aplica-se a todos e a segmentação morre antes de começar.

Dentro do editor, todas as políticas vivem sob Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update, na sub-pasta Windows Update for Business. São duas as que desenham o calendário:

  • Select when Preview Builds and feature updates are received — activa e define os dias de deferral de feature (0-365) e a data de início da pausa de feature.
  • Select when Quality Updates are received — activa e define os dias de deferral de quality (0-30) e a data de início da pausa de quality.

No anel Teste deixa a deferral de quality a 0 — a política de feature só se toca quando quiseres pilotar a próxima versão do Windows 11. Se as políticas não aparecerem nas consolas, o Central Store tem os templates ADMX desactualizados: copia os da build de Windows mais recente do domínio antes de desenhar mais nada.

Depois do gpupdate, verifica o que ficou gravado no cliente:

gpupdate /target:computer /force
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"

O que deve aparecer: DeferQualityUpdates e DeferFeatureUpdates a 1 (deferral activo) e os dois contadores de dias por deferral: DeferQualityUpdatesPeriodInDays (0-30) e DeferFeatureUpdatesPeriodInDays (0-365). É a prova de que a política chegou — a ausência das chaves significa que o filtro da GPO não apanhou essa máquina.

4. TargetReleaseVersion: travar a versão

A deferral atrasa — não trava. Quando a aplicação de facturação exige validação durante meses, quando precisas de saltar uma versão (de 24H2 directo para 26H2, um enablement package) ou de manter uma frota colada a uma versão suportada, o instrumento é o TargetReleaseVersion. Ele fixa o destino: a máquina move-se para a versão indicada e fica nela até ao limite do suporte ou até reconfigurares a política.

A regra do fim de serviço é dura e convém conhecê-la: um equipamento que atinja o fim de serviço da edição recebe a actualização à força 60 dias depois dessa data. É por isso que uma frota presa em 24H2 Home ou Pro — com fim de serviço a 13 de Outubro de 2026 — entra na actualização forçada por volta de 12 de Dezembro de 2026 (60 dias depois): hoje ainda está dentro da janela. As edições Enterprise e Education do 24H2 nem isto: têm suporte até Outubro de 2027. A política chama-se Select the target Feature Update version e vive em Windows Components > Windows Update > Manage updates offered from Windows Update: activa, escolhe Product Version (Windows 11) e a Target Version em causa. No registry, as três chaves que a política grava em HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate são:

Chave Tipo Exemplo
TargetReleaseVersion REG_DWORD 1
ProductVersion REG_SZ Windows 11
TargetReleaseVersionInfo REG_SZ 25H2 (ou 26H2)

Em máquina sem GPO à vista — o portátil do sócio em workgroup, por exemplo — as mesmas três chaves gravam-se à mão:

New-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name TargetReleaseVersion -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name ProductVersion -Value "Windows 11" -PropertyType String -Force
New-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate -Name TargetReleaseVersionInfo -Value "25H2" -PropertyType String -Force

Duas regras de convivência valem o preço da leitura: quando a política de target está activa, as deferrals de feature ficam desactivadas — não somam. E uma target version anterior à actual ou inválida faz a máquina deixar de receber feature updates até corrigires a política. Revê a target antes do fim de serviço da versão fixada — deixar a política apontada a uma versão expirada é o caminho silencioso para a frota congelada.

5. Pausas: o travão de emergência

Pausa e deferral parecem parentes e não são: a deferral é um atraso planeado no calendário, a pausa é um travão de emergência de 35 dias a partir da data que definires — e expira sozinha. Passados os 35 dias o equipamento volta a varrimento e a receber o tipo de actualização em pausa. No Intune, o botão Extend recomeça a contagem de 35 dias em vez de esperares pela expiração.

As duas políticas da secção 3 incluem a pausa correspondente: feature updates na Select when Preview Builds and feature updates are received e quality updates na Select when Quality Updates are received — cada uma com a sua data de início. O editor de GPO tem uma peculiaridade que apanha desatentos: o campo da pausa pode continuar marcado depois de os 35 dias esgotarem. O estado real lê-se no registry:

reg query "HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings" /v PausedFeatureStatus
Valor Estado
0 feature updates sem pausa
1 pausa de feature activa
2 pausa expirou — o equipamento retomou sozinho

⚠ Atenção: a pausa de quality congela o acumulativo inteiro — as correcções de segurança incluídas. Usa a pausa quando o anel Teste acusar uma regressão real (instalação que falha, aplicação que falha, periférico que deixa de responder), não como calendário preventivo. Quando a pausa expira, o equipamento não apanha dois acumulativos em fila: o próximo já traz tudo — o custo real é a janela de semanas sem correcções de segurança, exactamente o que se quer evitar.

A rotina de terça-feira de patches fica assim: na tarde de terça-feira confirma que o Anel Teste instalou o acumulativo. Na quarta de manhã — sem sintomas — deixa o patch avançar pelo Trabalho e pelo Crítico nos seus atrasos de 7 e 14 dias. Com sintomas confirmados, pausa quality no Trabalho e no Crítico e investiga a partir do Teste. A pausa de feature tem um gatilho próprio — uma feature update instalada no Teste com regressão de aplicação de facturação pausa feature em todos os anéis até a validação ficar feita.

6. Update rings no Intune

Se a frota já é gerida por Intune — o cenário do Microsoft 365 Business Premium — os update rings substituem os três GPOs: mesma lógica de anéis, consola na nuvem, gestão de grupos no Entra ID. Cria-os em Devices > By platform > Windows > Manage updates > Windows 10 and later updates > Update rings > Create profile e atribui cada perfil ao grupo Entra do anel com um grupo de exclusão para retirar equipamentos emprestados.

As settings que desenham o calendário são as mesmas da GPO: Quality update deferral period (0-30 dias) e Feature update deferral period (0-365 dias, contados desde o lançamento pela Microsoft). Duas merecem decisão consciente: o Set feature update uninstall period (2-60 dias) determina quanto tempo existe para fazer rollback por desinstalação após o upgrade — 20-30 dias é margem razoável para o Anel Trabalho. O interruptor Upgrade Windows 10 devices to Latest Windows 11 release decide se os poucos Windows 10 que restam sobem de versão ou ficam no ESU até expirarem.

Nos User experience settings convém travar o utilizador: desactiva a opção Option to pause Windows updates para impedir que alguém ponha o posto em pausa e esconda o patch de segurança, e deixa o Automatic update behavior como Auto install and restart at maintenance time com horas activas definidas. Quando activas os Use deadline settings, o Intune acrescenta prazos: deadline de 2-30 dias para cada tipo de update e grace period de 0-7 dias antes do reinício forçado — com Auto reboot before deadline em Yes, o reinício acontece fora das horas activas antes de as máquinas serem forçadas.

A operação de pausa ganha aqui o seu melhor lado: na visão geral do anel, o botão Pause separa Feature de Quality — 35 dias por tipo, com Resume e Extend ao lado. Pausas um anel sem tocar nos outros, e o Trabalho continua a receber patches enquanto o Crítico espera.

Assunto GPO Update ring Intune
Grupos Security groups do Active Directory no Security Filtering Grupos do Entra ID na atribuição do perfil
Deferrals As mesmas duas políticas do Windows Update for Business Quality update deferral (0-30) + Feature update deferral (0-365)
Pausa Data de início na política — expira aos 35 dias Pause/Resume/Extend por anel, por tipo, 35 dias
Prazos de instalação Deadline policy separada (grace period incluído) Deadlines 2-30 dias + grace 0-7 na própria política
Relatórios Windows Update for Business reports (portal Azure) Reports de update compliance na consola do Intune

7. O calendário de deferrals para uma PME

Os valores que se seguem são o ponto de partida com que começo qualquer desenho destes — ajusta para cima ou para baixo com a realidade da tua frota, mas mantém a escala entre anéis, que é o que dá tempo a correr atrás de uma regressão:

Anel Deferral quality Deferral feature TargetReleaseVersion Pausa
Teste 0 dias 30 dias Só para pilotar a versão nova É onde se decide pausar
Trabalho 7 dias 60 dias 25H2 enquanto a facturação valida Quality se o Teste acusar sintomas
Crítico 14 dias 90 dias Igual ao Trabalho Quality e feature até a validação ficar feita

A lógica de cada número: quality a 0 no Teste é o que cria a janela de decisão — sem anel que instale o patch no dia, não há sinal de regressão a tempo. Os 7 dias no Trabalho garantem uma terça-feira de separação. Os 14 no Crítico deixam sair duas terças antes de o patch tocar a facturação. Do lado das features, os 30 dias de Teste existem porque as primeiras semanas de um lançamento acumulam holds de compatibilidade — a 26H2 estreou com três problemas conhecidos, todos mitigados e nenhum com safeguard hold no lançamento — os de áudio USB e do Credential Guard vêm da actualização de Setembro e afectam 24H2 e 25H2 também, e o do Credential Guard ficou resolvido a 22 de Setembro.

Deferral de feature a 365 dias é a armadilha do congelamento: deixa o upgrade sem agenda real e quando a versão actual atinge o fim de serviço os 60 dias de margem arrastam a frota na mesma. Congelar versão é instrumento para o TargetReleaseVersion, não para o calendário.

8. GPO puro, Intune ou os dois

A escolha é curta e depende do que já pagas:

  • Só domínio Active Directory — GPO puro: três GPOs, três grupos AD, registos para verificar a aplicação. Funciona igual de bem e não acrescenta licenças.
  • Intune na caixa (M365 Business Premium ou licenças Intune separadas) — update rings: pausa e retoma na consola, deadlines incluídos e relatórios de compliance sem GPO.
  • Híbrido — mistura legítima, mas escolhe um canal por anel: a mesma política gerida em GPO e Intune com valores diferentes é a pior combinação possível, porque cada cliente resolve sozinho a que obedecer.

A visibilidade final não depende do canal: os Windows Update for Business reports — o portal Azure para equipamentos ligados ao Entra ID — mostram a compliance por update e apontam as máquinas com problemas de instalação. Sem esta leitura, gerir anéis é decidir às cegas. Com ela, as pausas decidem-se por sintoma e não por sensação.

Erros Comuns

  • Deixar os Authenticated Users no Security Filtering da GPO do anel — a segmentação morre e todos recebem o mesmo atraso. Filtrar por grupo + SYSTEM e conferir com o resultado da política no cliente.
  • Usar a pausa de quality como calendário — congela também as correcções de segurança. Deferral é calendário, pausa é emergência com expiração aos 35 dias.
  • Somar deferral e TargetReleaseVersion à mesma máquina na expectativa de somar atrasos — quando a target version está activa as deferrals de feature ficam desactivadas.
  • Deixar a target version apontada a uma versão expirada — a máquina deixa de receber feature updates até reconfiguração, e o fim de serviço traz o upgrade forçado aos 60 dias na mesma.
  • Central Store com ADMX antigos — as políticas do Windows Update nem aparecem numa consola com templates velhos. Copia os ADMX da build mais recente do domínio antes de desenhar.
  • Equipamentos Home na frota — as políticas do cliente não se aplicam a esta edição. Compra Pro ou encaminha-os para uma rota separada.

Checklist final

  • Três anéis com grupos reais (Teste, Trabalho, Crítico) e membros conferidos um a um
  • GPO (ou update ring) por anel com os deferrals quality/feature da tabela — e nada além disso nas políticas
  • Central Store com ADMX da build mais recente do domínio
  • TargetReleaseVersion só nos anéis que precisam de travar versão — e revisão marcada para antes do fim de serviço dessa versão
  • Uma pausa testada no Anel Teste (uma vez, no próximo patch Tuesday — para saber desmarcar e retomar)
  • Rotina de terça-feira escrita: quem confirma o Teste, quando se pausa, onde se regista a pausa e a sua expiração
  • Update rings criados por grupos do Entra ID quando o Intune já faz parte do desenho

Fontes Oficiais

Artigos Relacionados