Tu copia de Exchange Online depende de un campo de texto

Microsoft encendió el interruptor hoy. Desde el 10 de octubre, en su nube multi-tenant, un tenant con EwsEnabled en $true y la lista de aplicaciones permitidas vacía deja de dejar pasar a todas y pasa a no dejar pasar a ninguna. El 2 de octubre Microsoft anotó qué tenants estaban en ese estado, y el 8 y el 9 les escribió la lista poniendo dentro las aplicaciones a las que había visto usar EWS en los 60 días anteriores. Si copias los buzones de Microsoft 365, tu copia depende desde hoy de una lista que probablemente no escribiste tú. Y del parámetro que la guarda conviene saber una cosa: la documentación lo declara como <String>.

El calendario de esta semana

El equipo de Exchange publicó el 1 de octubre el detalle día a día. El 2 de octubre, al cierre del día en hora del Pacífico, Microsoft anota la lista de tenants con EwsEnabled en $true y sin EwsAllowedAppIDs. Entre el 8 y el 9, también al cierre del día, crea esa lista y la rellena con los identificadores de aplicación vistos usando EWS en los 60 días previos. Y a partir del 10 de octubre activa la configuración que exige que la lista esté presente si EwsEnabled está en $true. Esto último, de momento, solo en la nube mundial multi-tenant: las demás nubes recibirán su calendario por el centro de mensajes.

La tabla de comportamiento que publicó el aviso MC1447678 en agosto queda, a partir de hoy, en cuatro estados. Con EwsEnabled en $true y lista escrita, pasan solo las aplicaciones de la lista; es el único estado en el que decides tú. Con $true y lista vacía, se bloquea todo salvo las relaciones entre organizaciones. Con $false, se bloquea todo, como siempre. Y sin valor asignado, que según Veeam es donde está la mayoría de tenants, el tenant queda dentro del apagado por fases que Microsoft ejecuta a su ritmo. Más lejos queda la última fecha: el 1 de abril de 2027, cuando EWS se retira del todo.

La lista que tienes puesta puede que no sea tuya

Ese relleno automático es el detalle que cambia la conversación. Veeam lo resume en su artículo KB4820: Microsoft rellena previamente la lista según el uso de EWS observado en cada tenant, pero solo en los tenants donde no estaba ya configurada. El criterio es lo que se vio funcionando en 60 días, así que la lista describe el pasado reciente de tu tenant con bastante fidelidad y no describe nada más.

Para una copia de buzones diaria esto juega a favor: si el trabajo corría, la aplicación estaba dentro de esos 60 días y debería estar en la lista. La palabra importante es «debería». La parte de quién usa EWS en tu casa y cómo se inventaría la contamos en el post de agosto sobre la fecha límite real, cuando la lista todavía se podía escribir con calma.

El parámetro no admite añadir ni quitar

En la sintaxis de Set-OrganizationConfig, EwsBlockList figura como <MultiValuedProperty> y EwsAllowedAppIDs como <String>. Para las listas antiguas, Microsoft documenta la sintaxis @{Add="Valor1"; Remove="Valor2"}, que añade y quita sin tocar lo demás. Para la nueva no hay equivalente, y el propio fabricante lo dice con todas las letras en su anuncio: el cmdlet no admite operaciones incrementales de añadir o quitar, y escribir la propiedad escribe el valor completo, de modo que los identificadores que ya hubiera quedan reemplazados salvo que los incluyas en la nueva orden.

El patrón que publica Microsoft para modificarla es leer la lista actual, calcular la nueva y escribirla entera. Funciona perfectamente mientras lo haga alguien que sabe lo que hay dentro. El día que haya que dar de alta la herramienta de migración de correo con prisa y se escriba solo ese identificador, el de tu copia desaparece: sin aviso, sin error y sin que nadie haya querido hacerlo.

Comprobarla tiene truco

El comando que cualquiera escribiría, Get-OrganizationConfig | Format-List EwsAllowedAppIDs, devuelve el campo vacío aunque la lista esté configurada. Hay que pedirla con un conmutador: Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs. Microsoft lo documenta en la descripción del parámetro y en el blog del equipo de Exchange, donde además explica el porqué: se exige por razones de rendimiento. Donde no está es en la página de referencia de Get-OrganizationConfig, consultada hoy con fecha de revisión del 27 de febrero de 2026, cuya sintaxis solo admite -DomainController y cuyo ejemplo de EWS enseña las listas antiguas.

