Sophos Mobile: da Exchange Server a Exchange Online

Nel passaggio da un Exchange Server locale a Exchange Online, occorre rivalutare la configurazione degli account di posta nei criteri Sophos Mobile interessati. Non è la stessa cosa di una migrazione delle cassette postali: Sophos Mobile distribuisce le impostazioni ai dispositivi; la possibilità per gli utenti di accedere, inviare e ricevere messaggi dipende anche dall’app di posta, dall’autenticazione, dal tenant e dall’ambiente Exchange.

Importante: questo articolo offre indicazioni per la pianificazione, non è una procedura di cutover in produzione. La descrizione della migrazione di Sophos risale al 22 giugno 2023. Documenta il funzionamento dei criteri, ma non attesta una compatibilità end-to-end verificata oggi per il proprio tenant. Non rimuovere vecchi criteri o account di posta basandosi soltanto su questo articolo.

Cosa occorre modificare in Sophos Mobile

Sophos descrive due possibilità: aggiornare il criterio esistente con una nuova configurazione Email account oppure sostituirlo con un nuovo criterio. L’esempio documentato prevede la sostituzione del criterio. A seconda della configurazione esistente, possono essere interessati i criteri per dispositivi e profili di lavoro Android Enterprise, i criteri precedenti per dispositivi Android, i criteri per dispositivi e utenti iOS, i criteri per utenti macOS e i criteri Windows. Questo elenco serve a fare l’inventario: non conferma che ciascuno di questi client supporti Exchange Online con il metodo di accesso scelto.

Preparare i criteri prima di modificare i dispositivi

La scelta tra aggiornamento e sostituzione dipende dalla struttura dei criteri esistenti. Se un criterio condiviso contiene altre configurazioni, il loro ambito va preservato e verificato in entrambi i casi; una modifica non è limitata al dispositivo pilota selezionato. Per l’esempio di sostituzione, preparare prima un nuovo criterio non ancora assegnato. Una possibilità è duplicare il criterio attualmente assegnato; non è un metodo obbligatorio. Verificare nelle impostazioni ereditate i payload ancora necessari, i vecchi account e il corretto ambito utente/dispositivo. Ripetere questa preparazione per ogni famiglia di criteri effettivamente interessata dell’inventario precedente. Non inviare ancora pacchetti di attività e non rimuovere vecchi criteri.

Associare account, cloud e autenticazione

L’esempio generale di migrazione associa outlook.office365.com al campo Server name per il cloud Microsoft 365 globale e %_EMAILADDRESS_% al campo User. Sophos Mobile sostituisce il segnaposto con l’indirizzo e-mail dell’utente. Questo non garantisce che l’indirizzo e-mail e il nome di accesso effettivo coincidano nel proprio tenant. Per un altro cloud, selezionare il set di dati appropriato nella raccolta Microsoft 365 URLs and IP address ranges, aggiornata regolarmente da Microsoft: la vista predefinita è Worldwide (+GCC); 21Vianet, DoD e GCC High hanno set di dati propri. Non utilizzare l’host globale senza verificarlo.

La selezione di OAuth presuppone che l’autenticazione moderna per Exchange Online sia abilitata nel tenant. Verificare separatamente questo stato con il team Exchange. L’esempio di migrazione indica quindi Authentication > Modern authentication per Android Enterprise e Turn on OAuth 2.0 per iOS e macOS. Per Windows e per i criteri Android precedenti, questa fonte non mostra una corrispondente opzione OAuth. Né l’impostazione di un’opzione né una precedente dichiarazione relativa a un’impostazione predefinita del tenant dimostrano che l’accesso del client di posta effettivo riesca. Abilitare SSL/TLS; una connessione cifrata con verifica valida del certificato è un requisito per l’approvazione. Un accesso non riuscito non si risolve disattivando le verifiche TLS.

