Fim do EWS no Exchange Online: o que os responsáveis pelos sistemas empresariais devem verificar

Se uma aplicação empresarial depender do Exchange Web Services (EWS) no Exchange Online, identifique as funções que utiliza e confirme como irão continuar antes de aprovar a reconstrução da aplicação. Uma atualização suportada pelo fornecedor ou uma alteração à integração poderá satisfazer o requisito. A substituição de toda a aplicação passa a ser uma possibilidade quando a opção disponível não consegue suportar o trabalho de que a sua empresa necessita.

Para quem aprova o orçamento, um bom ponto de partida é um breve registo de dependências: o que faz a ligação, quem é responsável por ela, qual a opção suportada que a irá substituir e que evidências demonstrarão que a função empresarial continua a funcionar.

Compreenda o calendário e o âmbito atuais

O aviso geral da Microsoft sobre o fim do EWS descreve duas fases. A desativação, controlável pelos administradores, começou a 1 de outubro de 2026 e está a ser aplicada gradualmente, tenant a tenant. Durante esta transição, o acesso depende das definições da organização e dos controlos da aplicação, pelo que a data, por si só, não permite concluir se a ligação está atualmente bloqueada. O encerramento permanente começa a 1 de abril de 2027. A partir dessa data, os administradores deixam de poder controlar o acesso ao EWS através da definição da organização.

O aviso aplica-se ao Microsoft 365 e ao Exchange Online. O Exchange Server instalado nas instalações da organização fica fora deste processo de desativação. Peça ao responsável técnico que confirme a que ambiente se liga efetivamente a ligação afetada.

Quando permitido, o restabelecimento temporário do acesso ao EWS pode dar algum tempo durante a transição. Atribua a esta medida um responsável e uma data-limite para concluir a opção de substituição. O restabelecimento demonstra que a ligação existente pode voltar a funcionar; não demonstra que a aplicação está preparada para o encerramento permanente.

Associe a dependência técnica a um responsável operacional

Comece pelas pessoas responsáveis pelos sistemas ligados. Peça à equipa de TI provas da utilização do EWS e a cada responsável pela aplicação que explique o que faz a ligação identificada. As orientações da Microsoft sobre a desativação remetem os administradores para relatórios de utilização e ferramentas de análise.

Um identificador de aplicação é útil para quem gere o orçamento quando pode ser associado a uma função empresarial. Por exemplo, uma ligação pode atualizar marcações num sistema de gestão de horários. Se falhar, os colaboradores poderão trabalhar com um horário desatualizado. Essa consequência ajuda a definir a prioridade e quem deve aprovar o resultado.

Registe estes dados para cada dependência:

• Função e consequência: o que faz a ligação, com que frequência é importante e o que acontece se falhar.
• Aplicação e responsabilidade: o sistema, o fornecedor e a pessoa interna responsável pela sua continuidade.
• Requisito técnico: as operações ou capacidades do EWS utilizadas, bem como a caixa de correio e o ambiente envolvidos.
• Evidências de continuidade: o destino suportado proposto, a versão ou documentação do fornecedor que o abrange e quaisquer lacunas por resolver.
• Implementação e aceitação: quem fará a alteração, até quando e que teste empresarial tem de ser aprovado.

Um relatório da atividade observada ajuda a localizar uma dependência. Ainda assim, cabe ao responsável pela aplicação explicar a sua importância operacional, incluindo tarefas ocasionais, como o fecho do mês.

Verifique as capacidades da substituição proposta

O Microsoft Graph suporta muitos cenários de EWS, mas não deve presumir-se uma equivalência completa. O roteiro de capacidades da Microsoft identifica lacunas por resolver, alternativas e capacidades que não serão acrescentadas. Por exemplo, a importação e exportação de pastas públicas é distinta do acesso habitual para criar, ler, atualizar e eliminar. A opção proposta tem de abranger as operações de que a aplicação necessita.

O mesmo roteiro refere que as datas previstas de disponibilidade são indicativas e podem mudar. A presença de uma capacidade num trimestre do roteiro, mesmo que esse trimestre já tenha passado, não é prova suficiente de que foi disponibilizada. Peça ao fornecedor ou ao responsável técnico que identifique a capacidade disponível e a versão que a inclui.

Se uma atualização suportada da aplicação abranger as funções necessárias, avalie o custo, os requisitos de implementação e as evidências de aceitação. Se uma alteração à integração puder abrangê-las, avalie esse âmbito. Quando um componente necessário não tiver uma opção suportada adequada, compare outro componente, um fluxo de trabalho alterado ou outra aplicação. Baseie a comparação na função em falta e na respetiva consequência empresarial, para que a decisão tenha uma fundamentação clara.

Aprove um resultado que possa verificar

Como exemplo de teste para um sistema de gestão de agendas, crie uma marcação através do sistema ligado, altere a hora e confirme que os registos previstos são atualizados para os utilizadores pretendidos. Verifique se as permissões continuam adequadas às funções de cada pessoa. Inclua uma operação falhada e confirme que alguém responsável a consegue detetar e resolver. Acorde os resultados esperados antes de testar.

Um início de sessão bem-sucedido comprova apenas uma parte da ligação. A aceitação deve demonstrar o trabalho efetivo, incluindo um caso de falha com consequências. Junte o resultado ao registo de dependências para que quem aprova a conclusão possa ver o que foi verificado.

Se precisar de ajuda com uma ligação afetada a um sistema empresarial, descreva a aplicação e a função que desempenha. Prestamos serviços de integração de API; esse contexto permite iniciar uma conversa sobre o âmbito do trabalho necessário.