Power Automate deja de enviar correo al restringir EWS en Exchange Online

Un administrador de sistemas ha reportado que sus flujos de Power Automate dejan de enviar correo en cuanto restringe EWS en su tenant de Exchange Online. La acción que falla es Send an email (V2), del conector Office 365 Outlook. Lo llamativo es que la documentación de Microsoft sostiene que ese conector se migró a Graph hace años y que solo "algunas" operaciones siguen sobre el protocolo antiguo, pero en ningún sitio se aclara que esta acción concreta dependa de EWS ni que vaya a romperse cuando se aplique la retirada.

El caso aparece con la configuración puesta a mano. En la salida de Get-OrganizationConfig el administrador tiene EwsEnabled en True, EwsApplicationAccessPolicy en EnforceAllowList y una EwsAllowList que incluye Azure.Connectors.Office365Outlook.Office365OutlookConnector*, Azure.Connectors.Outlook.OutlookConnector*, PowerApps/, LogicAppsDesigner/, microsoft-flow/, azure-logic-apps/, okhttp/* y Microsoft%20Teams/*. Esa lista no se la ha inventado: la sacó de la propia documentación de Microsoft sobre errores comunes del conector. Los parámetros EwsAllowOutlook, EwsAllowMacOutlook y EwsAllowEntourage están vacíos.

Dos listas de control que no encajan

La duda que plantea es si está mezclando EwsAllowList con EwsAllowedAppIDs. Para el segundo ajuste hace falta el AppID de la aplicación que quiere permitir, y ahí es donde se atasca: no encuentra ningún identificador de PowerApps en el informe del centro de administración de M365 ni en los módulos Find-EWS que ha ejecutado sobre su tenant. Tampoco le cuadra que la lista de permitidos ya contemple los patrones del conector y aun así los flujos caigan.

Su pregunta es directa: ¿basta con obtener el AppID de Power Automate y añadirlo a EwsAllowedAppIDs, o son dos mecanismos distintos que se aplican en momentos distintos del flujo de autenticación? Nadie ha respondido con una confirmación de Microsoft, solo con la configuración que ya tenía.

Esto importa más de lo que parece. Cualquiera que haya ido cerrando EWS en su organización por motivos de seguridad ha ido tirando de listas de permitidos para no romper integraciones, y aquí hay una que se rompe sin aviso claro en la documentación. Si el conector realmente usa Graph para esta acción, el fallo apunta a que el flujo sigue autenticándose por EWS en algún punto intermedio, o a que las políticas de aplicación de Exchange Online se evalúan antes de que el conector haga la llamada. Mientras Microsoft no publique la matriz de qué operaciones quedan en EWS, el camino es probar en un tenant de laboratorio y revisar uno por uno los flujos que envían correo antes de aplicar el bloqueo en producción.