Analyse de la haute disponibilité et de la résilience de site

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2015-03-09

S’assurer que vos serveurs fonctionnent de manière fiable et que vos copies de base de données sont saines constituent des objectifs clés pour les opérations de messagerie quotidiennes. Pour garantir la disponibilité et la fiabilité de votre organisation Microsoft Exchange Server 2010, vous devez analyser activement le matériel, le système d’exploitation Windows et les services Exchange 2010. L’analyse proactive associée à la maintenance préventive peut vous aider à identifier les erreurs potentielles avant qu’un problème grave n’affecte le fonctionnement de votre organisation Exchange.

L’analyse de votre organisation Exchange implique de vérifier régulièrement qu’il n’existe aucun problème avec les services ou les données. L’analyse comprend généralement un système de notification qui envoie des alertes lorsque les problèmes surviennent. Windows Server 2008 et Exchange 2010 incluent plusieurs outils et services qui permettent de vous assurer que votre organisation Exchange fonctionne correctement. L’analyse quotidienne présente plusieurs avantages. Elle permet de :

• satisfaire les exigences de vos contrats SLA ;

• garantir l’exécution de tâches administratives spécifiques, comme les sauvegardes quotidiennes ;

• détecter et traiter les problèmes qui peuvent affecter le service de messagerie ou la disponibilité des données.

Dans une organisation Exchange 2010, les procédures, rôles et responsabilités intervenant dans les opérations doivent être formalisés. Il est primordial de comprendre le lien entre des méthodes opérationnelles et des procédures solides et une infrastructure saine. Bien documentées, les méthodes et procédures détaillées permettent de s’assurer que tous les composants de l’environnement d’une organisation sur lesquels Exchange s’appuie sont gérés de façon efficace.

Exchange 2010 comprend plusieurs outils, scripts et fonctionnalités intégrés qui peuvent être utilisés dans le cadre de l’analyse proactive lorsqu’Exchange est configuré pour la haute disponibilité ou la résilience de site. Les principales cmdlets d’analyse de la résilience de site et de la disponibilité élevée sont Get-MailboxDatabaseCopyStatus et Test-ReplicationHealth. Outre la fourniture de cmdlets qui peuvent exécuter des fonctions d’analyse et des rapports d’état, Exchange 2010 comporte également un nouveau flux de journal d’événements qui exploite les possibilités du canal crimson de Windows Server, ainsi que des scripts intégrés qui collectent et analysent les données à partir de ces canaux d’événements.

Vous pouvez utiliser les informations de cette rubrique pour analyser l’intégrité et l’état des copies de la base de données de boîtes aux lettres pour les groupes de disponibilité de base de données (DAG).

Contenu de cette rubrique

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Journalisation des événements du canal Crimson

Script CollectOverMetrics.ps1

Script CollectReplicationMetrics.ps1

Script CheckDatabaseRedundancy.ps1

Cmdlet Get-MailboxDatabaseCopyStatus

Vous pouvez utiliser la cmdlet Get-MailboxDatabaseCopyStatus pour afficher des informations sur l’état des copies de la base de données de boîtes aux lettres. Cette cmdlet vous permet de consulter des informations sur toutes les copies d’une base de données spécifique, des informations sur une copie spécifique d’une base de données installée sur un serveur donné ou des informations sur toutes les copies de base de données installées sur un serveur. Le tableau suivant décrit les valeurs possibles de l’état d’une copie de base de données de boîtes aux lettres.

État de copie de la base de données

