O EWS termina no Exchange Online a 1 de abril de 2027: como migrar as suas integrações para o Microsoft Graph

A Microsoft começou a desligar o Exchange Web Services (EWS) no Exchange Online. Os primeiros passos de aplicação decorrem este mês e, depois disso, os tenants que nunca mexeram nas definições do EWS vão sendo desligados um a um. A data que a Microsoft fixou para desligar o EWS por completo é 1 de abril de 2027, embora o aviso MC1485116 do Message Center, de 1 de outubro, preveja que a implementação nas clouds mundial e do governo dos EUA termine no início de julho de 2027. Planeie para 1 de abril. A Microsoft foi clara: não haverá exceções depois de abril de 2027.

Se alguma coisa que a sua empresa desenvolveu comunica com caixas de correio do Microsoft 365 através do EWS, deixa de funcionar nessa data, o mais tardar, e possivelmente muito antes. Os suspeitos do costume: um CRM que associa os emails dos clientes às respetivas contas, um script de arquivo ou retenção, um ecrã de reserva de salas de reunião, um sistema de tickets que lê uma caixa de correio partilhada de suporte, uma tarefa de relatórios que conta emails por equipa. A solução é reescrever tudo para o Microsoft Graph, e parte do que o EWS fazia não tem qualquer equivalente no Graph.

O que acontece, data a data

A Microsoft controla o EWS por tenant através da definição EWSEnabled, que tem três valores: Null (o valor por omissão), True e False. Ao lado dela existe agora uma segunda definição, EWSAllowedAppIDs: uma lista de identificadores de aplicações que ainda podem usar o EWS. A página atual do Microsoft Learn dá as linhas gerais: «October 2026: EWS starts to be disabled globally for all organizations» e «April 2027: EWS is fully disabled.»

O pormenor está no artigo da equipa do Exchange de 1 de outubro, EWS Deprecation Is Here. Para a cloud comercial mundial:

• 2 de outubro de 2026, ao fim do dia na hora do Pacífico: a Microsoft regista todos os tenants que têm EWSEnabled definido como True mas não têm lista de permissões.
• 8 e 9 de outubro de 2026: para esses tenants, a Microsoft cria a lista de permissões e preenche-a com os identificadores das aplicações que usaram o EWS nos 60 dias anteriores.
• A partir de 10 de outubro de 2026: quando EWSEnabled é True, a lista de permissões é obrigatória. Uma aplicação que não conste dela é recusada.
• Segunda fase, a seguir: os tenants que continuam em Null passam a ter EWSEnabled definido como False, o que bloqueia o EWS para todas as aplicações. Cada um recebe um aviso no Message Center com 7 dias de antecedência, e pouco antes a Microsoft preenche uma lista de permissões com base em 60 dias de utilização, para que um administrador possa voltar a ligar o EWS com True.
• 1 de abril de 2027: a data que a Microsoft fixou para o EWS ficar «fully and permanently disabled», depois da qual os administradores de tenants deixam de poder alterar EWSEnabled. O MC1485116 aponta o início de julho de 2027 como o fim previsto da implementação nas clouds Worldwide, GCC, GCC High e DoD, pelo que alguns tenants podem manter o EWS um pouco mais. Ninguém deve contar ser um deles.

Os tenants das outras clouds da Microsoft recebem os seus próprios calendários através do Message Center.

A lista de permissões compra tempo, não resolve

A lista automática é construída a partir de 60 dias de tráfego, e as próprias orientações da Microsoft de 4 de setembro avisam que «may miss applications that run infrequently». Uma exportação de fim de trimestre ou uma tarefa de arquivo de fim de ano não vai constar dela, e vai falhar da próxima vez que correr.

As alterações à lista de permissões demoram 24 horas a produzir efeito, e as alterações a EWSEnabled cerca de uma hora. Qualquer correção que faça depois de uma falha custa, no mínimo, um dia.

