Friday, March 31, 2017

Exchange 2016 (16) : répartition de charge - Outlook MAPI/HTTP - avec Citrix Netscaler

English summary: with high availability as our objective, we configure a load balancer for client access via MAPI/HTTP to Exchange 2016 mailboxes. In this first section, I concentrate on the creation and configuration of entries for servers, services and virtual servers. There is a problem. We suspect that, like OWA, Outlook MAPI/HTTP requires the importation of an SSL certificate on the load balancer. That will be the subject of the following blog post. Note : we use a Citrix NetScaler VPX for the load balancer.

***

A la fin de mon billet précédent, je me suis donné pour objectif de rendre l'accès client aux boîtes aux lettres le plus fiable possible. Je pourrais me contenter de la méthode "Round Robin" et j'en serais même obligé si je ne disposais pas d'un répartiteur de charge. Mais mon réseau d'essai en compte bien un, et plus précisément un Citrix Netscaler VPX (une version virtuelle du répartiteur). Je m'en suis déjà servi pour des expériences avec Exchange 2010 dans une série de billets de blogue ici (en anglais) :

NetScaler VPX - load balance Exchange - Part 1 (Installation and Configuration)

Dans ce cadre-là, il s'agissait de répartir les connexions RPC pour Outlook (MAPI/RPC). Maintenant que nous en sommes à Exchange 2016 (mais toujours à Outlook 2010 SP2), il s'agit de répartir des connexions HTTP (MAPI/HTTP). Il est vrai que j'ai déjà configuré HTTP à ce moment-là pour OWA et je suis curieux de savoir si je peux faire fonctionner Outlook sur ce modèle.

Quelques remarques...

Je vais m'y prendre en deux parties. Dans ce premier texte (ce que vous lisez en ce moment), je vais mettre en place les fondations pour la répartition du trafic Outlook (MAPI/HTTP). Cependant, à la différence du trafic RPC (et SMTP), le trafic requiert l'utilisation d'un certificat SSL. En effet, même si on écrit "HTTP" il s'agit en fait presque toujours de "HTTPS" (attention à la lettre "S" qui signifie "secure"). Nous verrons qu'à la fin de la configuration, nous aurons des "voyants" rouge dans notre interface, contrastant avec les voyants vert de la répartition SMTP (déjà mise en place).

Dans un texte à suivre (la seconde partie), je vais voir si le fait d'importer un certificat SSL et de l'associer au service HTTP (sur le Netscaler) résout le problème comme il l'a résolu pour OWA dans la série de billets de blogue pour laquelle j'ai mis un lien plus haut.

Je vais présenter les étapes à suivre avec moins de détails que pour Exchange 2010. Je vise avant tout à déterminer ce qu'il faut faire pour répartir le trafic Outlook (MAPI/HTTP). Je n'ai pas l'intention de refaire à l'identique (mais en français) la même présentation qu'en mars 2016. Si vous voulez une présentation plus générale ou plus complète de la répartition de charge (pour Exchange ou pas), je me permets de vous renvoyer à ma première série de textes ou de vous inviter à consulter la documentation disponible en ligne.


***


Je commence par saisir l'adresse IP de l'interface de gestion du NetScaler VPX et j'ouvre une session. Ensuite, je vais à la rubrique "Traffic Management | Load Balancing". Il s'agit de créer les composants suivants :
  • Deux "serveurs" qui représentent nos serveurs Exchange.
  • Un "service" HTTP(S) pour chacun de nos deux serveurs Exchange. Dans d'autres circonstances, nous pourrions en créer pour RPC, IMAP, POP, ou SMTP.
  • Un "serveur virtuel" qui présente le service au clients grâce à son adresse "VIP" (IP virtuelle) vers laquelle ceux-ci sont dirigés via DNS. Nous devons associer les deux services créés pour chacun des serveurs à ce serveur virtuel. Ainsi, tout est relié et fonctionne ensemble.

