HD Doctor Logo

Exchange 2016 e 2019 sem atualizações: como proteger as caixas de e-mail

Por Equipe Técnica HD Doctor

Resposta direta

As atualizações de 13/10/2026 foram as últimas do Exchange 2016 e do 2019, inclusive para quem contratou o ESU, e a Microsoft diz que não haverá nova extensão. A saída é migrar para o Exchange SE ou para a nuvem; até lá, mantenha backup testado dos bancos (EDB) e dos logs e reduza o que fica exposto à internet. Se o servidor ficou instável depois do update de outubro do Windows, a Microsoft indica uma chave de registro, não reparo do banco: não rode eseutil /p por causa desse sintoma.

O que mudou em outubro para quem tem Exchange na empresa

Em 13/10/2026, a equipe do Exchange publicou as atualizações de segurança de outubro para o Exchange SE RTM, o Exchange 2019 CU14 e CU15 e o Exchange 2016 CU23, esses dois últimos apenas para organizações inscritas no ESU Period 2. Segundo a Microsoft, outubro foi o último mês de correções para 2016 e 2019; daqui em diante, só o Exchange SE recebe atualizações. Fonte: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-october-2026-exchange-server-security-updates/ba-p/4563014. No anúncio do Period 2 (publicado em 15/04/2026 e atualizado em 13/10/2026), a empresa afirma que o programa, que cobriu de maio a outubro de 2026, não terá nova extensão, que os CVEs publicados pelo MSRC deixarão de mencionar 2016 e 2019 e que essas versões não serão mais testadas contra vulnerabilidades. Fonte: https://techcommunity.microsoft.com/blog/exchange/announcing-period-2-exchange-20162019-extended-security-update-esu-program/4511603. O BleepingComputer já havia noticiado o fim do programa em 22/07/2026: https://www.bleepingcomputer.com/news/microsoft/microsoft-exchange-2016-and-2019-esu-program-ends-in-october/. Na prática, um Exchange 2016 ou 2019 com OWA ou ActiveSync publicado na internet passa a acumular falhas sem correção, e o boletim de um CVE novo não dirá se a sua versão é afetada. As duas versões estão fora do suporte desde outubro de 2025; o ESU estendia apenas as correções de segurança. O caminho de saída depende da versão: a Microsoft só suporta upgrade in-place para o Exchange SE a partir do Exchange 2019 CU14 ou CU15, enquanto o 2016 CU23 exige upgrade legado, com um servidor SE na organização e a movimentação das caixas. Fonte: https://techcommunity.microsoft.com/blog/exchange/upgrading-your-organization-from-current-versions-to-exchange-server-se/4241305. A outra alternativa é o Exchange Online. Há um segundo problema, que atinge também o Exchange SE. Em 16/10/2026, a Microsoft informou que as atualizações de outubro do Windows Server (KB5126646 no 2025, KB5126655 no 2022, KB5126651 no 2019 e KB5126868 no 2016) podem deixar servidores Exchange instáveis depois de algum tempo, conforme a carga: o OWA falha com MapiExceptionMdbOffline (ec=1142, evento 1006 no log de Aplicativo), as filas crescem ao longo do dia até o fluxo de e-mail quase parar e membros de DAG têm dificuldade para atingir quórum. Reiniciar pode resolver temporariamente. A Microsoft afirma que a causa não são as atualizações do Exchange, pede que as do Windows não sejam desinstaladas e recomenda criar o valor EpmapSavedContextCap (REG_DWORD, 65536) em HKLM\SOFTWARE\Microsoft\Rpc, reiniciar e monitorar; se o problema voltar, elevar o limite. O FAQ incluído no post em 20/10 informa que não há correção definitiva iminente. Fonte: https://techcommunity.microsoft.com/blog/exchange/exchange-servers-may-become-unstable-after-installation-of-october-2026-windows-/4565382. O ITdaily repercutiu o aviso em 19/10/2026: https://itdaily.com/news/software/october-windows-updates-cause-exchange-servers-to-become-unstable/. O aviso descreve sintomas de disponibilidade e não fala em corrupção nem em perda de dados. Um banco "offline" logo depois do patch de outubro, portanto, não é motivo para reparar o EDB. O eseutil /p é um reparo destrutivo: a documentação arquivada da Microsoft desencoraja o comando porque ele pode causar perda de dados, reserva-o para quando não há como recuperar o banco com os logs (eseutil /r) e começa o procedimento copiando o EDB e os logs para outro local. Fonte técnica: https://learn.microsoft.com/en-us/archive/blogs/technet/mspfe/why-exchange-databases-might-remain-dirty-after-eseutil-r-recovery. Para a empresa, o risco aos dados está menos no aviso em si e mais no que se faz com pressa: reparar o banco sem necessidade, apagar logs para liberar espaço, migrar caixas sem backup testado. Se, apesar dos cuidados, um EDB não montar, o volume ficar ilegível ou faltarem logs, sem cópia validada, a HD Doctor pode avaliar a recuperação conforme o material preservado. Essa avaliação não corrige a instabilidade do Windows, não substitui a migração nem a resposta a incidentes e não garante recuperar conteúdo perdido.

