Rechercher dans ce blog

jeudi 28 février 2019

Maintenance d'un DAG Exchange 2019

Bonjour à tous, nouvel article sur Exchange 2019.

Aujourd'hui, nous allons voir comment mettre en maintenance un DAG sur Exchange 2019.

Dans le dernier épisode, nous avions pu voir la mise en place d'un DAG Exchange 2019, mais qui dit produit Microsoft dit bien évidemment mises à jour de nos serveurs Exchange (Cumulatifs Windows Server, Rollup Exchange..).

L'exemple le plus marquant pour la mise en maintenance d'un nœud Exchange sera bien évidement le passage d'un rollup Exchange.

L'installation d'un rollup Exchange  mettra hors connexion votre noeud, puisque le rollup désinstalle complètement l'application pour la réinstaller avec la nouvelle version.

Mais les questions qui reviennent le plus souvent sont les suivantes:

- Mais pourquoi mettre en maintenance un serveur Exchange  alors que je passe mes rollup le soir ou le Week-end?

- Mais pourquoi mettre en maintenance un serveur Exchange car je trouve que cela prend beaucoup de temps à faire toutes ces manipulations?

Comme toutes mises à jours il y a des phénomènes que l'on ne peut pas toujours anticipés, tout ne se passe pas comme prévu (il faut reconnaître qu'il n' y a plus beaucoup de problèmes, Microsoft ayant fait beaucoup d'effort sur la façon d'installer un nouveau rollup).

Chacun doit prendre conscience que l'on doit prendre un maximum de précautions même si cela doit prendre un peu plus de préparation.

Les avantages d'un DAG sont les suivants:

- Eviter de perdre des données et de rendre indisponible une base de données.
- Possibilité de passer un rollup en pleine Journalisée sans impacts sur les utilisateurs
- Possibilité de passer des cumulatifs update et redémarrer le serveur en pleine journée
- Possibilité de prendre du temps pour investiguer un problème matériel

Pour mettre un nœud Exchange en maintenance, nous n'allons pas utiliser le scripts présents par défaut dans le répertoire des binaires Exchange car je trouve qu'ils ne fonctionnent pas très bien donc je ne les recommande pas. (voir ci-dessous).









Nous allons en détails effectuer les différentes commandes.

Il est très important de comprendre le fonctionnement de mise en maintenance d'un nœud Exchange configuré dans un DAG.

Une fois que l'on maîtrise les différentes commandes on pourra automatiser le tout dans un script.

Pour commencer, nous allons nous connecter à la console "Exchange Management Shell".






La première commande à passer sera de vider le "Hub Transport" du nœud Exchange et de le passer en mode "drainage"

Set-ServerComponentState EXCH2019A -Component HubTransport -State Draining -Requester Maintenance 

Redémarrage du service.

Restart-Service MSExchangeTransport 





Nous allons ensuite forcer à rediriger tous les messages de la file d'attente vers l'autre serveur du DAG.

Redirect-Message -Server EXCH2019A -Target EXCH2019B.labo.local








Nous vérifions le résultat de la commande.

Get-ServerComponentState EXCH2019A -Component HubTransport








Nous vérifions ensuite quel serveur gère le "Primary Active Manager (https://docs.microsoft.com/fr-fr/exchange/high-availability/database-availability-groups/active-manager?view=exchserver-2019)


Get-DatabaseAvailabilityGroup -Status | fl Name, PrimaryActiveManager

Nous constatons que le PAM est géré par le noeud que souhaitons mettre en maintenance.
Il faudra donc le déplacer.








Nous allons donc déplacer le PAM vers l'autre nœud.

Remarque: vous devrez vous connecter en "PowerShell Remoting avec WinrM sur l'un deux serveurs.

Move-ClusterGroup "Groupe du cluster" -Node EXCH2019B






 On vérifie la bonne migration du PAM vers le deuxième serveur.

Get-DatabaseAvailabilityGroup -Status | fl Name, PrimaryActiveManager








Nous mettons en pause le cluster sur le Nœud Exchange.

Suspend-ClusterNode EXCH2019A






On vérifie le résultat.
Get-ClusterNode







Nous allons maintenant déplacer les copies Actives sur le nœud.
Nous vérifions quelles bases de données sont actives (Mounted) sur le Nœud Exchange.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A

