Monday, June 26, 2017

Exchange 2016 (24) : le mode maintenance pour le DAG (1)

English summary: with Exchange 2010, we could place Database Availability Group (DAG) servers in maintenance mode with a simple script. Since Exchange 2013, this is supposedly no longer possible or at least recommended. After consulting various sources (cited at the end of the text), I demonstrate the method that worked for me. It is essentially a matter of executing a number of PowerShell cmdlets that modify not only the status of the DAG but also Client Access and Transport functions.

***

La mise en mode maintenance pour les DAG (Database Availability Groups) ne fonctionne plus de la même manière pour Exchange 2016 (ou 2013) que pour Exchange 2010.

Avec Exchange 2010, il s'agissait d'exécuter le script ci-dessous pour la mise hors ligne du serveur auquel on allait appliquer des mises à jour de sécurité (ou autres) :

StartDagServerMaintenance.ps1

Après l'installation des mises à jour (et le redémarrage du serveur), il suffisait d'exécuter le script ci-dessous pour remettre le DAG en ligne :

StopDagServerMaintenance.ps1

Il convient de préciser que si le serveur tenait des copies dites "actives" des bases de données, ou bien le rôle "PAM" (Primary Active Manager) avant la mise hors ligne, l'exécution du second script ne rétablissait pas le statu quo antérieur. Il fallait déplacer les ressources qu'on voulait remettre au serveur en question par une opération distincte.

De plus, le script n'agissait que sur le fonctionnement du DAG. Les autres rôles (accès client et transport) ne subissaient aucun effet.

Avec Exchange 2016, ces scripts sont toujours disponibles mais il paraît que nous ne devons pas les utiliser (si j'ai bien compris les discussions à ce sujet sur divers forums en ligne dont les forums Exchange de TechNet).


Il faut plutôt suivre le processus que je vais présenter dans les lignes suivantes.


***


Voici le statu quo à notre point de départ. Nous allons mettre en mode maintenance le serveur EX16-4 qui tient la copie active de la base de données MBXDB-01 ainsi que le rôle "PAM" de notre DAG :






1. Purger les files d'attente

Nous commençons le processus par l'exécution de cette commande :

Set-ServerComponentState EX16-4 -Component HubTransport -State Draining -Requester Maintenance

Dans mon réseau d'essai, les files d'attente sont déjà vides. Les voici avant l'exécution de la commande :


C'est à peu près pareil sur EX16-3 :


De plus, je n'observe aucun changement après l'exécution de la commande.




2. Faire redémarrer deux services Transport

En fait, il est recommandé de faire redémarrer deux services Transport afin que le changement prenne effet tout de suite...

Restart-Service MSExchangeTransport

Restart-Service MSExchangeFrontEndTransport

Note : certaines sources que j'ai consultées ne mentionnent que le premier service.

Note : je me trouve au serveur EX16-3 mais je veux que ces commandes agissent sur le serveur EX16-4. Entre autres options, je peux recourir à "Invoke-Command" :




Mais quel effet ces commandes ont-elles ?

D'une part, des messages s'accumulent dans la file d'attente "ShadowRedundancy" du serveur EX16-4 (ce sont des messages de la boîte "Health Mailbox [GUID]")

D'autre part, le serveur EX16-3, lui, perd sa file d'attente "ShadowRedundancy" :


Note : il faudra que je me renseigne sur le rôle de ces messages qui s'accumulent dans la file d'attente du serveur EX16-4. Je pose comme hypothèse qu'ils doivent avoir une fonction de "message de vie" pour vérifier la voie de communication entre les deux serveurs.



3. Rediriger des messages en attente de livraison vers d'autres serveurs

Il s'agit d'exécuter cette commande :

Redirect-Message -Server EX16-4 -Target EX16-3.machlinkit.biz


Note : il faut, paraît-il, utiliser le FQDN du serveur cible.




4. Déplacer le rôle "PAM" vers un autre membre du DAG

Nous utilisons deux sortes de commandes PowerShell pour gérer le cluster (le DAG se bâtit sur la fondation du service cluster de Windows) :

*-ClusterNode
*-ClusterGroup

Pour observer le statu quo, nous utilisons...

Get-ClusterNode
Get-ClusterGroup




Je constate que le serveur EX16-4 est le propriétaire du nœud pour le groupe du cluster "Groupe du Cluster".

Note : c'est pareil dans la version originale anglaise : le "Cluster Group" a pour nom "Cluster Group". 

Je fais du serveur EX16-3 le propriétaire du nœud avec la commande suivante (et il faut bien utiliser le nom français) :

Move-ClusterGroup "Groupe du cluster" -Node EX16-3



Et cela revient à transférer le rôle PAM vers EX16-3... mais sans mettre EX16-4 hors ligne.

Observez que l'état du nœud est toujours "Up") :



Ainsi, nous devons également suspendre EX16-4 afin qu'on ne puisse pas lui renvoyer le rôle PAM en plein entretien par mégarde : 

Suspend-ClusterNode EX16-4


Note : cela n'a aucun autre effet sur le DAG (capture d'écran ci-dessus).




