Thursday, April 27, 2017

Exchange 2016 (19) : DAG - seconde partie

English summary: after creating a Database Availability Group (DAG) and adding the first of two servers in the previous blog post, we attempt to add a second server and encounter some difficulties. We resolve the problem and then add a mailbox database to the DAG for replication.

***

Après avoir ajouté au DAG le premier de nos deux serveurs Exchange (EX16-3), je croyais qu'il serait aussi facile d'en ajouter le second (EX16-4). En fait, il semblait encore plus facile, trop facile.

Je saisis la commande suivante...

Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX16-4

En quelques secondes, je me retrouve à l'invite de la ligne de commande. Les opérations en cours ne se sont pas affichées en caractères jaunes sur fond turquoise comme pour le premier serveur :



Je remarque aussi que le DAG ne comprend aucun "Operational Server(s)". J'y réfléchis un instant et je me souviens qu'il faut ajouter le paramètre -status pour afficher certaines propriétés (c'est ainsi). Je saisis la commande suivante, ce qui fournit des détails plus amples :



Quelque chose cloche. Je n'ai qu'un seul serveur opérationnel : EX16-3. Cette commande le confirme avec plus de concision :



Je commence le processus de dépannage.

Dans l'Observateur d'événements, je découvre un avertissement concernant le "FailoverClustering-Manager". Il faut savoir que le DAG repose sur des éléments de Windows Clustering bien que nous ne gérions pas le DAG avec cet outil directement. A première vue, cet avertissement pourrait avoir un lien avec l'absence du serveur EX16-4 parmi les serveurs opérationnels. Mais à y regarder de plus près, l'avertissement semble se rapporter à Hyper-V :



Quoi qu'il en soit, l'avertissement m'amène à vérifier l'installation des rôles et des fonctionnalités qui pourraient être nécessaires au DAG. D'emblée, je constate un message qui fait état d'un redémarrage en attente :




C'est la fonctionnalité "Outils de clustering de basculement" (Failover clustering tools) qui nécessite un redémarrage :



En comparaison, ces outils sont installés sur EX16-3 :




Malheureusement, le redémarrage n'a pas résolu le problème. J'observe même, dans le Gestionnaire du cluster de basculement, qu'il n'y a... rien :




Je décide de retirer EX16-4 du DAG...



Et d'essayer de l'ajouter à nouveau. Cette fois-ci, cela réussit mieux. Au lieu de sembler terminer en quelques secondes, l'opération prend environ une minute et chaque étape de l'opération s'affiche en haut de l'écran, en caractères jaunes sur fond turquoise :



Qui plus est, les deux serveurs sont maintenant affichés comme opérationnels :



En outre, nous pouvons comparer cette vue du Gestionnaire de cluster de basculement avec la précédente (plus haut). Tout est en place, y compris le Témoin de partage de fichiers (FSW) :



Et comme on pouvait (logiquement) s'y attendre, le répertoire "FSW-DAG1" a été créé sur le serveur que nous avons désigné comme "Témoin de partage de fichiers" :



Il nous reste encore à ajouter une base de données (de boîte aux lettres) au DAG pour la réplication. Comparons l'avant et l'après. Nous allons utiliser la base de données MBXDB-01 qui réside seulement sur EX16-3 pour le moment :

Get-MailboxDatabaseCopyStatus



A l'inverse, EX16-4 abrite la base de données MBXDB-03 sur le volume E: et les fichiers de journaux de transaction (log files) sur le volume F:




Gardons à l'esprit que le chemin pour la base de données et les journaux de transaction doit être le même sur tous les serveurs qui tiennent une copie de la base de données.

Pour le moment, EX16-4 n'a donc que les répertoires associés à la base de données MBXDB-03. Quand nous ajouterons MBXDB-01 au DAG, celui-ci créera un exemplaire (ou "replica") de cette base de données sur EX16-4 (sur le volume E:) et copiera les fichiers des journaux de transaction vers un répertoire sur le volume F:. A mesure que l'opération de copie se fait, les transactions seront consignées à la base de données.

Nous ajoutons la copie de la base de données MBXDB-01 sur EX16-4 avec la commande suivante :

Add-MailboxDatabaseCopy MBXDB-01 -MailboxServer EX16-4

Deux avertissements s'affichent concernant les permissions sur les répertoires créés (de façon automatique) sur EX16-4 pour la base de données et les journaux de transaction. Il est recommandé de limiter l'accès au SYSTEM et aux administrateurs locaux. C'est une recommandation que je vais étudier mais sans m'y étendre ici. 



Le troisième avertissement nous demande de faire redémarrer le service "Microsoft Exchange Information Store", ce qui est assez facile à faire :




Et voici les changements que nous pouvons observer après la mise en place du DAG et surtout après avoir ajouté la base de données MBXDB-01. D'abord, le serveur EX16-4 (adresse IP 10.4.1.17) a désormais une copie de la base de données MBXDB-01 à côté de la base de données MBXDB-03 qui s'y trouvait déjà (à comparer avec les captures d'écran plus haut) :



Et oui, Exchange crée le répertoire contenant le fichier .edb et l'index du contenu (le répertoire nommé MBXDB-01 dans la capture d'écran juste au-dessus). Il n'est pas nécessaire de le créer à la main.

Il en va de même pour le répertoire contenant les fichiers de journaux de transaction :



Et en dernier lieu, la commande dans la capture d'écran ci-dessous montre qu'il y a désormais deux copies de la base de données MBXDB-01. La première sur EX16-3 est montée ("Mounted") et la copie sur EX16-4 est en bonne santé ("Healthy").



Monday, April 24, 2017

Exchange 2016 (18) : DAG - première partie

English summary: more recent versions of Exchange Database Availability Groups (DAG) have options that were not present with Exchange 2010 (the concept of an "IP-less DAG" for example). After briefly presenting some (but not all) of these options, I complete the pre-requisites of the configuration that I've selected and then proceed to create the DAG. All in all (and excluding pre-requisites), it is a three step process: create the Database Availability Group itself, add servers to the DAG, add mailbox databases to the DAG for replication.


***


L'acronyme "DAG" signifie "Database Availability Group" que je traduirais par "Groupe de base de données en haute disponibilité". Il s'agit des bases de données de boîtes aux lettres, une innovation en haute disponibilité qui existe depuis Exchange 2010. Je tiens à préciser que cette méthode de haute disponibilité concerne seulement le rôle des boîtes aux lettres (Mailbox Role). Il faut d'autres méthodes pour assurer la haute disponibilité du rôle Accès client et du rôle Transport. De plus, même si nous parlons plutôt des "services" Accès client et Transport pour Exchange 2016, le principe reste valable : le DAG est un concept relatif aux boîtes aux lettres.

Le DAG version Exchange 2016 comporte certaines améliorations par rapport à Exchange 2010 que je voudrais examiner. D'abord, nous n'avons plus besoin de mettre sur pied un réseau distinct pour l'accès client et la réplication entre membres du DAG. Déjà, avec Exchange 2010, c'était recommandé mais non pas absolument nécessaire. En outre, nous n'avons plus besoin d'assigner une addresse IP à notre DAG. Ce sont les "DAG sans IP" ou "IP-less DAGs). Cependant, nous avons encore l'option d'assigner une adresse IP si, par exemple, notre logiciel de sauvegarde n'est pas en mesure de fonctionner sans cela.

Ma présentation n'est pas exhaustive. Pour des informations plus complètes, je renvoie le lecteur aux articles suivants :

Groupe de disponibilité de base de données

Ou dans la version originale :


Dans mon cas, je vais choisir d'assigner une adresse IP à mon DAG mais me contenter d'un seul réseau pour tout le trafic, tant accès client que réplication.


***


La mise en oeuvre d'un DAG se décompose en trois étapes principales :
  1. Nous créons le DAG lui-même, soit un objet dans Active Directory, avec ou sans adresse IP.
  2. Nous ajoutons un minimum de 2 serveurs Exchange (avec le rôle "boîte aux lettres") au DAG créé à la première étape. Un DAG peut avoir un maximum de seize serveurs membres. 
  3. Nous ajoutons des bases de données (de boîtes aux lettres) au DAG. La réplication se fait au niveau de la base de données. Toutes les bases de données d'un serveur Exchange peuvent faire l'objet d'une réplication ou seulement une partie d'entre elles. 

Selon nos choix (multiples réseaux ou non, adresse IP ou non), il faut, en plus,  accomplir certaines tâches au préalable.

Etant donné mes choix de configuration, je dois préparer un serveur qui sera notre "File Share Witness" (FSW - ou Témoin de partage de fichiers en français) et créer un compte ordinateur dans Active Directory de façon manuelle.

Je vais donc désigner un serveur comme "FSW". Il s'agit d'un nœud qui joue le rôle d'arbitre dans un DAG avec un nombre pair de membres. Il n'aurait aucun rôle à jouer si le nombre de membres était impair.

Dans mon réseau d'essai, je n'ai que quatre hôtes  :
  • 1 contrôleur de domaine Windows 2008 R2
  • 2 serveurs Windows 2012 R2 (avec Exchange 2016 CU5)
  • 1 client Windows 7 SP1

Pour des raisons de sécurité, il est déconseillé d'utiliser un contrôleur de domaine  pour le FSW. Mais, faute d'autre choix, et s'agissant précisément d'un simple réseau d'essai, je vais donc utiliser mon contrôleur de domaine.

Si le serveur qui tient le FSW n'est pas un serveur Exchange, nous devons y ajouter le compte "Exchange Trusted Subsystem" au groupe "Administrateurs locaux" ou "Administrateurs" dans le cas d'un contrôleur de domaine. Le compte hérite ainsi des privilèges considérables, voire excessifs, ce qui explique qu'il est normalement déconseillé. Il s'agit d'ajouter le compte dans les propriétés du groupe (onglet "Membres") :




De plus, si nous utilisons Windows 2012 R2, et si nous tenons à avoir un "cluster administrative access point" (en substance, un DAG avec une adresse IP), nous devons créer un compte ordinateur pour notre DAG. Je vais essayer cette option en raison d'un logiciel de sauvegarde qui est peut-être incompatible avec un DAG sans (adresse) IP. Soulignons, cependant, que ce "point d'accès" (et son adresse IP) n'est plus obligatoire. Dans la plupart des cas, nous pourrions sans doute nous en passer.

Je crée un compte (ordinateur) pour notre DAG, je l'appelle "DAG1" et je le désactive aussitôt : 


Note : je crée le compte dans le conteneur qui abrite les comptes de nos deux serveurs Exchange mais cela n'est pas nécessaire.


Pour l'étape suivante, je m'assure que l'option "Fonctionnalités avancées" est cochée (sous l'onglet "Affichage" dans Utilisateurs et ordinateurs Active Directory) : 