Dans ce cas, j'ai déjà créé les deux serveurs (il s'agit essentiellement de donner un nom à chaque objet qui les représente et d'en indiquer l'adresse IP qui convient). Voilà ce que cela donne : 



Quant aux services, j'en ai déjà créé pour SMTP (un pour chaque serveur). Faisons-en de même pour HTTP. Dans la section "Services", je clique sur le bouton "Add"... 





Et je configure un service HTTP pour chacun de nos deux serveurs. La forme du nom peut varier selon vos conventions de nommage et n'a pas besoin de ressembler exactement à ce que j'ai mis plus bas dans les captures d'écran. Je sélectionne un serveur existant pour chacun des services. Je choisis "SSL" (le nom choisi pour le service - au lieu de "HTTPS") et le port 443 :







Nous cliquons sur "OK" et nous voyons nos deux nouveaux services :




Ensuite, nous passons à la section "Virtual Servers" où nous en avons déjà un pour SMTP. Ajoutons-en un autre pour HTTP(S) :


(Oui, nous cliquons sur "Add". C'est pourquoi j'y ai mis le point rouge.)


Les paramètres de base sont d'une configuration facile. Je donne un nom au serveur virtuel, je choisis le protocole (SSL) et j'indique l'adresse IP (et port) par laquelle les clients passeront pour accéder au service :




Je clique sur OK et, sur la page suivante, je cherche la section "Services and Service Groups" parmi les propriétés de notre nouveau serveur virtuel, et enfin, j'ouvre la partie "No Load Balancing Virtual Server Binding" : 




Dans la fenêtre qui s'affiche, nous allons créer une association (ou un lien) entre le serveur virtuel et les deux services HTTPS (SSL) que nous avons créés plus tôt pour chacun de nos serveurs Exchange. Nous sélectionnons donc le service...




Ce qui nous amène à cette fenêtre où nous cochons les deux services HTTPS...



Et puis nous cliquons sur le bouton "Bind" :




Nous avons maintenant deux associations :



Mais cela ne semble pas suffire. L'état du virtuel serveur est "Down" (ce qu'on pourrait traduire par hors service) :



***

Changer de "Method" ou de "Persistence" ne change rien. Comme pour mes expériences avec Exchange 2010, je vais devoir essayer d'importer un certificat. Cela résoudra-t-il le problème ? Nous le verrons dans mon prochain billet de blogue. A suivre...

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.



Sunday, March 26, 2017

Exchange 2016 (14) : installation d'un second serveur

English summary : our objective is to install a second Exchange 2016 server in our test environment. We install pre-requisites for Exchange 2016 (CU5) on a second server (EX16-4) and then Exchange 2016 itself from the downloaded .iso file. We then adjust Url domain names on the second server and import the SSL certificate already in use on the first Exchange server (EX16-3). We confirm that no additional configuration of send or receive connectors is necessary (in this environment at least).


***

Maintenant que mon premier serveur Exchange est à CU5, je vais installer Exchange 2016 (CU5) sur un second serveur afin d'expérimenter avec des aspects comme les DAG (Database Availability Groups).

Note : le premier serveur a pour nom "EX16-3" et le second "EX16-4".

Je ne reprendrai pas chaque étape en détail, me contenant de rappeler qu'il faut installer au préalable ce qui suit.

Conditions préalables pour Exchange 2016


1. Installer les rôles et fonctionalités suivants (à la ligne de commande PowerShell) :

Install-WindowsFeature AS-HTTP-Activation, Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

Note : oui, vous pouvez copier et coller. Nul besoin de tout retaper à la main !

En voici une capture d'écran :



2. Installer .NET 4.6.2 (cette version est obligatoire pour Exchange 2016 CU5)

Nous pouvons trouver .NET 4.6.2 à ce site :

https://www.microsoft.com/fr-FR/download/details.aspx?id=53344