État de copie de la base de données	Description
Échec	La copie de la base de données de boîtes aux lettres possède l’état Échec car elle n’est pas suspendue et n’est pas capable de copier ou de relire les fichiers journaux. Lorsque la copie est définie sur l’état Échec et qu’elle n’est pas suspendue, le système vérifie régulièrement si le problème à l’origine de cet état a été résolu. Si le système détecte que le problème est résolu, et à condition qu’il n’y ait aucune autre difficulté, l’état de copie passe automatiquement à Sain.
Amorçage	La copie de la base de données de boîtes aux lettres ou l’index de contenu est en cours d’amorçage, ou tous deux le sont. Après l’exécution réussie de l’amorçage, l’état de la copie doit passer à Initialisation en cours.
SeedingSource	La copie de la base de données de boîtes aux lettres est utilisée comme élément source pour une opération d’amorçage de copie de base de données.
Suspendu	La copie de la base de données de boîtes aux lettres possède l’état Suspendu car un administrateur a manuellement suspendu la copie de la base de données en exécutant la cmdlet Suspend-MailboxDatabaseCopy.
Sain	La copie de la base de données de boîtes aux lettres est en train de copier et de relire les fichiers journaux ou a déjà effectué cette opération.
ServiceDown	Le service de réplication Microsoft Exchange n’est pas disponible ou est en cours d’exécution sur le serveur qui héberge la copie de la base de données de boîtes aux lettres.
Initialisation en cours	La copie de la base de données de boîtes aux lettres sera définie sur l’état Initialisation en cours lorsqu’une copie de base de données aura été créée, lorsque le service de réplication Microsoft Exchange démarrera ou aura démarré et pendant le passage de l’état Suspendu, ServiceDown, Échec, Amorçage, SinglePageRestore, LostWrite ou Déconnecté à un autre état. Lorsqu’elle est définie sur l’état d’initialisation, le système vérifie que la base de données et l’état du flux de journal sont cohérents. Dans la plupart des cas, l’état de la copie est défini sur Initialisation en cours pendant environ 15 secondes, mais dans tous les cas, il ne doit pas rester défini sur cet état pendant plus de 30 secondes.
Resynchronisation	La copie de la base de données de boîtes aux lettres et ses fichiers journaux sont comparés avec la copie active de la base de données pour vous permettre de rechercher d’éventuelles divergences entre les deux copies. L’état de la copie reste tel quel tant que les divergences trouvées n’ont pas été résolues.
Monté	La copie active est en ligne et accepte les connexions des clients. Seule la copie active de la base de données de boîtes aux lettres peut posséder l’état Monté.
Démontée	La copie active est hors ligne et n’accepte pas les connexions des clients. Seule la copie active de la base de données de boîtes aux lettres peut être définie sur Démontée.
Montage	La copie active va être en ligne mais n’accepte pas encore les connexions des clients. Seule la copie active de la base de données de boîtes aux lettres peut posséder l’état Montage.
Démontage	La copie active va passer en mode hors connexion et met fin aux connexions des clients. Seule la copie active de la base de données de boîtes aux lettres peut posséder l’état Démontage.
Déconnecté et Sain	La copie de la base de données de boîtes aux lettres n’est plus connectée à la copie active de la base de données et possédait l’état Sain lorsque la perte de connexion s’est produite. Cet état représente la copie de la base de données par rapport à la connectivité de sa copie de base de données source. Il peut être signalé lors des défaillances réseau d’un groupe de disponibilité de base de données entre la copie source et la copie cible.
Déconnecté et Resynchronisation	La copie de la base de données de boîtes aux lettres n’est plus connectée à la copie active de la base de données et possédait l’état Resynchronisation lorsque la perte de connexion s’est produite. Cet état représente la copie de la base de données par rapport à la connectivité de sa copie de base de données source. Il peut être signalé lors des défaillances réseau d’un groupe de disponibilité de base de données entre la copie source et la copie cible.
Échec et Suspendu	Les états Échec et Suspendu ont été définis simultanément par le système en raison de la détection d’une défaillance et parce que sa résolution nécessite l’intervention d’un administrateur. Cela se produit, par exemple, lorsque le système détecte une divergence irrécupérable entre la base de données de boîtes aux lettres active et une copie de la base de données. Contrairement à l’état Échec, le système ne vérifie pas régulièrement si le problème a été résolu et si une récupération automatique a lieu. L’intervention d’un administrateur est indispensable pour corriger la cause sous-jacente de la défaillance afin que la copie de la base de données puisse passer à un état sain.
SinglePageRestore	Cet état indique qu’une opération de restauration en page unique a lieu sur la copie de la base de données de boîtes aux lettres.

La cmdlet Get-MailboxDatabaseCopyStatus comprend également un paramètre appelé ConnectionStatus qui renvoie des informations sur les réseaux de réplication en cours d’utilisation. Si vous utilisez ce paramètre, les deux champs supplémentaires IncomingLogCopyingNetwork et SeedingNetwork seront renseignés dans la sortie de la tâche.

Exemples Get-MailboxDatabaseCopyStatus

Les exemples suivants utilisent la cmdlet Get-MailboxDatabaseCopyStatus. Chaque exemple transfère les résultats à la cmdlet Format-List afin qu’ils soient affichés sous la forme d’une liste.

Cet exemple renvoie les informations relatives à l’état de toutes les copies de la base de données nommée DB2.

Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List

