Projet exchange 2013 Clustering (Haute disponibilité)

Ce projet détaille le déroulement d’installation et de configuration de Microsoft exchange

2013, ainsi que des prérequis qui entoure ce module. La finalité sera de mettre en place un
système de haute disponibilité que l’on appelle « Clustering ».

Le principe de ce système est d’assurer la disponibilité et la continuité du service de

messagerie exchange dans les cas où si le serveur qui héberge le service de boîte mail
aux clients tombe, qu’un autre prenne le relai avec la même base de données que le
serveur d’origine pour éviter les pertes d’informations côté client.

Nous allons étudier et appliqué une méthode qui va nous permettre d’assurer ce service :

DAG : C’est une interface virtuelle qui va permettre aux clients de se connecter aux
serveurs d’hébergements de messagerie que l’on va appeler dans notre cas MBX1 et
MBX2 (MBX pour boîte aux lettres)

Ces serveurs fonctionnent de manière tour par tour (Actif /Passif), de part cette méthode
aucun des deux ne va opérer simultanément, l’un fonctionne et l’autre attend que ce soit à
son tour de fonctionner.

Notre DAG (cluster de basculement) aura donc pour mission premièrement de faire en sorte
que les MBX se synchronisent entre elles pour en venir à partager / copier leur bases de
données mutuellement. Et deuxièmement, avec l’aide de ce que l’on appelle CAS / Witness
(Serveur Témoin), de connaître l’identité du serveur qui fournit sur l’instant le service de
boîte aux lettres pour au final s’y placer et faire basculer les connexions des clients dessus
(donc haute disponibilité / tolérance de panne).

Pour se faire, nous aurons besoin niveau composants :

- D’un serveur Windows server 2012 AD DNS CAS qui sera contrôleur du
domaine Gary.local, contenant deux cartes réseaux :
- De deux serveurs Windows server 2012 MBX1 et MBX2 qui serviront d’accès à la
messagerie exchange avec pour cartes réseaux

Les principales étapes qui seront à retenir pour la configuration de notre service DAG sont :

1- L’intégration dans le domaine Gary.local des deux machines MBX 1 et

MBX2 2- L’installation des prérequis d’exchange 2013 sur nos serveurs
3- L’installation d’exchange 2013 sur nos serveurs
4- La configuration du DAG sur le centre d’administration d’exchange 2013 sur notre serveur AD
DNS CAS.
Nous procéderons bien sûr à différents test en parallèles à ces étapes pour s’assurer
au bon fonctionnement des paramétrages que l’on effectuera sur notre infrastructure.

Paramétrage des cartes réseaux de nos serveurs.

Il faut tout d’abord veillez à ce que nos serveurs puissent communiquer entre eux et conviennent au
plan que l’on a établi précédemment avant d’y installer une quelconque fonctionnalité.

Sur notre serveur AD DNS CAS qui sera contrôleur de domaine et gestionnaire des
paramètres de notre service de messagerie, nous allons lui attribuer deux adresses IP qui
lui permettront d’une part de servir de témoin pour le basculement de cluster/ DAG sur les
MBX pour convié à son rôle de CAS (identifié le serveur contenant la base de donnée
active) et d’autre part de faire la liaison entre les deux serveurs d’hébergement de
messageries (synchronisation / copie de bases de données entre eux)

Remarque : Cette explication est aussi valable pour les MBX dans le cas où elles doivent
être reliées à l’AD DNS CAS pour avoir la possibilité d’être administrer par ce dernier.

En suivant respectivement ce descriptif nous obtenons donc :

172.16.1.1 /24
Remarque : Pour le serveur DNS préféré, après l’installation du rôle DNS sous Active
Directory, il se mettra automatiquement lui-même en tant que tel.

192.168.1.1 /24

Nous passons ensuite à la configuration de nos MBX1 et MBX2

MBX1
Pour ce qui est de la MBX2, il y a juste à remplacer le dernier octet par 2 au niveau
des réseaux 192.168.1.2 et 172.16.1.2.
Nos serveurs étant maintenant paramétrés, des tests de ping sur l’invité de commande
s’imposent pour vérifier la connectivité.

Nous allons l’effectuer depuis l’AD DNS CAS

 Création du domaine Gary.local et intégration des serveurs dans le domaine