3. Installer Microsoft Unified Communications Managed API 4.0, Core Runtime 64 bits

Nous pouvons le trouver ici :

https://www.microsoft.com/fr-FR/download/details.aspx?id=34992


En ce qui concerne le schéma Active Directory, il suffit de le mettre à niveau une seule fois, lors de l'installation du premier serveur Exchange 2016. Nous n'avons nul besoin de répéter le processus pour chaque serveur additionnel. Cela n'accomplirait rien. Une fois que le schéma est mis à niveau (pour une version d'Exchange donnée), il est mis à niveau pour toujours.

En plus des prérequis énumérés ci-dessus, il est, bien entendu, recommandé d'installer les mises à jour Windows habituelles avant d'installer Exchange.


***

Quand tous les éléments sont en place, nous pouvons installer Exchange 2016 CU5. Comme pour la mise à niveau de notre premier serveur, je monte le fichier .iso afin qu'on puisse y accéder comme pour un CD/DVD. Ensuite, j'exécute setup.exe avec les paramètres suivants :

setup.exe /m:install /r:mailbox /IAcceptExchangeServerLicenseTerms



Si tout va bien, ce qui suit devrait s'afficher à l'écran :



A cette étape, je configure le second serveur de manière qu'il soit identique au premier pour les aspects suivants :

  • Les Urls pour ActiveSync, OWA, Exchange Web Services, etc.
  • Les certificats
  • Les connecteurs d'envoi et de réception

En fait, le connecteur d'envoi existe au niveau de l'organisation Exchange et ses paramètres sont ainsi identiques à tous les serveurs Exchange. Concernant le connecteur de réception, il fallait autrefois configurer les permissions pour qu'il puisse recevoir des messages des expéditeurs anonymes à l'extérieur de l'organisation. Depuis Exchange 2013, cette permission est accordée par défaut. Là aussi, donc, nous n'avons aucun ajustement à faire.

Remarque : depuis Exchange 2013, les connecteurs de réception sont multiples. Celui qui nous intéresse s'appelle (même en version française) "Default Frontend EX16-4" (ou "Default Frontend EX16-3" au premier de nos deux serveurs) :


Précision : nous sommes dans la section "Flux de messagerie | Connecteur de réception" de l'EAC.

C'est dans la section "sécurité" des propriétés du connecteur de réception que nous pouvons vérifier que le groupe "utilisateurs anonymes" est coché (par défaut) :



Il nous reste donc à gérer les Urls et le certificat.


URL

Les Urls se gèrent dans la section "serveurs | répertoires virtuels". Nous pouvons afficher tous les répertoires virtuels ou ceux d'un serveur donné, EX16-3 par exemple :



Il s'agit de changer l'Url avec le nom du serveur Exchange en l'Url que j'ai choisi pour mon organisation et qui figure sur notre certificat SSL, soit "mail.machlinkit.biz". Nous l'avons déjà fait pour les répertoires virtuels de notre premier serveur Exchange. Le second qui vient tout juste d'être mis sur pied a encore les Urls spécifiques au serveur (ce que nous ne voulons pas).

Nous pouvons le faire avec un script. J'ai donné au moins deux exemples dans un texte précédent :

Exchange 2016 (1) : Urls et répertoires virtuels

Dans ce cas, je vais me contenter de copier et de coller "mail" pour remplacer le nom de serveur et puis ajouter un Url externe identique à l'Url interne.

Au lieu de ceci (exemple du répertoire virtuel ECP)...



Plutôt cela :



Je répète l'opération pour chacun des répertoires virtuels.

