Windows Server: Boas Práticas de Actualização Mensal de Updates

Introdução

O incidente do RDS de Setembro de Updates de Setembro de 2026 no Windows Server ilustrou o tipo de risco que uma actualização mensal pode ter: um patch de segurança que parou os serviços de Remote Desktop em servidores de produção. Este artigo destila o processo que evita esse tipo de dor de cabeça — das verificações antes do patch ao acompanhamento depois — no formato de boas práticas aplicáveis a qualquer Patch Tuesday.

1. Antes de actualizar: inventário e known issues

A consulta mais valiosa da semana de patch não é a lista de KBs — é a página Release Health da Microsoft, que a Microsoft mantém por versão do Windows Server com os known issues de cada update e o estado de cada um. Consulta-a por versão do sistema:

O que procurar na página, na ordem certa:

1. Known issues abertos para o KB que se prepara instalar — o update do mês vai resolver ou agravar?
2. Issues recentes na tua frota — roles instalados (RDS, Hyper-V, AD DS), apps instaladas, drivers de impressão
3. Issues resolvidos com workaround — o KB indica como mitigar sem esperar por novo update
4. Safeguard holds — features updates com o update bloqueado pela Microsoft para a tua config (mais comum em Windows client, mas os servidores também entram)

Cada KB instalado tem uma página support.microsoft.com/help/<KB> com as secções específicas: How to get this update, Known issues in this update (com a lista de sintomas + workarounds), List of known issues resolved-by e os references aos CVEs. Um KB que tem um known issue com workaround descrito ainda antes de instalar é um KB que se instala com plano.

Para monitorização contínua em vez de consulta manual, as páginas da Release Health têm feeds consultáveis por API — e a Windows Updates API no Microsoft Graph automatiza a leitura do catálogo de updates (os known issues vivem nas páginas da Release Health).

Antes de instalar, um inventário do que o update vai tocar: Get-HotFix, os roles activos (Get-WindowsFeature | Where-Object Installed -eq True), e as aplicações instaladas. A pergunta de segurança: qual destes fica vulnerável ou parte se o KB tiver bug — é a resposta que decide o anel de distribuição na secção 5.

2. Backup: o passo obrigatório

O backup pré-update tem dois níveis, e ambos têm lugar:

1. Snapshot do hypervisor (Hyper-V, VMware, Proxmox) — recuperação em minutos do estado exacto da máquina antes do update. O snapshot não substitui o backup para ficheiros (usa o disco da própria VM), mas cobre o cenário mais comum: o update parte um serviço e o servidor precisa de voltar para a configuração de anteontem.

2. Backup do sistema com Windows Server Backup — o wbadmin cobre volumes críticos e o System State (Active Directory, registry, boot files, COM+). O System State é o que permite recuperar um AD comprometido por um update de forest recovery:

# Backup completo de volumes críticos para disco dedicado
wbadmin start backup -backupTarget:F: -include:C:,D: -allCritical -quiet

# Backup do System State (AD DS, registry, boot)
wbadmin start systemstatebackup -backupTarget:F: -quiet

-backupTarget é o caminho do destino: drive local (F:), volume GUID, ou UNC de partilha remota (\servidor\partilha\). -allCritical inclui os volumes boot e system por defeito. O backup corre sobre VSS (Volume Shadow Copy Service), por isso o sistema continua a responder durante o backup. O executante tem de ser Backup Operators ou Administrators, em prompt elevado.

Uma nota do próprio texto de help do wbadmin: o Windows Server Backup não inclui as hives de registry HKEY_CURRENT_USER no system state — irrelevante para contas de serviço mas relevante se usas aplicação que guarda configuração em HKCU de utilizador.

E teste de restauro? Um backup que nunca foi restaurado é uma hipótese, não um plano. O teste mínimo pré-update: num servidor de teste (do anel 0 da secção 5), restaurar o System State do último backup e confirmar que o wbadmin get versions lista a versão do dia. O artigo sobre backups PostgreSQL com pg_dump e pgBackRest descreve o mesmo princípio noutra tecnologia: o ciclo de backup não está validado até o restauro ter corrido.

3. Verificação de integridade do sistema antes de instalar

Uma verificação rápida que evita horas de debug: confirmar que o sistema está saudável antes de lhe aplicar um patch:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

O RestoreHealth valida os componentes do image store contra fontes conhecidas. Um update instalado sobre um sistema corrupto vai falhar a meio — e o rollback do update é sempre mais complicado que o da instalação. Se o DISM corrigir componentes, executar sfc de novo para confirmar e reiniciar antes do patch.

4. O que esperar: workarounds na página do KB

Quando um KB lista um known issue, a página indica o estado actual dele e um dos cenários possíveis. Ler essa linha antes de instalar poupa o dia do patch:

O caso do RDS de Setembro de 2026 é o exemplo do Resolved OOB — e de porque é que a consulta da Release Health se repete na semana seguinte ao patch: o KB5122871 instalado a 08/09 listou “Remote Desktop Services might stop responding” como known issue a 11/09 — três dias depois — e a Microsoft publicou o KB5129235 fora de banda a 14/09. Quem só consultou a Release Health no dia do patch viu a tabela limpa; quem voltou a consultar a 14/09 apanhou o aviso e o update de correcção antes de instalar o original em produção.

Um detalhe no mesmo espírito: o baseline 25H2 do Intune ganhou a política Disable Internet Explorer 11 Launch Via COM Automation no service update de Junho de 2026 — perfis criados antes do update só apanham a política nova depois de editar e voltar a gravar o perfil. É o mesmo padrão: mudanças de política pós-release chegam com notas de gestão que só se veem quando se consulta a página do produto antes de instalar.

5. Anéis de distribuição: piloto antes de frota