Para ver em que ponto está o seu tenant, um administrador com o Exchange Online PowerShell pode executar:

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

A quem se destina e quem pode parar de ler

O Exchange Server local não é afetado. A Microsoft diz que a descontinuação se aplica «only to Microsoft 365 and Exchange Online» e que «there are no changes to EWS in Exchange Server». Se todas as suas caixas de correio estão nos seus próprios servidores, pode parar aqui.

As configurações híbridas exigem uma análise mais atenta. As caixas de correio locais podem continuar a usar o EWS; as que estão na cloud têm de passar para o Graph. O artigo da Microsoft sobre ambientes híbridos, de 30 de setembro, trata de dois casos que exigem ação já, incluindo caixas de correio locais com arquivo no Exchange Online, para as quais a recomendação, por agora, é manter o EWS ligado e colocar a aplicação híbrida na lista de permissões.

O software de pacote cabe ao fornecedor. Se o que chama o EWS for um produto comercial, lançar uma versão para o Graph é trabalho do fornecedor, e o seu é obter uma data e instalar a atualização. Os próprios clientes da Microsoft não são exceção: alguns ainda aparecem nos relatórios de utilização e precisam da lista de permissões até serem atualizados.

O código interno cabe-lhe a si. Scripts, serviços internos, ferramentas open source personalizadas e integrações que uma agência desenvolveu há anos não têm ninguém a montante que os corrija. É aí que está o trabalho. Para dar uma ideia da escala: o exchangelib, uma biblioteca Python para comunicar com o Exchange através do EWS, foi descarregado 1 174 625 vezes do PyPI no último mês. Parte disso é utilização local, mas dá uma noção da quantidade de código que fala diretamente com o EWS.

Primeiro passo: encontrar tudo o que usa o EWS

Comece pelo relatório de utilização do EWS no centro de administração do Microsoft 365 (Relatórios, Utilização, Exchange e depois o separador de utilização do EWS). Para cada aplicação, indica o identificador de aplicação no Microsoft Entra, todas as ações SOAP que essa aplicação chamou, o volume de chamadas e a data da última atividade. Pode recuar 7, 30 ou 90 dias e exportar para CSV.

Três coisas a saber sobre ele:

• Os dados são agregados semanalmente e podem demorar até 10 dias a aparecer.
• Um identificador de aplicação não é um responsável. Faça corresponder cada identificador às aplicações empresariais no Microsoft Entra e depois encontre a pessoa ou a equipa que a gere. Conte com alguns identificadores que ninguém reconhece.
• A coluna das ações SOAP diz-lhe a dimensão de cada trabalho. Uma aplicação que só chama FindItem e GetItem é um trabalho curto. Uma que chama SyncFolderItems, Subscribe e ExportItems é um projeto.

Mesmo 90 dias deixam de fora as tarefas anuais, por isso verifique também o outro lado: tarefas agendadas e entradas de cron, e pesquise nos repositórios de código o endpoint do EWS (Exchange.asmx), a EWS Managed API para .NET e o exchangelib. A página de descontinuação da Microsoft também indica um analisador de EWS para código .NET (assinala chamadas ao EWS no Visual Studio e no VS Code e sugere equivalentes no Graph) e um tutorial sobre refatoração assistida por IA.

Segundo passo: decidir o destino de cada integração

Cada aplicação da lista recebe uma de quatro respostas:

1. Desativá-la. Algumas integrações só existem porque ninguém as desligou.
2. Atualizá-la. Os produtos de fornecedores recebem uma atualização do fornecedor. Acorde a data já.
3. Reescrevê-la para o Microsoft Graph. A opção por omissão para código interno.
4. Redesenhá-la. Para tudo o que dependa de uma capacidade que o Graph nunca vai ter (ver abaixo).

A Microsoft também indica a Power Platform como forma de reimplementar um fluxo de trabalho. Para um script que reencaminha anexos para uma pasta, pode ser a resposta mais barata.