En el foro de Veeam hay un hilo de septiembre con dos administradores que llegaron con el mismo susto: la lista configurada y la consulta en blanco. Lo que acabó devolviéndoles los valores no fue el conmutador a secas sino -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs. Conviene tenerlo a mano antes de concluir que la lista no está.

Los relojes tampoco van iguales. Según el equipo de Exchange, los cambios en EwsAllowedAppIDs tardan 24 horas en surtir efecto, porque los servidores refrescan su caché en memoria una vez al día, mientras que un cambio en EwsEnabled suele aplicarse en menos de una hora, con picos de hasta cuatro. Una prueba hecha diez minutos después de tocar la lista no demuestra nada, y empuja a tocar otra vez lo que ya estaba bien.

Y queda una frase de la documentación que hoy significa lo contrario de lo que parece: para quitar la restricción por identificador de aplicación, dice, se le pasa $null al parámetro. Con el interruptor encendido y EwsEnabled en $true, un tenant sin lista bloquea todo. La salida de emergencia documentada cierra la puerta.

Qué parte de tu copia cuelga de ese campo

Veeam mantiene un artículo específico, el KB4820, publicado el 25 de marzo de 2026 y modificado por última vez el 7 de octubre. Afecta a Veeam Backup for Microsoft 365 —recomiendan la versión 8.6 o posterior— y a Veeam Data Cloud for Microsoft 365. La frase que importa es corta: una vez bloqueado el acceso EWS en tu tenant, las copias de los buzones de Exchange Online fallan. Nosotros gestionamos copias con Veeam y con Proxmox Backup Server, así que esto no lo leemos como noticia de sector sino como una tarea.

El mismo artículo explica por qué sigue habiendo EWS por medio en 2026, y lo explica con nombre: lo que falta en Graph es el soporte de sincronización diferencial que necesitan las copias incrementales. Microsoft mantiene además un mapa público de huecos de paridad con el estado de cada pieza. No es una elección de Veeam ni pereza de nadie; son dos calendarios que no están sincronizados.

El agujero que deja el corte

Cuando se restablece el acceso, dice el KB4820, el primer trabajo hace una sincronización completa —más lenta que un incremental normal, aunque ocupe lo mismo— y los buzones que no se copiaron durante el corte quedan con una ventana de cobertura ausente en su historial de restauración. Los días bloqueados no se rellenan solos. El trabajo vuelve a salir en verde mañana y ese verde es cierto hacia delante, pero a la semana pasada no se vuelve: si alguien pide el buzón de una persona tal y como estaba el martes y el martes cae dentro del agujero, ese punto de restauración no existe.

Esto convierte un ajuste de PowerShell en un asunto de continuidad y cumplimiento. Si tu documento de continuidad promete un punto de recuperación de 24 horas para el correo, el día que la lista se quede corta ese número deja de ser cierto y nadie va a enviar un correo avisándote. Se parece a lo que vimos con el Backup de Microsoft 365 cuando se activa casilla a casilla: lo que no está marcado no está copiado, y el informe no distingue entre «no había nada» y «no se miró».

La capa de abajo no entiende de identificadores

Si la copia falla para tres buzones de cuatrocientos, no mires el tenant. Cada buzón tiene su propio EwsEnabled, con valor por defecto $true, y su propia política de aplicaciones permitidas o bloqueadas, escrita en cadenas de agente de usuario y no en identificadores de Entra. La documentación precisa que el valor del buzón solo es relevante si el de la organización no está en $false; qué ocurre en el sentido contrario no lo dice. Preguntado exactamente eso en su foro, el gestor de producto de Veeam respondió que esperaría que un $false de buzón siguiera cerrando el acceso, y que iba a confirmarlo con el equipo de alianzas. Cuando la mejor respuesta disponible es «esperaría», conviene probarlo en un buzón antes que en cuatrocientos.

La pregunta del 2 de abril de 2027

La lista de permitidos es una prórroga. El 1 de abril de 2027 EWS se apaga del todo y esa fecha no tiene casilla que la desactive, así que el día siguiente es el que conviene tener pensado. El hueco de Graph tiene nombre y tiene mapa, como decíamos; lo que no existe en ninguna página pública es la frase que diga qué copia los buzones de Exchange Online si ese mapa se desliza un trimestre.

