Sophos Mobile: de Exchange Server a Exchange Online

Al pasar de un Exchange Server local a Exchange Online, hay que reevaluar la configuración de las cuentas de correo en las directivas de Sophos Mobile afectadas. Esto no equivale a migrar los buzones: Sophos Mobile distribuye ajustes a los dispositivos; que los usuarios puedan iniciar sesión y enviar y recibir mensajes depende también de la aplicación de correo, la autenticación, el tenant y el entorno de Exchange.

Importante: Este artículo sirve para planificar, no es una guía para ejecutar el cambio en producción. La descripción de la migración de Sophos data del 22 de junio de 2023. Documenta el funcionamiento de las directivas, pero no acredita una compatibilidad integral verificada hoy para el tenant propio. No elimine directivas ni cuentas de correo antiguas basándose únicamente en este artículo.

Qué hay que adaptar en Sophos Mobile

Sophos describe dos opciones: actualizar la directiva existente con una nueva configuración de Email account o sustituirla por una directiva nueva. El ejemplo documentado opta por sustituirla. Según el entorno, pueden verse afectadas directivas de dispositivos y perfiles de trabajo de Android Enterprise, directivas antiguas de dispositivos Android, directivas de dispositivos y usuarios de iOS, directivas de usuarios de macOS y directivas de Windows. Esta enumeración sirve para hacer inventario; no confirma que todos esos clientes admitan Exchange Online con el método de inicio de sesión elegido.

Preparar las directivas antes de cambiar los dispositivos

Que resulte más sencillo actualizar o sustituir una directiva depende de la estructura de directivas existente. Si una directiva compartida contiene otras configuraciones, hay que conservar y comprobar su ámbito de aplicación en ambas opciones; modificarla no afecta únicamente al dispositivo piloto seleccionado. Para el ejemplo de sustitución, prepare primero una directiva nueva que aún no esté asignada. Una posibilidad es duplicar la directiva actualmente asignada; no es un método obligatorio. Revise los ajustes heredados para comprobar las configuraciones que siguen siendo necesarias, las cuentas antiguas y el ámbito correcto de usuarios y dispositivos. Repita esta preparación para cada familia de directivas realmente afectada del inventario anterior. No envíe todavía ningún paquete de tareas ni elimine ninguna directiva antigua.

Asociar la cuenta, la nube y la autenticación

El ejemplo general de migración asigna outlook.office365.com al campo Server name para la nube global de Microsoft 365, y %_EMAILADDRESS_% al campo User. Sophos Mobile sustituye el marcador por la dirección de correo del usuario. Esto no garantiza que la dirección de correo coincida con el nombre de inicio de sesión real en el tenant propio. Para otra nube, seleccione el conjunto de datos correspondiente en la biblioteca Microsoft 365 URLs and IP address ranges, que Microsoft mantiene actualizada: la vista predeterminada es Worldwide (+GCC); 21Vianet, DoD y GCC High tienen sus propios conjuntos de datos. No utilice el host de la nube global sin comprobarlo.

La selección de OAuth requiere que la autenticación moderna para Exchange Online esté habilitada en el tenant. Compruebe este estado por separado con el equipo de Exchange. Para Android Enterprise, la guía indica seleccionar Authentication > Modern authentication; para iOS y macOS, Turn on OAuth 2.0. Para Windows y las directivas antiguas de Android, esta fuente no muestra una opción de OAuth equivalente. Ni activar una opción ni una afirmación anterior sobre el valor predeterminado del tenant demuestran que el cliente de correo real pueda iniciar sesión. Active SSL/TLS. La aprobación exige una conexión cifrada con una comprobación válida de certificados; desactivar las comprobaciones TLS no soluciona los fallos de inicio de sesión.