5. Déplacer les bases de données actives vers un autre membre du DAG

Jusqu'à présent, nous nous sommes occupés des services Transport et du cluster. Il nous reste encore un certain nombre de tâches à accomplir et en particulier le déplacement des copies actives vers un autre membre du DAG. Nous y parvenons avec cette commande : 

Set-MailboxServer EX16-4 -DatabaseCopyActivationDisabledAndMoveNow $True


Attention ! Il faut un moment (quelques minutes au moins) pour que le déplacement s'achève. Quand j'ai exécuté la commande...

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus

une première fois, la copie active se trouvait toujours sur EX16-4. Il a fallu attendre encore quelques minutes avant d'observer le résultat désiré :





6. Bloquer la possibilité d'activation 

Comme pour les services de cluster, nous devons empêcher la copie active de revenir au serveur EX16-4 pendant la maintenance, ce qu'accomplit cette commande :

Set-MailboxServer EX16-4 -DatabaseCopyAutoActivationPolicy Blocked





7. Mettre le serveur en mode maintenance (services Accès client)

C'est ainsi que certaines sources décrivent cette dernière étape bien que le processus de mise en maintenance ait réellement commencé plus tôt. Voici la commande à exécuter :

Set-ServerComponentState EX16-4 -Component ServerWideOffline -State Inactive -Requester Maintenance


Cette commande agit notamment sur les services Accès client (CAS). Le serveur, mis en mode maintenance, ne répond plus, en principe, aux messages de vie des répartiteurs de charge (load balancer heart beats).

En fait, cette commande ne semble rien changer si on considère l'état des services vu de mon répartiteur de charge (Citrix NetScaler VPX) :



Quant aux services Transport, nous devrions veiller à ce que les files d'attente soient effectivement purgées. Mais qu'arriverait-il aux messages encore dans les files d'attente après l'exécution de cette commande ? Les messages en cours de traitement par les services Transport sont stockés dans une base de données. A priori, ils y seraient retenus pendant l'arrêt du service Transport et traités seulement à la remise en marche de celui-ci. Ils ne seraient pas perdus comme s'ils n'existaient que dans la mémoire vive.

Quoi qu'il en soit, nous vérifions l'effet de cette dernière commande avec sa variation "Get" :

Get-ServerComponentState EX16-4

Toutes les composantes, sauf "Monitoring" et "RecoveryActionEnabled" devraient avoir, pour la propriété "State" (état), la valeur "Inactive" :




***

A cette étape, nous pouvons (enfin) accomplir ce que nous avons à faire (installer des mises à jour de sécurité, par exemple).