Cet exemple renvoie l’état de toutes les copies de base de données sur le serveur de boîtes aux lettres nommé MBX2.

Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List

Cet exemple renvoie l’état de toutes les copies de base de données sur le serveur de boîtes aux lettres local.

Get-MailboxDatabaseCopyStatus -Local | Format-List

Cet exemple renvoie des informations sur l’état, l’envoi des journaux et le réseau d’amorçage pour la base de données DB3 sur le serveur de boîtes aux lettres nommé MBX1.

Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List

Pour plus d’informations sur l’utilisation de la cmdlet Get-MailboxDatabaseCopyStatus, voir Get-MailboxDatabaseCopyStatus.

Cmdlet Get-MailboxDatabaseCopyStatus

Cmdlet Test-ReplicationHealth

Vous pouvez utiliser la cmdlet Test-ReplicationHealth pour afficher des informations sur l’état de réplication continue des copies de la base de données de boîtes aux lettres. Cette cmdlet permet de vérifier tous les aspects de l’état de réplication et de relecture afin d’offrir une vue d’ensemble complète d’un serveur de boîtes aux lettres spécifique dans un groupe de disponibilité de base de données.

La cmdlet Test-ReplicationHealth a été conçue pour l’analyse proactive de la réplication continue et du pipeline de la réplication continue, la disponibilité d’Active Manager, l’état du service de cluster sous-jacent, le quorum et les composants réseau. Elle peut être exécutée localement ou à distance sur n’importe quel serveur de boîtes aux lettres dans un groupe de disponibilité de base de données. La cmdlet Test-ReplicationHealth exécute les tests répertoriés dans le tableau suivant.

Tests de la cmdlet Test-ReplicationHealth

Nom du test	Description
ClusterService	Vérifie que le service de cluster est en cours d’exécution et accessible sur le membre du DAG spécifié ou, si aucun membre de DAG n’est indiqué, sur le serveur local.
ReplayService	Vérifie que le service de réplication Microsoft Exchange est en cours d’exécution et accessible sur le membre du DAG spécifié ou, si aucun membre de DAG n’est indiqué, sur le serveur local.
ActiveManager	Vérifie que l’instance d’Active Manager exécutée sur le membre du DAG spécifié (ou, si aucun membre de DAG n’est indiqué, sur le serveur local) se trouve dans un rôle valide (principal, secondaire ou autonome).
TasksRpcListener	Vérifie que le serveur d’appel de procédure distante (RPC) des tâches est en cours d’exécution et accessible sur le membre du DAG spécifié ou, si aucun membre de DAG n’est indiqué, sur le serveur local.
TcpListener	Vérifie que le port d’écoute TCP de copie du journal est en cours d’exécution et accessible sur le membre du DAG spécifié ou, si aucun membre de DAG n’est indiqué, sur le serveur local.
DagMembersUp	Vérifie que tous les membres du DAG sont disponibles, en cours d’exécution et accessibles.
ClusterNetwork	Vérifie que tous les réseaux gérés par des clusters sur le membre de DAG spécifié (ou, si aucun membre de DAG n’est indiqué, sur le serveur local) sont disponibles.
QuorumGroup	Vérifie que le groupe de clusters par défaut (groupe quorum) est sain et en ligne.
FileShareQuorum	Vérifie que le serveur témoin, le répertoire témoin et le partage configurés pour le DAG sont accessibles.
DBCopySuspended	Vérifie si des copies de la base de données de boîtes aux lettres ont l’état Suspendu sur le membre de DAG spécifié ou, si aucun membre de DAG n’est indiqué, sur le serveur local
DBCopyFailed	Vérifie si des copies de la base de données de boîtes aux lettres ont l’état Échec sur le membre de DAG spécifié ou, si aucun membre de DAG n’est indiqué, sur le serveur local.
DBInitializing	Vérifie si des copies de la base de données de boîtes aux lettres ont l’état Initialisation en cours sur le membre de DAG spécifié ou, si aucun membre de DAG n’est indiqué, sur le serveur local.
DBDisconnected	Vérifie si des copies de la base de données de boîtes aux lettres ont l’état Déconnecté sur le membre de DAG spécifié ou, si aucun membre de DAG n’est indiqué, sur le serveur local.
DBLogCopyKeepingUp	Vérifie que la copie et l’inspection du journal par les copies passives des bases de données sur le membre de DAG spécifié (ou, si aucun membre de DAG n’est indiqué, sur le serveur local) sont capables de suivre le rythme de l’activité de génération du journal sur la copie active.
DBLogReplayKeepingUp	Vérifie que l’activité de relecture pour les copies passives des bases de données sur le membre de DAG spécifié (ou, si aucun membre de DAG n’est indiqué, sur le serveur local) est capable de suivre le rythme de l’activité de copie et d’inspection du journal.