Ensuite, dans les propriétés de l'objet "DAG1", et sous l'onglet "Sécurité", nous allons ajouter le compte "Exchange Trusted Subsystem" et lui accorder un contrôle total sur cet objet (voir les trois captures d'écran suivantes) :









Créer le DAG

Tout cela accompli, nous pouvons passer à la création du DAG lui-même. Celle-ci peut se faire dans l'interface graphique (EAC-CDE) ou à la ligne de commande (EMS ou "Exchange Mangement Shell"). Je vais employer cette dernière option.

Je saisis la commande suivante, tenant compte du système de fichiers du volume qui contient les bases de données (ReFS) :

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer DC4 -WitnessDirectory C:\FSW_DAG1 -DatabaseAvailabilityGroupIpAddresses 10.4.1.18 -FileSystem ReFS


Note : il suffit de cliquer sur l'image pour l'agrandir.


L'opération réussit sans le moindre accroc. Dans le cas contraire, nous aurions vu un message d'erreur en caractères rouges (ce qui n'est pas le cas).

On aurait pu croire que l'opération a échoué, du moins en partie, parce que le répertoire pour le FSW n'a pas été créé :



En fait, cela est normal. A cette étape, le DAG existe surtout en tant qu'objet en Active Directory. C'est seulement ensuite que les autres éléments vont se matérialiser.

Nous le voyons bien si nous exécutons la commande suivante :


Le DAG ne compte encore aucun serveur et les paramètres du FSW en sont de simples propriétés.



Ajouter des serveurs Exchange au DAG

La prochaine étape consiste à ajouter des serveurs au DAG. A mon premier essai, cette opération a échoué. Je vais montrer ce qui s'est passé et puis la solution au problème.

Nous ajoutons un serveur au DAG avec la commande suivante...

Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX16-3

Et nous devrions voir l'affichage des opérations en cours en haut de l'écran : 



Mais pour moi, l'opération ne s'est pas achevée comme il fallait :



Qu'est-ce qui ne va pas ?

Le fichier journal mentionné dans le message d'erreur fournit des indices.

Le DAG a bel et bien une adresse IP (10.4.1.18) mais la résolution du nom "DAG1" échoue parce que l'hôte est inconnu :



Je dois créer une entrée pour DAG1 dans la zone DNS qui convient :



Le problème a persisté lors d'une seconde tentative mais ne s'est plus manifesté après la mise hors tension de tout mon réseau d'essai et son redémarrage un jour plus tard. Je pose comme hypothèse qu'il fallait purger DNS côté client où le premier échec de résolution bloquait les résolutions suivantes. Il est plus que probable que cette commande aurait accompli la même chose :

ipconfig /flushdns


A ma troisième tentative d'ajouter un serveur, tout s'est donc bien passé. Il faut environ une minute pour que toutes les opérations finissent :



Et notre serveur EX16-3 fait désormais partie du DAG :




***

En principe, il suffirait de faire la même chose pour EX16-4 mais, là aussi, je me suis heurté à des obstacles. Comme pour le problème de résolution de noms, je tiens à présenter le problème et puis la solution. Ce sera le sujet de mon prochain billet de blogue où, en plus, nous ajouterons une base de données au DAG.

Tuesday, April 11, 2017

Exchange 2016 (17) : répartition de charge - certificats SSL - avec Citrix Netscaler

English summary: the subject is the configuration of load-balancing MAPI/HTTP with a Citrix NetScaler VPX. In the previous post, we configured the server, services and virtual server but the service remains in the "down" state. Based on previous experience, it appears that we must import (a copy of) the certificate used on our Exchange 2016 (CU5) servers, install it and bind it to the HTTPS virtual server. The process is outlined below.


***


Dans mon texte précédent, j'ai configuré mon répartiteur de charge pour la répartition du trafic MAPI/HTTP (voir le texte précédent). Cependant, l'état de la connexion est "hors service" ("Down"). En me fondant sur des expériences menées en mars 2016, je crois qu'il serait possible de dépasser ce contretemps en important le certificat SSL qu'utilisent les serveurs Exchange. J'ai déjà exporté le certificat en question quand j'ai mis sur pied mon second serveur Exchange et je ne referai donc pas le processus d'exportation. Je suppose donc que nous avons une copie du certificat et dans les lignes suivantes je vais droit au processus d'importation.

D'abord, nous ouvrons une session à notre NetScaler VPX et nous nous dirigeons vers l'emplacement montré ci-dessous :

NetScaler > Traffic Management > SSL

Je fais un clic-droite sur "SSL" et je choisis "Enable Feature" :






Cela fait, je vais à la section "Tools" et je clique sur "Import PKCS#12" :





Je renseigne les cases comme l'image ci-dessous le montre. Je donne un nom au "Output File - fichier de sortie). Il n'est pas nécessaire de naviguer vers un fichier (bien que l'option existe) pour cette propriété. Ensuite, je navigue jusqu'à l'emplacement où j'ai mis le fichier .pfx contenant notre certificat et je saisis le mot de passe qui protège le certificat (plus exactement la clé privée associée au certificat). Il n'est pas nécessaire de mettre quelque chose pour "Encoding Format" :






Je clique sur "OK" (je ne vais pas le préciser à chaque étape) et je me retrouve à la section SSL où je dois, cette fois-ci, cliquer sur "Manage Certificates / Keys / CSRs" :





En arrangeant les entrées selon la date de modification, nous voyons le fichier .pfx que nous avons importé ainsi que le fichier de sortie .pem :




Note : je ne suis pas certain à 100% quel rapport existe entre les deux fichiers mais je crois qu'au moment de l'importation du fichier .pfx, son contenu  (le certificat) passe au "fichier de sortie" (Output file).


Quoi qu'il en soit, nous venons d'importer le certificat et nous devons maintenant l'installer en nous rendant à l'emplacement suivant :

 NetScaler > Traffic Management > SSL > SSL Certificates

Vous avez peut-être remarqué la présence d'un certificat qui se trouve déjà sur la liste des certificats. C'est sans doute un certificat auto-signé. En tout cas, il faut installer le nôtre en plus (cliquer sur "Install") :




Nous naviguons jusqu'à notre fichier .pem que nous sélectionnons :



Je remplis les cases comme nous voyons dans la capture d'écran suivante :



Note : oui, c'est le même nom pour "Certificate File Name" and "Key File Name".


Et voilà. Nous avons réussi à importer et à installer le certificat SSL qu'utilisent nos serveurs Exchange :




Mais si nous revenons à nos serveurs virtuels...

NetScaler > Traffic Management > Load Balancing > Virtual Servers

Il est clair que rien n'a changé. L'état de la connexion est toujours "hors service" ("Down") :





Il faut accomplir encore une tâche : associer le certificat au serveur virtuel HTTPS.

Note : le terme anglais est "Bind" ou "lier".

Dans les paramètres du serveur virtuel lb_vs_HTTPS, nous devons cliquer sur "No Server Certificates" :



A la fenêtre qui s'affiche, nous allons sélectionner un certificat en cliquant sur le signe " > " désigné dans la capture d'écran ci-dessous par le point rouge :



Parmi les certificats proposés (seulement deux dans notre cas), nous choisissons celui que nous avons importé et installé :



Et nous cliquons sur "Bind" :




Il en résulte que nous avons un certificat associé à notre serveur virtuel...




Et que l'état de la connexion est désormais "en service" ou "Up" :



Nous ne devons pas oublier de diriger les clients Outlook vers le répartiteur de charge en ajustant l'enregistrement DNS pour "mail" (ou l'enregistrement comparable dans votre environnement). L'adresse IP devrait être l'adresse IP virtuelle "VIP" du serveur virtuel (soit 10.4.1.37 comme nous pouvons voir dans la capture d'écran précédente) : 




L'épreuve finale consiste à ouvrir Outlook sur un client et à voir s'il donne accès à la boîte aux lettres de l'utilisateur en question. C'est effectivement ce qui se passe. Mais comment être sûr que, en y accédant, nous passons bel et bien par le répartiteur de charge ?

Je le vérifie en désactivant le serveur virtuel lb_vs_HTTPS (il faut cliquer sur "Disable") :



Comme je m'y attendais, le serveur Exchange n'est plus accessible :




Il suffit d'activer le serveur virtuel pour rétablir l'accès.