Dans les lignes ci-dessus, j'ai cherché non seulement à présenter la marche à suivre mais aussi à vérifier pour moi-même si les commandes ont l'effet escompté. Il en résulte que le texte s'est allongé plus que je m'y attendais. De ce fait, je remets à plus tard la présentation de la remise en ligne du serveur.


Liens

Managing database availability groups - Exchange 2016

C'est la version anglaise originale.

La procédure présentée dans ce texte consiste...
  1. A exécuter certaines des commandes que j'ai utilisées plus haut.
  2. A exécuter le script StartDagServerMaintenance.ps1 (nommé à tort "StartDagServerMaintenanceScripts.ps1") comme avec Exchange 2010.
  3. A exécuter encore d'autres commandes utilisées dans mon billet de blogue ici.

En traduction française :

Gestion de groupes de disponibilité de base de données

---

Exchange 2013 Maintenance mode

La procédure est valable pour Exchange 2016 mais j'ai remarqué que la commande Suspend-ClusterNode ne déplace pas le PAM vers un autre membre du DAG. Il faut d'abord utiliser la commande Move-ClusterGroup.

---

Installing Cumulative Updates on Exchange Server 2016 - Paul Cunningham

Le sujet concerne l'installation des mises à jour mais l'auteur (fort respecté dans la communauté Exchange) présente sa façon de mettre les serveurs en mode maintenance.

Sunday, June 11, 2017

Exchange 2016 (23) : récupération d'un serveur membre d'un DAG (3)

English summary: after reinstalling our failed Exchange 2016 server with the /recoverserver parameter, reconfiguring the client access Urls and the SSL certificate (see previous blog post), we readd the recovered server to the DAG and create a copy of the MBXDB-01 database on the recovered server. Various functions are tested (client access, send/receive email) and we consider the interaction with our load balancer. Lastly, I point out that there may be other elements to reinstall and reconfigure such as the antivirus and backup programs


***
 

Maintenant que le serveur EX16-3 est remis sur pied, nous sommes prêts à le rajouter à notre DAG et à lui ajouter une copie de la base de données MBXDB-01.


Voici notre point de départ...

Seul le serveur EX16-4 fait partie du DAG en ce moment :



Les lecteurs E: et F: du serveur EX16-3 sont vides :



Voici, par exemple, le contenu du lecteur E: (rien) :



Si nous mettons de côté la base de donnée MBXDB-03 (qui ne joue aucun rôle dans cet exercice), nous pouvons observer que la base de données MBXDB-01 ne compte qu'une seule copie qui se trouve sur le serveur EX16-4 :





Rajouter le serveur au DAG

Maintenant, nous allons rajouter le serveur récupéré, EX16-3, au DAG avec la commande suivante :

Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX16-3



Nous devrions voir les opérations affichées à mesure qu'elles se réalisent :


Note : oui, c'est au serveur EX16-4 que je me trouve et où j'exécute la commande qui cible bel et bien le serveur EX16-3.


Les résultats sont observables tout de suite. Notre DAG compte de nouveau deux serveurs :





Ajouter une copie de la base de données à EX16-3

Maintenant que le serveur récupéré (EX16-3) fait de nouveau partie du DAG, nous sommes en mesure d'ajouter une copie des bases de données à répliquer. Dans notre cas, il s'agit de la base de données MBXDB-01. Il n'est pas obligatoire de faire une copie de toutes nos bases de données sur tous les serveurs membres du DAG. Nous avons, par exemple, une autre base de données, MBXDB-03, et nous n'en garderons qu'une seule copie.

Nous ajoutons donc une copie de la base de données MBXDB01 sur EX16-3 avec la commande suivante :

Add-MailboxDatabaseCopy MBXDB-01 -MailboxServer EX16-3


Note : l'avertissement en caractères jaunes concernent les permissions sur les répertoires qui viennent d'être créés. Il est recommandé de créer les répertoires au préalable pour avoir les permissions les plus sûres. Je ne vais pas traiter de cette question ici.


