Hotpatching no Windows Server 2025: Patches Sem Reiniciar

O sintoma que leva qualquer administrador de PME a procurar esta funcionalidade: é Patch Tuesday, o servidor de ficheiros tem 200 utilizadores ligados, e o update cumulativo exige reiniciar em plena manhã de trabalho. O Hotpatching resolve isto no Windows Server 2025: aplica os updates de segurança de Julho e Agosto — os dois meses entre baselines — sem reiniciar a máquina, porque corrige o código em memória dos processos a correr. Em cada trimestre, o ciclo é: um update cumulativo com reboot (baseline) seguido de dois meses de hotpatching sem reinício. A partir de 2026, o Azure Arc-enabled Hotpatch está disponível sem custo adicional para Windows Server 2025 Standard e Datacenter, o que o torna viável para servidores on-premises de PME ligados ao Azure Arc.

⚠ Atenção: hotpatching não elimina os reboots. O update cumulativo trimestral (baseline) exige reinício, tal como os updates que não fazem parte do programa — updates .NET, firmware, drivers e updates não-segurança. O hotpatching reduz o número de reboots de 12 por ano para 4 por ano. Não os elimina. Planeia uma janela de manutenção trimestral mesmo com hotpatching activo.

Neste artigo

O que Está a Acontecer — Como o Hotpatching Funciona

Um update de segurança tradicional substitui binários no disco — e como os processos já têm os binários antigos em memória, é preciso reiniciar para carregar as versões novas. O hotpatching funciona de forma diferente: o patch contém apenas as diferenças (as funções alteradas), e o Windows injecta-as directamente na memória dos processos a correr. O processo não reinicia. A correcção fica activa no momento seguinte à instalação.

O ciclo funciona em três tempos. Primeiro, uma baseline: o update cumulativo completo do mês, que inclui tudo (segurança + não-segurança) e exige reboot. Depois, dois meses de hotpatch releases — pacotes pequenos, só com correcções de segurança, instalados sem reinício. Ao fim de três meses, nova baseline, e o ciclo repete. Num ano típico são quatro baselines (com reboot) e oito hotpatches (sem reboot): de 12 reboots anuais passa-se para 4. A Microsoft mantém um calendário oficial de lançamentos (Windows Server release info).

Existem dois tipos de baseline. As planeadas seguem o calendário trimestral. As não planeadas surgem quando uma correcção urgente — tipicamente um zero-day — não consegue ser distribuída como hotpatch. Nesse mês, o hotpatch é substituído por uma baseline completa e o reboot é obrigatório. É a reserva de segurança do sistema: quando o patch é demasiado intrusivo para aplicar em memória, a Microsoft força o caminho tradicional.

O hotpatching está disponível em duas vias: VMs Azure com as imagens Windows Server 2025 Datacenter Azure Edition (a orquestração é automática via Azure Update Manager) e, desde 2026, máquinas ligadas ao Azure Arc — incluindo servidores físicos on-premises — sem custo extra (Hotpatch for Windows Server).

Cenários em que Faz Sentido

  • Servidor single-role crítico — um DC, um file server ou um servidor de ERP que não pode estar indisponível numa janela de trabalho. O reboot de Patch Tuesday passa de mensal para trimestral.
  • PME sem cluster — sem segundo nó para fazer failover, cada reboot é downtime real. O hotpatching dá 8 em 12 meses sem interrupção.
  • Frota Azure Local — VMs em Azure Local com as imagens Azure Edition suportadas. Orquestração por Group Policy ou SConfig.
  • Servidores on-premises ligados ao Azure Arc — o caminho novo, sem custo, que leva o hotpatching a hardware próprio. É o cenário mais relevante para PMEs que não correm em Azure.
  • Aplicações sensíveis a reinício — sistemas de manufactura, POS, ou bases de dados com arrancadas lentas em que cada reboot representa minutos de produção perdidos.

