O que a desativação do EWS pela Microsoft significa para a sincronização de calendários
O Exchange Web Services começa a ser desligado em 1º de outubro de 2026 e sai do ar de vez em 1º de abril de 2027. Veja o que realmente para de funcionar, o que não é afetado e as duas configurações de tenant que definem em qual grupo você está.
A Microsoft está desativando o Exchange Web Services (EWS) no Exchange Online. A desativação começa globalmente em 1º de outubro de 2026, e o EWS é desligado por completo em 1º de abril de 2027. A sincronização de calendários que roda sobre o Microsoft Graph não é afetada. O que para de funcionar é o livre/ocupado entre organizações parceiras (cross-tenant), as caixas de correio com licenças Kiosk, F1 e F3, e qualquer aplicativo de terceiros que ainda chame o EWS.
Resumindo: se o seu tenant estiver hoje com EWSEnabled definido como Null, a Microsoft vai mudá-lo para False em 1º de outubro de 2026, e todo aplicativo dependente de EWS no seu tenant deixará de funcionar naquele dia. Null é o padrão atual, portanto não fazer nada também é uma decisão.
A linha do tempo, com datas
Quatro coisas acontecem em quatro datas diferentes. Elas costumam ser noticiadas como um único evento, e é por isso que tantos administradores têm o prazo errado em mente.
| Data | O que acontece | Quem é afetado |
|---|---|---|
| 1º de setembro de 2026 | O livre/ocupado entre tenants, o MailTips e o Calendar Sharing concluem a migração do EWS para a Cross-Tenant Access Policy do Microsoft 365. A implantação começou em agosto de 2026. | Organizações que compartilham disponibilidade com tenants parceiros |
| 1º de outubro de 2026 | O EWS começa a ser desativado globalmente. Tenants ainda definidos como Null passam para False. A partir dessa data, o acesso ao EWS também exige uma lista de permissões preenchida. | Todo tenant que não tiver agido |
| 1º de outubro de 2026 | Caixas de correio licenciadas como Kiosk, F1 e F3 perdem totalmente o acesso ao EWS. As requisições retornam HTTP 403. Nenhuma entrada na lista de permissões as isenta. | Trabalhadores de linha de frente e de quiosque |
| 1º de abril de 2027 | O EWS é desativado por completo. Nenhuma lista de permissões, licença ou configuração o mantém em funcionamento. | Todos |
A Microsoft anunciou pela primeira vez em 2018 que o EWS deixaria de receber atualizações de funcionalidade e, em 2023, definiu outubro de 2026 como a data de desativação. O incidente Midnight Blizzard, em janeiro de 2024, envolveu o EWS e ampliou o escopo, que passou dos aplicativos de terceiros para os próprios produtos da Microsoft — e é por isso que Outlook, Office, Teams e Dynamics 365 também estão sendo migrados para fora dele.
As duas configurações que decidem tudo
A desativação do EWS é controlada por duas propriedades no nível do tenant, e é na interação entre elas que as organizações são pegas de surpresa.
EWSEnabled
Ela tem três valores: True, False e Null. Null é o padrão hoje e atualmente se comporta como True. Em 1º de outubro de 2026, à medida que a implantação alcança o seu tenant, Null é alterado para False. Essa única mudança bloqueia o EWS para todos os aplicativos do tenant de uma só vez.
Se você ainda tiver um aplicativo que realmente precise do EWS entre outubro de 2026 e abril de 2027, será necessário definir explicitamente EWSEnabled como True. Manter o padrão não é o mesmo que deixar tudo como está.
EWSAllowedAppIDs
Definir EWSEnabled como True já não basta por si só. A partir de 1º de outubro de 2026, você também precisa de uma lista de permissões preenchida com os App IDs autorizados a chamar o EWS. Se faltar qualquer uma das duas metades, o EWS para para tudo que depende dele.
A Microsoft está pré-preenchendo essa lista antes de setembro de 2026 para os tenants que ainda não montaram a sua, com base no uso observado em cada tenant. Isso ajuda, mas a lista é construída a partir do que o seu tenant chamou recentemente. Um aplicativo que roda trimestralmente, ou que ficou ocioso durante a janela de amostragem, pode estar ausente de uma lista que você supõe estar completa.
Como verificar o seu próprio tenant
Conecte-se ao Exchange Online PowerShell e leia o estado atual antes de planejar qualquer coisa:
Get-OrganizationConfig | Format-List EWSEnabled, EWSAllowedAppIDs, EWSApplicationAccessPolicy, EWSAllowList, EWSBlockList
Depois descubra se algo de fato está chamando o EWS. Os Relatórios de Uso do EWS no centro de administração do Microsoft 365 mostram o tráfego real por aplicativo, o que é mais confiável do que perguntar internamente.
Se você compartilha disponibilidade com organizações parceiras, verifique as três configurações que dependem do EWS por baixo:
Get-OrganizationRelationship | Format-List Name, DomainNames, FreeBusyAccessEnabled
Get-AvailabilityAddressSpace | Format-List Name, ForestName, AccessMethod
Get-SharingPolicy | Format-List Name, Domains, Enabled
Resultados vazios nos três casos significam que a parte cross-tenant não se aplica a você. A Microsoft enviou o aviso do centro de mensagens a todos os tenants, então um grande número de administradores recebeu um alerta sobre algo que não utiliza.
O que para de funcionar e o que não para
A distinção que importa é se a ferramenta conversa com o Exchange Online por meio do EWS ou do Microsoft Graph. O Graph é a API substituta e não é afetado por nenhuma das datas acima.
| Recurso | Situação depois de outubro de 2026 |
|---|---|
| Sincronização de calendários construída sobre o Microsoft Graph | Não é afetada |
| Livre/ocupado entre tenants via Organization Relationship | Precisa migrar para a Cross-Tenant Access Policy |
| MailTips e compartilhamento de calendário entre tenants | Precisa migrar para a Cross-Tenant Access Policy |
| Qualquer caixa de correio somente com Kiosk, F1 ou F3 | EWS bloqueado, sem isenção disponível |
| Aplicativos de terceiros que ainda chamam o EWS | Bloqueados, a menos que estejam na lista de permissões — e apenas até abril de 2027 |
| Scripts internos legados que usam a EWS Managed API | Precisam ser reescritos para o Graph |
Isso afeta o CalendarBridge?
Não. O CalendarBridge se conecta ao Microsoft 365 pelo Microsoft Graph, usando os escopos delegados Calendars.ReadWrite e User.Read. Ele não tem nenhuma dependência de EWS, portanto nada nas datas de outubro de 2026 ou abril de 2027 muda o comportamento das suas conexões de sincronização, e o CalendarBridge não precisa de uma entrada na sua lista de permissões EWSAllowedAppIDs.
Se você está auditando fornecedores antes do prazo, esta é a pergunta que vale a pena fazer a cada um deles: Graph ou EWS? Qualquer ferramenta de calendário que ainda esteja no EWS tem uma parada definitiva marcada para abril de 2027 e uma migração a concluir antes disso.
Como migrar, conforme o que você realmente tem
Não existe uma migração única. O que fazer depende de qual das quatro situações acima se aplica a você, e a maioria das organizações se enquadra em mais de uma.
| Se você tem | Faça isto | Prazo |
|---|---|---|
| Scripts ou aplicativos internos que chamam o EWS | Reescreva-os para o Microsoft Graph. Use o EWS Analyzer para localizar as chamadas e os mapeamentos publicados de operações EWS para Graph para traduzi-las. | 1º de abril de 2027 — e inclua-os na lista de permissões antes de 1º de outubro de 2026 para ganhar esse tempo |
| Livre/ocupado entre tenants com uma organização parceira | Migre a Organization Relationship para a Cross-Tenant Access Policy ou substitua a consulta por uma sincronização de calendários. As duas opções são detalhadas abaixo. | 1º de setembro de 2026 |
| Uma ferramenta de terceiros que usa o EWS | Peça ao fornecedor, por escrito, a data de migração para o Graph. Se não houver uma, planeje a substituição agora, e não em março de 2027. | 1º de abril de 2027 |
| Usuários Kiosk, F1 ou F3 em uma ferramenta baseada em EWS | Mude-os para uma licença com direitos de EWS ou para uma ferramenta que não precise de EWS. A lista de permissões não ajuda nesse caso. | 1º de outubro de 2026 |
Substituir o livre/ocupado entre tenants por sincronização de calendários
A parte cross-tenant é a que tem mais chance de chegar aos usuários comuns de calendário, e vale entender a escolha em vez de optar pela migração equivalente por padrão.
A Cross-Tenant Access Policy mantém o modelo atual: um tenant consulta o outro em tempo real sempre que alguém abre o assistente de agendamento. Ela preserva as consultas ao vivo e é a resposta certa se você precisa de disponibilidade realmente atualizada ao segundo entre organizações. O custo é que você está migrando uma configuração de confiança entre tenants, e os dois tenants precisam mantê-la saudável depois disso.
A sincronização de calendários inverte o modelo. Em vez de consultar o tenant parceiro, o CalendarBridge copia os eventos para um calendário no seu próprio tenant, onde eles se comportam como quaisquer outros eventos. Eles bloqueiam horário, aparecem no assistente de agendamento e no Find a Time, e sobrevivem ao que quer que aconteça com a relação entre os dois tenants, porque não há consulta ao vivo que possa quebrar.
A sincronização costuma ser a melhor escolha quando o requisito é que as pessoas consigam ver quando seus colegas de outra organização estão comprometidos. A Cross-Tenant Access Policy é a melhor escolha quando você precisa de precisão em tempo real ou de visibilidade bidirecional real dos detalhes do calendário do parceiro.
Configurando para você mesmo
- Conecte as duas contas ao CalendarBridge. As contas do Microsoft 365 se conectam por OAuth usando os escopos delegados do Graph
Calendars.ReadWriteeUser.Read, portanto não há envolvimento de EWS nem necessidade de entrada na lista de permissões. - Crie uma sincronização unidirecional do calendário do parceiro ou secundário para o calendário em que você realmente trabalha.
- Nas configurações de privacidade da conexão de sincronização, deixe Subject, Description, Location e Attendees desmarcados, para que cada cópia seja um simples bloco de ocupado. Marque também All Private se quiser que as cópias apareçam como ocupado no Outlook Scheduling Assistant e no Google Find a Time.
Configurando para toda a organização
Se você está substituindo uma Organization Relationship que atendia a uma empresa inteira, o caminho são as sincronizações gerenciadas, em vez de pedir que cada usuário configure a sua:
- Crie uma conta de grupo com licenças de sincronização em vez de licenças de usuário.
- Autorize o acesso para sincronizações gerenciadas em cada tenant que hospeda calendários de que você precisa. No Microsoft 365, isso é uma concessão de permissão de aplicativo feita por um administrador do tenant, novamente sobre o Graph.
- Conecte os domínios autorizados à conta de grupo, uma vez por tenant.
- Crie as conexões de sincronização gerenciadas. Abaixo de vinte, atribua-as individualmente. A partir de vinte, use um trabalho em lote para importar toda a lista de mapeamentos de uma só vez.
Como isso roda sobre permissões de aplicativo concedidas pelo administrador de cada tenant, não depende de uma Organization Relationship, de um Availability Address Space nem de uma Sharing Policy. Nenhuma das três configurações que estão sendo migradas em setembro de 2026 está no caminho.
Se você só precisa publicar a disponibilidade
Algumas relações entre tenants existem apenas para que alguém de fora possa ver quando as suas pessoas estão livres. Para isso, um feed de calendário público é mais simples do que qualquer uma das opções acima. Escolha os calendários, desative todos os campos de detalhe e compartilhe o link resultante ou a URL de assinatura ICS. O destinatário não precisa de um tenant do Microsoft 365, de uma relação com o seu, nem de conta alguma. Veja como sincronizar calendários sem compartilhar os detalhes dos eventos para a versão campo a campo.
Qualquer que seja o caminho escolhido, faça primeiro o levantamento. Execute Get-OrganizationRelationship antes de planejar uma migração cross-tenant. Boa parte dos tenants que receberam esse aviso do centro de mensagens não tem nenhum compartilhamento entre tenants configurado e não precisa fazer nada em relação à data de setembro.
O que fazer nas próximas seis semanas
- Verifique o estado atual. Execute o comando
Get-OrganizationConfigacima e anote qual é hoje o valor deEWSEnabled. - Puxe o relatório de uso. Descubra o que realmente chama o EWS, em vez de confiar na memória da organização.
- Verifique as configurações cross-tenant. Se
Get-OrganizationRelationshipnão retornar nada, você pode parar de se preocupar com a data de setembro. - Audite a atribuição de licenças. Usuários Kiosk, F1 e F3 perdem o EWS sem isenção. Se algum deles depende de uma ferramenta baseada em EWS, precisará de outra licença.
- Faça aos seus fornecedores a pergunta do Graph. Obtenha a resposta por escrito e trate vagueza como uma resposta.
A lista de permissões é uma ponte, não um destino. Tudo o que você acrescentar a ela em outubro de 2026 ainda deixará de funcionar em abril de 2027, então use a janela para migrar, e não para adiar.
Perguntas frequentes
Quando exatamente o EWS para de funcionar?
O EWS começa a ser desativado globalmente em 1º de outubro de 2026 e é totalmente desativado em 1º de abril de 2027. Entre essas datas, o EWS só continua funcionando se o tenant tiver EWSEnabled definido como True e o App ID do aplicativo que faz as chamadas estiver na lista de permissões EWSAllowedAppIDs. Depois de 1º de abril de 2027, nenhuma configuração o mantém no ar.
Minha sincronização de calendários vai parar de funcionar com a desativação do EWS?
Apenas se a sua ferramenta de sincronização de calendários usar o EWS. Ferramentas construídas sobre o Microsoft Graph não são afetadas, porque o Graph é a API substituta e não uma vítima da desativação. O CalendarBridge usa o Microsoft Graph e não precisa de entrada na lista de permissões nem de qualquer mudança de configuração.
O que acontece se eu não fizer nada antes de 1º de outubro de 2026?
Os tenants que ainda tiverem EWSEnabled definido como Null terão o valor alterado para False conforme a implantação os alcança, o que bloqueia o EWS para todos os aplicativos do tenant. Null é o padrão atual, então a maioria dos tenants que não tomar nenhuma providência será desligada automaticamente.
A desativação do EWS afeta o livre/ocupado entre tenants?
Sim. O livre/ocupado entre tenants, o MailTips e o Calendar Sharing configurados por Organization Relationship, Availability Address Space ou Sharing Policy funcionam todos sobre o EWS. A Microsoft está migrando esses recursos para a Cross-Tenant Access Policy do Microsoft 365, com implantação iniciada em agosto de 2026 e conclusão até 1º de setembro de 2026.
Caixas de correio Kiosk, F1 e F3 podem manter o acesso ao EWS?
Não. A partir de 1º de outubro de 2026, as requisições EWS de caixas de correio que tenham apenas licenças Exchange Online Kiosk, Microsoft 365 F1 ou Office 365 F3 retornam HTTP 403. A lista de permissões não as isenta. Esses usuários precisam de uma licença que inclua direitos de EWS, como Exchange Online Plan 1 ou 2, ou Microsoft 365 E3 ou E5.
Como descubro quais aplicativos ainda usam o EWS?
Use os Relatórios de Uso do EWS no centro de administração do Microsoft 365, que mostram o tráfego real de EWS detalhado por aplicativo. A Microsoft também publica a ferramenta EWS Analyzer para varrer código interno em busca de chamadas ao EWS.
Fontes
Linha do tempo e funcionamento verificados na documentação da própria Microsoft: Deprecation of Exchange Web Services in Exchange Online, Exchange Online EWS, Your Time is Almost Up, Introducing EWSAllowedAppIDs e Migrate to Microsoft 365 Cross-Tenant Access Policy. Referências do centro de mensagens: MC1446796, MC1227454, MC1191578.
Uma migração a menos na sua lista de outubro
O CalendarBridge sincroniza calendários do Google, do Microsoft 365, do iCloud e CalDAV por meio do Microsoft Graph, portanto a desativação do EWS não muda nada nas suas conexões de sincronização. Sem entrada em lista de permissões, sem mudança de configuração, sem prazo.
Iniciar teste gratuito