Qué significa la retirada de EWS por parte de Microsoft para la sincronización de calendarios

Exchange Web Services empieza a desactivarse el 1 de octubre de 2026 y deja de funcionar por completo el 1 de abril de 2027. Esto es lo que realmente deja de funcionar, lo que no, y las dos opciones del tenant que determinan en qué grupo estás.

Microsoft está retirando Exchange Web Services (EWS) en Exchange Online. La desactivación comienza a nivel global el 1 de octubre de 2026 y EWS se apaga por completo el 1 de abril de 2027. La sincronización de calendarios que funciona sobre Microsoft Graph no se ve afectada. Lo que deja de funcionar es la disponibilidad libre/ocupado entre tenants de organizaciones asociadas, los buzones con licencias Kiosk, F1 y F3, y cualquier aplicación de terceros que siga llamando a EWS.

El calendario, con fechas

Ocurren cuatro cosas en cuatro fechas distintas. Con frecuencia se relatan como si fueran un único evento, y por eso tantos administradores tienen en mente la fecha límite equivocada.

Microsoft anunció por primera vez en 2018 que EWS dejaría de recibir actualizaciones de funcionalidad, y en 2023 fijó la fecha de desactivación de octubre de 2026. El incidente de Midnight Blizzard de enero de 2024 tuvo que ver con EWS y amplió el alcance de las aplicaciones de terceros a los propios productos de Microsoft, y por eso Outlook, Office, Teams y Dynamics 365 también se están migrando fuera de él.

Las dos opciones que lo deciden todo

La desactivación de EWS se controla mediante dos propiedades a nivel de tenant, y es en la interacción entre ambas donde las organizaciones se ven sorprendidas.

EWSEnabled

Admite tres valores: True, False y Null. Hoy el valor predeterminado es Null, y actualmente se comporta como True. El 1 de octubre de 2026, a medida que el despliegue llegue a tu tenant, Null se cambia a False. Ese único cambio bloquea EWS de golpe para todas las aplicaciones del tenant.

Si todavía tienes una aplicación que realmente necesita EWS entre octubre de 2026 y abril de 2027, debes establecer explícitamente EWSEnabled en True. Dejarlo con el valor predeterminado no equivale a dejar las cosas como están.

EWSAllowedAppIDs

Establecer EWSEnabled en True ya no basta por sí solo. A partir del 1 de octubre de 2026 también necesitas una lista de permitidos con contenido que indique los App ID autorizados a llamar a EWS. Si falla cualquiera de las dos mitades, EWS deja de funcionar para todo lo que dependa de él.

Microsoft está rellenando previamente esta lista antes de septiembre de 2026 para los tenants que no hayan creado una, basándose en el uso observado en cada tenant. Eso ayuda, pero se construye a partir de lo que tu tenant llamó recientemente. Una aplicación que se ejecuta trimestralmente, o que estuvo inactiva durante la ventana de muestreo, puede faltar en una lista que das por completa.

Cómo comprobar tu propio tenant

Conéctate a Exchange Online PowerShell y consulta el estado actual antes de planificar nada:

Get-OrganizationConfig | Format-List EWSEnabled, EWSAllowedAppIDs, EWSApplicationAccessPolicy, EWSAllowList, EWSBlockList

Después, averigua si algo está llamando realmente a EWS. Los informes de uso de EWS del centro de administración de Microsoft 365 muestran el tráfico real por aplicación, lo cual es más fiable que preguntar internamente.

Si compartes disponibilidad con organizaciones asociadas, revisa las tres configuraciones que se apoyan en EWS por debajo:

Get-OrganizationRelationship | Format-List Name, DomainNames, FreeBusyAccessEnabled
Get-AvailabilityAddressSpace | Format-List Name, ForestName, AccessMethod
Get-SharingPolicy | Format-List Name, Domains, Enabled

Si los tres devuelven resultados vacíos, la parte de los tenants cruzados no te afecta. Microsoft envió el aviso del centro de mensajes a todos los tenants, así que muchísimos administradores recibieron una advertencia sobre algo que no utilizan.

Qué deja de funcionar y qué no

La distinción que importa es si una herramienta habla con Exchange Online a través de EWS o a través de Microsoft Graph. Graph es la API sustituta y no se ve afectada en absoluto por ninguna de las fechas anteriores.

