Sophos Mobile : migration d’Exchange Server vers Exchange Online

Lors du passage d’un serveur Exchange local à Exchange Online, il faut réévaluer la configuration des comptes de messagerie dans les stratégies Sophos Mobile concernées. Ce n’est pas la même chose qu’une migration de boîtes aux lettres : Sophos Mobile distribue des paramètres aux appareils ; la possibilité pour les utilisateurs de se connecter, d’envoyer et de recevoir des messages dépend aussi de l’application de messagerie, de l’authentification, du tenant et de l’environnement Exchange.

Important : cet article sert à préparer la migration ; ce n’est pas une procédure de bascule en production. La description de migration de Sophos date du 22 juin 2023. Elle documente le fonctionnement des stratégies, mais ne documente pas de compatibilité de bout en bout vérifiée aujourd’hui pour votre tenant. Ne supprimez pas d’anciennes stratégies ni de comptes de messagerie sur la seule foi de cet article.

Modifications à apporter dans Sophos Mobile

Sophos décrit deux possibilités : mettre à jour la stratégie existante avec une nouvelle configuration Email account, ou la remplacer par une nouvelle stratégie. Son exemple documenté utilise le remplacement. Selon le parc, cela peut concerner les stratégies d’appareil et de profil professionnel Android Enterprise, les anciennes stratégies d’appareil Android, les stratégies d’appareil et d’utilisateur iOS, les stratégies d’utilisateur macOS ainsi que les stratégies Windows. Cette liste aide à dresser l’inventaire ; elle ne confirme pas que chacun de ces clients prend en charge Exchange Online avec la méthode de connexion choisie.

Préparer les stratégies avant de modifier la configuration des appareils

Le choix entre une mise à jour et un remplacement dépend de la structure des stratégies existantes. Si une stratégie partagée contient d’autres configurations, leur périmètre doit être préservé et vérifié dans les deux cas ; une modification de cette stratégie ne se limite pas à l’appareil pilote sélectionné. Pour l’exemple de remplacement, préparez d’abord une nouvelle stratégie qui n’est pas encore attribuée. Dupliquer la stratégie actuellement attribuée est une possibilité, pas une méthode imposée. Vérifiez les paramètres repris : configurations encore nécessaires, anciens comptes et périmètre correct pour les utilisateurs et les appareils. Répétez cette préparation pour chaque famille de stratégies effectivement concernée dans l’inventaire ci-dessus. N’envoyez pas encore de lot de tâches et ne retirez aucune ancienne stratégie.

Associer le compte, le cloud et l’authentification

L’exemple général de migration associe outlook.office365.com au champ Server name pour le cloud Microsoft 365 mondial, et %_EMAILADDRESS_% au champ User. Sophos Mobile remplace cette variable par l’adresse de messagerie de l’utilisateur. Cela ne garantit pas que l’adresse de messagerie corresponde au véritable identifiant de connexion dans votre tenant. Pour un autre cloud, sélectionnez le jeu de données correspondant dans la bibliothèque Microsoft 365 URLs and IP address ranges, tenue à jour par Microsoft : la vue par défaut est Worldwide (+GCC) ; 21Vianet, DoD et GCC High disposent de leurs propres jeux de données. Ne reprenez pas l’hôte du cloud mondial sans vérification.

La sélection d’OAuth suppose que l’authentification moderne pour Exchange Online soit activée dans le tenant. Vérifiez cet état séparément avec l’équipe Exchange. L’exemple de migration indique ensuite Authentication > Modern authentication pour Android Enterprise et Turn on OAuth 2.0 pour iOS et macOS. Pour Windows et les anciennes stratégies Android, cette source ne présente pas d’option OAuth équivalente. Ni l’activation d’une option ni une ancienne indication sur le paramètre par défaut du tenant ne prouvent que le véritable client de messagerie parvient à se connecter. Activez SSL/TLS ; l’approbation suppose une connexion chiffrée et une vérification valide des certificats. Désactiver les contrôles TLS ne résout pas un échec de connexion.