Exemple Test-ReplicationHealth

Cet exemple utilise la cmdlet Test-ReplicationHealth pour tester l’intégrité de la réplication pour le serveur de boîtes aux lettres MBX1.

Test-ReplicationHealth -Identity MBX1

Cmdlet Get-MailboxDatabaseCopyStatus

Journalisation des événements du canal Crimson

Windows Server 2008 comprend deux catégories de journaux d’événements : les journaux Windows et les journaux des applications et des services. La catégorie de journaux Windows inclut les journaux d’événements disponibles dans les versions précédentes de Windows : les journaux des événements d’application, de sécurité et système. Elle inclut également deux nouveaux journaux : le journal d’installation et le journal des événements transmis (ForwardedEvents). Les journaux Windows sont conçus pour le stockage d’événements appartenant à des applications héritées et d’événements qui s’appliquent à la totalité du système.

Les journaux des applications et des services sont une nouvelle catégorie de journaux d’événements. Ces journaux stockent les événements d’une application ou d’un composant unique au lieu des événements qui concernent le système entier. Cette nouvelle catégorie de journaux d’événements est désignée par les termes « canal crimson d’une application ».

La catégorie de journaux des applications et services inclut quatre sous-types : les journaux d’administration, opérationnels, d’analyse et de débogage. Les événements des journaux d’administration sont particulièrement utiles si vous utilisez des enregistrements du journal d’événements pour résoudre les problèmes. Les événements contenus dans le journal d’administration doivent vous indiquer comment répondre aux événements. Les événements du journal opérationnel sont eux aussi utiles, mais ils nécessitent une interprétation plus détaillée. Les journaux d’administration et de débogage ne sont pas aussi conviviaux. Les journaux d’analyse (masqués et désactivés par défaut) stockent des événements qui effectuent le suivi d’un problème. Ils contiennent généralement un grand nombre d’événements. Les journaux de débogage sont utilisés par les développeurs lors du débogage d’applications.

Exchange 2010 enregistre les événements dans les canaux crimson, dans la zone des journaux des applications et services. Vous pouvez afficher ces canaux en procédant comme suit :

1. Ouvrez l’Observateur d’événements.

2. Dans l’arborescence de la console, accédez à Journaux des applications et des services > Microsoft > Exchange.

3. Sous Exchange, sélectionnez un canal crimson : HighAvailability ou MailboxDatabaseFailureItems.

Le canal HighAvailability contient des événements liés au démarrage et à la fermeture du service de réplication Microsoft Exchange ainsi que les divers composants qui s’exécutent au sein de ce service Microsoft Exchange, comme Active Manager, l’API de réplication synchrone tiers, le serveur de tâches RPC, le port d’écoute TCP et l’enregistreur VSS (Service de cliché instantané de volumes). Le canal HighAvailability permet également à Active Manager de journaliser les événements associés aux événements d’analyse de rôle et d’action de base de données Active Manager, comme le montage de la base de données et la troncation du journal, et d’enregistrer des événements associés au cluster sous-jacent du DAG.

Le canal MailboxDatabaseFailureItems sert à journaliser les événements associés aux défaillances qui affectent une base de données de boîte aux lettres répliquées.

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectOverMetrics.ps1

Exchange 2010 comprend un script appelé CollectOverMetrics.ps1 disponible dans le dossier Scripts. CollectOverMetrics.ps1 lit les journaux des événements relatifs aux membres du DAG pour rassembler des informations sur les opérations relatives aux bases de données (telles que montages, déplacements et basculements de bases de données) sur une période donnée. Pour chaque opération, le script enregistre les informations suivantes :

• Identité de la base de données

• Heure de début et de fin de l’opération

• Serveurs sur lesquels la base de données a été montée au début et à la fin de l’opération

• Raison de l’opération

• Les informations en cas de réussite ou d’échec de l’opération

Le script consigne ces informations dans des fichiers .csv avec une opération par ligne. Il crée un fichier .csv pour chaque DAG.