Não faz sentido para: máquinas com janelas de manutenção fáceis (reboot trimestral é quase o mesmo esforço), servidores sem ligação à Internet ou ao Arc, ou ambientes onde o update não-segurança mensal (.NET, drivers) já obriga a reinício de qualquer forma.

Passo 1 — Verificar se o Servidor Cumpre os Requisitos

O hotpatching para máquinas ligadas a Arc aplica-se a Windows Server 2025 Datacenter e Standard. Confirma a versão e edição antes de avançar:

Get-ComputerInfo | Select-Object WindowsProductName, OsVersion, OsBuildNumber, WindowsEditionId

O cmdlet devolve a versão exacta do Windows Server. Para hotpatching via Arc, precisas de Windows Server 2025 (build 26100.1742 ou superior) nas edições Standard ou Datacenter. Builds preview e Windows Server Insiders não são suportados. Se o servidor ainda estiver em 2022, o caminho é o Azure Edition — mas o Arc-enabled Hotpatch é só para 2025.

O requisito que mais falha na prática: o servidor tem de cumprir os requisitos de Virtualization-Based Security (VBS) — no mínimo, firmware UEFI com Secure Boot activado. Numa VM Hyper-V, isto significa uma VM de Geração 2 — VMs de Geração 1 não são suportadas e a activação no portal falha. Confirma antes de avançar:

# Verificar Secure Boot e VBS
Confirm-SecureBootUEFI
Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption, BuildNumber

O Confirm-SecureBootUEFI devolve True se o Secure Boot estiver activo — é a condição mínima da VBS. Em VMs Hyper-V, verifica a geração em Hyper-V Manager (Propriedades da VM) ou com Get-VM | Select-Object Name, Generation no anfitrião.

Verifica também a ligação ao Azure Arc, que é o pré-requisito do caminho on-premises:

# Confirmar que a máquina está ligada ao Azure Arc
Get-AzConnectedMachine -ResourceGroupName "rg-pme-servidores" 2>$null
# Se o módulo Az não estiver instalado:
Install-Module -Name Az.ConnectedMachine -Scope CurrentUser

O primeiro comando lista as máquinas ligadas ao Arc no resource group — o servidor deve aparecer com Status = Connected. Se não aparecer, a ligação ao Arc é o primeiro passo (o agente Azure Connected Machine instala-se com um script do portal Azure, em Connect > Servers > Add). O Install-Module traz o módulo PowerShell necessário para gerir a ligação. A sintaxe dos cmdlets Get-AzConnectedMachine e Install-Module está validada contra a documentação do módulo Az.ConnectedMachine.

Passo 2 — Activar Hotpatching via Azure Arc

A activação é feita no portal Azure, não no servidor. Com a máquina ligada ao Arc:

  1. Abre o portal Azure e navega até Azure Arc > Machines.
  2. Selecciona o nome da tua máquina.
  3. Selecciona Hotpatch e depois Confirm.
  4. Aguarda cerca de 10 minutos para as alterações aplicarem.
  5. Se o estado ficar preso em Pending, segue o troubleshooting do agente Azure Arc.

O estado fica visível no painel Recommended updates — o campo Hotpatch status passa a Enabled.

A partir daqui, o Azure Update Manager orquestra o ciclo: baselines trimestrais com reboot agendado, hotpatches nos restantes meses aplicados automaticamente nas horas de menor carga do fuso do servidor (Hotpatch for Windows Server).

⚠ Atenção: o reboot da baseline trimestral não desaparece — é agendado pelo Azure Update Manager. Configura a janela de manutenção (maintenance window) para um horário fora de produção, senão o reboot da baseline pode apanhar o servidor em pleno horário laboral.

Passo 3 — Gerir o Ciclo de Patches