¿Afecta esto a CalendarBridge?

No. CalendarBridge se conecta a Microsoft 365 a través de Microsoft Graph, usando los ámbitos delegados Calendars.ReadWrite y User.Read. No tiene ninguna dependencia de EWS, así que nada de las fechas de octubre de 2026 o abril de 2027 cambia el funcionamiento de tus conexiones de sincronización, y CalendarBridge no necesita figurar en tu lista de permitidos EWSAllowedAppIDs.

Si estás auditando proveedores antes de la fecha límite, esa es la pregunta que merece la pena hacerle a cada uno: ¿Graph o EWS? Cualquier herramienta de calendario que siga en EWS tiene un final abrupto en abril de 2027 y una migración que completar antes de esa fecha.

Cómo migrar, según lo que realmente tengas

No existe una única migración. Lo que hagas depende de cuál de las cuatro situaciones anteriores te aplica, y la mayoría de las organizaciones tienen más de una.

Sustituir el libre/ocupado entre tenants por sincronización de calendarios

La parte de los tenants cruzados es la que más probablemente llegue a los usuarios de calendario habituales, y conviene entender bien la elección en lugar de optar por defecto por la migración equivalente.

La Cross-Tenant Access Policy mantiene el modelo actual: un tenant consulta al otro en tiempo real cada vez que alguien abre el asistente de programación. Conserva las consultas en vivo y es la respuesta correcta si necesitas disponibilidad realmente actualizada al segundo entre organizaciones. El coste es que estás migrando una configuración de confianza entre tenants y que ambos tenants deben mantenerla en buen estado después.

La sincronización de calendarios invierte el modelo. En lugar de consultar al tenant asociado, CalendarBridge copia los eventos a un calendario de tu propio tenant, donde se comportan como cualquier otro evento. Bloquean tiempo, aparecen en el asistente de programación y en Buscar una hora, y sobreviven a lo que ocurra con la relación entre los dos tenants, porque no hay ninguna consulta en vivo que pueda romperse.

La sincronización suele encajar mejor cuando el requisito es que las personas puedan ver cuándo sus homólogos tienen tiempo reservado. La Cross-Tenant Access Policy encaja mejor cuando necesitas precisión en tiempo real o visibilidad bidireccional real del detalle del calendario de un socio.

Configurarlo para ti

1. Conecta ambas cuentas a CalendarBridge. Las cuentas de Microsoft 365 se conectan mediante OAuth usando los ámbitos delegados de Graph Calendars.ReadWrite y User.Read, así que no interviene EWS ni hace falta ninguna entrada en la lista de permitidos.
2. Crea una sincronización unidireccional desde el calendario del socio o el calendario secundario hacia el calendario en el que realmente trabajas.
3. En la configuración de privacidad de la conexión de sincronización, deja sin marcar Subject, Description, Location y Attendees para que cada copia sea un simple bloque de ocupado. Marca también All Private si quieres que las copias figuren como ocupado en el Asistente de programación de Outlook y en Buscar una hora de Google.

Configurarlo para toda la organización

Si vas a sustituir una Organization Relationship que daba servicio a toda una empresa, conviene usar sincronizaciones gestionadas en lugar de pedir a cada usuario que configure la suya:

1. Crea una cuenta de grupo con licencias de sincronización en lugar de licencias de usuario.
2. Autoriza el acceso para las sincronizaciones gestionadas en cada tenant que aloje calendarios que necesites. En Microsoft 365 se trata de una concesión de permisos de aplicación por parte de un administrador del tenant, también sobre Graph.
3. Conecta los dominios autorizados a la cuenta de grupo, una vez por tenant.
4. Crea las conexiones de sincronización gestionadas. Si son menos de veinte, asígnalas una a una. Si son veinte o más, usa un trabajo masivo para importar toda la lista de asignaciones de una sola vez.

Como esto funciona con permisos de aplicación concedidos por el administrador de cada tenant, no depende de una Organization Relationship, de un Availability Address Space ni de una Sharing Policy. Ninguna de las tres configuraciones que se migran en septiembre de 2026 interviene aquí.

Si solo necesitas publicar la disponibilidad