Ce script prend en charge des paramètres qui vous permettent de personnaliser son comportement et ses résultats. Par exemple, les résultats peuvent être limités à un sous-ensemble spécifique à l’aide des paramètres Database et ReportFilter. Seules les opérations correspondant à ces filtres seront consignées dans le rapport récapitulatif au format HTML. Les paramètres disponibles sont répertoriés dans le tableau suivant.

Paramètres du script CollectOverMetrics.ps1

Paramètre	Description
DatabaseAvailabilityGroup	Spécifie le nom du DAG à partir duquel vous voulez collecter des mesures. Si ce paramètre est omis, le DAG auquel le serveur local appartient sera utilisé. Des caractères génériques peuvent être utilisés pour collecter des informations à partir de plusieurs DAG et créer des rapports.
Database	Fournit la liste des bases de données pour lesquelles le rapport doit être généré. Les caractères génériques sont pris en charge, par exemple, -Database:"DB1","DB2" ou -Database:"DB*".
StartTime	Spécifie la durée de la période à analyser. Le script analyse uniquement les événements consignés au cours de cette période. Par conséquent, le script peut sélectionner des enregistrements d’opération partiels (par exemple, seulement la fin d’une opération au début de la période ou inversement). Si ni le paramètre StartTime, ni le paramètre EndTime n’est spécifié, le script analyse par défaut les dernières 24 heures. Si un seul des deux paramètres est spécifié, l’analyse du script commencera ou se terminera à l’heure spécifiée pour une période de 24 heures.
EndTime	Spécifie la durée de la période à analyser. Le script analyse uniquement les événements consignés au cours de cette période. Par conséquent, le script peut sélectionner des enregistrements d’opération partiels (par exemple, seulement la fin d’une opération au début de la période ou inversement). Si ni le paramètre StartTime, ni le paramètre EndTime n’est spécifié, le script analyse par défaut les dernières 24 heures. Si un seul des deux paramètres est spécifié, l’analyse du script commencera ou se terminera à l’heure spécifiée pour une période de 24 heures.
ReportPath	Spécifie le dossier utilisé pour stocker les résultats du traitement des événements. Si ce paramètre est omis, le dossier Scripts sera utilisé. Si le paramètre est spécifié, le script génère une liste de fichiers .csv et utilise ces derniers comme données source pour créer un rapport récapitulatif au format HTML. Ce rapport est le même que celui qui est généré avec l’option -GenerateHtmlReport. Les fichiers peuvent être générés pour plusieurs groupes de disponibilité de base de données à différents moments ou simultanément et le script fusionne ensuite toutes leurs données.
GenerateHtmlReport	Indique au script de rassembler toutes les informations qu’il a enregistrées, de les regrouper ensuite par type d’opération et de générer un fichier HTML comprenant des statistiques pour chacun de ces groupes. Le rapport indique le nombre total d’opérations dans chaque groupe ainsi que le nombre d’opérations ayant échoué et fournit des statistiques sur la durée des opérations dans chaque groupe. Le rapport indique également le type des erreurs qui ont entraîné l’échec des opérations.
ShowHtmlReport	Indique que le rapport HTML doit être affiché dans un navigateur Web après avoir été généré.
SummariseCSVFiles	Indique au script de lire les données des fichiers .csv qu’il a générés. Ces données sont ensuite utilisées pour générer un rapport récapitulatif similaire au rapport généré par le paramètre GenerateHtmlReport.
ActionType	Indique le type des actions opérationnelles que le script doit collecter. Les valeurs de ce paramètre sont Move, Mount, Dismount et Remount. La valeur Move indique quand la base de données change de serveur, par déplacement contrôlé ou par basculement. Les valeurs Mount, Dismount et Remount indiquent quand la base de données change d’état de montage sans être transférée sur un autre ordinateur.
ActionTrigger	Indique quelles opérations administratives doivent être collectées par le script. Les valeurs de ce paramètre sont Admin et Automatic. Les actions automatiques sont des actions effectuées automatiquement par le système (par exemple, un basculement lorsqu’un serveur n’est plus disponible en ligne). Les actions administratives sont des actions effectuées par un administrateur à l’aide de l’environnement de ligne de commande Exchange Management Shell ou de la console de gestion Exchange.
RawOutput	Indique au script de consigner les résultats directement dans le flux de sortie, comme c’est le cas dans un scénario d’écriture de sortie (write-output), au lieu de les consigner dans des fichiers .csv. Ces informations peuvent ensuite être transmises à d’autres commandes.
IncludedExtendedEvents	Indique au script de collecter les événements qui fournissent des informations de diagnostic sur le temps consacré au montage des bases de données. Cette étape peut prendre du temps si le journal des événements relatifs aux applications est volumineux.
MergeCSVFiles	Indique au script de récupérer tous les fichiers .csv contenant des données sur chaque opération et de les fusionner en un seul fichier .csv.
ReportFilter	Indique d’appliquer un filtre aux opérations à partir des champs des fichiers .csv. Ce paramètre utilise le même format qu’une opération Where, chaque élément étant défini sur $_ et retournant une valeur booléenne. Par exemple : {$_DatabaseName -notlike "Mailbox Database*"} peut être utilisé pour exclure les bases de données par défaut du rapport.

