Migration Messagerie OVH vers Office 365 plan E3

Scénario :

La société A vient d’être rachetée par un grand groupe. La société A possède un système de messagerie basé sur Exchange 2016 entièrement hébergé chez OVH. Le groupe lui possède un ensemble de licence sous Office 365 en Plan E3.
Le groupe souhaite harmoniser ses systèmes de messagerie en hébergeant tout sur Office 365. Il faut donc basculer toutes les messageries de la société A sur le contrat O365 du groupe.

Situation de départ :

  • 1 domaine hébergé chez OVH : mdutech.com
  • 1 Abonnement Exchange 2016 (hosted) toujours chez OVH
  • ~40 boites aux lettres hébergées sur l’Exchange OVH
  • 1 contrat Office 365 plan E3

Situation souhaitée :

  • Avoir toutes les BAL hébergées sur Office 365
  • Continuer à pouvoir gérer les BAL à la fois sur O365 et sur OVH pour faire une migration par étape. Je ne voulais pas migrer tout le monde d’un coup tout en gardant une continuité de service.
  • Récupérer les mails, contacts et agenda de mes utilisateurs

Méthode utilisée : Migration partielle des BAL

Au départ je souhaitais migrer mes BAL via la méthode à basculement proposée par Microsoft. Ca m’aurait permis de faire une vraie migration de boite aux lettres (mails + contacts + calendrier). Malheureusement je n’ai pas pu aller au bout de cette idée à cause d’un pré-requis : Désactiver la synchro de l’annuaire Active Directory sur Office 365. En effet sur mon contrat O365, je gère d’autres sociétés et pour l’une d’entre elle, j’ai besoin de garder cette option active. J’avais donc pas le choix d’utiliser une autre méthode.
Avec la migration partielle je vais repartir d’une nouvelle boite aux lettres pour chaque utilisateur et ensuite récupérer les données.

Plan d’action


Etapes de préparation :

  1. Création du domaine mdutech.com dans O365
  2. Configuration du serveur O365 en serveur relais Interne
  3. Configuration du serveur Exchange OVH en mode non autoritatif
  4. Création de tous les utilisateurs sur O365 sans licence exchange
  5. Modification des MX + SPF + Autodiscover chez OVH
Une fois les étapes ci dessus réalisées, mon serveur O365 devient le serveur de messagerie principal. Tous les mails envoyés sur une adresse en @mdutech.com contacteront mon serveur O365. Si celui-ci ne trouve pas la boite aux lettres correspondante au destinataire (ce qui est le cas étant donné que nos utilisateurs n’ont pas encore de licence Exchange Online), il redirigera le mail vers le serveur OVH qui lui redistribuera le message au destinataire (OVH héberge encore là boite aux lettres de l’utilisateur). Et vice-versa.

Etapes de migration :

  1. Attribution de la licence Exchange Online à l’utilisateur Toto
A la fin de ces étapes, Toto aura sa boite active sur O365. Tous les nouveaux mails arriveront dessus
 

Etapes Post-Migration :

  1. Export \ Import du pst de Toto
  2. Export \ Import des contacts de Toto
  3. Reconfiguration de la messagerie sur le client Outlook de Toto
  4. Reconfiguration de la messagerie sur l’IPhone de Toto
A ce moment toto aura récupéré tous ces mails, contacts et agendas. La migration sera donc terminée

Procédures


Création du domaine O365

La première étape consiste à ajouter le domaine mdutech.com sur Office 365. Cette étape peut être réaliser sans risque

Se connecter sur l’interface d’administration d’O365 => Paramètres => Domaines => Ajouter un Domaine

Entrez le nom du domaine : mdutech.com

La prochaine fenêtre indique quels enregistrements il va falloir ajouter dans la zone DNS d’OVH pour prouver qu’on est bien le propriétaire du nom de domaine mdutech.com

Il faut donc se connecter maintenant sur le manager OVH => Domaines => mdutech.com => Zone DNS

Ajouter l’enregistrement txt indiqué à l’étape précédente en cliquant sur ajouter une entrée (laissé le champ sous-domaine vide) :

Il faut ensuite patienter. D’après l’hébergeur ça peut prendre 24h avant que l’information se diffuse. Pour mon cas ça a duré 15 minutes.