Algunas relaciones entre tenants existen únicamente para que una parte externa pueda ver cuándo está libre tu personal. Para eso, un feed de calendario público es más sencillo que cualquiera de las dos opciones anteriores. Elige los calendarios, desactiva todos los campos de detalle y comparte el enlace resultante o la URL de suscripción ICS. El destinatario no necesita un tenant de Microsoft 365, ni una relación con el tuyo, ni ninguna cuenta. Consulta cómo sincronizar calendarios sin compartir los detalles de los eventos para la versión campo por campo.

Qué hacer en las próximas seis semanas

1. Consulta tu estado actual. Ejecuta el comando Get-OrganizationConfig anterior y anota qué valor tiene hoy EWSEnabled.
2. Descarga el informe de uso. Averigua qué está llamando realmente a EWS en lugar de fiarte de la memoria institucional.
3. Comprueba las configuraciones entre tenants. Si Get-OrganizationRelationship no devuelve nada, puedes dejar de preocuparte por la fecha de septiembre.
4. Audita la asignación de licencias. Los usuarios con Kiosk, F1 y F3 pierden EWS sin excepción posible. Si alguno depende de una herramienta basada en EWS, necesita otra licencia.
5. Haz a tus proveedores la pregunta sobre Graph. Consíguelo por escrito y considera la vaguedad como una respuesta en sí misma.

La lista de permitidos es un puente, no un destino. Todo lo que añadas a ella en octubre de 2026 dejará igualmente de funcionar en abril de 2027, así que aprovecha esa ventana para migrar, no para aplazar.

Preguntas frecuentes

¿Cuándo deja exactamente de funcionar EWS?

EWS empieza a desactivarse a nivel global el 1 de octubre de 2026 y queda totalmente desactivado el 1 de abril de 2027. Entre esas dos fechas, EWS solo puede seguir funcionando si el tenant tiene EWSEnabled en True y el App ID de la aplicación que hace la llamada figura en la lista de permitidos EWSAllowedAppIDs. Después del 1 de abril de 2027, ninguna configuración lo mantiene en funcionamiento.

¿Dejará de funcionar mi sincronización de calendarios cuando se retire EWS?

Solo si tu herramienta de sincronización de calendarios usa EWS. Las herramientas construidas sobre Microsoft Graph no se ven afectadas, porque Graph es la API sustituta y no una víctima de la retirada. CalendarBridge usa Microsoft Graph y no necesita ninguna entrada en la lista de permitidos ni ningún cambio de configuración.

¿Qué ocurre si no hago nada antes del 1 de octubre de 2026?

A los tenants que sigan con EWSEnabled en Null se les cambia a False a medida que el despliegue les alcanza, lo que bloquea EWS para todas las aplicaciones del tenant. Null es el valor predeterminado actual, así que la mayoría de los tenants que no hagan nada quedarán desactivados automáticamente.

¿Afecta la retirada de EWS al libre/ocupado entre tenants?

Sí. La disponibilidad libre/ocupado entre tenants, los MailTips y el uso compartido de calendarios configurados mediante Organization Relationship, Availability Address Space o Sharing Policy funcionan todos sobre EWS. Microsoft los está migrando a la Cross-Tenant Access Policy de Microsoft 365, con un despliegue que comenzó en agosto de 2026 y que finaliza el 1 de septiembre de 2026.

¿Pueden los buzones Kiosk, F1 y F3 conservar el acceso a EWS?

No. A partir del 1 de octubre de 2026, las solicitudes de EWS desde buzones que solo tengan licencias Exchange Online Kiosk, Microsoft 365 F1 u Office 365 F3 devuelven un HTTP 403. La lista de permitidos no los exime. Esos usuarios necesitan una licencia que incluya derechos de EWS, como Exchange Online Plan 1 o 2, o Microsoft 365 E3 o E5.

¿Cómo averiguo qué aplicaciones siguen usando EWS?

Usa los informes de uso de EWS del centro de administración de Microsoft 365, que muestran el tráfico real de EWS desglosado por aplicación. Microsoft también publica la herramienta EWS Analyzer para analizar el código interno en busca de llamadas a EWS.

Fuentes

Cronología y funcionamiento verificados con la documentación de la propia Microsoft: Deprecation of Exchange Web Services in Exchange Online, Exchange Online EWS, Your Time is Almost Up, Introducing EWSAllowedAppIDs y Migrate to Microsoft 365 Cross-Tenant Access Policy. Referencias del centro de mensajes: MC1446796, MC1227454, MC1191578.