Exemples CollectOverMetrics.ps1

L’exemple suivant collecte des mesures pour toutes les bases de données correspondant à DB* (avec un caractère générique) dans un groupe de disponibilité de base de données nommé DAG1. Une fois les mesures recueillies, un rapport HTML est généré et affiché.

CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport

Les exemples suivants montrent différentes manières de filtrer un rapport récapitulatif HTML. Le premier exemple utilise le paramètre Database qui récupère une liste de noms de base de données. Le rapport récapitulatif contient alors uniquement des données sur ces bases de données. Les deux exemples suivants utilisent l’option ReportFilter. Le dernier exemple filtre toutes les bases de données par défaut.

CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }

Cmdlet Get-MailboxDatabaseCopyStatus

Script CollectReplicationMetrics.ps1

Le script d’évaluation de l’intégrité CollectReplicationMetrics.ps1 est lui aussi inclus dans Exchange 2010. Il fournit une forme active d’analyse, car il collecte des mesures en temps réel, pendant son exécution. CollectReplicationMetrics.ps1 collecte des données à partir des compteurs de performance liés à la réplication des bases de données. Le script rassemble des données de compteur à partir de plusieurs serveurs de boîtes aux lettres, consigne ces données dans un fichier .csv et établit des statistiques à partir de celles-ci (par exemple, la durée pendant laquelle chaque copie était en panne ou suspendue, la longueur moyenne de la file d’attente de copie ou de relecture ou la durée pendant laquelle les copies ne correspondaient plus aux critères de basculement).

Vous pouvez spécifier les serveurs individuellement ou vous pouvez spécifier des DAG entiers. Vous pouvez exécuter le script pour collecter des données afin de générer un rapport, ou bien vous pouvez l’exécuter pour collecter uniquement des données ou établir un rapport à partir des données déjà collectées. Vous pouvez spécifier la fréquence à laquelle les données doivent être collectées et la durée totale de la collecte.

Les données collectées sur chaque serveur sont consignées dans un fichier nommé CounterData.<Nom_serveur>.<horodatage>.csv. Le rapport récapitulatif sera enregistré dans un fichier nommé HaReplPerfReport.<Nom_DAG>.<horodatage>.csv ou HaReplPerfReport.<horodatage>.csv si vous n’avez pas exécuté le script avec le paramètre DagName.

Le script lance des tâches PowerShell pour collecter les données de chaque serveur. Ces tâches sont exécutées pour toute la durée de la collecte des données. Si vous spécifiez un grand nombre de serveurs, ce processus peut consommer une quantité considérable de mémoire. L’étape finale du processus, lorsqu’un rapport récapitulatif est établi à partir des données, peut également prendre beaucoup de temps pour de grands volumes de données. Il est possible d’exécuter l’étape de collecte sur un ordinateur, puis de copier les données ailleurs pour les traiter.

Le script CollectReplicationMetrics.ps1 prend en charge des paramètres qui vous permettent de personnaliser son comportement et ses résultats. Les paramètres disponibles sont répertoriés dans le tableau suivant.

Paramètres du script CollectReplicationMetrics.ps1

