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.



Sunday, May 28, 2017

Exchange 2016 (21) : récupération d'un serveur membre d'un DAG (1)

English summary: we manage the recovery of a failed Exchange server that is a member of a DAG (Database Availability Group). First (out of curiosity), I simulate the failure of the server and observe the resilience of the DAG. Can users still access their mailbox and send/receive messages? I review some of the general steps for the recovery of a failed server using the /recoverserver option. However, when the server is a member of a DAG, we have to perform three other actions first: 1) Remove mailbox database copies on the failed server, 2) Remove the failed server from the DAG and 3) purge the failed server from the cluster. The reinstallation of the server OS, Exchange prerequisites and Exchange itself, will take place in the following blog post. 


***

Dans ce texte, nous allons démontrer la démarche à suivre pour récupérer un serveur Exchange en panne quand il est aussi membre d'un DAG (Database Availability Group).

Une récupération réussie suppose l'installation d'Exchange sur un nouveau serveur avec le même nom et aussi avec la même configuration des disques. Si, par exemple, la base de données MBXDB-01 se trouvait sur le lecteur F: avant la panne, il faut un lecteur F: sur le nouveau serveur. Dans un DAG, les chemins vers les bases de données sont censés être les mêmes et nous pourrions déduire la configuration des disques du serveur en panne à partir de la configuration des disques d'un serveur en bon état. Cela étant, il vaudrait mieux posséder une documentation à jour de nos serveurs. Je vais supposer que nous avons mis en pratique ce principe et pris note de la disposition des disques.

Remarque : nous devons installer la même version d'Exchange sur le nouveau serveur (de remplacement). Si le serveur en panne exécutait Exchange 2016 CU5, nous devons installer Exchange 2016 CU5 sur le serveur de remplacement.

Dans notre scénario, nous avons deux serveurs Exchange dont chacun compte un lecteur C: pour le système d'exploitation et les binaires Exchange, un lecteur E: pour les bases de données et un lecteur F: pour les fichiers des journaux de transaction.



Je sais aussi que les noms de nos serveurs sont EX16-3 et EX16-4. Nous pouvons aussi documenter d'autres éléments comme les paramètres TCP/IP. Il vaudrait sans doute mieux que le serveur ait la même adresse IP mais je ne vois pas cela comme une exigence dans la documentation.


***

Voici notre point de départ...

Nous avons donc deux serveurs Exchange (EX16-3 et EX16-4) qui font partie de "DAG1". Chacun possède une copie de la base de données "MBXDB-01".

La copie de MBXDB-01 est "active" sur EX16-3. De plus, EX16-3 tient le rôle "PAM" (Primary Active Manager).


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



Note : EX16-4 compte aussi une "simple" base de données (MBXDB-03) qui ne fait pas partie du DAG. Cette base de données n'entre pas en jeu dans notre scénario.

C'est donc le pire des scénarios : la base de données est "active" sur EX16-3, EX16-3 tient le PAM et c'est EX16-3 qui va connaître une panne soudaine. Pour simuler une telle panne, j'ai éteint la machine virtuelle tout d'un coup, comme si on avait coupé le courant à un serveur physique dépourvu d'une batterie de secours.

 Qu'est-ce qui se passe au moment de cette panne brusque ?

Les clients Outlook perdent leur connexion, d'autant plus que les boîtes aux lettres ne sont pas en mode cache (dans mon environnement). Mais Outlook essaie de rétablir la connexion :



Après une minute environ, la connexion se rétablit :



Dès que le connexion est rétablie, les clients peuvent envoyer (et recevoir) des courriels (et cela même si leur boîte aux lettres se trouve dans la base de données MBXDB-01). Dans l'exemple ci-dessous, Sonia Smith envoie un message à Paul York, malgré la panne de EX16-3 :






Je me connecte en tant que Paul York et je vois le message dans ma boîte de réception :




Le DAG a donc résisté à la perte d'un de ses membres sans la moindre difficulté.

***

