Haute disponibilité Exchange : créer un DAG et répliquer les bases

Un groupe de disponibilité de base de données (DAG) permet à une base de boîtes aux lettres de basculer automatiquement sur un autre serveur Exchange. Voici comment Microsoft le décrit et le construit.

Par la rédaction de Pixelabs · 12 octobre 2026

Un DAG (Database Availability Group) est, selon Microsoft, la base de la haute disponibilité des serveurs de boîtes aux lettres Exchange : un groupe de 16 serveurs Mailbox au plus qui héberge un ensemble de bases et assure une récupération automatique, au niveau de chaque base, en cas de panne de disque, de serveur ou de réseau.

Créer un DAG installe un cluster de basculement Windows et modifie Active Directory. Montez-le d'abord dans un lab et sauvegardez les serveurs avant d'intervenir en production.

Exchange 2016 et les DAG aujourd'hui

L'ancienne page visait Exchange 2016, dont le support étendu a pris fin le 14 octobre 2025. Les procédures de Microsoft Learn citées ici s'appliquent à Exchange 2019 et à Exchange Server SE. Un point compte pour la migration : tous les serveurs d'un DAG doivent exécuter la même version d'Exchange. On ne convertit donc pas un DAG 2016 : on crée un DAG sur les nouveaux serveurs et on y déplace les boîtes aux lettres.

Comment fonctionne un DAG

• Active Manager, présent sur chaque serveur Mailbox, gère les basculements.
• Au premier serveur ajouté, Exchange crée automatiquement un cluster de basculement dédié au DAG ; l'utiliser à autre chose n'est pas supporté.
• La réplication continue intégrée copie les journaux de transactions de la base active vers ses copies passives.
• Le quorum décide quel groupe de membres reste opérationnel. Avec un nombre pair de membres, un serveur témoin externe départage les votes ; avec un nombre impair, chaque membre vote seul.

L'exemple de Microsoft : avec quatre membres et un témoin, au moins trois votants doivent communiquer. Deux votants peuvent être hors ligne sans coupure ; à trois, le DAG perd le quorum et les bases se démontent.

La topologie du lab

Les deux serveurs Exchange sont installés comme décrit dans le guide de déploiement d'Exchange Server, à la même version.

Créer le DAG

Microsoft impose quelques règles avant la commande :

• le nom du DAG compte 15 caractères au plus ; il devient aussi le nom du cluster ;
• le témoin se désigne par un nom d'hôte ou un FQDN, jamais par une adresse IP, et ne peut pas être membre du DAG ;
• Microsoft recommande un serveur Exchange comme témoin. Avec un serveur de fichiers ordinaire, ajoutez le groupe Exchange Trusted Subsystem au groupe Administrateurs local du témoin, sinon la création échoue avec une erreur « Access is denied ».

Dans l'Exchange Management Shell :

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer fs01.lab.local -WitnessDirectory C:\DAG1

Sans adresse IP indiquée, cet exemple de Microsoft laisse le DAG obtenir ses adresses par DHCP. Microsoft décrit aussi des DAG sans point d'accès administratif : pas d'adresse IP, pas de nom DNS, pas d'objet ordinateur de cluster. Elle les recommande quand aucune application tierce (sauvegarde, supervision) n'a besoin de joindre le cluster, car ils réduisent la surface d'attaque. Les conditions de version de Windows associées sont détaillées sur la page de Microsoft : vérifiez-les pour votre système.

Ajouter les serveurs et les copies

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer ex01
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer ex02

Le cluster naît à l'ajout du premier serveur ; chaque ajout suivant rejoint le cluster et Exchange ajuste le modèle de quorum. Ajoutez ensuite une copie de chaque base sur l'autre membre :

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer ex02 -ActivationPreference 2

La base active doit être montée, et le serveur cible ne doit pas déjà en héberger une copie. La durée de l'amorçage (seeding) dépend de la taille de la base et du réseau. Pour une copie décalée, Microsoft montre le paramètre -ReplayLagTime.

Vérifier la réplication

Get-MailboxDatabaseCopyStatus -Identity DB1 | Format-List
Test-ReplicationHealth -Identity ex02

Les colonnes Status et Content Index State doivent valoir Healthy. Les autres états documentés ont un sens précis : Initializing ne devrait pas durer plus de 30 secondes, Failed signale une copie qui n'arrive plus à copier ou rejouer ses journaux, ServiceDown un service de réplication arrêté.

Test-ReplicationHealth contrôle le service de cluster, le service de réplication, Active Manager, le quorum, l'accès au témoin et la redondance des bases. Les événements détaillés sont dans l'Observateur d'événements, sous les canaux HighAvailability et MailboxDatabaseFailureItems d'Exchange. Ces outils sont repris dans la page Exchange troubleshooting.

Un DAG ne dispense pas des mises à jour de sécurité, comme l'explique la page sur la faille Exchange et ses correctifs. Les autres guides sont dans la rubrique Exchange Server et sur l'accueil des tutoriels Linux et Windows.

Questions fréquentes