Paramètre	Description
DagName	Spécifie le nom du DAG à partir duquel vous voulez collecter des mesures. Si ce paramètre est omis, le DAG auquel le serveur local appartient sera utilisé.
DatabaseNames	Fournit la liste des bases de données pour lesquelles le rapport doit être généré. Les caractères génériques sont pris en charge, par exemple, -DatabaseNames:"DB1","DB2" ou -DatabaseNames:"DB*".
ReportPath	Spécifie le dossier utilisé pour stocker les résultats du traitement des événements. Si ce paramètre est omis, le dossier Scripts sera utilisé.
Duration	Spécifie la durée pendant laquelle que le processus de collecte doit s’exécuter. Il s’agit en général de valeurs comprises entre une et trois heures. Des durées plus longues doivent être utilisées uniquement pour des intervalles plus importants entre chaque collecte ou pour une série de tâches plus courtes exécutées par des tâches planifiées.
Frequency	Spécifie la fréquence à laquelle les mesures de données sont collectées. En général, les valeurs sont 30 secondes, une minute ou cinq minutes. Dans des circonstances normales, des intervalles plus courts que ces valeurs ne montrent pas des changements importants entre chaque collecte.
Servers	Indique l’identité des serveurs sur lesquels des statistiques seront collectées. Vous pouvez spécifier n’importe quelle valeur, y compris des caractères génériques ou des GUID.
SummariseFiles	Spécifie une liste de fichiers .csv pour générer un rapport récapitulatif. Ces fichiers sont nommés CounterData.<Données_compteur>* et sont générés par le script CollectReplicationMetrics.ps1.
Mode	Spécifie les étapes de traitement que le script exécute. Vous pouvez utiliser les valeurs suivantes : CollectAndReport   Il s’agit de la valeur par défaut. Cette valeur signifie que le script doit collecter les données des serveurs et les traiter pour produire le rapport récapitulatif. CollectOnly   Cette valeur signifie que le script doit uniquement collecter les données et ne pas produire de rapport. ProcessOnly   Cette valeur signifie que le script doit importer les données d’un ensemble de fichiers .csv et les traiter pour produire le rapport récapitulatif. Le paramètre SummariseFiles est utilisé pour fournir au script la liste de fichiers à traiter.
MoveFilestoArchive	Spécifie que le script doit placer les fichiers dans un dossier compressé une fois qu’ils sont traités.
LoadExchangeSnapin	Spécifie que le script doit charger les commandes Exchange Shell. Ce paramètre est utile lorsque le script doit s’exécuter en dehors de l’environnement de ligne de commande Exchange Management Shell, comme c’est le cas pour une tâche planifiée.

Exemple CollectReplicationMetrics.ps1

L’exemple suivant collecte des données sur une période d’une heure, et à des intervalles d’une minute, à partir de tous les serveurs dans le DAG « DAG1 », puis génère un rapport récapitulatif. Le paramètre ReportPath est également utilisé pour que le script place tous les fichiers dans le répertoire actuel.

CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath

L’exemple suivant lit les données dans tous les fichiers correspondant à « CounterData* », puis génère un rapport récapitulatif.

CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath

Cmdlet Get-MailboxDatabaseCopyStatus

Script CheckDatabaseRedundancy.ps1

Comme son nom l’indique, l’objet du script CheckDatabaseRedundancy.ps1 est de surveiller la redondance des bases de données de boîtes aux lettres répliquées en vérifiant qu’au moins deux copies configurées sont à jour et saines. Le script vous prévient s’il n’existe qu’une seule copie saine d’une base de données répliquée. Dans ce cas, il compte les copies actives et passives pour déterminer la redondance des bases de données.

Lorsque le rôle serveur de boîtes aux lettres est installé, le script CheckDatabaseRedundancy.ps1 est automatiquement configuré par Exchange afin d’exécuter une tâche planifiée appelée Database One Copy Alert. Par défaut, la tâche planifiée Database One Copy Alert est configurée pour une exécution toutes les 60 minutes. Vous pouvez modifier ce comportement et les paramètres de la tâche planifiée à l’aide du service Planificateur de tâches de Windows. Ce script est conçu avant tout pour vérifier l’appartenance à un groupe de disponibilité de base de données (DAG). Ainsi, si le serveur de boîtes aux lettres n’est pas membre d’un groupe de disponibilité de base de données, le script se ferme aussitôt.

Le script peut également être exécuté interactivement à partir du dossiers Scripts. Si vous exécutez le script de manière interactive, vous devez spécifier le nom d’une base de données ou le nom d’un membre du groupe de disponibilité de base de données. Deux paramètres sont prévus à cet effet, MailboxDatabaseName pour spécifier une base de données et MailboxServerName pour spécifier un membre du DAG. Lorsque vous exécutez le script dans la console, celui-ci effectue la vérification de redondance une seule fois et en indique l’état à l’écran (rouge ou vert).