Ainsi, notre système de messagerie continue à fonctionner mais nous n'avons plus qu'un seul serveur Exchange, ce qui nous rend vulnérables à une perte totale des services en cas d'une nouvelle panne. Nous devons donc mettre en service un second serveur, plus ou moins vite, et en faire un membre du DAG. Quelles sont nos options ? Nous pourrions avoir un logiciel de sauvegarde compatible avec Exchange, capable de restaurer une sauvegarde récente du serveur défaillant. Dans mon cas, je vais installer Exchange sur un nouveau serveur (une nouvelle machine virtuelle) avec l'option /recoverserver. Cette option permet au nouveau serveur de prendre l'identité de l'ancien mais il faut veiller à faire deux choses au préalable :
  1. Réinitialiser le compte ordinateur d'EX16-3 en Active Directory.
  2. Donner le même nom de hôte au nouveau serveur et l'ajouter au domaine (après avoir ré-initialisé le compte ordinateur. Il est crucial de respecter l'ordre des opérations).

De plus, lorsqu'il s'agit d'un serveur membre d'un DAG (comme dans le cas présent), nous devons réaliser d'abord trois autres opérations :
  1. Supprimer les copies des bases de données qui se trouvaient sur le serveur hors service. Dans notre scénario, il s'agit de la base de données MBXDB-01.
  2. Retirer le serveur en panne du DAG.
  3. Expulser le serveur en panne du "cluster". Il faut préciser que le DAG utilise des éléments du service Windows Clustering.


Je vais présenter ces trois opérations dans les paragraphes suivants et réserver l'installation de Windows, et puis d'Exchange, pour un texte à suivre.

Voici l'état du DAG après la panne du serveur EX16-3 :


EX16-3 et EX16-4 s'affichent comme serveurs membres (du DAG) mais seulement EX16-4 s'affiche comme serveur opérationnel. De plus, EX16-4 est devenu le PAM.

L'état de la copie de la base de données MBXDB-01 sur EX16-3 s'affiche comme "ServiceDown" et l'état de l'index de contenu comme "Unknown" : 



Nous commençons notre récupération en supprimant cette copie de la base de données avec la commande suivante :

Remove-MailboxDatabaseCopy MBXDB-01\EX16-3


Un assez long avertissement en caractères jaunes s'affiche. Il nous apprend ce que nous savons déjà : le serveur EX16-3 n'est pas accessible. La copie de la base de données est supprimée tout de même et l'avertissement nous rappelle de supprimer de façon manuelle les fichiers constituant la base de données (si nécessaire). Au fond, nous avons supprimé la référence à cette copie de la base de données dans les propriétés du DAG. Bien entendu, nous n'avons pas littéralement supprimé la base de données sur EX16-3 parce qu'il n'est plus en état de fonctionnement et nous ne pouvons pas accéder à ces fichiers pour les supprimer.

Il en résulte que la base de données MBXDB-01 ne compte plus de copie sur le serveur EX16-3. Il n'en reste plus que la copie sur EX16-4 :




La seconde de nos trois opérations consiste à retirer le serveur EX16-3 du DAG. En voici la commande :

Remove-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX16-3 -ConfigurationOnly



Remarque : si le serveur n'est pas accessible (cas probable s'il est en panne), il faut ajouter le paramètre -ConfigurationOnly. Sinon, vous verrez un message d'erreur comme ceci :




La troisième opération consiste à expulser EX16-3 du cluster. Nous pouvons voir des détails sur le cluster et puis expulser EX16-3 avec les commandes suivantes :




***

A cette étape, nous avons achevé les opérations concernant notre DAG. Cela faisant, nous avons sans doute éliminé certains messages d'erreur qui auraient commencé à inonder les journaux si le DAG essayait toujours de communiquer avec un serveur membre qui n'existe plus.

Mais nous devons remettre sur pied un second serveur Exchange. En effet, une seconde panne en ce moment signifierait la perte totale de notre système de messagerie. Nous allons donc réinitialiser le compte ordinateur d'EX16-3, installer Windows 2012 R2 avec les mêmes caractéristiques d'EX16-3 (notamment le nom et la disposition des disques), l'ajouter au domaine et puis installer tous les prérequis pour Exchange et enfin, installer Exchange 2016 CU5.

Ce sera, avec plus de détails, le sujet de mon prochain texte.

---

Ressources :