Directiva actual de dispositivos iOS: detección del host con OAuth en lugar de un valor de servidor general. En Email account para Apple Mail, Server name se deja vacío con OAuth: el host de Exchange se detecta automáticamente. Introduzca OAuth authorization endpoint solo si lo exige el proveedor de autenticación; esto desactiva la detección del host y obliga a que Server name contenga la URL del servidor correspondiente. Rellene también OAuth token endpoint solo si lo exige el proveedor. Por tanto, la asignación general del host indicada arriba no es un paso de configuración obligatorio en todos los casos para iOS con OAuth. Para Exchange Online, Domain se deja vacío. %_EMAILADDRESS_% en User introduce la dirección del usuario asignado al dispositivo; para ello, Exchange Login y Email Address de ese usuario deben estar cumplimentados en Sophos Fusion. Compruebe por separado la asignación del usuario, los valores resueltos, la detección del host y el inicio de sesión real en el piloto autorizado. No aplique automáticamente esta descripción de dispositivos iOS a directivas de usuarios de iOS ni a otros clientes.

Comprobar los demás ajustes de cuenta según el tipo de directiva

Cambiar únicamente el host no sustituye una revisión completa de Email account. Antes de asignar la directiva, revise por tipo de directiva la presentación de la cuenta existente, la asignación del usuario, el inicio de sesión, el alcance de la sincronización, la transferencia de datos y, si procede, los certificados. En las directivas de dispositivos iOS, Synchronization period limita los mensajes sincronizados localmente. Allow move, Allow recent address syncing y Use in Mail only son decisiones separadas sobre el cambio entre cuentas, la sincronización de direcciones con iCloud y las aplicaciones que pueden enviar correo. Identity certificate, así como la firma y el cifrado S/MIME, requieren los certificados adecuados de la directiva; no se derivan del cambio de servidor. Defina de forma consciente la sincronización del correo, el calendario y los contactos, junto con los cambios que se permiten al usuario; no los herede a ciegas del perfil antiguo.

Para tareas independientes de cada plataforma, la directiva de dispositivos iPhone/iPad explica el modo de gestión, las cuentas y los efectos de la directiva. La directiva de dispositivos corporativos Android Enterprise trata solo Full Device con Gmail, incluida la configuración antigua de Gmail, la asignación del usuario y el requisito de Chrome para OAuth; no es una receta para perfiles de trabajo ni para Android antiguo. Para macOS user policy, la directiva de macOS explica la cuenta EWS y su detección del host con OAuth, no EAS. En Windows, aclare primero los límites de las cuentas y los clientes; de ello no se deduce que se admita el despliegue de un cliente de correo actual. Para perfiles de trabajo de Android, directivas antiguas de Android o directivas de usuarios de iOS, revise por separado los campos de cuenta disponibles y los requisitos del cliente. Mientras no se confirme su comportamiento, no asigne valores de otra familia de directivas como si fueran una configuración verificada.

Planificar por separado los paquetes de tareas y las futuras inscripciones

Como ejemplo de sustitución de directivas, Sophos propone un paquete de tareas con Assign policy para la directiva nueva; solo menciona Uninstall policy para las directivas de dispositivos Android e iOS, y Unassign iOS user policy solo para las directivas de usuarios de iOS. Los dispositivos existentes y las futuras inscripciones mediante autoservicio siguen vías distintas: el paquete de tareas enviado a los dispositivos existentes no sustituye automáticamente el paquete de inscripción de una configuración del Self Service Portal. Si se usan esas configuraciones, sustituya allí los paquetes de inscripción afectados por otros que asignen la nueva directiva; antes de permitir nuevas inscripciones, compruebe cada configuración afectada y los paquetes que tiene asignados. El paquete de tareas combinado es un ejemplo documentado, no una secuencia aprobada para una sustitución en producción. Que se ejecuten sus tareas o que aparezcan como completadas no demuestra que sea posible iniciar sesión, que el correo fluya ni que eliminar el perfil antiguo sea inocuo.

El control de acceso EAS no es la ruta del correo

Si el entorno anterior utiliza el EAS proxy de Sophos Mobile para controlar el acceso, Sophos distingue dos modos de funcionamiento para Exchange Online: según su documentación, Proxy mode admite Exchange Server, pero no Exchange Online. En PowerShell mode, los dispositivos se comunican directamente con Exchange; el servicio de Sophos controla las decisiones de acceso mediante la interfaz de administración de Exchange. La aplicación de correo sigue necesitando una vía de autenticación y de datos propia que funcione. Según Sophos, el control de acceso ActiveSync basado en PowerShell no está disponible para los Mac.