Nous remarquons que la base de données DB01 est active sur le serveur Exch2019A.




Nous déplaçons donc la copie active de la base de données DB01 vers le serveur Exch2019B.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A | ? {$_.Status -eq "Mounted"} | % {Move-ActiveMailboxDatabase $_.DatabaseName -ActivateOnServer EXCH2019B -Confirm:$false}




Nous vérifions les copies actives sur le serveur Exch2019B

Get-MailboxDatabaseCopyStatus -Server EXCH2019B

DB01 est bien active sur le serveur EXCH2019B.





On peut également vérifier la présence dans le Centre d'Administration Exchange.
















La commande ci-dessous sera nécessaire pour empêcher le serveur EXCHA2019A de pouvoir à nouveau monter la base de données DB01.

Set-MailboxServer EXCH2019A -DatabaseCopyAutoActivationPolicy Blocked





Vérification de la stratégie.

Get-MailboxServer EXCH2019A | ft Name,DatabaseCopyAutoActivationPolicy





 Pour terminer nous mettons notre nœud en maintenance.

Set-ServerComponentState EXCH2019A -Component ServerWideOffline -State Inactive -Requester Maintenance




Notre serveur est maintenant totalement hors ligne du DAG!!! 💪😏
Vous pouvez maintenant effectuer votre maintenance en toute sécurité!!!



Une fois votre maintenance terminée, nous allons pouvoir sortir le serveur Exchange de sa maintenance.

On sort le serveur du mode maintenance.

Set-ServerComponentState EXCH2019A -Component ServerWideOffline -State Active -Requester Maintenance







On réactive le cluster du le nœud.

Resume-ClusterNode EXCH2019A







On autorise à nouveau la possibilité l'auto-montage de la base de données sur le nœud.

Set-MailboxServer EXCH2019A -DatabaseCopyAutoActivationPolicy Unrestricted

    Et on vérifie.

Get-MailboxServer EXCH2019A | ft Name,DatabaseCopyAutoActivationPolicy







 On réactive le transport sur le serveur Exchange.

Set-ServerComponentState EXCH2019A -Component HubTransport -State Active -Requester Maintenance

Et on vérifie.

Get-ServerComponentState EXCH2019A -Component HubTransport





On vérifie que le serveur est à nouveau hors maintenance.

Get-ServerComponentState EXCH2019A | ft Component,State -AutoSize




 On rétablit le PAM sur le serveur Principal (Juste plus clair pour moi).

Move-ClusterGroup "Groupe du cluster" -Node EXCH2019A








On vérifie les bases de données.

Get-MailboxDatabaseCopyStatus -Server EXCH2019A

Get-MailboxDatabaseCopyStatus -Server EXCH2019B

On peu constater que tout est revenu comme à l'origine:

- DB01 est Active sur Exch2019A et Passive sur EXCH2019B
- DB02 est Active sur Exch2019B et Passive sur EXCH2019A











Voilà c'est terminé, tout est maintenant opérationnel. 😃😄

Dans cet article nous avons pu voir et comprendre la mise en maintenance d'un serveur Exchange 2019 présent dans un DAG.

Si vous avez compris et que vous maîtrisez les différentes étapes effectuées ci-dessus vous n'avez plus qu'à construire votre script.

A vos tests!Scriptez!!😊😊

samedi 16 février 2019

DAG Exchange 2019




Bonjour à tous, aujourd'hui nouvel article sur Exchange 2019.

Nous allons nous attaquer à la mise en place d'un "cluster" ou "DAG Exchange".

L'objectif de ce DAG sera bien évidemment d'avoir de la redondance des bases de données en cas de perte d'un noeud Exchange.

Les schéma ci-dessous nous montre l'architecture que nous allons utiliser.


Les serveurs ci-dessous ont été installés en mode core 2019 (Installation Exchange 2019 sur un serveur core 2019).


Récapitulatif de notre laboratoire en détails.


  • Deux serveurs Exchange 2019 en mode core (EXCH2019A et EXCH2019B).
  • Un serveur témoin (Witness) CA2019 (Serveur Windows 2019 pour autorité de certification interne).
  • Chaque serveur aura deux bases de données active et passive (DB01 active sur Exch2019A et DB02 active sur EXCH2019B).
  • Une machine en Windows 10 avec Outlook pour le test de bon fonctionnement
  • Une machine d'administration distante avec les outils de gestion Exchange 2019 (Voir Article)