Criterio attuale per dispositivi iOS: individuazione dell’host OAuth anziché un valore server generalizzato. In Email account per Apple Mail, con OAuth il campo Server name resta vuoto: l’host Exchange viene individuato automaticamente. Inserire OAuth authorization endpoint solo se richiesto dal provider di autenticazione; in questo caso l’individuazione dell’host viene disabilitata e Server name deve contenere l’URL del server appropriato. Compilare anche OAuth token endpoint solo se richiesto dal provider. L’associazione generale dell’host descritta sopra non è quindi un passaggio di configurazione obbligatorio per iOS con OAuth. Per Exchange Online, Domain resta vuoto. %_EMAILADDRESS_% in User inserisce l’indirizzo dell’utente associato al dispositivo; a questo scopo, Exchange Login ed Email Address di tale utente devono essere compilati in Sophos Fusion. Verificare separatamente nel pilota autorizzato l’associazione dell’utente, i valori risolti, l’individuazione dell’host e l’accesso effettivo. Non applicare automaticamente questa descrizione dei dispositivi iOS ai criteri per utenti iOS o ad altri client.

Verificare le altre impostazioni dell’account per tipo di criterio

Il solo cambio dell’host non sostituisce una verifica completa di Email account. Prima dell’assegnazione, verificare per ogni tipo di criterio la visualizzazione dell’account esistente, l’associazione dell’utente, l’accesso, l’ambito di sincronizzazione, la condivisione dei dati e, se applicabile, i certificati. Nei criteri per dispositivi iOS, Synchronization period limita i messaggi sincronizzati localmente. Allow move, Allow recent address syncing e Use in Mail only sono decisioni distinte sul passaggio tra account, sulla sincronizzazione degli indirizzi con iCloud e sulle app usate per l’invio. Identity certificate, la firma S/MIME e la crittografia S/MIME richiedono i certificati appropriati del criterio; non derivano dal cambio del server. Definire consapevolmente la sincronizzazione di posta, calendari e contatti e le modifiche consentite agli utenti, senza copiarle alla cieca dal vecchio profilo.

Per le attività specifiche delle piattaforme, il criterio per dispositivi iPhone/iPad illustra modalità di gestione, account ed effetti del criterio. Il criterio per dispositivi aziendali Android Enterprise riguarda solo Full Device con Gmail, incluse la vecchia configurazione Gmail, l’associazione dell’utente e la necessità di Chrome per OAuth; non è una procedura per Work Profile o per Android precedente. Per macOS user policy, il criterio macOS spiega l’account EWS e la relativa individuazione dell’host OAuth, non EAS. Per Windows, chiarire prima i limiti di account e client; ciò non implica una distribuzione supportata di un client di posta attuale. Per i profili di lavoro Android, i criteri Android precedenti o i criteri per utenti iOS, verificare separatamente i campi dell’account effettivamente disponibili e i requisiti dei client. Finché il loro comportamento non è confermato, non assegnare valori di un’altra famiglia di criteri come configurazione verificata.

Pianificare separatamente pacchetti di attività e future registrazioni

Per sostituire il criterio, l’esempio Sophos prevede un pacchetto di attività con Assign policy per il nuovo criterio; indica Uninstall policy per il vecchio criterio soltanto per i criteri dei dispositivi Android e iOS, e Unassign iOS user policy soltanto per i criteri degli utenti iOS. I dispositivi esistenti e le future registrazioni self-service seguono percorsi distinti: il pacchetto di attività inviato ai dispositivi esistenti non sostituisce automaticamente il pacchetto di attività di registrazione di una configurazione nel Self Service Portal. Se si usano tali configurazioni, sostituire i pacchetti di attività di registrazione interessati con pacchetti che assegnino il nuovo criterio; prima di ulteriori registrazioni, verificare ogni configurazione interessata e l’assegnazione dei suoi pacchetti. Il pacchetto di attività combinato è un esempio documentato, non una sequenza approvata per una sostituzione in produzione. La sua esecuzione o uno stato dell’attività riuscito non dimostrano né l’accesso, né il flusso di posta, né che il vecchio profilo possa essere rimosso senza conseguenze.

Il controllo degli accessi EAS non è il percorso della posta