Stratégie d’appareil iOS actuelle : découverte de l’hôte avec OAuth plutôt qu’une valeur de serveur systématique. Dans Email account pour Apple Mail, le champ Server name reste vide avec OAuth : l’hôte Exchange est déterminé automatiquement. Ne renseignez OAuth authorization endpoint que si le fournisseur d’authentification l’exige ; cela désactive la découverte de l’hôte et Server name doit alors contenir l’URL du serveur approprié. Ne renseignez OAuth token endpoint que si le fournisseur l’exige également. L’association générale de l’hôte ci-dessus n’est donc pas une étape de configuration systématique pour iOS avec OAuth. Pour Exchange Online, Domain reste vide. %_EMAILADDRESS_% dans User insère l’adresse de l’utilisateur associé à l’appareil ; cela nécessite que Exchange Login et Email Address soient renseignés pour cet utilisateur dans Sophos Fusion. Vérifiez séparément l’association de l’utilisateur, les valeurs obtenues après substitution, la découverte de l’hôte et la connexion réelle dans le cadre du pilote autorisé. N’appliquez pas automatiquement cette description des stratégies d’appareil iOS aux stratégies d’utilisateur iOS ni à d’autres clients.

Vérifier les autres paramètres du compte selon le type de stratégie

Le seul changement d’hôte ne remplace pas une vérification complète de Email account. Avant l’attribution, vérifiez pour chaque type de stratégie les paramètres existants d’affichage du compte, l’association de l’utilisateur, l’authentification, le périmètre de synchronisation, le partage des données et, le cas échéant, les certificats. Dans les stratégies d’appareil iOS, Synchronization period limite les courriels synchronisés localement. Allow move, Allow recent address syncing et Use in Mail only correspondent à des décisions distinctes concernant le changement de compte, la synchronisation des adresses avec iCloud et les applications autorisées à envoyer des messages. Identity certificate, ainsi que la signature et le chiffrement S/MIME, nécessitent les certificats appropriés dans la stratégie ; ils ne découlent pas du changement de serveur. Définissez délibérément la synchronisation des courriels, des calendriers et des contacts ainsi que les modifications autorisées aux utilisateurs, sans reprendre aveuglément l’ancien profil.

Pour les tâches propres à chaque plateforme, la stratégie d’appareil iPhone/iPad explique le mode de gestion, les comptes et les effets de la stratégie. La stratégie Android Enterprise pour les appareils d’entreprise traite uniquement de Full Device avec Gmail, y compris l’ancienne configuration Gmail, l’association de l’utilisateur et la nécessité de Chrome pour OAuth ; ce n’est pas une procédure pour Work Profile ni pour les anciennes stratégies Android. Pour macOS user policy, la stratégie macOS explique le compte EWS et sa découverte de l’hôte avec OAuth, et non EAS. Pour Windows, clarifiez d’abord les limites des comptes et des clients ; cela ne signifie pas que le déploiement d’un client de messagerie actuel soit pris en charge. Pour les profils professionnels Android, les anciennes stratégies Android ou les stratégies d’utilisateur iOS, vérifiez séparément les champs de compte réellement proposés et les prérequis des clients. Tant que leur comportement n’est pas confirmé, n’attribuez pas de valeurs issues d’une autre famille de stratégies en les présentant comme une configuration vérifiée.

Planifier séparément les lots de tâches et les futures inscriptions

Pour remplacer une stratégie, l’exemple Sophos prévoit un lot de tâches contenant Assign policy pour la nouvelle stratégie. Il ne mentionne Uninstall policy pour l’ancienne stratégie que dans le cas des stratégies d’appareil Android et iOS, et Unassign iOS user policy que pour les stratégies d’utilisateur iOS. Les appareils existants et les futures inscriptions en libre-service suivent des parcours distincts : le lot de tâches envoyé aux appareils existants ne remplace pas automatiquement le lot de tâches d’inscription d’une configuration du Self Service Portal. Si de telles configurations sont utilisées, remplacez les lots de tâches d’inscription concernés par des lots qui attribuent la nouvelle stratégie ; vérifiez chaque configuration concernée et les lots qui lui sont associés avant toute nouvelle inscription. Le lot de tâches combiné est un exemple documenté, pas un ordre d’exécution validé pour un remplacement en production. Son exécution, même avec des tâches indiquées comme réussies, ne prouve ni que la connexion ou la messagerie fonctionne, ni que le retrait de l’ancien profil est sans conséquence.

Le contrôle d’accès EAS n’est pas le chemin de la messagerie