O mesmo update nunca vai a toda a frota no mesmo dia. A distribuição em anéis é a única defesa que sobrevive a um KB com bug descrito horas depois do lançamento:

• Anel 0 (teste): VMs descartáveis ou servidores de pré-produção — máquinas que replicam o ambiente de produção e só servem para testar estas mudanças — com os roles críticos da frota (AD DS, RDS, impressão, DB). Espera 24 a 48 h
• Anel 1 (piloto): servidores menos críticos, 10 a 20% da frota. Espera 72 h com monitorização
• Anel 2 (produção): o resto, depois de confirmar que o anel 1 está estável

Nos clientes Windows 10/11 as políticas do Windows Update para Business deferem feature e quality updates por anel (dias de diferimento). Nos servidores não há feature updates mas a política Select when Quality Updates are received existe e defer até 30 dias (GPO DeferQualityUpdatesPeriodInDays); o controlo fino por anel segue com WSUS ou com a janela de manutenção da ferramenta de gestão (SCCM/Intune para co-management). O princípio é o mesmo: o anel 0 recebe cedo para apanhar o bug antes da produção.

O que monitorizar no anel 0 não é só “o servidor arrancou”: os serviços críticos (RDS listener, AD replication, serviços de impressão), o event log System e Application nos primeiros minutos, e a aplicação de negócio a falar com o servidor.

6. Known Issue Rollback: reverter sem desinstalar

O KIR é a tecnologia que a Microsoft usa para reverter uma mudança específica de um update sem desinstalar o update inteiro — disponível desde Windows 10 2004 e nas versões suportadas do Windows Server. Dois factos que o artigo do RDS usou na correcção e que valem fixar:

• O KIR aplica-se só a correctões não-segurança — security fixes nunca usam KIR (a Microsoft não expõe a possibilidade de reverter uma fix CVE)
• O KIR activa-se por GPO com o ADMX do update (o MSI + ADMX publicados no KB) — a política nasce Not Configured — é o GPO que a define como Disabled, e é essa definição que reactiva o comportamento antigo da funcionalidade em causa

A vantagem operacional sobre desinstalar o update: o servidor mantém as restantes correctões de segurança — e a compliance não se perde. Quando o KB indica que o known issue tem KIR, a sequência de resposta é: aplicar o MSI/ADMX do KIR via GPO, com a política do known issue em Disabled → verificar nos 24-48 h seguintes se o sintoma reverteu (os checks da secção 8 servem para isto).

7. Desinstalar: o plano C

Quando não há KIR e o update parte o servidor, o rollback manual é wusa ou DISM:

:: identificar o package
DISM /Online /Get-Packages | findstr /i "5122871"

:: desfazer o update
wusa.exe /uninstall /kb:5122871 /quiet /norestart

O DISM /Online /Get-Packages lista os packages instalados com o nome exacto que o uninstall precisa (o número do KB aparece no nome do package, não é garantido em todos os tipos). Depois de remover, reiniciar e re-verificar a saúde com os mesmos checks da secção 8.

O plano C tem um limite que se deve à forma como o servicing Windows funciona: desinstalar um update pode desinstalar com ele as correctões de segurança acumuladas — os quality updates são cumulativos e a remoção devolve o servidor a um estado anterior. É o motivo de o KIR existir: reverter o comportamento problemático preservando o resto.

8. Acompanhamento após o update

As primeiras 48 h depois de um anel entrar em produção valem uma rotina de verificação:

• Serviços críticos a levantar — Get-Service | Where-Object {$_.StartType -ne "Disabled" -and $_.Status -ne "Running"} — o que parou? (ex. RDS listener, serviços de impressão)
• Event log System e Application — nos dias seguintes, filtrar por Critical/Error e comparar com a linha base anterior ao patch
• Replicação de AD — repadmin /replsummary para confirmar que a replicação não partiu
• Performance baseline — CPU/memória/disk para comparar com a semana anterior — alguns bugs só aparecem como regressão de performance
• Release Health na semana seguinte — o known issue pode ser confirmado dias depois e a página indica o estado resolvido ou não

O acompanhamento termina com uma entrada na base de conhecimento interna: o KB número, os sintomas vistos (nenhum é também um resultado), as acções — a memória do ano seguinte quando o mesmo rol voltar a ser tocado.

Erros comuns

Checklist

• [ ] Página Release Health da tua versão consultada para o KB do mês
• [ ] Página support.microsoft.com/help/<KB> lida — known issues e workarounds
• [ ] Inventário de roles e aplicações que o update pode tocar
• [ ] Backup de volumes + System State feitos no dia e verificados com wbadmin get versions
• [ ] Teste de restauro do System State numa VM em dia regular
• [ ] DISM RestoreHealth e sfc /scannow sem erros antes de instalar
• [ ] Workaround identificado (se houver) e testado no anel 0
• [ ] Anéis de distribuição definidos: teste → piloto → produção com esperas de 24/72 h
• [ ] Verificação de serviços críticos + event log + replicação nas 48 h seguintes
• [ ] Registo na base de conhecimento interna no fim

Artigos Relacionados

• Updates de Setembro de 2026 no Windows Server: falhas no RDS e correcções
• PostgreSQL: Backups Fiáveis com pg_dump e pgBackRest
• Windows Server 2025: o que mudou na prática

Fontes Oficiais

• Windows Server 2025 known issues and notifications (Release Health)
• Windows release health
• KB5006965: How to check information about safeguard holds
• Known Issue Rollback — Windows Server
• Use Group Policy to deploy a Known Issue Rollback
• wbadmin start backup
• wbadmin start systemstatebackup
• Plan Your Windows Server Upgrade Path
• Windows Updates API no Microsoft Graph