Si tout se passe bien, nous devrions avoir vu les opérations se réaliser en haut de l'écran :


 

En outre, nous pouvons observer  le progrès des données copiées vers EX16-3. La file d'attente où les données attendent d'être copiées décroît en nombre pour enfin arriver à zéro :




Quant à l'état de l'index du contenu, il est "en échec". J'ai essayé de le réparer avec la commande suivante :

Update-MailboxDatabaseCopy MBXDB-01\EX16-3 -CatalogOnly



Mais son état n'a pas changé tout de suite et il a fallu attendre encore un moment avant que tout rentre dans l'ordre :



Peut-être fallait-il simplement faire preuve de plus de patience ? Je me suis demandé si l'état de l'index serait redevenu normal sans la commande Update-MailboxDatabaseCopy ?

En tout cas, les lecteurs E: et F: qui étaient vides au départ contiennent désormais une copie de la base de données et les fichiers des journaux de transaction respectivement :



Voici l'exemple du lecteur E:



Les répertoires ont été créés de façon automatique sans intervention manuelle aucune. Cependant, il paraît que le processus n'ajuste pas les permissions selon les recommandations que nous avons vues dans les avertissements en caractères jaunes plus haut.


****


Nous avons rétabli notre DAG mais est-il vraiment en état de marche ? Les commandes exécutées plus haut semblent le confirmer mais pouvons-nous rendre la base de données MBXDB-01 active sur EX16-3 avec succès ? Je fais le changement avec cette commande :

Move-ActiveMailboxDatabase MBXDB-01 -ActivateOnServer EX16-3



Je confirme l'état de la base de donnée (et ses copies) avec cette commande :

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus



Ensuite, je vérifie que mes utilisateurs peuvent accéder à leur boîte aux lettres, envoyer et recevoir des messages, à la fois entre eux et avec des correspondants à l'extérieur. Nous avons déjà vu dans le texte précédent que si nous devons remplacer les Urls et le certificat SSL pour le service Accès client, les services Transport s'étaient rétablis sans intervention manuelle au cours de l'installation du serveur, grâce au paramètre /recoverserver.

 ***