O que implica, na prática, reescrever para o Graph

A maior parte das operações do EWS tem uma correspondência direta no Graph, e a Microsoft mantém um mapeamento do EWS para o Graph. O mapeamento é a parte fácil. As partes difíceis são as que ele não mostra.

As permissões ficam mais restritas, e isso é uma vantagem

Uma aplicação que usa o EWS sem utilizador com sessão iniciada tem a permissão de aplicação do EWS, que a Microsoft descreve como «full access to all mailboxes». O Graph divide isso em permissões separadas: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read e assim por diante.

Também pode limitar as caixas de correio a que uma aplicação chega. O RBAC for Applications no Exchange Online atribui uma permissão a um âmbito de gestão ou a uma unidade administrativa, e substitui as antigas Application Access Policies. Um ecrã de reserva de salas pode ler os calendários de doze caixas de correio de salas e mais nada. Uma armadilha: as concessões feitas desta forma somam-se a qualquer concessão ao nível do tenant no Microsoft Entra, pelo que, se Mail.Read ainda tiver consentimento aí, o seu âmbito não restringe nada. Retire a concessão no Entra.

Sempre que possível, use certificados em vez de segredos de cliente para autenticar a aplicação, e mantenha as credenciais fora dos scripts e dos repositórios.

A sincronização e as notificações reconstroem-se, não se traduzem

É normalmente a maior mudança para tudo o que mantém uma cópia local dos dados da caixa de correio.

Sincronização. SyncFolderItems corresponde à delta query de mensagens do Graph, e SyncFolderHierarchy à delta query de pastas de correio. A delta de mensagens funciona uma pasta de cada vez, pelo que sincronizar uma caixa de correio inteira obriga a acompanhar a árvore de pastas e a guardar um delta link separado por pasta. A filtragem é limitada (apenas pela data de receção), e os resultados incluem eliminações, saídas da pasta e alterações do estado de leitura, mesmo quando não correspondem ao seu filtro.

Notificações. As subscrições de streaming e push do EWS passam a ser change notifications do Graph, entregues num webhook gerido por si ou no Azure Event Hubs ou Event Grid. Um webhook tem de estar acessível do lado da Microsoft, o que é uma mudança de arquitetura para um script que mantinha uma ligação aberta por trás da firewall. As subscrições de correio, calendário e contactos duram no máximo 10 080 minutos (pouco menos de sete dias), ou 1 440 minutos quando a notificação transporta os dados, pelo que alguma coisa tem de as renovar. Cada caixa de correio admite no máximo 1 000 subscrições ativas, somando todas as aplicações.

O padrão que resiste: trate uma notificação como um indício, execute a delta query para ver o que mudou e execute-a também com um temporizador, para apanhar o que uma notificação perdida teria deixado escapar.

Dados, identificadores e débito

• Identificadores guardados. Se o seu CRM ou sistema de tickets guardou identificadores de itens do EWS para associar emails a registos, essas ligações têm de ser convertidas. O Graph tem uma função translateExchangeIds precisamente para isto. Planeie a conversão como um passo de migração autónomo.
• Pesquisas. ResolveNames corresponde à People API, GetUserAvailability a getSchedule, as definições de ausência às definições da caixa de correio. Equivalentes próximos, não idênticos.
• Limitação de pedidos. O Graph limita cada par aplicação e caixa de correio a 10 000 pedidos por 10 minutos, quatro pedidos em simultâneo e 150 MB de carregamentos por 5 minutos. Uma tarefa em massa que corria dezenas de threads EWS em paralelo contra uma caixa de correio tem de ser redesenhada em função destes números.

As lacunas, e o que nunca vai chegar