Si l’environnement actuel utilise l’EAS proxy de Sophos Mobile pour contrôler l’accès, Sophos distingue deux modes de fonctionnement pour Exchange Online : selon sa documentation, Proxy mode prend en charge Exchange Server, mais pas Exchange Online. En PowerShell mode, les appareils communiquent directement avec Exchange ; le service Sophos pilote les décisions d’accès par l’interface d’administration Exchange. L’application de messagerie doit toujours disposer de son propre chemin fonctionnel pour la connexion et les données. Selon Sophos, le contrôle d’accès ActiveSync fondé sur PowerShell n’est pas disponible pour les Mac.

L’authentification du service Sophos demande encore une vérification : la description Sophos de janvier 2026 indique qu’après l’échec d’une connexion moderne, une tentative est faite avec Basic Authentication. Microsoft ne permet pas de réactiver Basic Authentication pour Exchange Online EAS ni pour Remote PowerShell. Ce mécanisme de repli ne constitue donc pas une solution de rétablissement. Sophos décrit séparément Basic pour la connexion d’administration de son service en mode PowerShell à un serveur Exchange local ; cela ne concerne ni l’authentification des clients EAS ni Exchange Online et n’autorise pas l’activation de Basic sans validation de sécurité. Par ailleurs, les instructions de configuration Sophos de septembre 2026 mentionnent une URI de connexion /powershell-liveid. Microsoft indique également cette URI comme valeur par défaut dans sa documentation actuelle du module Connect-ExchangeOnline, qui décrit des connexions REST modernes sans WinRM Basic. L’URI, à elle seule, ne prouve ni l’utilisation d’un transport obsolète ni la compatibilité de la version précise du logiciel Sophos ; son module, son mode d’authentification et son comportement réel à la connexion restent à vérifier. Le guide Sophos sur PowerShell de septembre 2026 cite encore Exchange Server 2016 et 2019 parmi les versions prises en charge ; la feuille de route de Microsoft situe la fin du support des deux versions au 14 octobre 2025. Séparément, les tableaux du cycle de vie Microsoft pour Exchange Server 2016 et Exchange Server 2019 indiquent chacun le 15 octobre 2025 à 06 h 59 min 59 s, heure du Pacifique, comme fin du support étendu. Ces sources primaires diffèrent sur le jour civil et aucune n’explique cet écart. N’en déduisez ni un même instant ni une journée de support supplémentaire. La liste Sophos ne vaut donc pas validation du cycle de vie de ces serveurs. Avant de mettre en place le contrôle d’accès, clarifiez avec Sophos et l’équipe Exchange responsable la compatibilité de la version du proxy, le module, le point de terminaison du cloud, le compte de service, les droits, la connexion OAuth/REST effective et le statut de support des serveurs actuels. N’en déduisez aucune autorisation générale d’utiliser Basic, WinRM Basic ou de désactiver la vérification des certificats.

Configuration PowerShell : une tâche distincte et conditionnelle

Cette branche n’est nécessaire que si le contrôle d’accès EAS doit effectivement être utilisé. Le choix d’architecture EAS traite du protocole client, de l’identité des appareils et de la quarantaine ; la vérification préalable à l’installation traite de l’hôte, de la version du logiciel, du compte de service et de la confiance accordée aux certificats. Il s’agit dans les deux cas de vérifications préalables, pas de procédures de configuration approuvées. Pour planifier la migration, la configuration peut être divisée en trois parties distinctes :

Environnement d’administration et compte de service : faites confirmer l’environnement PowerShell et les modules appropriés sur l’hôte prévu, ainsi qu’un compte dédié à l’administration Exchange, avec les droits nécessaires et les exigences de connexion du tenant. Les prérequis d’Exchange Server et d’Exchange Online ne sont pas interchangeables. Les commandes d’activation de Basic sur le répertoire PowerShell d’Exchange local n’ont pas leur place dans un changement Exchange Online. Les modifications de la stratégie d’exécution PowerShell constituent elles aussi une intervention sur l’hôte à approuver séparément.
Instance et connexion : sur EAS Proxy instance setup, l’assistant de configuration décrit Instance type > PowerShell Exchange/Office 365, un Instance name librement choisi, la cible sous Exchange server et Service account avec Password. Ce sont des champs à préparer, pas des valeurs déjà confirmées pour votre version du logiciel. Pour le cloud mondial, l’exemple indique outlook.office365.com ; l’assistant ajoute lui-même le protocole et le chemin. Ne copiez pas aveuglément une URI complète dans le champ de l’hôte et ne déduisez pas du chemin ajouté que le transport est actuellement approuvé. Allow all certificates désactive la vérification du certificat du serveur et reste désactivé dans ce plan ; corrigez séparément toute erreur de confiance. Le fonctionnement de l’authentification d’administration prise en charge doit être démontré indépendamment du chemin de messagerie des appareils.
Confiance entre l’instance et Sophos Mobile : le certificat généré lors de la configuration de chaque instance PowerShell doit être associé à la bonne instance. Le téléversement documenté se trouve sous My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file, puis Save. Ce certificat n’est ni le certificat TLS du serveur ni un certificat client du profil de messagerie. Le redémarrage du service Windows EASProxy décrit ensuite constitue une interruption de service et doit exclusivement relever d’un changement approuvé séparément, avec vérification du démarrage et du retour en arrière ; ne déclenchez ici ni téléversement ni redémarrage.