Dans la plupart des réseaux, Exchange ne fonctionne pas tout seul (sans même compter l'interaction nécessaire avec Active Directory). Il faudrait sans doute réinstaller, par exemple, un logiciel d'antivirus et de sauvegarde. Il arrive aussi que le système de messagerie recourt à un répartiteur de charge. Dans le scénario de panne et de récupération que j'ai mis en scène ici, le basculement s'est fait sans mal et l'utilisateur d'Outlook n'a remarqué qu'une courte déconnexion (une minute au plus ? ). Il faut penser que le répartiteur a bien géré la panne de son côté aussi.

A ce sujet, je voulais prendre note de l'état des éléments concernant mes serveurs Exchange lors de la panne, afin de savoir ce qui est normal dans une telle situation. Bien entendu, l'interface de chaque répartiteur varie. Ce qui suit montre les effets de la panne d'un serveur Exchange vus de la perspective de mon répartiteur (Citrix NetScaler VPX v. 11).

Dans la section "Servers", rien ne change. Les "voyants" restent verts :



Dans la section "Virtual Servers", tout est au vert, sans doute parce qu'au moins un des serveurs est en état de marche et capable de fournir le service en question (HTTPS, SMTP). C'est seulement si nous regardons de plus près, dans la colonne " % Health " que nous voyons qu'un des deux serveurs manque à l'appel :



Dans la section "Services", nous avons une vue plus détaillée de ceux-ci et nous voyons que c'est EX16-3 (le serveur en panne) qui ne fournit plus le service en question (HTTPS et SMTP dans notre configuration) :

  

Bien entendu, après la récupération d'EX16-3, tous les voyants sont verts de nouveau.

De plus, je n'ai été obligé de prendre aucune action sur le répartiteur de charge. Quand le serveur en panne était remis sur pied, les communications avec le répartiteur ont repris automatiquement.





Tuesday, June 6, 2017

Exchange 2016 (22) : récupération d'un serveur membre d'un DAG (2)

English summary: after the failure of an Exchange 2016 mailbox server that was also a DAG member, we stabilized our environment by removing the failed server (and its database copies) from the DAG (subject of the previous blog post). In this blog post, we reinstall the server using the /recoverserver parameter which rebuilds much of the configuration from values stored in Active Directory. Preliminary tasks are presented, such as the resetting of the failed server's computer account in Active Directory and the installation of Exchange prerequisites on the rebuilt server. Lastly, we reconfigure the client access urls and import the SSL certificate associated with various Exchange services, notably IIS and SMTP. The installation program, even with the /recoverserver switch, does not re-establish these components automatically. On the other hand, send and receive connectors do not require manual configration (at least not in my environment). The addition of the rebuilt server to the DAG, as well as some other considerations, will be addressed in the following blog post.


***


Dans le texte précédent, nous avons consolidé l'état de notre DAG après la panne d'un de ses serveurs membres. Encore faut-il remettre le serveur défaillant sur pied afin de ne pas risquer une perte totale du système de messagerie en cas de panne du second serveur de la paire.

Le terme utilisé dans la documentation - "récupération" - n'est pas tout à fait juste dans la mesure où nous allons réaliser une toute nouvelle installation du système d'exploitation. A ce titre-là, il ne s'agit donc pas de "récupérer" ou de "restaurer" le serveur en panne à partir d'une sauvegarde. En revanche, quand nous installons Exchange, nous allons utiliser le paramètre /recoverserver qui va chercher dans Active Directory toutes les propriétés concernant l'ancien serveur et les rétablir sur le nouveau. C'est donc un serveur neuf par l'installation de l'OS mais configuré avec les propriétés de l'ancien serveur retenues dans le répertoire.

Dans les paragraphes qui suivent, je vais présenter les nombreuses étapes de la remise en service du serveur. Nous avons vu dans le texte précédent qu'il faut réinitialiser le compte ordinateur du serveur car nous devons utiliser ce compte pour recréer (selon les termes expliqués plus haut) l'ancien serveur Exchange. Il faut donc utiliser le même compte mais aussi le même nom d'hôte. Nous pouvons alors installer le système d'exploitation, certains pré-requis, Exchange lui-même (avec le paramètre /recoverserver) et puis en configurer certains éléments. Voici les principales étapes... 



Préparation de la machine virtuelle (ou physique)

Il faut préparer une machine virtuelle (ou physique) qui respecte les exigences matérielles pour Exchange 2016, en particulier le nombre de processeurs, la quantité de mémoire vive et une disposition des disques identiques à celle du serveur qu'on va remplacer. Chaque logiciel de virtualisation varie (vCenter, Hper-V, ou VMware Workstation pour mon réseau d'essai). Pour de plus amples détails, je renvoie le lecteur à la documentation Microsoft :

Configuration requise pour Exchange 2016



Réinitialisation du compte ordinateur du serveur à récupérer

Cette opération se fait en Active Directory. C'est une simple opération en trois étapes :








Attention à ne pas supprimer le compte ordinateur ! Il faudrait alors le restaurer. Créer un nouveau compte ordinateur avec le même nom n'est pas une solution. En effet, le nouveau compte n'aurait pas le même SID que l'ancien compte ordinateur.


Installation de Windows 2012 R2 sur le serveur

Comme pour les autres installations (dans mes autres textes), je suppose que le lecteur sait installer un système d'exploitation et je ne présente pas l'opération, pas à pas, ici. Vous devez savoir, par exemple, qu'il faut Windows 2012 R2 Standard ou Datacenter avec l'interface graphique (et non pas "Server Core"). Nous veillons à donner le même nom d'hôte au serveur (EX16-3 dans mon cas) et les mêmes paramètres TCP/IP. Nous configurons aussi les méthodes de gestion comme "bureau à distance" ou winrm (etc.) selon les normes de notre organisation.