Passé ce délais, on peut revenir sur O365. il va nous demander de mettre à jour les paramètres DNS pour les différents services Microsoft. Pour l’instant on ne va pas le faire et donc cliquez sur « Ignorer cette étape ». On les configurera par la suite.

Notre domaine est donc maintenant rajouter et valider (même si il y a un point d’exclamation pour les enregistrements DNS). On peut donc passer à la suite et configurer les relais.

Configuration du serveur O365 en serveur relais Interne

Cette étape est importante. Vu que je vais migrer mes utilisateurs au compte goutte, je dois m’assurer que les mails des personnes non migrés continuent d’arriver sur la boite mail OVH. Ca tombe bien ! C’est exactement le rôle de la fonction « Relais Interne » proposée sur O365 : Si il ne trouve pas la boite aux lettres sur O365, il redirigera le mail sur OVH. C’est pas beau tout ça 🙂

Se connecter au Centre d’Administration Exchange (CAE) sur O365 => Flux de messagerie => Domaines acceptés

Là j’y retrouve mon domaine mdutech.com avec comme information dans la colonne Type de domaine : « Faisant autorité ». C’est justement ça que je veux changer

J’édite donc mon domaine et je sélectionne : « Est un relais Interne » puis j’enregistre

Ensuite je vais sur l’onglet « Connecteurs » qui va me permettre d’indiquer vers quel serveur les mails @mdutech.com qui n’ont pas de boite aux lettres sur O365 doivent être redirigés :

J’ajoute un connecteur et j’indique mon scénario : Les mails venant d’O365 vers un serveur de messagerie de mon organisation (OVH)

Je donne ensuite un nom au connecteur et je pense bien à cocher les deux cases pour l’activer et conserver les entêtes de message.

J’indique ensuite que je souhaite utiliser ce connecteur uniquement pour les mails envoyés aux adresses @mdutech.com

Esnuite j’indique le nom du serveur OVH : Attention j’ai mis « ex2.mail.ovh.net », si jamais votre Exchange OVH est en 2013, il faudra mettre : « ex.mail.ovh.net

Je ne mets pas de critères de sécurité :

Pour vérifier que ça fonctionne, le wizard me demande une adresse de messagerie mdutech.com chez ovh.

L’état est bien en réussite, mon relais interne sur O365 est donc bien configuré. Je peux passer à la suite.

Dans cette configuration, OFFICE 365 renvoie les mails vers OVH mais n’accepte pas automatiquement ceux venant d’OVH. Il faut donc créer un connecteur inverse : Les mails venant d’un serveur de messagerie de mon organisation (OVH) vers Office 365.

 

Configuration du serveur Exchange OVH en mode non autoritatif

Maintenant il faut que je fasse la même chose du coté OVH pour que les mails soient automatiquement renvoyés à O365 si il ne trouve pas la BAL sur OVH. Ce qui sera le cas pour les utilisateurs migrés.

La notion de relais interne n’existe pas sur OVH. On parle de mode Autoritatif ou non Autoritatif.

L’opération est assé simple. il suffit d’aller dans son manager OVH => Microsoft => Exchange => Hosted-xxx

Ensuite sur la ligne du domaine concerné (mdutech.com), je clique sur configuration et je modifie les informations comme ceci :

Mode : Non Autoritatif

Serveur mail cible : smtp.outlook.office365.com

Si je résume nous avons donc maintenant :

  • Notre domaine MDUTECH.COM qui est reconnu sur O365
  • O365 de configuré pour renvoyer les mails @mdutech.com vers OVH si la BAL n’est pas gérée sur O365
  • OVH de configuré pour renvoyer les mails @mdutech.com vers O365 si la BAL n’est pas gérée sur OVH

 Création des utilisateurs dans O365

On arrive presque au bout 🙂

Je vais maintenant créer mes utilisateurs dans Office 365 mais je ne vais pas leur attribuer de licence Exchange Online. Comme ça Office 365 verra que leur boites aux lettres ne sont pas gérés chez lui et renverra les mails sur OVH.

Du coup je vais sur le portail O365 => Ajouter un utilisateur et je prend soin de désactiver la licence Exchange Online. Je l’activerai que lorsque je voudrais migrer un utilisateur.