Três reações que podem custar caixas de e-mail

  1. 1.
    Rodar eseutil /p porque o OWA diz que o banco está offline. Para o erro MapiExceptionMdbOffline após o patch de outubro, a Microsoft indica uma chave de registro. O /p pode descartar dados e só deve ser usado como último recurso, em cópia do EDB, depois de tentar a recuperação com os logs.
  2. 2.
    Apagar logs de transação ou o arquivo de checkpoint para forçar a montagem. Os logs são o que permite levar o banco a um estado consistente sem perda com o eseutil /r. Se o volume de logs estiver enchendo, a forma segura de truncá-los é um backup completo do Exchange concluído com sucesso, não a exclusão manual.
  3. 3.
    Desinstalar o update do Windows ou adiar correções por causa da instabilidade. A Microsoft pede o contrário: manter as atualizações de outubro, que trazem correções de segurança relevantes, e aplicar a chave recomendada. Adiar patch em servidor de e-mail exposto à internet troca um problema de disponibilidade por risco de invasão.

Cinco passos para atravessar o fim do ESU sem perder caixas

Roteiro para a equipe que administra o Exchange e para quem decide a migração. Faça mudanças fora do horário de pico e registre cada comando executado nos servidores.

  1. 1

    Inventarie versões, CUs e o update do Windows

    Liste cada servidor Exchange com versão e CU (2016 CU23, 2019 CU14 ou CU15, SE), a versão do Windows Server e se a atualização de outubro (KB5126646, KB5126655, KB5126651 ou KB5126868) está instalada. O Exchange Server Health Checker, indicado pela Microsoft no post de outubro, ajuda nesse levantamento. Inclua membros de DAG em outros sites e servidores de contingência.

  2. 2

    Se houver sintoma, aplique a recomendação da Microsoft

    Com OWA exibindo MapiExceptionMdbOffline (ec=1142), evento 1006, filas crescendo ou DAG sem quórum, siga o post de 16/10: em prompt elevado, reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f, reinicie o servidor e monitore. Confira o comando no post original e registre a mudança. Se o sintoma voltar, a orientação é elevar o limite.

  3. 3

    Faça e teste um backup consistente antes de mexer

    Antes de aplicar a chave, instalar atualizações ou mover caixas, confirme que o último backup completo do Exchange, feito por software compatível com o VSS writer do Exchange, terminou sem erro e inclui bancos e logs. Restaure um banco em ambiente separado ou como recovery database e abra algumas caixas. Backup nunca restaurado é hipótese, não garantia.

  4. 4

    Se um banco não montar, preserve antes de reparar

    Verifique o estado com eseutil /mh (Clean ou Dirty Shutdown e logs exigidos) e copie EDB, logs e arquivo de checkpoint para outro volume antes de qualquer recuperação. A recuperação com logs (eseutil /r) vem primeiro; eseutil /p só em cópia, como último recurso. Se o disco, o RAID ou o volume apresentarem falha, não rode reparos sobre eles: preserve as mídias.

  5. 5

    Planeje a saída do 2016 e 2019 e reduza a exposição até lá

    Do Exchange 2019 CU14 ou CU15, o upgrade in-place para o SE é suportado; do 2016 CU23, o caminho é o upgrade legado, com servidor SE novo e movimentação das caixas. O Exchange Online é a outra saída. Até concluir, revise com a segurança o que fica publicado na internet e mantenha os bancos antigos até validar as caixas migradas.

Perguntas sobre o fim do ESU e os bancos do Exchange

Meu Exchange 2019 está funcionando. Preciso migrar mesmo assim?

Sim. Funcionar não é estar protegido: depois das atualizações de 13/10/2026, nem quem tem ESU recebe novas correções para 2016 e 2019, e a Microsoft avisa que CVEs futuros não mencionarão essas versões. No 2019 CU14 ou CU15, o upgrade in-place para o Exchange SE é suportado; no 2016 CU23, o caminho é o upgrade legado.

O erro de banco offline depois do update de outubro significa que o EDB corrompeu?

Não, pelo que a Microsoft publicou: o aviso descreve falhas de disponibilidade, que o reinício pode resolver temporariamente, e não menciona corrupção nem perda de dados. Aplique a chave recomendada e monitore. Se um banco continuar sem montar depois disso, trate como outro problema: confira o estado com eseutil /mh e copie EDB e logs antes de qualquer recuperação.

A chave de registro também vale para o Exchange SE?

Sim. Segundo a Microsoft, qualquer versão do Exchange (2016, 2019 ou SE) rodando em um Windows Server com a atualização de outubro pode ser afetada. A empresa pede que o update do Windows não seja desinstalado e diz que não há correção definitiva iminente, por isso não vale esperar um novo patch.

Quando faz sentido pedir recuperação profissional de dados?

Quando o EDB ou o volume onde ele fica estiver ilegível e não houver cópia validada: disco ou RAID com falha, logs ausentes, um reparo que falhou na única cópia. Preserve mídias, EDB e logs e registre os comandos já executados. Instabilidade que a chave de registro resolve não é caso de recuperação de dados.

O banco de caixas de e-mail não monta?

Preserve o EDB, os logs e as mídias e informe sintomas, datas e comandos já executados.

Próximas leituras