O ciclo fica visível no portal (Updates > Recommended updates), mas convém conhecer os três estados:

  • Hotpatch release (meses 2 e 3 do trimestre) — instala sem reboot, aplica-se automaticamente. Não requer acção.
  • Planned baseline (mês 1 de cada trimestre) — update cumulativo completo, reboot necessário. O Azure agenda dentro da janela configurada.
  • Unplanned baseline (zero-days) — substitui um hotpatch quando a correcção não cabe em memória. Reboot fora do calendário; o portal mostra a razão.

No servidor, o estado do Windows Update mantém-se consultável pelos cmdlets normais:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

O Get-HotFix lista os patches instalados, mais recentes primeiro. Os hotpatch releases aparecem como updates de segurança com datas nos meses intercalares — é a forma rápida de confirmar que o ciclo está activo sem abrir o portal.

Passo 4 — Configurar via PowerShell e GPO

Para VMs em Azure Local (sem portal Azure), o cliente Windows Update controla-se por Group Policy ou PowerShell. Nas VMs Azure Local, o doc oficial aponta Group Policy e SConfig como ferramentas de configuração do cliente Windows Update (Azure Local).

Configuração do cliente Windows Update por GPO (para garantir que o servidor recebe os hotpatches na janela certa):

# Via PowerShell — política local do cliente Windows Update
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" `
  -Name NoAutoRebootWithLoggedOnUsers -Value 1

Este valor impede o reboot automático com utilizadores ligados — relevante para as baselines trimestrais em servidores com sessões RDP activas. O reboot fica para a janela de manutenção agendada.

O que o Hotpatching Não Cobre

O hotpatch cobre só updates de segurança do Windows, com paridade de conteúdo com o canal regular. Estes seguem a via tradicional e exigem reinício mesmo nos meses de hotpatch:

  1. Updates não-segurança do Windows — fixes de qualidade, melhorias.
  2. Updates .NET — ciclo próprio, fora do programa.
  3. Updates não-Windows — drivers, firmware, software de terceiros.
  4. Baselines trimestrais — o cumulativo completo, por definição, tem reboot.

Na prática, a PME continua a precisar de uma janela de manutenção trimestral planeada. O ganho é real — 8 meses sem reboot por ano — mas o reboot trimestral não é opcional.

Erros Comuns

Problema Causa provável Solução
Hotpatch não aparece em Updates no portal Máquina não ligada ao Arc ou feature não activada Verificar ligação Arc e clicar Enable Hotpatch
Activação falha no portal (Hotpatch indisponível) Requisitos VBS em falta — VM Geração 1 ou Secure Boot desactivado Migrar para VM Geração 2 com UEFI/Secure Boot e repetir
Hotpatch aplicado mas o fix provocou problema Hotpatching não tem rollback automático Desinstalar o último update e reinstalar a última baseline funcional (requer reboot)
Updates aplicados mas estado continua Pending Baseline pendente por falta de reboot Agendar reboot da baseline na janela de manutenção
Hotpatch rejeitado na instalação Imagem não suportada (custom/Standard on-prem sem Arc) Confirmar imagem Azure Edition ou ligação Arc com 2025
Servidor efetuou reboot em mês de hotpatch Unplanned baseline (zero-day) Verificar o calendário de releases e a razão no portal
Patches .NET continuam a exigir reboot .NET está fora do programa hotpatching Manter ciclo separado para .NET e firmware

Checklist Rápido de Verificação

  • Windows Server 2025 Standard ou Datacenter, build 26100.1742+ (sem builds preview/Insiders).
  • UEFI com Secure Boot activado (requisito VBS) — VMs Hyper-V têm de ser Geração 2.
  • Ligação ao Azure Arc activa e a mostrar Connected no portal.
  • Hotpatch Enabled em Updates > Recommended updates.
  • Janela de manutenção (maintenance window) configurada no Azure Update Manager.
  • Calendário de baselines trimestrais no calendário da equipa IT.
  • Plano para updates .NET/firmware fora do hotpatching.
  • Backup do estado do servidor antes da primeira baseline via hotpatching.

Artigos Relacionados