Documente Academic
Documente Profesional
Documente Cultură
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).
- 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 :
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.
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
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é.
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.
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.
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.
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é.
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)
Et nous y voilà.
Installation d’exchange et de ses prérequis
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 :
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 ».
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.
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 ».
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é).
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.