Comme d’autres scripts et cmdlets, le script CheckDatabaseRedundancy.ps1 peut également être exécuté en mode de surveillance et générer des événements. Il suffit pour cela d’ajouter le paramètre MonitoringContext. La tâche planifiée créée par Exchange exécute le script en mode de surveillance. Ce mode permet également d’appeler le script au moyen d’une solution de contrôle, telle que Microsoft System Center Operations Manager (SCOM). En mode de surveillance, le script génère des événements d’alerte rouge et verte dans le journal des événements d’application du serveur local. Un événement d’alerte rouge (ID d’événement 4113) est généré uniquement si la base de données a été « rouge » pendant plus de 20 minutes non consécutives sur la durée d’une heure de l’exécution du script. Un événement d’alerte verte (ID d’événement 4114) est, quant à lui, généré lorsque la base de données a été « verte » pendant 10 minutes consécutives. Par défaut, une fois qu’un événement d’alerte rouge est généré, il continuera à être signalé toutes les 15 minutes.

Le script offre également des options utiles. Par exemple, vous pouvez ajouter le paramètre ShowDetailedErrors pour obtenir plus de détails sur les erreurs qui se produisent et le paramètre Verbose pour obtenir plus d’informations de dépannage. Le script comprend également le paramètre SendSummaryMailTos qui lui permet d’envoyer, à la fin de son exécution, un rapport récapitulatif par courrier électronique à une liste d’adresses de messagerie spécifiées. Les administrateurs peuvent alors consulter rapidement les rapports émis toutes les heures pour voir si des problèmes de redondance se sont produits. Si vous utilisez la fonctionnalité de messagerie, vous devrez inclure le paramètre SummaryMailFrom à chaque fois que vous utilisez le paramètre SendSummaryMailTos.

Microsoft recommande d’exécuter régulièrement ce script dans le cadre de vos activités normales de surveillance, soit au moyen d’une tâche planifiée automatisée, soit à l’aide d’un système de surveillance comme SCOM. Pour éviter que la redondance des bases de données soit incorrecte pendant de longues périodes, exécutez le script toutes les 60 minutes. Le script comprend un paramètre appelé TerminateAfterDurationSecs, qui lorsqu’il est défini sur -1 ou 0, permet d’exécuter le script pour une durée indéterminée.

Si vous n’exécutez aucune solution de surveillance telle que SCOM, nous vous recommandons de créer une tâche planifiée créé automatiquement afin d’automatiser et de planifier l’exécution du script.

Il existe des problèmes connus dans le planificateur de tâches Windows Server 2008 SP2 qui peuvent entraîner un blocage de ce dernier lorsque vous avez planifié une tâche devant s’exécuter sur une longue durée. Ces problèmes ne concernent pas Windows Server 2008 R2 ; si possible, exécutez alors le script à partir de Windows Server 2008 R2. Si vous ne pouvez pas exécuter le script à partir de Windows Server 2008 R2 et l’exécutez à partir de Windows Server 2008 SP2, deux modifications sont préconisées. D’abord, au lieu d’exécuter le script avec sa suppression temporaire intégrée de 60 minutes, exécutez-le toutes les 5 minutes avec les paramètres suivants :

CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

Ensuite, si possible, utilisez SCOM pour définir le comportement de suppression temporaire (par exemple, si 3 événements d’alerte rouge sont consignés au cours d’une période de 20 minutes, une alerte est générée, et si un événement d’alerte verte est consigné, changez l’état courant de sorte qu’il soit vert).

Si la tâche planifiée Database One Copy Alert est modifiée ou supprimée, vous pouvez tout supprimer et replanifier en exécutant la commande suivante :

schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY

Remplacez les paramètres dans le script ci-dessus par les paramètres que vous voulez utiliser. D’autres paramètres sont également décrits dans le script.

Lorsque vous créez une tâche planifiée à l’aide de l’outil de ligne de commande schtasks, l’option /TR est limitée à 261 caractères. L’exemple ci-dessus dépasse cette limite. Si les paramètres et les chemins que vous utilisez dépassent la limite de 261 caractères pour l’option /TR, vous devez manuellement créer la tâche planifiée à l’aide de l’applet Planificateur de tâches du menu Outils d’administration. Vous pouvez également copier et coller le code XML suivant dans le Bloc-notes, le modifier comme il convient, l’enregistrer dans un fichier XML et l’importer à l’aide de l’applet Planificateur de tâches.

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2010-05-11T15:55:47</Date>
    <Author>administrator</Author>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2010-05-11T15:55:00</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>SYSTEM</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
    </Exec>
  </Actions>
</Task>

Cmdlet Get-MailboxDatabaseCopyStatus

 © 2010 Microsoft Corporation. Tous droits réservés.