Migration des boîtes aux lettres sur site vers Exchange Online

Migration des boîtes aux lettres sur site vers Exchange Online

La migration de vos boîtes aux lettres utilisateur vers Exchange Online est une réalisation importante. Mais vous devez ensuite relever un défi plus difficile : la migration de vos boîtes aux lettres d’application. Une planification minutieuse est nécessaire car les boîtes aux lettres d’application servent souvent des fonctions commerciales vitales.

Par exemple, les boîtes aux lettres des applications de votre entreprise peuvent recevoir des données importantes provenant d’imprimantes. Mais elles peuvent aussi recevoir des alertes provenant de systèmes de sécurité informatique. De plus, pour éviter toute perturbation de l’activité, vous devez coordonner la migration de ces boîtes avec leurs propriétaires.

Cet article détaille les exigences de planification à prendre en compte lors de la planification des scénarios d’application lors de la migration de boîtes aux lettres sur site vers Exchange Online.

Comprendre le volume du trafic de messagerie de vos applications

Commencez par recueillir des informations des journaux Exchange sur le volume d’emails transitant par vos boîtes aux lettres. Pour attraper les processus qui s’exécutent moins souvent, vous devrez peut-être examiner ces données sur une période prolongée.

Pour recueillir ces statistiques de trafic, vous devrez rassembler ces informations à partir des journaux Exchange. Vous pouvez le faire en exécutant les cmdlets PowerShell ci-dessous à partir du Shell de gestion Exchange. Veillez à modifier les dates de début et de fin et le paramètre Destinataires. Si vous utilisez Exchange 2010, vous devrez remplacer la cmdlet Get-TransportService par Get-TransportServer :

$usersentresults = Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start "09/14/2021" -End "10/14/2021" -Sender user@domain.com -EventID RECEIVE | where {$_.Source -eq “STOREDRIVER”}
 
$appsentresults = Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start "09/14/2021" -End "10/14/2021" -Sender user@domain.com -EventID SEND
 
$mbxrecresults = Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start "09/14/2021" -End "10/14/2021" -Recipients user@domain.com -EventID DELIVER
 
Write-Output "Count of emails sent by mailbox is $($usersentresults).Count"
 
Write-Output "Count of emails sent by application is $($appsentresults).Count"
 
Write-Output "Count of emails received by mailbox is $($mbxrecresults).Count"

Le code ci-dessus collecte trois types d’événements :

• DELIVER – Cet événement indique qu’un message a été remis à une boîte aux lettres. Cependant, il y a deux requêtes d’envoi ci-dessus en raison de la façon dont certaines applications peuvent être configurées.
• SEND – Cet événement indique que le message a été envoyé à partir d’une adresse qui n’a pas de boîte aux lettres associée, comme une adresse arbitraire de type noreply@domain.com.
• RECEIVE – Cet événement indique que le service de transport a reçu un message et qu’une boîte aux lettres correspond à l’adresse de l’expéditeur. Les détails de l’événement peuvent inclure la source storedriver, qui indique que le service Mailbox Transport Submission a soumis un message à la BAL pour livraison.

Si vous envoyez des courriels en masse, gardez à l’esprit les limites d’expéditeur et de destinataire de Microsoft.

Ensuite, il faut tenir compte des limites horaires que Microsoft impose aux messages envoyés et reçus par boîte aux lettres pour protéger le service Exchange Online. Ces limites ont été mises à jour en septembre 2021.

Le scénario le plus courant de dépassement de ces limites est l’utilisation d’emails en masse, tels que des publicités ou des messages marketing.

Si l’une de vos boîtes aux lettres d’application ne peut pas rester dans les limites fixées par Microsoft, vous devez planifier votre stratégie pour elle. Vous pouvez choisir d’utiliser un outil de campagne tiers pour le marketing de masse et les courriels en vrac, ou de conserver la boîte aux lettres d’application sur votre dernier serveur Exchange sur site.

Mettre à jour les applications qui utilisent EWS

Si l’une de vos applications et boîtes aux lettres d’application utilise Exchange Web Services (EWS) pour créer et envoyer des emails, vous devrez mettre à jour toutes les références à votre point de terminaison EWS sur site pour pointer vers le point de terminaison EWS d’Exchange Online, que vous utilisiez ou non Autodiscover pour trouver vos boîtes aux lettres dans l’application.

En outre, Microsoft a annoncé qu’elle désactiverait l’authentification de base dans Exchange Online à compter du 1er octobre 2022.

Ce changement signifie que vous devez mettre à jour le code EWS dans toutes vos applications afin d’utiliser OAuth 2.0. Les documents officiels de Microsoft constituent un bon point de départ pour planifier ces changements.

Pour les applications tierces et les services hébergés d’un fournisseur, vous devez lui demander si la fonctionnalité OAuth est disponible. Si ce n’est pas le cas, étudiez sa feuille de route pour le passage à OAuth.

Mettre à jour les applications qui utilisent POP ou IMAP

Si l’une de vos applications internes et boîtes aux lettres d’application doit accéder aux protocoles IMAP4 ou POP3 dans Exchange Online, vous devrez les mettre à jour pour qu’elles prennent en charge OAuth avec les messages. De même, pour les applications tierces qui utilisent IMAP4, POP3, renseignez vous sur la date de prise en charge d’OAuth.

Vos applications clientes doivent également prendre en charge OAuth pour POP3 ou IMAP4. Et Microsoft ne prévoit pas pour l’instant qu’Outlook prenne en charge POP et IMAP avec OAuth. Thunderbird, par exemple, est une application utilisée pour lire les messages POP3 et IMAP4 qui prend en charge OAuth.

Il existe des processus pour configurer la prise en charge d’IMAP4 et d’OAuth avec Exchange Online. Cela est extrêmement utile pour le mise à jour de la configuration après la prise en charge d’OAuth.

Préparez-vous à passer à Microsoft Graph et aux politiques d’accès aux applications.

Microsoft a annoncé en juillet 2018 que EWS ne recevrait plus de mises à jour de fonctionnalités. En effet sa stratégie pour le développement d’applications consiste à utiliser les API Microsoft Graph.

Lorsque vous passez d’EWS aux API Graph, vous pouvez avoir besoin de limiter la portée à certaines BAL Exchange Online.

Dans un environnement Exchange sur site, vous pouvez accomplir cela en permettant l’accès EWS aux boîtes aux lettres par l’intermédiaire de l’application impersonation. Le code ci-dessous attribue le rôle ApplicationImpersonation à un groupe de sécurité. Puis il limite la portée de la gestion de ce groupe à certaines BAL, et non à l’unité organisationnelle IT/Users.

 *Notez que nous aurions pu attribuer le rôle à un utilisateur particulier ou à un compte de service au lieu d’un groupe de sécurité.

New-ManagementRoleAssignment -Role "ApplicationImpersonation" -SecurityGroup "ExchSvcAccounts" -RecipientOrganizationalUnitScope "domain.com/IT/Users"

Dans Exchange Online, ce résultat s’obtient en utilisant des politiques d’applications EWS et des appels à l’API Graph

Conclusion

Migrer des boîtes aux lettres sur site vers Exchange Online est une partie essentielle de votre projet de migration. Mais il est impératif de recueillir le volume du trafic de messagerie. Il faut aussi déterminer comment les emails sont générés avant de planifier la mise à jour du code d’application interne.