A Microsoft publica um roteiro das capacidades do EWS que ainda faltam no Graph. Inclui importação e exportação com fidelidade total para caixas de correio de arquivo, de pastas públicas e de grupos, acesso aos arquivos in-place, permissões de pastas através da Exchange Admin API e criação de mensagens que não sejam rascunhos a partir de MIME. A maior parte está prevista para o quarto trimestre de 2026. Três estavam previstas para o terceiro trimestre, que já terminou: a API de notas ficou disponível de forma geral no Graph em agosto de 2026, e as listas de contactos pessoais estão em pré-visualização (beta) desde junho de 2026. Quanto ao resto, confirme o que foi efetivamente lançado antes de desenhar a solução à volta disso. O aviso da própria Microsoft: se uma capacidade não está no roteiro, «don't plan on» um equivalente no Graph antes de o EWS ser desligado.

Há três capacidades confirmadas que nunca vão chegar ao Graph:

• Acesso genérico a pastas públicas (criar, ler, atualizar e eliminar pastas e itens).
• Acesso genérico a caixas de correio de grupos do Microsoft 365. Em vez disso, o Graph cobre as conversas, os tópicos e as publicações dos grupos.
• Acesso a caixas de correio de deteção. A Microsoft remete, em vez disso, para o Purview eDiscovery.

Se uma ferramenta depende de uma destas, portar o código não basta: os dados ou o fluxo de trabalho têm primeiro de passar para outro sítio, e isso demora mais do que uma reescrita.

Um plano de seis meses

De hoje até 1 de abril de 2027 vão pouco menos de seis meses. Uma ordem realista:

Outubro de 2026: perceber onde está. Verifique EWSEnabled e a lista de permissões. Exporte 90 dias do relatório de utilização. Reveja a lista que a Microsoft preencheu, retire o que lá não devia estar e acrescente as tarefas pouco frequentes que conhece. Se o seu tenant continua em Null, pondere definir a lista e o valor True por iniciativa própria, em vez de esperar que a Microsoft mude para False e descobrir então o que deixa de funcionar.

Novembro de 2026: triagem. Atribua um responsável e uma resposta (desativar, atualizar, reescrever, redesenhar) a cada identificador de aplicação. Analise o código. Assinale tudo o que toque em pastas públicas, caixas de correio de grupos ou caixas de correio de deteção e comece já o redesenho. Crie os registos de aplicação no Graph com permissões delimitadas.

Dezembro de 2026 a janeiro de 2027: desenvolvimento. Comece pela integração cuja falta o negócio sentiria primeiro. Construa uma vez a infraestrutura de sincronização e notificações e reutilize-a. Converta os identificadores guardados.

Fevereiro de 2027: as duas versões em paralelo. Enquanto o EWS ainda funciona, corra a versão antiga e a nova sobre as mesmas caixas de correio e compare os resultados. À medida que cada uma é aceite, retire o respetivo identificador da lista de permissões. Esse é também o teste: espere as 24 horas e confirme que nada mais parou.

Março de 2027: desligue o EWS por iniciativa própria. Defina EWSEnabled como False bem antes de 1 de abril. Tudo o que lhe tenha escapado falha enquanto ainda pode voltar a ligar o EWS. Depois de 1 de abril, essa opção desaparece. Faça também, antes disso, um teste deliberado às tarefas trimestrais e anuais: uma tarefa que corre no fecho do primeiro trimestre vai correr pela primeira vez já sem o EWS.

Onde obter ajuda

O caso difícil é a integração cujo programador original já saiu. O nosso serviço de manutenção de sistemas legados foi pensado para isso: lemos o código existente, reescrevemos as partes do EWS para o Microsoft Graph (permissões, sincronização, notificações, migração de identificadores) e corremos a versão antiga e a nova em paralelo até os números baterem certo. Se precisar de engenheiros a trabalhar dentro da sua própria equipa, consulte o nosso serviço de reforço de equipas.

Se o seu relatório de utilização está cheio de identificadores de aplicação que ninguém reconhece, escreva para office@c9group.dev.