Ajouter le serveur au domaine

Aucune précision à faire.


Installation des rôles, fonctionnalités et logiciels pré-requis

Il faut effectuer trois opérations à cette étape :

Installer les éléments ci-dessous à la ligne de commande PowerShell.

Oui, vous pouvez copier et coller au lieu de tout saisir à la main.

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, 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

Cela ressemble à ceci :




Installer la version de .NET Framework qui convient à votre version d'Exchange 2016

Dans mon cas (Exchange 2016 CU5), il s'agit de la version 4.6.2.


Installer "Unified Communications Managed API"

Sauf changement, il devrait s'agir de la version 4. Comme toujours, il faut consulter la documentation Microsoft pour les renseignements les plus à jour.



Formatage des disques (lecteurs)

Il s'agit des disques que nous avons ajoutés pour les bases de données et les journaux de transactions. Si nous ouvrons le gestionnaire de disques tout de suite après l'installation de l'OS (SE), nous voyons ceci (dans mon cas évidemment) :



A priori, nous pourrions configurer les lecteurs E: et F: à l'aide du gestionnaire. Mais j'avais fait le choix du système de fichiers ReFS pour le serveur défaillant et il faut recourir à la ligne de commande pour configurer les lecteurs ReFS selon les meilleures pratiques Exchange. Je ferai donc ce que j'ai fait lors de la première installation de EX16-3, à savoir exécuter la commande suivante :