Queda por aclarar la autenticación del servicio de Sophos: la descripción de Sophos de enero de 2026 indica que, si falla el inicio de sesión moderno, se intenta usar Basic Authentication. Microsoft no permite volver a habilitar Basic Authentication para EAS ni para Remote PowerShell en Exchange Online. Por tanto, ese mecanismo de reserva no sirve para recuperar el servicio. Sophos describe por separado Basic para la conexión administrativa de su servicio en modo PowerShell a un Exchange Server local; esto no se refiere al inicio de sesión de los clientes EAS ni a Exchange Online, ni autoriza activar Basic sin aprobación de seguridad. Además, la configuración de Sophos de septiembre de 2026 menciona una URI de conexión /powershell-liveid. Microsoft también indica esa URI como valor predeterminado en su documentación actual del módulo Connect-ExchangeOnline, que describe conexiones REST modernas sin WinRM Basic. La URI por sí sola no demuestra ni que se utilice un transporte obsoleto ni que la versión concreta de Sophos sea compatible; siguen sin comprobarse su módulo, su autenticación y el comportamiento real de la conexión. La guía de PowerShell de Sophos de septiembre de 2026 sigue enumerando Exchange Server 2016 y 2019 como versiones admitidas; la hoja de ruta de Microsoft sitúa el fin del soporte de ambas el 14 de octubre de 2025. Por separado, las tablas del ciclo de vida de Microsoft para Exchange Server 2016 y Exchange Server 2019 indican para cada producto el 15 de octubre de 2025 a las 06:59:59, hora del Pacífico, como fin del soporte extendido. Estas fuentes primarias difieren en la fecha de calendario y ninguna explica la discrepancia. No infiera que señalan un mismo instante ni un día adicional de soporte. Por ello, la lista de Sophos no supone una aprobación del ciclo de vida de esos servidores. Antes de implantar el control de acceso, hay que aclarar con Sophos y el equipo responsable de Exchange la compatibilidad de la versión del proxy, el módulo, el endpoint de la nube, la cuenta de servicio, los permisos y la conexión OAuth/REST real, así como el estado de soporte del entorno de servidores anterior. No deduzca de ello una autorización general para Basic, WinRM Basic ni para desactivar la comprobación de certificados.

Configuración de PowerShell como tarea separada y condicional

Esta vía solo es necesaria si se va a utilizar realmente el control de acceso EAS. La decisión de arquitectura EAS trata el protocolo del cliente, la identidad del dispositivo y la cuarentena; la comprobación previa a la instalación trata el host, la versión del software, la cuenta de servicio y la confianza en los certificados. Ambas son comprobaciones previas, no procedimientos de configuración aprobados. Para planificar la migración, la configuración puede dividirse en tres partes independientes:

Entorno de administración y cuenta de servicio: solicite la confirmación del entorno de PowerShell y módulos adecuado en el host previsto, y de una cuenta dedicada de administración de Exchange con los permisos necesarios y los requisitos de inicio de sesión del tenant. Los requisitos de Exchange Server y Exchange Online no son intercambiables. Los comandos para activar Basic en el directorio local de Exchange PowerShell no deben incluirse en un cambio de Exchange Online. Los cambios en la directiva de ejecución de PowerShell también son una intervención en el host que requiere una aprobación separada.
Instancia y conexión: el asistente de configuración describe, en EAS Proxy instance setup, Instance type > PowerShell Exchange/Office 365, un Instance name elegido libremente, el destino en Exchange server y Service account junto con Password. Son campos que hay que preparar, no valores ya confirmados para la versión propia del software. Para la nube global, el ejemplo indica outlook.office365.com; el asistente añade por sí mismo el protocolo y la ruta. No introduzca a ciegas una URI completa en el campo del host ni deduzca de la ruta añadida una aprobación actual del transporte. Allow all certificates desactiva la comprobación del certificado del servidor y debe permanecer desactivado en este plan; resuelva por separado cualquier error de confianza. Hay que demostrar que el método de inicio de sesión administrativo está admitido, independientemente de la ruta de correo de los dispositivos.
Confianza de la instancia con Sophos Mobile: el certificado generado durante la configuración de cada instancia de PowerShell debe estar asociado a la instancia correcta. La carga documentada se encuentra en My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file, seguida de Save. No es lo mismo que el certificado TLS del servidor ni que un certificado de cliente en el perfil de correo. El reinicio del servicio de Windows EASProxy descrito a continuación interrumpe el servicio y solo corresponde a un cambio aprobado por separado, con comprobación del arranque y de la vuelta atrás; no inicie aquí ni la carga ni el reinicio.