Sans confirmation de la version du logiciel, de l’authentification, de l’association des certificats et du retour en arrière, restez au stade de cette préparation. Un compte renseigné, un certificat téléversé ou un service accessible ne prouvent ni qu’une décision d’accès est effectivement appliquée ni que l’envoi et la réception fonctionnent. Ne validez ces trois chemins séparément qu’après une approbation spécifique ; n’utilisez pas une mise en quarantaine généralisée dans Exchange comme test de configuration.

Points à clarifier avant toute décision de mise en production

Groupes concernés : relevez séparément le propriétaire et le mode de gestion, les stratégies actuelle et prévue, l’appareil et son système d’exploitation, l’application de messagerie, le type de compte et la méthode d’authentification utilisée. Ne déduisez pas de la liste de migration Sophos une compatibilité OAuth des clients Windows ou des anciens clients Android.
Tenant et autorisations : vérifiez le cloud Microsoft, le point de terminaison, l’offre Exchange Online et les boîtes aux lettres des utilisateurs ; le compte de service utilisé pour le contrôle d’accès emprunte un chemin d’authentification différent de celui du compte de messagerie de l’utilisateur. Vérifiez les autorisations et les exigences de MFA et d’accès conditionnel avec l’équipe Exchange, sans supposer qu’il faut accorder de larges droits d’administrateur ni qu’un repli vers Basic est possible.
Validation encadrée : commencez par relever, sur un appareil pilote autorisé doté d’une boîte aux lettres de test, l’appareil cible, la stratégie actuellement attribuée, l’état de synchronisation, l’application de messagerie, l’état de la boîte aux lettres et les données de messagerie présentes, sans attribuer ni désinstaller de stratégie. Avant toute modification dans le pilote, clarifiez avec l’équipe Exchange la méthode de connexion prise en charge, les conséquences possibles pour les profils et les données, la disponibilité d’une sauvegarde vérifiable des données concernées, ainsi que les critères d’arrêt et de retour en arrière ; si les conséquences ou la possibilité de revenir en arrière sont inconnues, arrêtez-vous là. Ensuite seulement, planifiez une modification de stratégie autorisée séparément et limitée au groupe pilote, puis vérifiez l’application effective des nouveaux paramètres du compte, la connexion réelle, l’envoi, la réception et, le cas échéant, la décision de contrôle d’accès EAS attendue. Ne décidez d’un déploiement généralisé ou du retrait de l’ancienne stratégie qu’après cette validation. Ne présumez pas que les anciens et les nouveaux profils peuvent coexister ni que Uninstall policy est réversible ; ne lancez pas de désinstallation comme simple vérification préalable du pilote. En cas d’écart, examinez d’abord le client et sa connexion, puis séparément la connexion du système de contrôle d’accès ; n’activez pas le blocage généralisé des appareils inconnus comme étape de diagnostic.
Retour en arrière et approbation : documentez les anciennes et nouvelles stratégies ainsi que les lots de tâches du portail en libre-service ; clarifiez la fenêtre de changement, les critères d’arrêt, les responsabilités et la possibilité de restaurer l’environnement réel des boîtes aux lettres et des serveurs avant la bascule. Réattribuer l’ancienne stratégie Sophos ne restaure ni une boîte aux lettres déjà déplacée ni un serveur Exchange local arrêté.

Tant que ces points n’ont pas été confirmés pour l’environnement concerné, la description des stratégies ne constitue qu’une base de planification. Cet article ne recommande pas de bascule en production ni de retour en arrière applicable à tous les cas, et ne garantit pas le succès.