Se l’ambiente attuale usa EAS proxy di Sophos Mobile per il controllo degli accessi, Sophos distingue due modalità operative per Exchange Online: secondo la sua documentazione, Proxy mode supporta Exchange Server, non Exchange Online. In PowerShell mode, i dispositivi comunicano direttamente con Exchange; il servizio Sophos gestisce le decisioni di accesso tramite l’interfaccia di amministrazione di Exchange. L’app di posta necessita comunque di un proprio percorso funzionante per l’accesso e i dati. Secondo Sophos, per i Mac non è disponibile un controllo degli accessi ActiveSync basato su PowerShell.

Riguardo all’autenticazione del servizio Sophos, resta una discrepanza da chiarire: la descrizione Sophos di gennaio 2026 indica, dopo il fallimento dell’autenticazione moderna, un tentativo con Basic Authentication. Microsoft non consente di riattivare Basic Authentication per EAS e Remote PowerShell in Exchange Online. Il fallback descritto non è quindi un percorso di ripristino. Sophos descrive separatamente Basic per la connessione amministrativa del proprio servizio in modalità PowerShell a un Exchange Server locale; ciò non riguarda l’accesso dei client EAS né Exchange Online e non autorizza ad abilitare Basic senza approvazione di sicurezza. Inoltre, le istruzioni di configurazione Sophos di settembre 2026 indicano un URI di connessione /powershell-liveid. Microsoft indica lo stesso URI come valore predefinito nella documentazione corrente del modulo Connect-ExchangeOnline, che descrive connessioni REST moderne senza WinRM Basic. Il solo URI non dimostra né che il trasporto sia obsoleto né che la specifica build Sophos sia compatibile; il modulo, l’autenticazione e il comportamento effettivo della connessione restano da verificare. La guida Sophos su PowerShell di settembre 2026 elenca ancora Exchange Server 2016 e 2019 tra le versioni supportate; la roadmap Microsoft indica il 14 ottobre 2025 come fine del supporto per entrambe. Separatamente, le tabelle del ciclo di vita Microsoft per Exchange Server 2016 e Exchange Server 2019 riportano ciascuna il 15 ottobre 2025 alle 06:59:59, ora del Pacifico, come fine del supporto esteso. Queste fonti primarie differiscono nel giorno di calendario e nessuna spiega la discrepanza. Non dedurne né un unico istante né un giorno aggiuntivo di supporto. L’elenco Sophos non costituisce quindi un’approvazione del ciclo di vita dei server. Prima di attivare il controllo degli accessi, occorre chiarire con Sophos e con il team Exchange competente la build del proxy supportata, il modulo, l’endpoint cloud, l’account di servizio, i permessi e l’effettiva connessione OAuth/REST, nonché lo stato del supporto dell’ambiente server esistente. Non dedurne un’approvazione generale per Basic, WinRM Basic o per la disattivazione della verifica dei certificati.

Configurazione PowerShell come attività separata e condizionata

Questo ramo è necessario solo se si intende effettivamente usare il controllo degli accessi EAS. La decisione sull’architettura EAS tratta il protocollo del client, l’identità del dispositivo e la quarantena; la verifica preliminare all’installazione tratta host, build, account di servizio e attendibilità dei certificati. Entrambe sono verifiche preliminari, non procedure di configurazione approvate. Per pianificare la migrazione, la configurazione può essere suddivisa in tre parti distinte:

Ambiente di amministrazione e account di servizio: far confermare l’ambiente PowerShell e i moduli appropriati sull’host previsto, nonché un account dedicato all’amministrazione di Exchange con i permessi necessari e i requisiti di accesso del tenant. I prerequisiti per Exchange Server e Exchange Online non sono intercambiabili. I comandi per abilitare Basic nella directory PowerShell di Exchange locale non devono rientrare in una modifica di Exchange Online. Anche le modifiche ai criteri di esecuzione di PowerShell sono interventi sull’host da approvare separatamente.
Istanza e connessione: nella schermata EAS Proxy instance setup, la procedura guidata descrive Instance type > PowerShell Exchange/Office 365, un Instance name scelto liberamente, la destinazione in Exchange server e Service account con Password. Sono campi da preparare, non valori già confermati per la propria build. Per il cloud globale, l’esempio indica outlook.office365.com; la procedura guidata aggiunge automaticamente protocollo e percorso. Non copiare alla cieca un URI completo nel campo host e non dedurre dal percorso aggiunto un’approvazione del trasporto attuale. Allow all certificates disabilita la verifica del certificato del server e resta disattivato per questo piano; risolvere separatamente eventuali errori di attendibilità. L’autenticazione amministrativa supportata deve essere dimostrata indipendentemente dal percorso di posta dei dispositivi.
Attendibilità dell’istanza verso Sophos Mobile: il certificato generato durante la configurazione di ogni istanza PowerShell deve essere associato all’istanza corretta. Il caricamento documentato si trova in My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file, seguito da Save. Non è lo stesso certificato TLS del server né un certificato client nel profilo di posta. Il successivo riavvio descritto del servizio Windows EASProxy comporta un’interruzione operativa e deve rientrare esclusivamente in una modifica approvata separatamente, con verifica dell’avvio e del percorso di ripristino; qui non avviare né il caricamento né il riavvio.