Maintenant que nos serveurs communiquent ensemble, il est temps de créer notre
domaine Gary.local sur le serveur AD DNS CAS via l’Active Directory.

Il est impératif d’effectuer cette action, c’est un prérequis indispensable pour notre
service de messagerie exchange.

Exchange se sert du domaine Gary.local et de l’Active Directory pour détecter les différents
serveurs d’hébergement qui sont inclus dedans. Comme dit précédemment, le serveur AD DNS
CAS sera le point de contrôle / centre d’administration de notre messagerie, pour se faire il
faudra que nos serveurs d’hébergement MBX1 et MBX2 se trouvent dans le même domaine +
avoir exchange d’installer en tant que service de boîte au lettre.

Notre AD DNS CAS sera installé en tant qu’accès client, mais nous verrons tout ceci au moment venu.

Création du domaine Gary.local

Au niveau de notre serveur AD DNS CAS après y avoir ajouté les rôles AD DS et DNS
(ces deux rôles fonctionnent ensemble pour faire en sorte que le domaine soit accessible
aux autres appareils du réseau) un pop-up apparaitra pour nous proposer de promouvoir
le serveur en contrôleur de domaine.
Cette fenêtre s’affichera ensuite, dans notre cas nous venons tout juste crée notre
infrastructure, il nous faut donc ajouter une nouvelle forêt.

Forêt : C’est en gros une arborescence / un arbre généalogique regroupant plusieurs

domaine entre eux avec à sa tête le domaine racine (celui que nous créons actuellement),
nous sommes en train de formé ce qu’on l’on appelle le squelette de l’Active Directory.

Et ensuite y spécifié le nom du domaine racine Gary.local.

Ils demanderont ensuite le niveau fonctionnel du domaine et de la forêt, c’est-à-dire l’OS
qui sera utiliser pour les serveurs des domaines, il indiquera par défaut celui utiliser par
le contrôleur de domaine (WIN 2012 R2 dans notre cas).

Un petit clin d’œil au DNS qui est un prérequis pour le fonctionnement de notre forêt.

Et enfin le mot de passe DRSM (Directory Services Restore Mode) qui est un outil qui permet
de restaurer / réparer une base de données Active Directory dans le cas où celle qui est
utiliser serait endommagé ou comprenant tout simplement des erreurs de paramétrage.
NetBios : C’est système de nommage et une interface logicielle qui permet
d’établir des sessions entre différents ordinateurs d’un réseau.

Dans notre cas ils nous demandent en gros d’attribuer un nom qui servira d’identification à
notre domaine Gary.Local, nous l’appellerons tout simplement Gary.
Sur cette fenêtre, on nous propose de choisir l’emplacement des fichiers où seront stockées
toutes les informations relatives à notre service Active Directory.

Il indiquera des chemins par défaut dans le dossier Windows.

Fichiers journaux : C’est un fichier qui nous tiendra informé de l’état et de modifications
apportés à notre AD (comme un journal).

SYSVOL : SysVol (System Volume) est un répertoire partagé qui stocke la copie serveur des
fichiers publics qui sont partagé pour être accessible et commun à travers tout le domaine.
Nous arrivons sur la fenêtre qui fait le récapitulatif des options et paramétrages effectuer concernant
la création de notre forêt. Et avec est fourni un script Windows PowerShell de ces options pour
automatiser des modifications ou installations (apporté des paramétrages qui s’appliqueront plus
rapidement que l’interface graphique Active Directory) à l’avenir sur ce domaine.

Il ne nous reste plus qu’à faire « suivant » et laisser l’installation de notre domaine se déroulé.

L’ordinateur redémarrera après la fin de l’installation du domaine et le tour est joué !

Intégration des serveurs dans le domaine

Maintenant que notre domaine Gary.local est créé, nous pouvons dès à présent intégrer
nos deux mailbox 1 et 2 dans ce dernier.

Mais avant de le faire, nous devons d’abord renseigner notre AD DNS CAS en tant que DNS
sur nos mailbox’s (le DNS étant un prérequis pour accéder à la base Active Directory).