Sin confirmar la versión del software, el inicio de sesión, la asociación de certificados y la vuelta atrás, no se debe pasar de esta preparación. Una cuenta introducida, un certificado cargado o un servicio accesible no demuestran que se aplique una decisión de acceso ni que se pueda enviar y recibir correo. Valide estas tres vías por separado solo después de obtener una aprobación específica; no utilice una cuarentena generalizada de Exchange como prueba de configuración.

Qué aclarar antes de decidir un cambio en producción

Grupos afectados: registre por separado la titularidad y el modo de gestión, la directiva actual y la prevista, el dispositivo y el sistema operativo, la aplicación de correo, el tipo de cuenta y la autenticación utilizada. No infiera de la lista de migración de Sophos que Windows y los clientes Android antiguos sean compatibles con OAuth.
Tenant y permisos: compruebe la nube de Microsoft, el endpoint, el plan de Exchange Online y los buzones de los usuarios; la cuenta de servicio para el control de acceso usa una vía de autenticación distinta de la cuenta de correo del usuario. Revise los permisos y los requisitos de MFA y acceso condicional con el equipo de Exchange, en vez de dar por supuestos amplios privilegios de administración o la posibilidad de recurrir a Basic.
Validación segura: primero, sin asignar ni desinstalar directivas, registre en un dispositivo piloto autorizado con un buzón de prueba el dispositivo de destino, la asignación actual, el estado de sincronización, la aplicación de correo, el estado del buzón y los datos de correo existentes. Antes de cualquier cambio en el piloto, aclare con el equipo de Exchange qué métodos de inicio de sesión se admiten, qué efectos puede haber sobre perfiles y datos, cómo hacer una copia verificable de los datos afectados y cuáles son los criterios para detener el proceso y volver atrás; si se desconocen los efectos o la vía de retorno, deténgase aquí. Solo entonces planifique un cambio de directiva autorizado por separado y limitado al grupo piloto, y compruebe los nuevos ajustes de cuenta aplicados, el inicio de sesión real, el envío, la recepción y, si procede, la decisión de acceso EAS prevista. Decida si distribuir ampliamente la nueva directiva o retirar la antigua solo después de esa validación. No dé por supuesto que los perfiles antiguos y nuevos pueden coexistir ni que Uninstall policy sea reversible; no inicie una desinstalación como simple comprobación preliminar del piloto. Si hay discrepancias, investigue primero el cliente y el inicio de sesión y, por separado, la conexión del control de acceso; no active un bloqueo generalizado de dispositivos desconocidos como paso de diagnóstico.
Vuelta atrás y aprobación: documente las directivas antiguas y nuevas y los paquetes de tareas de autoservicio; antes del cambio, acuerde la ventana de intervención, los criterios para detener el proceso, las responsabilidades y la posibilidad de restaurar el entorno real de buzones y servidores. Volver a asignar la antigua directiva de Sophos no restaura un buzón ya migrado ni un Exchange Server local que se haya apagado.

Mientras no se confirmen estos puntos para el entorno concreto, la descripción de las directivas solo sirve para planificar. Aquí no se recomienda ejecutar un cambio en producción, garantizar su éxito ni prometer una vuelta atrás generalizada.