Senza conferma di build, autenticazione, associazione dei certificati e percorso di ripristino, ci si limita a questa preparazione. Un account inserito, un certificato caricato o un servizio raggiungibile non dimostrano né che una decisione di accesso venga applicata né che l’invio e la ricezione riescano. Verificare separatamente questi tre percorsi solo dopo un’approvazione specifica; non usare una quarantena Exchange generalizzata come test di configurazione.

Cosa chiarire prima di una decisione per la produzione

Gruppi interessati: rilevare separatamente proprietà e modalità di gestione, criterio attuale e previsto, dispositivo e sistema operativo, app di posta, tipo di account e autenticazione utilizzata. Per Windows e i client Android precedenti, non dedurre la compatibilità OAuth dall’elenco di migrazione Sophos.
Tenant e autorizzazioni: verificare il cloud Microsoft, l’endpoint, il piano Exchange Online e le cassette postali degli utenti; l’account di servizio per il controllo degli accessi segue un percorso di autenticazione diverso dall’account di posta dell’utente. Verificare autorizzazioni e requisiti MFA/Conditional Access con il team Exchange, senza presupporre privilegi amministrativi estesi o un fallback Basic.
Verifica sicura: inizialmente, senza assegnare criteri né disinstallarli, registrare su un dispositivo pilota autorizzato con una cassetta postale di test il dispositivo di destinazione, l’assegnazione attuale, lo stato di sincronizzazione, l’app di posta, lo stato della cassetta postale e i dati di posta presenti. Prima di qualsiasi modifica nel pilota, chiarire con il team Exchange il metodo di accesso supportato, le possibili conseguenze per profili e dati, una copia di sicurezza verificabile dei dati interessati e i criteri di interruzione e ripristino; se le conseguenze o il percorso di ripristino sono sconosciuti, fermarsi qui. Solo allora pianificare una modifica dei criteri autorizzata separatamente e limitata al gruppo pilota, e osservare le nuove impostazioni dell’account effettivamente applicate, l’accesso reale, l’invio, la ricezione e, se usata, la decisione prevista del controllo degli accessi EAS. Decidere se distribuire su larga scala o rimuovere il vecchio criterio soltanto dopo questa verifica. Non presumere che vecchi e nuovi profili possano coesistere o che Uninstall policy sia reversibile; non avviare una disinstallazione come semplice verifica preliminare del pilota. In caso di anomalie, esaminare prima il client e l’accesso e, separatamente, la connessione del controllo degli accessi; non attivare il blocco generalizzato dei dispositivi sconosciuti come passo diagnostico.
Ripristino e approvazione: documentare i vecchi e i nuovi criteri e i pacchetti di attività self-service; prima di una migrazione, chiarire la finestra di intervento, i criteri di interruzione, le responsabilità e la possibilità di ripristinare l’ambiente reale delle cassette postali e dei server. Riassegnare il vecchio criterio Sophos non ripristina una cassetta postale già migrata né un Exchange Server locale disattivato.

Finché questi punti non sono confermati per l’ambiente specifico, la descrizione dei criteri resta soltanto una base per pianificare. Qui non si raccomandano né un cutover in produzione, né una garanzia di successo, né un rollback generalizzato.