Et ainsi de suite avec les différentes carte réseaux de nos mailbox’s par rapport au
contexte de notre infrastructure (172.16.1.1 pour le deuxième sous réseaux)
Maintenant que notre DNS est renseigné sur nos mailbox’s, nous allons maintenant les
intégrer dans le domaine. Pour cela il faut donc sur les deux serveurs, accéder au panneau
de configuration et aller dans l’onglet « Système » pour modifier le nom / l’appartenance au
domaine ou groupe de travail de la machine en question.
Nous nous trouvons actuellement sur la machine MBX1, que l’on nommera « Mbxx1 »
sur cette infrastructure et domaine.

Sur la partie bas de la fenêtre nous avons une partie « Membre d’un » ou d’un domaine,
ou d’un groupe de travail (pour du local), nous avons juste à coché l’onglet domaine et y
spécifié le nom de domaine que l’on veut joindre.
En appuyant sur « Ok », une autre fenêtre s’affichera pour renseigner les Identifiants et mot
de passe du contrôleur de domaine (l’AD DNS CAS)

Son autorisation est obligatoire pour les entrées / sorties du domaine.

Et nous y voilà.
Installation d’exchange et de ses prérequis

Nous passons maintenant à l’installation des prérequis (module supplémentaire /

add-on) d’exchange.

Ces prérequis sont un regroupement de patch correctifs et de fonctionnalités supplémentaire

délivré par Microsoft qui serviront à faire fonctionner notre service de messagerie de manière à
ce que l’on puisse mettre en place notre DAG sans encombrements.

Ils sont disponibles sur le site de Microsoft et gratuitement téléchargeable, pour notre cas nous
avons tout ce qu’il nous faut dans un dossier nommé « Exchange 2013 », il nous reste tout
simplement à les exécutés et passé ensuite à l’installation d’exchange sur l’AD DNS CAS.

Les prérequis spécifiés par windows pour faire fonctionner notre DAG sont ceux surlignés
en jaune sur cette capture d’écran, il y a un ordre respectif pour les installer :

1. Les filterpacks qui sont des patchs correctifs et ajustement de compatibilité

2. Msciuu2
3. Pre-requis server 2k12
4. UcmaRuntimeSetup (à lancer après avoir redémarré le pc à la suite des
précédentes installations de prérequis)

Remarque : De préférence les exécuter en tant qu’Administrateur.

Aperçu des installations (rien de bien spécial).
Et c’est avec ceci que nous terminons l’installation de nos prérequis !

Nous pouvons maintenant passer à l’installation et la configuration d’exchange 2013 sur notre AD
DNS CAS.
Installation et configuration d’exchange 2013

Comme dit dans la présentation du plan, pour que notre centre de gestion des serveurs
d’hébergement exchange qui se trouve sur le contrôleur de domaine fonctionne, il faut à tout prix
qu’il y est des serveurs de présent dans le domaine avec au minimum exchange d’installer !

Nous allons donc effectuer l’installation d’exchange sur l’AD DNS CAS et y spécifier les
différences qu’il y aura par rapport aux installations sur les MBX 1 et 2 vu qu’ils ont des
rôles différents sur notre infrastructure.

Pour se faire, nous allons nous diriger vers le dossier exchange 2013 (celui que l’on a utilisé pour
l’installation des prérequis) et exécuter le setup d’exchange depuis le dossier « source install ».
Après l’avoir exécuté, nous atterrissons sur l’assistant d’installation qui nous demandera de
vérifier les mises à jour ou non pour exchange, dans notre cas vu que nous sommes sur une
infrastructure se concentrant uniquement sur du local (donc pas de FAI = pas d’internet),
nous allons choisir l’option du bas « Ne pas vérifier les mises à jour maintenant ».

L’assistant commencera ensuite à préparer l’installation.

Remarque : Je laisserais de côté les informations n’ayant aucune pertinence sur l’installation
d’exchange tel que les contrats de licence, les news à propos des versions et etc.
Après que l’initialisation de l’installation se soit terminé, sur cette fenêtre nous allons cocher
« N’utilisez pas les paramètres recommandés », dans notre cas nous avons déjà un plan spécifiques
et un but précis d’attribuer à notre exchange, nous allons donc tout configurer manuellement.

Nous arrivons sur le choix du rôle pour notre serveur,

Deux choix s’offrent à nous par rapport aux composants de notre infrastructure :