Remarque : comme pour le serveur EX16-3, je dois changer l'Url dans le raccourci sur lequel je clique pour ouvrir l'EAC (en fait, j'ai fini par créér un autre raccourci).



Certificat

Puisque que nous avons déjà un certificat émis par une autorité de certification tierce pour notre premier serveur, EX16-3, il s'agit d'exporter le certificat de ce serveur et puis de l'importer au second serveur, EX16-4.

Cette opération se fait à la section "serveurs | certificats" de l'EAC.

D'abord, nous indiquons le serveur dont nous allons exporter le certificat, EX16-3 dans notre cas :

Note : il faut cliquer sur les trois points (...) pour afficher les options d'exporter et d'importer un certificat.

Nous devons exporter le certificat, sous la forme d'un fichier .pfx, vers un répertoire partagé, par exemple :

\\EX16-3\C$\SW\E2K16A.pfx


Note : puisque le certificat, exporté de cette manière, inclut la clé privée, nous devons protéger le fichier .pfx avec un mot de passe.


Il en résulte un fichier de ce genre :




Ensuite, nous indiquons le serveur où nous voulons importer le certificat, EX16-4 dans ce cas :



Nous saisissons le chemin vers le répertoire partagé du premier serveur (et le mot de passe) :



Nous devons spécifier le serveur où nous souhaitons installer le certificat :








Et voilà ! Le certificat vient d'être importé sur notre second serveur Exchange, EX16-4 :



Mais il faut encore assigner le certificat aux services Exchange appropriés.  Nous désignons le certificat E2K16A (le nom que j'ai choisi faute de mieux et qui n'a aucune signification particulière) et nous cliquons sur l'icône du crayon (voir la capture d'écran ci-dessus). Dans les propriétés de E2K16A, à la section "services", nous cochons les cases qui conviennent à notre milieu :



Il nous sera demandé de confirmer le remplacement du certificat SMTP par défaut :




***

Maintenant que nous avons notre second serveur Exchange, nous pouvons expérimenter avec un certain nombre d'éléments comme la migration de boîtes aux lettres entre serveurs, les DAG (Database Availability Groups) et l'équilibrage de charge.

Thursday, March 23, 2017

Exchange 2016 (13) : mise à jour CU5

English summary: before installing Exchange 2016 CU5 on a second server (so I can experiment with features such as Database Availability Groups  - DAG), I upgrade my existing Exchange 2016 test server with CU5. This is a rather simple procedure. Besides pre-requisites for the original installation, the only new item to install is .NET Framework 4.6.2.

***

A plus long terme, je voudrais expérimenter avec certains aspects d'Exchange 2016 qui nécessitent au moins deux serveurs. Je pense en particulier aux "DAG" (Database Availability Groups).

A cette fin, j'allais installer Exchange 2016 sur un second serveur, mais cette fois avec la version CU5. Cependant, la version d'Exchange 2016 est toujours CU3 sur le serveur déjà en place. Je me suis donc dit qu'il serait préférable de mettre à jour mon premier serveur d'abord, afin que les versions soient identiques. C'est seulement ensuite que je mettrai en place mon second serveur Exchange.

Note : le nom de mon premier serveur est "EX16-3" et le second s'appellera "EX16-4". 

Mais qu'est-ce que CU3, CU5, etc. ? "CU" signifie "cumulative update" qu'on pourrait comparer aux anciens "service packs". C'est un ensemble de mises à jour que Microsoft, à intervalles réguliers, met à la disposition des administrateurs afin de corriger des bogues ou des failles de sécurité. Puisque ces mises à jour cumulatives sont précisément cumulatives, chacune comprend toutes les mises à jour précédentes. Nous pouvons effectuer une toute nouvelle installation avec Exchange 2016 CU5 (nul besoin de commencer par Exchange 2016 RTM et installer ensuite CU1, CU2, CU3, etc.).  

Avant d'installer CU5, il faut que je mette .NET à jour. Notre premier serveur avait la version 4.6.1 mais il faut 4.6.2 pour être compatible avec Exchange 2016 CU5.

Ainsi, je vais mettre à jour .NET et puis passer de CU3 à CU5 en installant ce dernier. Encore une fois, puisque les mises à jour cumulatives sont, justement, cumulatives, nous pouvons passer CU4.