Les choses sérieuses vont commencer maintenant…

Modification des MX + SPF + Autodiscover chez OVH

La modification du MX chez OVH pour le remplacer par celui d’O365 est une étape cruciale. En effet, si les opérations ci-dessus ont été mal effectuée, vous pourrez rencontrer des problèmes de réception ou d’envoie de mails.

Pour rappel : L’enregistrement MX sert à identifier le serveur de messagerie qui gère nos boites aux lettres.

Je vais donc créer chez OVH un nouvel enregistrement de type MX pour lui dire que c’est O365 le serveur de messagerie qui traite les mails envoyés à @mdutech.com

Pour avoir les informations à renseigner, il faut regarder dans le centre d’administration d’O365 => Paramètres => Domaines => MDUTECH.COM : A droite on voit tous les champs DNS à rajouter. Tous les enregistrements ne sont pas nécessaire pour le besoin de migration de messagerie. Pour la messagerie il faut obligatoirement les 3 ci-dessous (MX + SPF + Autodiscover)

Je retourne donc dans mon manager OVH => Domaines => Zone DNS => Ajouter une entrée

Ajout du champ MX :

Microsoft m’indique de renseigner les informations suivantes :

Type : MX
Priorité : 0
Nom d’hôte : @
Adresse de pointage ou de valeur : mdutech-com.mail.protection.outlook.com
Durée de vie : 1 heure
 
Ce qui nous donne sur OVH ceci à remplir (attention de bien mettre un point à la fin de la ligne « cible » sinon vous aurez un message d’erreur). Microsoft ne nous le dis pas ça 😉
 

Ajout du champ SPF :

Cet enregistrement est très important. Il va permettre de valider les serveurs qui envoie du mail (OVH et O365). Beaucoup de serveur de destination refuse le mail si cet enregistrement n’est pas présent ou mal renseigné.

Microsoft m’indique de renseigner les informations suivantes :

Type : TXT
Priorité :
Nom d’hôte : @
Adresse de pointage ou de valeur : v=spf1 include:spf.protection.outlook.com -all
Durée de vie : 1 heure
 
Ce qui donne dans OVH :
 
J’en profite pour parler de l’erreur que j’ai rencontré : Certains utilisateurs non migrés (donc encore sur OVH) recevaient des mails de non remise de la part de certains serveurs distant quand ils essayaient d’envoyer des mails vers un domaine externe. Pour certains domaines distant ça marché, pour d’autre non.
Le message qu’ils recevaient été le suivant : 5.7.1 smtp; 550 5.7.1 SPF unauthorized mail is prohibited 
 
En fait j’avais bien rajouté le SPF pour O365 mais je me suis rendu compte que celui d’OVH n’était pas présent (je ne sais pas si c’est moi qui l’ai supprimé par mégarde ou si il n’y en avait pas besoin jusque là). Ce qui faisait que les serveurs distants qui demandés cet enregistrement refusé tous les mails envoyés depuis OVH.
Quoiqu’il en soit pour résoudre le problème, j’ai dû rajouter un autre enregistrement SPF dans ma zone DNS OVH :
 
Ajouter une entrée => Type SPF : Il faut juste rajouter cette ligne dans le champ Include : include:mx0.ovh.net
 

Ajout du champ AutoDiscover :

Cet enregistrement aide à la configuration des clients. Notamment sur Outlook, c’est lui qui va permettre de juste renseigner votre adresse mail et votre mot de passe pour configurer votre client. Sinon il faudrait renseigner manuellement les paramètres serveurs.

Microsoft m’indique de renseigner les informations suivantes :

Type : CNAME
Priorité :
Nom d’hôte : autodiscover
Adresse de pointage ou de valeur : autodiscover.outlook.com
Durée de vie : 1 heure
 
Ce qui donne sur OVH :
 
Attention, une fois l’enregistrement Autodiscover pour O365 ajouter, il faut supprimer celui d’OVH (_autodiscover._tcp.corialis.com)
 
Mes enregistrements sont maintenant tous configurés, la messagerie doit donc être opérationnelle à la fois sur OVH et sur O365. Je vais pouvoir commencer à basculer mon premier utilisateur sur O365.