Le rôle boîte aux lettres qui promu le serveur en question en tant qu’hébergeur des données
de messageries des utilisateurs (boite aux lettre, contact, calendrier etc.) (MBX 1 et 2).
Le rôle d’accès au client qui est plutôt axé vers le côté gestion de l’infrastructure
exchange, c’est à partir de celui-ci que l’on pourra mettre en place des paramétrages /
règles / désigner les serveurs qui hébergeront la / les bases de données, et surtout crée
l’interface virtuel qui permettra aux clients d’accéder aux MBX’s (AD DNS CAS).

Nous choisissons donc le rôle d’accès client pour notre serveur AD DNS CAS.
Nous arrivons sur la fenêtre qui permettra de relié nos serveurs sur exchange, et tout ça grâce à
« L’organisation Exchange », nos serveurs se trouvant dans un même domaine et se situant
tous sur la base Active Directory, Exchange va se servir de cela pour faire en sorte qu’ils
soient compris dans un même groupe du moment qu'ils aient le même nom d’organisation,
dans notre cas nous la nommerons « Gary Local ».

Et enfin l’installation débutera, mais avant ça il vérifiera si le serveur en question a bien

tous les modules nécessaires pour exchange.
L’installation terminée, il faut maintenant l’effectuer sur les MBX’s en veillant bien à préciser le
deux rôle boîte au lettre.
Configuration du DAG et de la gestion des bases de données entre les MBX’s
(Centre Administration Exchange)

Nous voici sur le centre d’administration exchange (Serveur AD DNS CAS), nous partons du
principe que les messageries des utilisateurs sont déjà configurées, nous avons juste à
gérer la partie gestion de base de données du côté de nos serveur d’hébergement
messageries MBX1 et MBX2 et gestion de l’interface virtuel (DAG).

Pour se faire, nous allons tout d’abord dans l’onglet « Serveurs », ici nous aurons
d’afficher tous les serveurs ayant exchange d’installé avec un rôle prédéfinis (boite au
lettre ou accès client), et se trouvant dans un même domaine (exchange se servant de la
base Active Directory pour contacté d’autres serveurs ayant le service d’installé).

Et ensuite de sélectionner l’onglet « Groupe de disponibilité de la base de

données » et de sélectionner le petit plus au niveau de l’onglet du bas.

Comme le nom de cette onglet l’indique, nous allons créer un lien entre nos MBX’s pour
pouvoir y partager les bases de données / crée le DAG.
Nous nommons notre groupe de disponibilité « DAGMBX »

Au niveau des onglets « Serveur témoin » et « Répertoire témoin », il indiquera par défaut l’AD DNS
CAS dans le cas où les champs ci-dessus après l’enregistrement du DAG se trouvent vide.

Et enfin l’attribution d’adresses IP pour intégrer notre DAG dans un ou des réseaux spécifiques
pour la synchronisation des serveurs et de leur bases de données ou des connexions clients à
ces bases de données (le réseau pour le LAN client 172.16.1.X a été ajoutée à ce même DAG).
Comme on peut le constater, le serveur témoin (CAS / Witness) pour le DAGMBX est l’AD
DNS CAS. Il nous faut maintenant y ajouter nos deux MBX’s pour ensuite y spécifié les
réseaux sur lesquels notre DAG va opérer.

Nous pouvons maintenant passez au partage des bases de données entre les membres
du DAGMBX (MBX1 et MBX2) et tester la réplication entre eux (la prise de relai pour être
la base de données active)
Nous voici dans l’onglet « Base de données », c’est ici que l’on pourra gérer les copies de bases de
données entre nos serveurs et en voir leur état, et pour se faire, le dernier icône nous permettra
d’effectuer une copie de base de donnée d’un autre serveur sur le serveur sélectionner dans l’instant.

Dans notre cas, nous voulons effectuer une copie de la base de données de MBX1 sur la MBX2.
Notre copie est maintenant montée, et notre DAG mis en place !

Au niveau du descriptif des bases de données de nos serveur, il doit normalement y avoir
les bases de données propre à chacun des serveurs qui doivent se trouver dans un état «
Actif Monté », suivis des copies qui elles vont se synchroniser avec la base active du
serveur qui fournira l’accès à la boîte au lettre « Passif Sain ».

Par exemple, MBX1 est le serveur actif, avec sa propre banque de donnée qui est celle qui fournit
l’accès à la boîte au lettre, dans un cas où MBX1 tombe, le serveur MBX2 qui possède la copie de
MBX1, va reprendre la base et assuré la continuité du service de messagerie et vice versa.