***

Comme dans mes autres textes (billets de blogue), je considère que quelqu'un chargé de la gestion d'un système de messagerie en entreprise devrait savoir chercher les fichiers nécessaires en ligne, les télécharger et les installer. Je ne fournis donc pas une marche à suivre pour ces tâches. Je me contente de signaler ce qui suit.

Les seuls prérequis logiciels pour Exchange 2016 CU5 sont :

  • .NET Framework 4.6.2 (ou plus - en ce moment, c'est la version la plus récente disponible).
  • Microsoft Unified Communications Managed API 4.0, Core Runtime 64 bits

Le second des deux est déjà installé (et ne requiert aucune mise à jour pour à passage de CU3 à CU5). Aucune action de notre part n'est donc requise en ce qui concerne ce logiciel.

Nous pouvons trouver .NET 4.6.2 à ce site :

.NET 4.6.2

(programme d'installation hors connexion)

Et Exchange 2016 CU5 ici :

Exchange 2016 CU5

Note : si vous préférez la version anglaise (ou une autre langue), il suffit de la sélectionner.

Tous les autres prérequis (les rôles et autres composantes) ont été ajoutés peu avant l'installation d'Exchange 2016 CU3 (l'installation originale dans ce cas).


Pour la première étape de la mise à jour, j'installe donc la version 4.6.2 de .NET Framework :




Pour la seconde étape, il faut savoir que les CU se distribuent sous la forme de fichiers .iso. Quand le téléchargement s'achève, je dois monter le fichier de sorte que EX16-3 puisse y accéder comme s'il s'agissait d'un CD ou DVD. La démarche exacte varie selon le système de virtualisation (VMware, Hyper-V, etc.).  Ensuite, je trouve et j'exécute setup.exe pour installer Exchange 2016 CU5 :




Une fois que l'Assistant de mise à jour s'affiche, nous devons décider si nous voulons vérifier les mises à jour avant d'installer CU5. Je fais le choix d'entamer l'installation tout de suite :



Note : nous pouvons toujours vérifier les mises à jour après l'installation de CU5 qui pourrait comprendre certaines des mises à jour que nous aurions autrement installées une à une séparément.


Des fichiers sont copiés...



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


L'Assistant nous informe que nous allons mettre à jour Exchange :



Note : nous cliquerons sur "suivant" ou "terminer" (etc.) selon le cas.


Bien entendu, nous devons accepter les termes du contrat si nous voulons continuer :




L'Assistant effectue des essais (tests) de préparation qui, dans ce cas, ont réussi : 




L'installation se fait en 18 étapes. Les services Exchange sont arrêtés, des fichiers Exchange sont supprimés (ceux de l'ancien version sûrement) et de nouveaux fichiers sont mis en place. Je présente seulement quelques-unes de ces étapes ci-dessous :





Puisque des fichiers Exchange sont supprimés, et que toute installation comporte un risque d'échec, il serait prudent de réaliser une sauvegarde du serveur au préalable.

Dans notre exemple, tout se passe bien :



Après le redémarrage du serveur, je vérifie le bon fonctionnement d'Exchange et observe que "Programmes" indique bel et bien que nous sommes à CU5 :



Parmi les choses à vérifier, je m'assure de ce qui suit :
  • Puis-je ouvrir l'EAC (Exchange Administrative Console) et naviguer parmi les sections ?
  • Puis-je ouvrir l'EMS (Exchange Management Shell) et exécuter des commandes ?
  • En tant que client, puis-je accéder à ma boîte à lettres via Outlook et OWA ?
  • Puis-je envoyer et recevoir des messages ?

***

Maintenant que mon premier serveur est mis à jour avec Exchange 2016 CU5, je vais m'occuper ensuite de l'installation de la même version d'Exchange sur un second serveur.