Attribution de la licence Exchange Online à l’utilisateur toto@mdutech.com

Voilà j’y suis, c’est le moment de vérité et je décide de basculer mon utilisateur toto sur Office 365 :

Je me connecte donc sur le Centre d’Administration d’O365 => Utilisateurs actifs.
Je recherche mon compte toto et je modifie ces licences pour lui rajouter « Exchange Online ».

Le fait de lui attribuer cette licence va lui créer une boite aux lettres toute neuve sur O365. Du coup, comme O365 détecte qu’il gère bien la BAL de toto, il va bien distribuer tous les nouveaux mails envoyés à son adresse sur la BAL O365. Il ne redirigera plus les mails vers sa BAL OVH.

J’ai donc mon utilisateur Toto qui se retrouve avec une nouvelle BAL sur O365, les nouveaux mails qui arrivent bien dessus mais il ne va pas être content si je ne lui récupère pas les anciens mails qui sont encore stockés sur OVH.

Export \ Import du PST de Toto

Le but de cette étape est de permettre à Toto d’accéder à ces anciens mails directement depuis sa nouvelle boite O365. Pour cela je vais utiliser une option chez OVH qui me permet d’exporter directement la bal de toto en format PST depuis le manager. Et une autre option d’O365 ce coup-ci qui me permet d’importer le pst directement dans la BAL O365. Petite précision, ce n’est pas un ajout de fichier pst mais bien un import. Les anciens mails seront accessible aussi bien depuis le client Outlook que du Webmail.

Export du PST depuis OVH Manager :

OVH Manager => Microsoft => Exchange => Hosted-xxx => Comptes courriel

A partir de là je recherche mon utilisateur Toto.
Je clique sur la petite roue dentée => Exporter en pst

Ca va me générer un lien valide 10 minutes pour télécharger le fichier PST. Quelque fois ça ne marche pas et ça mouline pour me donner le lien. Du coup je réessayer un peu plus tard et là ça remarche… Mystère…

Voilà on a un beau fichier PST, il nous reste plus qu’à l’importer.

Import du PST depuis O365 :

L’import est plus complexe que l’export et nécessite quelques outils : La clé SAS + AzCopy + Le fichier de mappage. Mais rien de bien complexe non plus, il suffit de pas se tromper.