C'est l'exemple du disque 1. Je fais de même pour le disque 2 (en gardant à l'esprit qu'on compte à partir de zéro, s'agissant de disques).  Get-Disk a affiché ceci avant l'exécution de la commande ci-dessus : 


Note : oui, ce sont bien des commandes PowerShell au lieu des commandes diskpart.



Installation d'Exchange 2016 avec le paramètre /recoverserver

Dans mon scénario (Exchange installé sur une machine virtuelle), je monte un fichier .iso comme si c'était un CD/DVD et accède ainsi aux fichiers d'installation. A la ligne de commande (cmd.exe), j'exécute la commande suivante :

setup /m:recoverserver /iAcceptExchangeServerLicenseTerms


Note : je ne crois pas que ce soit sensible à la case mais dans le cas contraire, il suffirait de tout mettre en minuscules.


Sauf contretemps, l'installation devrait se dérouler comme suit :




Je constate que, contrairement à une toute nouvelle installation, aucune base de données par défaut n'a été créée sur EX16-3 :




Ainsi, grâce au paramètre /recoverserver, le programme d'installation semble "comprendre" qu'il ne faut pas (re)créer une base de données par défaut sur le serveur récupéré.

Par contre, le programme d'installation ne sait pas configurer ce qui suit :

  • Les Urls des répertoires virtuels
  • Le certificat SSL associé aux répertoires virtuels (un seul certificat d'habitude)

Je vais présenter l'essentiel de la configuration de ces composantes dans les paragraphes suivants, quitte à renvoyer le lecteur à mes textes précédents pour plus de détails.


Les Urls des répertoires virtuels

Nous pouvons les configurer à la ligne de commande PowerShell, avec des scripts ou simplement à l'interface graphique ("EAC" ou "CAE" en français). Je vais me contenter de cette dernière option.

Nous allons donc dans cette partie de l'EAC :

serveurs | répertoires virtuels 

J'affiche les répertoires virtuels pour les deux serveurs, je copie l'Url de chaque répertoire, avec EX16-4 comme source, et le colle dans les propriétés correspondantes d'EX16-3.

Nous copions sur EX16-4...



Et nous collons sur EX16-3 (répertoire après répertoire - il y en a sept au total)...




Note : pour la sélection de serveurs et de types de répertoires, choisissez "Tous les serveurs" et "Tous" respectivement. Une fois le répertoire sélectionné, il suffit de cliquer sur l'icône du crayon (voir la première des deux captures d'écran ci-dessus) pour en afficher les propriétés.

Vous avez sans doute remarqué que nous ne pouvons pas configurer autodiscover dans l'EAC. En fait, ce n'est pas nécessaire dans le cadre d'une récupération. Au fond, il s'agit d'un Uri (nuance - remarquez la lettre "i" au lieu de "l") dont les paramètres semblent résider dans Active Directory. En effet, j'allais vérifier ces paramètres avant de reconfigurer EX16-3 et je me suis rendu compte que tout était déjà comme il fallait :

  

Pour d'autres détails sur les Urls, reportez-vous à ce texte :

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



Le certificat SSL

La gestion des certificats est plus facile sous Exchange 2016. Dans le cadre d'une récupération, nous pouvons exporter le certificat d'un autre serveur Exchange 2016 (s'il y en a) et l'importer sur le serveur récupéré. Mieux encore, nous pouvons tout faire à partir du Centre d'administration Exchange d'un seul serveur.

Nous nous rendons à cette partie de l'EAC...

serveur | certificats

Et nous sélectionnons le serveur qui n'a pas eu de panne et possède toujours le certificat en question (EX16-4 dans notre scénario) :

Note : je suppose que le même certificat est utilisé sur les deux serveurs.


Nous devons spécifier un chemin UNC qui a l'avantage de faciliter l'accès au certificat exporté à partir de l'autre serveur (le serveur récupéré) et puis protéger le fichier .pfx avec un mot de passe :



Ensuite, nous sélectionnons le serveur qu'on vient de récupérer (EX16-3)...


Et nous importons le certificat :







Nous saisissons le mot de passe et le certificat s'installe :



Il nous reste à désigner les services qui s'en serviront :





Oui, nous pouvons écraser le certificat par défaut :




Dès que nous aurons importé le certificat, nous devrons changer l'Url de l'EAC (CAE) afin qu'il corresponde aux noms présent sur le certificat. Autrement dit, nous devrons remplacer...

https://localhost/ecp/?ExchClientVer=15

par...

https://mail.machlinkit.biz/ecp/?ExchClientVer=15


Pour d'autres détails sur les certificats, reportez-vous à ce texte :

Exchange 2016 (3) : certificats - seconde partie



***


D'autres paramètres n'exigent aucune configuration supplémentaire. C'est le cas des connecteurs d'envoi et de réception.

Les premiers se configurent de façon automatique à partir des objets et des propriétés stockés dans Active Directory. Je n'ai même pas eu besoin de rajouter EX16-3 à la liste des serveurs "source": il était déjà présent quand je m'en suis assuré à l'emplacement suivant (EAC ou CAE) :

flux de messagerie | connecteurs d'envoi | [nom du connecteur] | propriétés | étendue



Note : nous accédons aux propriétés du connecteur ("cde_principal" dans mon exemple) en cliquant sur l'icône du stylo.


Quant aux connecteurs de réception, nous n'avons plus besoin de cocher l'option "Utilisateurs anonymes" afin de recevoir des messages des correspondants non-authentifiés à l'extérieur. Depuis Exchange 2013 (mais contrairement à Exchange 2010), cette case est cochée par défaut.

flux de messagerie | connecteurs de réception | [nom du connecteur] | propriétés | sécurité 




Note : les connecteurs de réception sont maintenant au nombre de cinq. C'est le "Default Frontend [nom de serveur]" qui nous intéresse, s'agissant des autorisations pour les utilisateurs anonymes.


***


Comme ce texte commence à s'allonger, je remettrai au billet de blogue suivant l'opération de rejoindre EX16-3 au DAG. C'est aussi dans ce texte-là que je ferai quelques vérifications supplémentaires (accès client, envoi et réception des messages, basculement du DAG) ainsi que quelques remarques sur des éléments comme le comportement de mon répartiteur de charge.