A nuestros proveedores les estamos preguntando eso mismo, y cabe en un correo: qué fecha interna manejáis para la sincronización diferencial, y qué plan hay si llega abril de 2027 sin ella. Una respuesta vaga a esa pregunta también es información.

Comprobaciones que caben en una mañana

• Lee la lista con el conmutador documentado y, si sale en blanco, repítelo con Select-Object -ExpandProperty EwsAllowedAppIDs antes de concluir nada. EwsEnabled se lee aparte. Guarda esa salida antes de tocar: es la copia de seguridad de la lista, y no hay otra.
• Mira qué te escribió Microsoft el 8 o el 9 y cotéjalo con el informe de uso de EWS. Lo que interesa son las aplicaciones que no corrieron en los últimos 60 días, que son las que faltan por definición; y las de Microsoft cuentan, porque también se bloquean.
• Confirma que el identificador de tu herramienta de copia está dentro, y deja escrito en el procedimiento que cualquier cambio en ese parámetro se hace leyendo, recomponiendo y escribiendo la lista entera. Esa nota vale más que el comando.
• Si falla un subconjunto de buzones y no todos, baja al buzón: Get-CASMailbox -Identity <buzón> | Format-List Ews*.
• Y mira hacia atrás, no solo hacia delante: comprueba si hay días sin punto de restauración en los buzones durante esta semana. Es la comprobación que nadie hace, porque el panel solo enseña el último trabajo.

Lo que no haríamos: escribir el parámetro sin haber guardado antes el valor anterior, porque no hay deshacer y lo que borras no sale en ningún registro que vayas a mirar. Tampoco daríamos el asunto por cerrado porque el trabajo salga verde al día siguiente, que es mirar el lado del calendario que ya está arreglado. Y no dejaríamos esta dependencia sin fecha de revisión, teniendo una caducidad publicada y pendiente de resolver en abril de 2027.

Un campo de texto delante de tu copia

Lo que nos llama la atención no es el apagado de una API vieja, que llevaba años anunciado y tiene su lógica. Es que la pieza de la que depende hoy la copia de los buzones de cualquier tenant de Exchange Online sea un campo de texto sin historial, sin dueño declarado y sin operación de añadir, rellenado automáticamente hace dos días con una foto de 60 días. Si administras Microsoft 365, ese campo acaba de entrar en tu lista de cosas críticas, y es de las que no suelen estar en ningún inventario.

Fuentes: blogs del equipo de Exchange en Microsoft Tech Community, «Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement» y «EWS Deprecation Is Here – What This Means To You» (este último del 1 de octubre de 2026), de donde salen el calendario del 2, del 8-9 y del 10 de octubre, la limitación a la nube mundial multi-tenant, el relleno automático con los 60 días previos, la falta de operaciones incrementales de añadir o quitar, el patrón de leer-recomponer-escribir, el conmutador de consulta y su motivo, y los tiempos de 24 horas y de menos de una hora. Aviso del centro de mensajes MC1447678, del 5 de agosto de 2026, para la tabla de comportamiento y la excepción de las relaciones entre organizaciones. Referencias de Microsoft Learn de Set-OrganizationConfig, Get-OrganizationConfig y Set-CASMailbox (tipos de los parámetros, sintaxis @{Add=…}, cadenas de agente de usuario, valor por defecto del buzón y la nota sobre $null), consultadas el 10 de octubre de 2026. Artículo KB4820 de Veeam, «What Microsoft's EWS Retirement Means for Your Veeam Backups», publicado el 25 de marzo de 2026 y modificado el 7 de octubre de 2026: productos y versiones, fallo de las copias, sincronización completa con ventana de cobertura ausente en el historial de restauración, relleno automático solo donde no había lista, y la sincronización diferencial como capacidad pendiente de Graph. Hilo público de los foros de Veeam sobre EwsAllowedAppIDs, de septiembre de 2026, para la consulta que sí devuelve los valores y para la respuesta del gestor de producto sobre el nivel de buzón. No hemos verificado ningún dato de este artículo contra tenants de clientes: todo lo anterior es documentación pública.