Centre d’administration O365 => Utilisateurs => Migration de données (si la page ne s’affiche pas, passez par la version classique du centre d’administration (=> Importation)

En cliquant sur le + on va choisir de télécharger des messages électroniques (pst) et ça va nous ouvrir l’assistant :

Je clique sur : Afficher l’url SAS de chargement réseau

Une fois l’url afficher le la copie dans un fichier texte car elle me servira plus tard

Ensuite je clique sur télécharger l’outil Azure AzCopy : C’est un outil en ligne de commande qui va nous permettre d’envoyer notre pst chez Microsoft. Laissez les paramètres par défaut lors de l’installation

Je télécharge le fichier de mappage : Là c’est étrange qu’ils n’indiquent pas le lien pour le trouver. Donc le voici : https://technet.microsoft.com/fr-fr/library/mt644809.aspx#step4 (étape 4 : créer le fichier de mappage d’importation PST).

Voilà donc on a notre clé SAS, Azcopy d’installé, Un exemple de fichier de mappage

Je laisse la fenêtre d’assistant ouverte et je suis prêt à commencer :

1 : Téléchargement de mon fichier pst avec AzCopy :

Je lance donc l’outil AzCopy et me retrouve avec une fenêtre de commande/

La ligne de commande à taper et la suivante :

AzCopy.exe /Source: »D:\IT\O365 Migration\toto » /Dest: »URL SAS » /V: »D:\IT\O365 Migration\AzCopyToto.log »

/source : Correspond au dossier où se trouve mon fichier pst

/dest : Correspond à l’URL SAS recopiée tout à l’heure

/V : Correspond au fichier de log que la copie va générer

La copie est rapide chez moi

2 : Configuration du fichier de mappage :

Le fichier de mappage est un csv classique. Il ne faut surtout pas supprimer la première ligne qui indique les entêtes de colonnes.

Voilà comment j’ai configuré le mien :

Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,SPFileContainer,SPManifestContainer,SPSiteUrl
Exchange,,toto.pst,toto@mdutech.com,FALSE,Import-OVH,,,    

Workload : correspond au service O365 où les données seront importé. Dans notre cas c’est le service Exchange. On peut aussi importer des données Sharepoint

FilePath : c’est le chemin d’accès du fichier pst que l’on souhaite importer. Vu qu’on a pas spécifié de chemin avec AzCopy, on laisse vide. Ca prendra le chemin par défaut

Name : correspond au nom du fichier pst qu’on souhaite importer : toto.pst

Mailbox : Correspond à la boite mail dans laquelle on veut importer le fichier : toto@mdutech.com

IsArchive : Nous permet de spécifier si on veut que le pst soit importer dans l’archive user ou non : Ici je veux qu’il soit dans la boite principale donc FALSE

TargetRootFolder : Je veux qu’il soit à la racine de la boite principale et qu’il s’appelle Import-OVH

Vous aurez plus d’info sur les paramètres du fichier de mappage sur ce lien : https://technet.microsoft.com/fr-fr/library/mt644809.aspx#step4

3 : je reviens sur la fenêtre d’assistant et je coche les deux cases avant de cliquez sur suivant :

  • J’ai terminé le téléchargement de mes fichiers
  • J’ai accès au fichier de mappage

4 : Je donne un nom à ma tâche d’importation : mdu-test

5 : J’ajoute mon fichier de mappage et je clique sur valider.

6 : Une fois valider je coche comme quoi j’accepte les conditions générales et c’est partie pour l’importation.

La ça peut prendre du temps. De mon coté je suis à ce ration à peu près : 100Mo/10min

Une fois l’opération terminé, toto verra dans sa boite aux lettre un nouveau dossier : Import-OVH où il retrouvera tous ces anciens mails.

Reste les contacts à gérer

Export \ Import du PST de Toto

Pour les contacts c’est plus rapide :

L’export se fait depuis le client Outlook (encore configuré en OVH) de Toto

Fichier => Ouvrir et Exporter => Importer/Exporter => Exporter des données vers un fichier => Valeurs séparées par une virgule => Sélection du dossier contact => ne pas mettre de mot de passe => Exporter.

On a donc un beau fichier csv qu’on peut importer dans la BAL de Toto.

C’est à Toto de faire cette manipulation. Pour cela il faut qu’il se logue avec son compte O365 : https://login.microsoftonline.com/fr

Ensuite en cliquant en haut à gauche (l’icone faite d’un ensemble de carré), il doit cliquer sur Contact pour arriver à la page de gestion de ses contacts.

Et enfin pour les importer il faut cliquer sur Gérer => Importer des contacts.
Là il choisi le fichier csv exporter à l’étape précédente et cliquez sur Charger.

Voilà la procédure bien décrite par Microsoft :

Eh ben voilà, on est bon une fois qu’on a fait ça. Juste un dernier truc à faire : Configurer le client Outlook et le Pushmail sur l’IPhone :

Pour Outlook :

Il suffit d’aller dans Fichier => Paramètres du compte et cliquez sur Réparer pour le compte en question (vous admirerez mon beau screenshot :

Normalement il doit retrouver tout seul les paramètres liés à l’Office 365 et donc reconfigurer le client comme il faut. Attention avant de reconfigurer le client de l’utilisateur, il faut exporter ces contacts.

Pour l’iphone :

Il faut aller dans réglages => Mails, contacts, Calendrier

Choisir la boite aux lettres de toto@mdutech.com

Cliquez sur le nom du compte

Changez l’adresse du serveur par : Outlook.office365.com

Retapez bien le mot de passe

Validez

Il faut attendre environ 5 minutes avant que la boite aux lettres se mette à jour

Et voilà c’est fini.

J’ai mon utilisateur Toto qui peut utiliser sa boite aux lettres avec son compte O365.

  • Il reçoit bien les mails et peut en envoyer avec son adresse toto@mdutech.com
  • Il a ses anciens mails, calendrier et contacts accessibles
  • Mes utilisateurs non migrés reçoivent et peuvent aussi envoyer des mails en mdutech.com
Donc tout est bon, la migration pour cet utilisateur est fini, je peux enchainer maintenant avec les autres !!!!