En prérequis il vous faudra:

Si besoin renommer et déplacer les bases de données et logs sur des partitions différentes pour plus de visibilité et de facilité d'administration (voir article).

Ajouter le groupe "Exchange Trusted Subsystem"

Installer le rôle cluster de basculement sur chaque serveur Exchange:

Install-WindowsFeature –Name Failover-Clustering

Information: Dans notre laboratoire nous utiliserons le réseau MAPI pour le DAG.
En production il est recommandé d'avoir 2 réseaux (un pour le réseau MAPI Exchange et un pour le DAG Exchange) et au minimum deux cartes réseau par serveur.

Le DAG Exchange que nous allons configurer ne disposera pas d'adresse ip, car il utilise la nouvelle génération de clustering introduite depuis Exchange 2013 Server.


Pour créer le nouveau DAG à partir d'Exchange Management Shell, nous exécutons la commande New-DatabaseAvailabilityGroup, en fournissant le nom du DAG et en spécifiant le nom du serveur témoin de partage de fichiers. 
Je spécifie également le système de fichiers du DAG car mes serveurs Exchange 2019 utilisent ReFS pour leurs volumes de données.
Le witness sera créé automatiquement.

New-DatabaseAvailabilityGroup -Name EXCH2019DAG01 -WitnessServer CA2019.labo.local -FileSystem ReFS

Le DAG est maintenant créé.







La commande ci-dessous va nous permettre d'ajouter les serveurs membres au DAG.

Add-DatabaseAvailabilityGroupServer -Identity EXCH2019DAG01 -MailboxServer EXCH2019A
Add-DatabaseAvailabilityGroupServer -Identity EXCH2019DAG01 -MailboxServer EXCH2019B








Nous vérifions la présence de nos serveurs Exchange dans notre DAG.

Get-DatabaseAvailabilityGroup EXCH2019DAG01 -Status





Nous pouvons également vérifier la bonne configuration du Witness

Get-DatabaseAvailabilityGroup EXCH2019DAG01 -Status | fl *witness*












Sur le serveur témoin "CA2019" , on remarque la présence des fichiers "Witness"




Les écrans ci-dessous nous montrent la bonne création de notre DAG depuis la console du centre d'administration Exchange.



Le serveur témoin a été correctement  configuré.


On peut constater ci-dessous, que le DAG ne comporte pas d'adresses ip.


Notre DAG est maintenant en place mais ce n'est pas terminé.

Nous allons mettre en place la copie des bases de données.

Petit rappel de la configuration souhaitée:

-Le serveur EXCH2019A hébergera la base de données DB01 en actif et la base de données DB02 en passif.

-Le serveur EXCH2019B hébergera la base de données DB02 en actif et la base de données DB01 en passif.

Pour exemple si le serveur EXCH2019A devient indisponible, la base de données DB01 passera en actif sur EXCH2019B.


Pour information: dans un prochain article nous parlerons de la mise en place de la fonction "d' AutoReseed" qui est une technologie permettant de prévenir d'une défaillance disque.


Pour mettre en place la copie de base de données, lancer les commandes suivantes:

Add-MailboxDatabaseCopy -Identity DB01 -MailboxServer Exch2019A -ActivationPreference 2

Add-MailboxDatabaseCopy -Identity DB02 -MailboxServer Exch2019B -ActivationPreference 2








Commandes exécutées avec succès.



Comme demandé, nous redémarrons le service "MSExchangeIS" de chaque serveur.

Invoke-Command -ComputerName EXCH2019A -ScriptBlock {Restart-Service MSEchangeIS}



Nous vérifions la bonne santé de nos bases de données (état Healthy).

Get-MailboxDatabaseCopyStatus DB01


Nous vérifions également la bonne configuration dans le centre de gestion d'administration Exchange.







Nous pouvons également vérifier la copie des bases de données sur les différentes partitions.




Les différentes manipulations effectuées n'ont eu aucun impacts sur mon client Outlook.




Dans cet article, nous avons pu voir comment mettre en place un DAG Exchange.

A bientôt. 😏