Wednesday, March 29, 2017

Exchange 2016 (15) : migration d'une boîte aux lettres

English summary : I migrate some mailboxes from a mailbox database on my first Exchange 2016 server (EX16-3) to a mailbox on my second Exchange 2016 server (EX16-4). I want to observe the behavior of Outlook and the user experience. What warnings, if any, display? Must the user close and re-open Outlook after the migration? What if the mailbox is open in Outlook during the migration?

*** 

Dans ce texte, notre objectif sera de faire migrer une boîte au lettres (BAL) d'une base de données sur notre premier serveur, EX16-3, vers notre second serveur, EX16-4. Il s'agit d'observer un certain nombre de choses, parmi lesquelles :
  • Le comportement des clients comme Outlook et l'expérience de l'utilisateur. Quand la BAL migre vers l'autre base de données, que voit l'utilisateur ? Un message s'affiche-t-il ? Faut-il rouvrir Outlook ? Pouvons-nous faire migrer une BAL pendant qu'Outlook est ouvert et que l'utilisateur travaille là-dedans ? Note : la version d'Outlook que nous utilisons dans ces expériences est toujours 2010 SP2.
  • La capacité d'un premier serveur Exchange à gérer une connexion à une BAL se trouvant dans une base de données abritée par un second serveur Exchange. Pour le moment, notre enregistrement DNS pour "mail" ne désigne toujours que l'adresse IP de notre premier serveur (EX16-3). Cependant, la BAL, après migration, se trouvera au second serveur (EX16-4).

***


Nous commençons la migration à la section "destinataires | migration" de l'EAC (Centre d'administration d'Exchange). Nous cliquons sur le signe " + " et choisissons l'option "Déplacement vers une base de données différente" : 



Note : vous pouvez cliquer sur les images pour les agrandir.


A l'étape suivante, nous devons sélectionner les utilisateurs dont nous voulons déplacer la BAL. Nous cliquons encore une fois sur le signe " + " et (dans cet exemple) choisissons Karen Roberts :



 Nous cliquons sur "ajouter" et puis OK :



Note : je ne vais pas préciser pour chaque étape "Cliquez sur OK" ou "nouveau" ou "Terminer". Je suppose que le lecteur sait ce qu'il faut faire pour passer à l'étape suivante.


Et voilà Karen Roberts sélectionnée pour la migration :




Nous donnons un nom à ce lot de migration afin de le distinguer des autres lots que nous pourrions être amenés à créer, nous indiquons s'il faut faire migrer la BAL principale seulement, la BAL d'archivage seulement, ou les deux, et enfin, nous désignons la base de données cible :



Note : en cliquant sur "Parcourir", nous sommes amenés à sélectionner la base de données cible ainsi :






Ensuite, nous désignons un destinataire à qui un rapport de migration sera expédié et décidons si nous voulons faire démarrer la migration tout de suite ou plus tard. Nous avons un choix similaire pour terminer la migration : 



Dès que nous cliquons sur "nouveau" ("nouveau lot"), nous retournons à l'écran d'origine où nous pouvons observer l'état de la migration (en effet, j'ai choisi de lancer la migration tout de suite) :



Si tout va bien, nous devrions voir, à la fin de la migration, le chiffre 1 dans la colonne "Finalisé" :


Note : bien sûr, ce chiffre varie selon le nombre de migrations réussies.


***

Quant à la perspective de l'utilisateur, qu'observe-t-on pendant et après la migration ? En fait, j'ai effectué deux migrations. La première, de la BAL de Karen Roberts, présentée ci-dessus, s'est faite avec Outlook fermé. Quand Karen ouvre Outlook après la fin de la migration, tout se passe comme d'habitude. Aucun avertissement n'indique que la BAL vient d'être déplacée et qu'il faut fermer et rouvrir Outlook en conséquence. Il n'est pas non plus nécessaire de réparer l'installation d'Outlook ou de recréer le profil. La migration n'a donc eu aucun effet sur l'expérience de l'utilisateur.

La seconde migration ciblait la BAL de Mark Patel. J'ai suivi les mêmes étapes déjà présentées mais cette fois-ci Outlook restait ouvert. Agissant donc en tant que Mark Patel, j'ai pu laisser ouvert Outlook et envoyer des messages sans jamais devoir rouvrir l'application. L'accès à la BAL n'a jamais été interrompu. C'est tout juste si pendant un instant, en passant d'un répertoire à un autre (Boîte de réception, Eléments envoyés, Eléments supprimés, etc.) tel répertoire paraissait vide avant que l'affichage se rafraîchisse et que tout se présente normalement.

Ce résultat me semble d'autant plus encourageant que le mode cache (Cached Exchange Mode)  pour les utilisateurs en question n'est pas coché et que ceux-ci ont une interaction directe avec leur BAL (la raison pour laquelle je préfère effectuer ainsi ces essais dépasse le cadre de ce texte).

Sans en être certain à 100%, je crois que cette bonne expérience utilisateur doit beaucoup à ce qui est maintenant le protocole par défaut pour les connexions Outlook : MAPI/HTTP(S). J'ai traité de MAPI/HTTP dans un billet précédent et donné ce lien pour ceux qui aimeraient en savoir plus long sur ses avantages :

Outlook Connectivity with MAPI over HTTP

Mais si l'expérience utilisateur s'améliore grâce à MAPI/HTTP, la configuration de nos services accès client n'est pas optimale. En effet, dans notre zone DNS, l'enregistrement "mail" ne désigne que l'adresse IP de notre premier serveur Exchange. Qu'arriverait-il si ce serveur était en panne ? Cela constitue une sorte de "point de défaillance unique" que nous devrions corriger.

La solution la plus simple serait de configurer "round robin" dans notre DNS, c'est-à-dire deux entrées identiques qui désignent chacune un serveur différent :

mail > 10.4.1.16 (EX16-3)
mail > 10.4.1.17 (EX16-4)

Les demandes seraient réparties entre les deux serveurs, à tour de rôle, tantôt vers le premier et tantôt vers le second. Ce serait mieux que rien mais c'est encore loin d'être idéal. Il faut savoir que DNS n'est pas capable de vérifier la disponibilité effective d'un serveur. Même si le premier serveur était en panne, DNS continuerait à lui expédier (la moitié) des demandes de connexion. Bien entendu, ces tentatives seraient vouées à l'échec.

La mise en place d'un répartiteur de charge (load balancer) est une meilleure solution et c'est celle que je vais exploiter dans mon prochain texte. Parmi d'autres capacités (variables selon les modèles), le répartiteur de charge est en mesure d'évaluer la disponibilité des serveurs par le simple envoi d'un "ping" ou par des moyens plus évolués. Si le serveur ne répond pas dans un certain délai, le répartiteur expédie les requêtes de service vers d'autres serveurs.



No comments:

Post a Comment