Gestion des copies de base de données de boîtes aux lettres

Article
04/04/2023

S’applique à : Exchange Server 2013

Une fois qu’un groupe de disponibilité de base de données (DAG) a été créé, configuré et rempli avec les membres du serveur de boîtes aux lettres, vous pouvez utiliser le Centre d’administration Exchange (EAC) ou Exchange Management Shell pour ajouter des copies de base de données de boîtes aux lettres de manière flexible et granulaire.

Gestion des copies de base de données

Après la création de plusieurs copies d’une base de données, vous pouvez utiliser le CENTRE d’administration Exchange ou l’interpréteur de commandes pour surveiller l’intégrité et l’état de chaque copie et effectuer d’autres tâches de gestion associées aux copies de base de données. Par exemple, vous pourrez être amené à interrompre ou reprendre la copie d’une base de données, amorcer la copie d’une base de données, contrôler les copies de base de données, configurer les paramètres de copie de base de données ou supprimer une copie de base de données.

Interruption et reprise des copies de base de données

Pour diverses raisons, telles que l’exécution d’une maintenance planifiée, il peut être nécessaire de suspendre et de reprendre l’activité de réplication continue pour une copie de base de données. En outre, certaines tâches d’administration, telles que l’amorçage, nécessitent d’abord l’interruption d’une copie de base de données. Nous vous recommandons de suspendre toute l’activité de réplication lorsque le chemin d’accès de la base de données ou de ses fichiers journaux est modifié. Vous pouvez suspendre et reprendre l’activité de copie de base de données à l’aide du Centre d’administration Exchange ou en exécutant les applets de commande Suspend-MailboxDatabaseCopy et Resume-MailboxDatabaseCopy dans l’interpréteur de commandes. Pour savoir en détail comment interrompre ou reprendre l'activité de réplication continue d'une copie de base de données, consultez la rubrique Interruption ou reprise d'une copie de base de données de boîtes aux lettres.

Amorçage d’une copie de base de données

L’amorçage, également appelé mise à jour, est le processus dans lequel une base de données( une base de données vide ou une copie de la base de données de production) est ajoutée à l’emplacement de copie cible sur un autre serveur de boîtes aux lettres dans le même DAG que la base de données active. Ainsi, elle devient la base de données de base pour la copie gérée par ce serveur.

Selon la situation, l’amorçage peut être un processus automatique ou manuel que vous initiez. Quand une copie de base de données est ajoutée, la copie est automatiquement amorcée si le serveur cible et son stockage sont correctement configurés. Si vous souhaitez amorcer manuellement une copie de base de données et ne souhaitez pas que l’amorçage automatique se produise lors de la création de la copie, vous pouvez utiliser le paramètre SeedingPostponed lors de l’exécution de l’applet de commande Add-MailboxDatabaseCopy .

Les copies de base de données doivent rarement être réinsérées après l’amorçage initial. Toutefois, si une nouvelle installation est nécessaire, ou si vous souhaitez amorcer manuellement une copie de base de données au lieu que le système amorce automatiquement la copie, ces tâches peuvent être effectuées à l’aide de l’Assistant Mise à jour de la copie de la base de données de boîte aux lettres dans le Centre d’administration Exchange ou à l’aide de l’applet de commande Update-MailboxDatabaseCopy dans l’interpréteur de commandes. Avant d’amorcer une copie de base de données, vous devez d’abord suspendre la copie de la base de données de boîtes aux lettres. Pour obtenir des instructions détaillées sur la façon d’amorcer une copie de base de données, consultez Mettre à jour une copie de base de données de boîtes aux lettres.

Après une opération d'amorçage manuel, la réplication de la copie de base de données de boîtes aux lettres amorcée reprend automatiquement. Si vous ne souhaitez pas que la réplication reprenne automatiquement, utilisez le paramètre ManualResume lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Choix des éléments à amorcer

Lorsque vous effectuez une opération d’amorçage, vous pouvez choisir d’amorcer la copie de la base de données de boîtes aux lettres, le catalogue d’index de contenu pour la copie de base de données de boîtes aux lettres, ou la copie de la base de données et la copie du catalogue d’index de contenu.

Par défaut, l'Assistant Mise à jour de la copie de base de données de boîtes aux lettres et la cmdlet Update-MailboxDatabaseCopy amorcent la copie de la base de données de boîtes aux lettres et la copie du catalogue d'index de contenu. Pour amorcer uniquement la copie de la base de données de boîtes aux lettres sans amorcer le catalogue d’index de contenu, utilisez le paramètre DatabaseOnly lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy . Pour amorcer le catalogue d’index de contenu uniquement, utilisez le paramètre CatalogOnly pendant l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Sélection de la source d’amorçage

Toute copie de base de données en bon état peut être utilisée comme source d’amorçage pour une copie supplémentaire de cette base de données. Cela s'avère particulièrement utile quand un groupe de disponibilité de base de données a été étendu sur plusieurs emplacements physiques. Par exemple, imaginez le déploiement d'un groupe de disponibilité de base de données de quatre membres, dont deux membres (MBX1 et MBX2) sont situés à Portland dans l'Oregon et deux membres (MBX3 et MBX4) sont situés à New York. Une base de données de boîtes aux lettres appelée DB1 est active sur MBX1 et des copies passives de DB1 se trouvent sur MBX2 et MBX3. Lorsque vous ajoutez une copie de DB1 à MBX4, vous avez la possibilité d'utiliser la copie sur MBX3 comme source pour l'amorçage. Ce faisant, vous évitez l'amorçage sur le réseau étendu (WAN) qui relie Portland à New York.

Pour utiliser une copie spécifique comme source d’amorçage lors de l’ajout d’une nouvelle copie de base de données, procédez comme suit :

Utilisez le paramètre SeedingPostponed lors de l’exécution de l’applet de commande Add-MailboxDatabaseCopy pour ajouter la copie de base de données. Si le paramètre SeedingPostponed n’est pas utilisé, la copie de base de données est explicitement amorcée à l’aide de la copie active de la base de données comme source.
Vous pouvez spécifier le serveur source que vous souhaitez utiliser dans le cadre de l’Assistant Mise à jour de la base de données de boîte aux lettres dans le CENTRE d’administration Exchange, ou vous pouvez utiliser le paramètre SourceServer lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy pour spécifier le serveur source souhaité pour l’amorçage. Dans l'exemple précédent, vous indiqueriez MBX3 comme serveur source. Si le paramètre SourceServer n’est pas utilisé, la copie de base de données est explicitement amorcée à partir de la copie active de la base de données.

Amorçage et réseaux

En plus de sélectionner un serveur source spécifique pour l’amorçage d’une copie de base de données de boîtes aux lettres, vous pouvez également utiliser l’interpréteur de commandes pour spécifier les réseaux DAG à utiliser et éventuellement remplacer les paramètres de compression et de chiffrement du réseau DAG pendant l’opération de démarrage.

Remarque

L’amorçage d’un catalogue d’index de contexte n’est possible que sur un réseau MAPI. Cela est vrai même si vous utilisez le -Network paramètre dans l’applet de commande Update-MailboxDatabaseCopy.

Pour spécifier les réseaux que vous souhaitez utiliser pour l’amorçage, utilisez le paramètre Network lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy et spécifiez les réseaux DAG que vous souhaitez utiliser. Si vous n’utilisez pas le paramètre Network , le système utilise le comportement par défaut suivant pour sélectionner un réseau à utiliser pour l’opération d’amorçage :

Si le serveur source et le serveur cible sont sur le même sous-réseau et qu'un réseau de réplication a été configuré incluant le sous-réseau, le réseau de réplication sera utilisé.
Si le serveur source et le serveur cible sont sur différents sous-réseaux, même si un réseau de réplication contenant ces sous-réseaux a été configuré, le réseau client (MAPI) sera utilisé pour l'amorçage.
Si le serveur source et le serveur cible se trouvent dans des centres de données différents, le réseau client (MAPI) sera utilisé pour l'amorçage.

Au niveau du groupe de disponibilité de base de données (DAG), les réseaux DAG sont configurés pour le chiffrement et la compression. Les paramètres par défaut sont d’utiliser le chiffrement et la compression uniquement pour les communications sur différents sous-réseaux. Si la source et la cible sont sur différents sous-réseaux et que le DAG est configuré avec les valeurs par défaut pour NetworkCompression et NetworkEncryption, vous pouvez remplacer ces valeurs en utilisant les paramètres NetworkCompressionOverride et NetworkEncryptionOverride, respectivement, pendant l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Processus d’amorçage

Lorsque vous lancez un processus d’amorçage à l’aide des applets de commande Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy , les tâches suivantes sont effectuées :

Les propriétés de base de données d’Active Directory sont lues pour valider la base de données et les serveurs spécifiés, et pour vérifier que les serveurs source et cible exécutent Exchange 2013, qu’ils sont tous les deux membres du même DAG et que la base de données spécifiée n’est pas une base de données de récupération. Les chemins d'accès aux fichiers de base de données sont également lus.
Il y a une préparation aux contrôles de réamorçage à partir du service de réplication Microsoft Exchange sur le serveur cible.
Le service de réplication Microsoft Exchange du serveur cible contrôle la présence de fichiers journaux des bases de données et des transactions dans le répertoire de fichiers lu lors des contrôles Active Directory à l'étape 1.
Le service de réplication Microsoft Exchange renvoie les informations sur l'état du serveur cible à l'interface d'administration à partir de l'emplacement d'exécution de la cmdlet.
Si tous les contrôles préliminaires ont été effectués avec succès, vous serez invité à confirmer l'opération avant de continuer. Si vous confirmez l'opération, le processus se poursuit. Si une erreur se produit lors des contrôles préliminaires, elle est signalée et l'opération échoue.
L'opération d'amorçage est lancée à partir du service de réplication Microsoft Exchange sur le serveur cible.
Le service de réplication Microsoft Exchange suspend la réplication de base de données de la copie de base de données active.
Les informations sur l'état de la base de données sont mises à jour par le service de réplication Microsoft Exchange pour rendre compte de l'état de l'amorçage.
Si le serveur cible ne contient pas déjà les répertoires pour les fichiers journaux et de base de données cibles, ils sont alors créés.
Une demande d'amorçage de la base de données est transmise du service de réplication Microsoft Exchange du serveur cible au service de réplication Microsoft Exchange du serveur source à l'aide du protocole TCP. Cette demande et les communications qui suivent pour l'amorçage de la base de données ont lieu sur un réseau DAG qui a été configuré comme réseau de réplication.
Le service de réplication Microsoft Exchange du serveur source lance une sauvegarde en continu ESE (Extensible Storage Engine) via l'interface du service de banque d'informations Microsoft Exchange.
Le service de banque d'informations Microsoft Exchange transmet les données de la base de données au service de réplication Microsoft Exchange.
Les données de la base sont transférées du service de réplication Microsoft Exchange du serveur source au service de réplication Microsoft Exchange du serveur cible.
Le service de réplication Microsoft Exchange sur le serveur cible écrit la copie de la base de données dans un répertoire temporaire situé dans le répertoire de base de données principal appelé amorçage temporaire.
L'opération de sauvegarde en continu sur le serveur source se termine à la fin de la base de données.
L'écriture sur le serveur cible se termine et la base de données est déplacée du répertoire temp-seeding à l'emplacement final. Le répertoire temp-seeding est supprimé.
Sur le serveur cible, le service de réplication Microsoft Exchange traite la demande et la communique au service de recherche Microsoft Exchange pour monter le catalogue d'index de contenu de la copie de base de données, s'il existe. S'il y a des fichiers du catalogue qui n'ont pas été mis à jour depuis la fois précédente sur la copie de base de données, l'opération de montage échoue, ce qui entraîne la nécessité de répliquer le catalogue du serveur source. De la même manière, si le catalogue n'existe pas et qu'il n'existe pas sur un nouvel exemplaire de la copie de base de données du serveur cible, il faut une copie du catalogue. Le service de réplication Microsoft Exchange dirige le service de recherche Microsoft Exchange pour qu'il interrompe l'indexation de la copie de base de données pendant qu'un nouveau catalogue est copié à partir de la source.
Le service de réplication Microsoft Exchange du serveur cible envoie alors une demande d'amorçage du catalogue au service de réplication Microsoft Exchange du serveur source.
Sur le serveur source, le service de réplication Microsoft Exchange demande les informations de répertoire du service de recherche Microsoft Exchange et demande la suspension de l'indexation.
Le service de recherche Microsoft Exchange du serveur source renvoie les informations du répertoire du catalogue de recherche au service de réplication Microsoft Exchange.
Le service de réplication Microsoft Exchange du serveur source lit les fichiers de catalogue du répertoire.
Le service de réplication Microsoft Exchange du serveur source déplace les données de catalogue vers le service de réplication Microsoft Exchange du serveur cible à l'aide d'une connexion sur le réseau de réplication. Une fois la lecture finie, le service de réplication Microsoft Exchange envoie une demande au service de recherche Microsoft Exchange pour qu'il reprenne l'indexation de la base de données source.
Si des fichiers de catalogue existent déjà sur le serveur cible du répertoire, le service de réplication Microsoft Exchange sur le serveur cible les supprime.
Le service de réplication Microsoft Exchange sur le serveur cible écrit les données du catalogue dans un répertoire temporaire appelé CiSeed.Temp jusqu’à ce que les données soient complètement transférées.
Le service de réplication Microsoft Exchange déplace les données de catalogue complètes vers l'emplacement final.
Le service de réplication Microsoft Exchange du serveur cible reprend l'indexation de recherche sur la base de données cible.
Le service de réplication Microsoft Exchange du serveur cible renvoie un état d'exécution.
Le résultat final de l'opération est transmis à l'interface d'administration à partir de laquelle la cmdlet a été exécutée.

Configuration de copies de base de données

Après la création d’une copie de base de données, vous pouvez afficher et modifier ses paramètres de configuration, si nécessaire. Vous pouvez afficher certaines informations de configuration sur la page Propriétés d'une copie de base de données dans le CAE. Vous pouvez également utiliser les applets de commande Get-MailboxDatabase et Set-MailboxDatabaseCopy dans l’interpréteur de commandes pour afficher et configurer les paramètres de copie de base de données, tels que le délai de relecture, le délai de décalage de la troncation et l’ordre des préférences d’activation. Pour savoir en détail comment afficher et configurer les paramètres de copie de base de données, consultez la rubrique Configurer les propriétés des copies de la base de données de boîtes aux lettres.

Utilisation des options de délai d’attente de relecture et de troncation

Les copies de base de données de boîtes aux lettres prennent en charge l’utilisation d’un délai d’attente de relecture et d’un délai d’attente de troncation ; les deux sont définis en minutes. Le paramétrage d’un délai d’attente de relecture vous permet de renvoyer la copie de base de données à un certain moment dans le temps. Le paramétrage d'un délai d'attente de troncation vous permet d'utiliser les fichiers journaux sur une copie passive de base de données à récupérer après la perte de fichiers journaux sur la copie active de base de données. Parce que ces deux fonctionnalités entraînent l’accumulation temporaire des fichiers journaux, leur utilisation aura des répercussions sur votre conception de stockage.

Délai d’attente de relecture

Le délai de relecture est une propriété d’une copie de base de données de boîtes aux lettres qui spécifie la durée, en minutes, pour retarder la relecture du journal pour la copie de la base de données. Le minuteur de décalage de relecture se déclenche quand un fichier journal est répliqué dans la copie passive et passe l'inspection avec succès. En retardant la relecture des journaux de la copie de base de données, vous pouvez récupérer la base de données à un certain moment dans le temps passé. Une copie de base de données de boîtes aux lettres configurée avec un décalage de relecture supérieur à 0 s’appelle une copie retardée de base de données de boîtes aux lettres ou simplement une copie retardée.

Une stratégie qui utilise des copies de base de données et les fonctionnalités de conservation pour litige dans Exchange 2013 peut fournir une protection contre toute une série de défaillances qui entraîneraient normalement une perte de données. Toutefois, ces fonctionnalités ne peuvent pas fournir de protection contre la perte de données en cas d'altération logique qui, bien que rare, peut entraîner une perte de données. Les copies retardées sont faites pour éviter la perte de données en cas d'altération logique. En règle générale, il existe deux types d'altération logique :

Corruption logique de la base de données : la somme de contrôle des pages de base de données correspond, mais les données sur les pages sont incorrectes logiquement. Cela peut arriver quand l’ESE tente d’écrire sur une page de base de données et, même si le système d’exploitation envoie un message de succès, soit les données ne sont pas écrites sur le disque soit elles sont écrites à la mauvaise place. Il s’agit d’un vidage perdu. Afin d’éviter la perte de données par les vidages perdus, l’ESE comporte un mécanisme de détection des vidages perdus dans la base de données ainsi qu’une fonctionnalité de mise à jour corrective (restauration d’une seule page).
Corruption logique du magasin : les données sont ajoutées, supprimées ou manipulées d’une manière non attendue par l’utilisateur. Ces cas sont généralement provoqués par des applications tierces. Ce n'est généralement de la corruption que dans le sens où l'utilisateur voit cela comme une altération. La banque d'informations Exchange considère la transaction qui est à l'origine de l'altération logique comme une série d'opérations MAPI valides. La fonctionnalité de conservation pour litige dans Exchange 2013 offre une protection contre la corruption logique du magasin (car elle empêche la suppression définitive du contenu par un utilisateur ou une application). Toutefois, dans certains cas, une boîte aux lettres d'utilisateur est si endommagée qu'il serait plus facile de la restaurer à un point antérieur à l'altération, et d'exporter ensuite la boîte aux lettres de l'utilisateur pour récupérer les données intactes.

La combinaison des copies de base de données, de la stratégie de rétention et de la restauration ESE des pages uniques ne laisse que les cas rares mais catastrophiques d'altération logique de banque d'informations. Votre choix d'utiliser une copie de base de données avec retard de relecture (une copie retardée) dépendra des applications tierces que vous utilisez et de l'historique de votre organisation quant à l'altération logique de banque d'informations.

Les copies différées peuvent prendre en charge elles-mêmes dans Exchange 2013 lorsque vous appelez la relecture automatique des journaux pour lire les fichiers journaux dans certains scénarios :

Lorsque le seuil d'espace disque faible est atteint
Lorsque la copie retardée est physiquement endommagée et doit faire l'objet d'une mise à jour corrective de pages
Quand il y a moins de trois copies intègres disponibles (actives ou passives uniquement, les copies de base de données retardées ne sont pas comptées) pendant plus de 24 heures

La mise à jour corrective des pages est disponible pour les copies à retardement via cette fonctionnalité de lecture automatique. Si le système détecte qu'une mise à jour corrective de page est nécessaire pour une copie retardée, les journaux sont automatiquement relus dans la copie retardée pour exécuter la mise à jour corrective de page. Les copies retardées appellent également cette fonction de relecture automatique lorsque le seuil d'espace disque faible est atteint et lorsque la copie retardée a été détectée comme étant la seule copie disponible pendant une période spécifique.

Le comportement de lecture de copie retardée est désactivé par défaut, mais peut être activé en exécutant la commande suivante :

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

Une fois activée, la lecture a lieu lorsque le nombre de copies est inférieur à trois. Vous pouvez modifier la valeur 3 par défaut en changeant la valeur de registre DWORD suivante :

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

Pour activer la lecture pour les seuils d'espace disque faible, vous devez configurer l'entrée de registre suivante :

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

Après avoir configuré un de ces paramètres de registre, redémarrez le service de gestion des groupes de disponibilité de base de données (DAG) Microsoft Exchange pour que les modifications prennent effet.

Prenons l’exemple d’un environnement où une base de données donnée a 4 copies (3 copies hautement disponibles et une copie à 1 décalage) et où le paramètre par défaut est utilisé pour ReplayLagManagerNumAvailableCopies. Si une copie non retardée est hors de service pour une raison quelconque (elle est par exemple suspendue, etc.), la copie retardée lira automatiquement ses fichiers journaux dans les 24 heures.

Si vous choisissez d’utiliser des copies avec décalage sans activer le ReplayLagManagerEnabled paramètre, tenez compte des implications suivantes :

Le délai d'attente de relecture est une valeur configurée par l'administrateur qui est désactivée par défaut.
Par défaut, le paramètre de délai d'attente de relecture est défini sur 0 jour et le paramètre maximal sur 14 jours.
Les copies retardées ne sont pas considérées comme des copies hautement disponibles. Elles sont plutôt prévues à des fins de récupération d'urgence pour éviter l'altération logique de la banque d'informations.
Plus le délai d'attente de relecture est important, plus le processus de récupération de base de données est long. Selon le nombre de fichiers journaux qui doivent être relus pendant la récupération, et selon la vitesse à laquelle votre matériel peut les relire, le processus peut mettre plusieurs heures à récupérer une base de données.
Nous vous recommandons de déterminer si les copies retardées sont essentielles à votre stratégie générale de récupération d'urgence. Si elles sont essentielles à votre stratégie, nous vous recommandons d'utiliser plusieurs copies retardées ou un RAID (Redundant array of independant disks) pour protéger une seule copie retardée, si vous n'avez pas plusieurs copies retardées. Si vous perdez un disque ou si une altération se produit, vous ne perdez pas votre moment retardé dans le temps.
Les copies en retard ne peuvent pas être corrigées avec la fonctionnalité de restauration d’une page unique ESE. Si une copie en retard rencontre une altération de la page de base de données (par exemple, une erreur -1018), elle doit être réinsérée (ce qui perdra l’aspect décalage de la copie).

L’activation et la récupération d’une copie de base de données de boîte aux lettres différée sont un processus simple si vous souhaitez que la base de données relit tous les fichiers journaux et que la copie de la base de données soit à jour. Si vous souhaitez relire les fichiers journaux jusqu’à un point spécifique dans le temps, il s’agit d’une opération plus difficile, car vous manipulez manuellement les fichiers journaux et exécutez Exchange Server utilitaires de base de données (Eseutil.exe).

Pour obtenir des instructions détaillées sur l’activation d’une copie de base de données de boîtes aux lettres avec décalage, consultez Activer une copie de base de données de boîtes aux lettres avec décalage.

Délai d’attente de troncation

Temps de décalage de troncation est une propriété d’une copie de base de données de boîtes aux lettres qui spécifie la durée, en minutes, pour retarder la suppression du journal pour la copie de la base de données une fois que le fichier journal a été relu dans la copie de base de données. Le minuteur de décalage de troncation se déclenche quand un fichier journal est répliqué dans la copie passive, a passé l'inspection avec succès et a été relu avec succès dans la copie de la base de données. En retardant la troncation des fichiers journaux de la copie de base de données, vous pouvez effectuer des récupérations à la suite des échecs ayant affecté les fichiers journaux de la copie active de la base de données.

Copies de la base de données et troncation de journaux

La troncation du journal fonctionne de la même façon dans Exchange 2013 que dans Exchange 2010. Le comportement de troncation est déterminé par les paramètres de délai d'attente de relecture et de délai d'attente de troncation de la copie.

Les critères suivants doivent être remplis pour que le fichier journal d'une copie de base de données soit tronqué lorsque les paramètres sont laissés par défaut sur 0 (désactivé) :

Le fichier journal doit avoir été sauvegardé ou la journalisation circulaire doit être activée.
Le fichier journal doit être en-dessous du point de contrôle (fichier journal minimum nécessaire pour la récupération) de la base de données.
Toutes les autres copies retardées doivent avoir inspecté le fichier journal.
Toutes les autres copies (et non les copies différées) doivent avoir relu le fichier journal.

Pour la troncation d'une copie retardée de base de données, les critères suivants doivent être remplis :

Le fichier journal doit être inférieur au point de contrôle de la base de données.
Le fichier journal doit être plus ancien que ReplayLagTime + TruncationLagTime.
Le fichier journal doit avoir été tronqué sur la copie active.

Dans Exchange 2013, la troncation du journal ne se produit pas sur une copie de base de données de boîtes aux lettres active lorsqu’une ou plusieurs copies passives sont suspendues. Si des activités de maintenance planifiées doivent être effectuées sur une période prolongée (par exemple, plusieurs jours), la création de fichiers journaux risque d'être considérable. Pour éviter de remplir le lecteur avec des journaux de transactions, vous pouvez supprimer la copie de base de données passive concernée au lieu de l'interrompre. Une fois la maintenance planifiée terminée, vous pouvez rajouter la copie de base de données passive.

Exchange 2013 Service Pack 1 (SP1) introduit une nouvelle fonctionnalité appelée troncation libre, qui est désactivée par défaut. En temps normal, chaque copie de base de données conserve les journaux devant être envoyés vers d'autres copies de base de données jusqu'à ce que toutes les copies d'une base de données confirment qu'elles ont relu (copies passives) et reçu (copies retardées) les fichiers journaux. Il s'agit du comportement de troncation de journal par défaut. Si une copie de base de données est hors ligne pour une raison quelconque, les fichiers journaux s'accumulent sur les disques utilisés par les autres copies de la base de données. Si la copie de base de données concernée reste déconnectée pendant une période prolongée, les autres copies de base de données risquent d'arriver à court d'espace disque.

Lorsque la troncation libre est activée, le comportement de troncation est différent. Chaque copie de base de données suit la disponibilité de son propre espace disque et applique le comportement de troncation souple si l'espace disponible devient faible. Pour la copie active, la copie de base de données passive la plus en retard dans la relecture du journal est ignorée et la troncation respecte les copies passives restantes les plus anciennes. La troncation globale est calculée dans la copie de base de données active. Les copies passives tenteront de respecter la décision de troncation prise sur la copie active. Malgré l’implication du nom MinCopiesToProtect, Exchange ignore uniquement le plus ancien straggler connu au moment de l’exécution de la troncation. Pour une copie passive, si l’espace est faible, elle tronque indépendamment ses fichiers journaux à l’aide des paramètres configurés décrits ci-dessous.

Les fichiers journaux ayant été supprimés des autres copies saines seront manquants sur la base de données déconnectée lorsque celle-ci sera remise en ligne, et son statut sera FailedAndSuspended. Dans ce cas, si Autoreseed est configuré, la copie concernée sera réamorcée automatiquement. Si Autoreseed n'est pas activé, la copie de base de données devra être amorcée manuellement par un administrateur.

Le nombre requis de copies saines, le seuil d'espace disque libre et le nombre de journaux à conserver sont tous des paramètres configurables. Par défaut, le seuil d'espace disque disponible est de 204 800 Mo (200 Go) et le nombre de journaux à conserver est de 100 000 (100 Go) pour les copies passives et de 10 000 (10 Go) pour les copies actives.

Pour activer la troncation souple et en configurer les paramètres, vous devez modifier le Registre Windows sur chaque membre du DAG. Il existe trois valeurs de Registre qui peuvent être configurées, qui sont toutes stockées sous HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. La clé BackupInformation et les valeurs DWORD suivantes n'existent pas par défaut et doivent être créées manuellement. Les valeurs du registre DWORD sous BackupInformation sont décrites dans le tableau suivant :

Valeur de Registre	Description	Valeur par défaut
LooseTruncation_MinCopiesToProtect	Cette clé permet d'activer la troncation souple. Elle représente le nombre de copies passives à protéger de la troncation souple sur la copie active d'une base de données. Si la valeur de cette clé est définie sur 0, la troncation souple est désactivée.	0
LooseTruncation_MinDiskFreeSpaceThresholdInMB	Seuil d'espace disque disponible (en Mo) pour le déclenchement de la troncation souple. Si l'espace disque disponible descend en dessous de cette valeur, la troncation souple est déclenchée.	Si cette valeur de registre n'est pas configurée, la valeur par défaut utilisée par la troncation souple est 200 Go.
LooseTruncation_MinLogsToProtect	Nombre minimal de fichiers journaux à conserver sur les copies saines dont les journaux sont tronqués. Si cette valeur de registre est configurée, la valeur configurée s'applique alors aux copies actives et passives.	Si cette valeur de registre n'est pas configurée, les valeurs par défaut 100 000 pour les copies de base de données passives et 10 000 pour les copies de base de données actives sont utilisées.

Lorsque vous utilisez la valeur de LooseTruncation_MinLogsToProtect Registre, notez que le comportement est différent pour les copies de base de données actives et passives. Sur la copie de base de données active, il s’agit du nombre de journaux supplémentaires conservés avant ceux requis par les copies passives protégées et la plage requise de la copie active. Sur une copie de base de données passive, il s’agit du nombre de journaux conservés à partir du dernier journal disponible. Un dixième de ce nombre est également utilisé pour gérer les journaux avant la plage requise de cette copie passive. Les deux limites sont en place pour garantir que les copies de base de données retardées ne prennent pas trop d’espace, car leur plage requise est généralement très grande.

Stratégie d’activation de la base de données

Les stratégies d’activation de la base de données sont des scénarios dans lesquels vous voulez créer une copie de base de données de boîtes aux lettres et éviter que le système active automatiquement cette copie en cas de panne, par exemple :

Si vous déployez une ou plusieurs copies de base de données de boîtes aux lettres dans un centre de données de remplacement ou de veille.
Si vous configurez une copie retardée de base de données à des fins de récupération.
Si vous effectuez la maintenance ou la mise à niveau d'un serveur.

Dans chacun des scénarios évoqués ci-dessus, vous avez des copies de base de données que vous ne voulez pas voir activées automatiquement par le système. Si vous voulez éviter que le système active automatiquement une copie de base de données de boîtes aux lettres, vous pouvez configurer la copie pour qu'elle soit bloquée (suspendue) à l'activation. Cela permet au système de maintenir l'actualité de la base de données par l'envoi de fichiers journaux et la relecture, mais l'empêche d'activer et d'utiliser automatiquement la copie. Les copies bloquées pour l'activation doivent être activées manuellement par un administrateur. Vous pouvez configurer la stratégie d’activation de base de données pour un serveur entier à l’aide de l’applet de commande Set-MailboxServer ou d’une copie de base de données individuelle à l’aide de l’applet de commande Set-MailboxDatabaseCopyCopy pour définir le paramètre DatabaseCopyAutoActivationPolicy sur Bloqué.

Pour plus d'informations sur la configuration des stratégies d'activation de la base de données, consultez la rubrique Configurer la stratégie d'activation pour une copie de base de données de boîte aux lettres.

Impact des déplacements de boîtes aux lettres sur la réplication continue

Sur une base de données de boîtes aux lettres très occupée avec une fréquence élevée de génération des journaux, vous risquez davantage de perdre des données si la réplication sur les copies passives de base de données ne parvient pas à suivre la génération des journaux. Un déplacement de boîtes aux lettres peut provoquer une fréquence élevée de génération de journaux. Exchange 2013 inclut une API de garantie des données utilisée par des services tels que le service de réplication de boîtes aux lettres Microsoft Exchange (MRS) pour vérifier l’intégrité de l’architecture de copie de base de données en fonction de la valeur du paramètre DataMoveReplicationConstraint défini par le système ou un administrateur. Plus précisément, l'API de garantie des données peut servir à :

Vérifier l’intégrité de la réplication : confirme que le nombre de copies de base de données requis est disponible.
Vérifier le vidage de la réplication : confirme que les fichiers journaux requis ont été relus par rapport au nombre de copies de base de données requis.

Lorsqu'elle est exécutée, l'API retourne les informations d'état suivantes à l'application appelante :

Nouvelle tentative : signifie qu’il existe des erreurs temporaires qui empêchent la vérification d’une condition par rapport à la base de données.
Satisfait : signifie que la base de données remplit les conditions requises ou que la base de données n’est pas répliquée.
Non satisfait : signifie que la base de données ne remplit pas les conditions requises. De plus, des informations sont fournies à l'application appelante sur le motif du retour de la réponse NotSatisfied.

La valeur du paramètre DataMoveReplicationConstraint pour la base de données de boîtes aux lettres détermine le nombre de copies de base de données à évaluer dans le cadre de la requête. Le paramètre DataMoveReplicationConstraint a les valeurs possibles suivantes :

None: lorsque vous créez une base de données de boîtes aux lettres, cette valeur est définie par défaut. Lorsque cette valeur est définie, les conditions de l'API de garantie des données sont ignorées. Ce paramètre doit être utilisé uniquement pour les bases de données de boîtes aux lettres qui ne sont pas répliquées.
SecondCopy: il s’agit de la valeur par défaut lorsque vous ajoutez la deuxième copie d’une base de données de boîtes aux lettres. Lorsque cette valeur est définie, au moins une copie passive de base de données doit respecter les conditions de l'API de garantie des données.
SecondDatacenter: lorsque cette valeur est définie, au moins une copie de base de données passive dans un autre site Active Directory doit répondre aux conditions de l’API De garantie des données.
AllDatacenters: lorsque cette valeur est définie, au moins une copie de base de données passive dans chaque site Active Directory doit répondre aux conditions de l’API De garantie des données.
AllCopies: lorsque cette valeur est définie, toutes les copies de la base de données de boîtes aux lettres doivent répondre aux conditions de l’API De garantie des données.

Vérifier l’intégrité de la réplication

Lorsque l’API de garantie des données est exécutée pour évaluer l’intégrité de l’infrastructure de la copie de base de données, plusieurs éléments sont évalués.

Si le paramètre DataMoveReplicationConstraint est défini sur...	Ensuite, pour une base de données donnée...	Conditions
`SecondCopy`	Au moins une copie passive de base de données pour une base de données répliquée doit respecter les conditions dans la colonne suivante.	La copie passive de base de données doit : Être intègre. Avoir une file d'attente de relecture comprise dans les 10 minutes du délai d'attente de relecture. Avoir une longueur de file d'attente de copie inférieure à 10 journaux. Avoir une longueur moyenne de file d'attente de copie inférieure à 10 journaux. La longueur moyenne de file d'attente de copie est calculée en fonction du nombre de fois où l'application a demandé l'état de la base de données.
`SecondDatacenter`	Au moins une copie passive de base de données d'un autre site Active Directory doit respecter les conditions énoncées dans la colonne suivante.
`AllDatacenters`	La copie active doit être montée, et une copie passive de chaque site Active Directory doit respecter les conditions énoncées dans la colonne suivante.
`AllCopies`	La copie active doit être montée, et toutes les copies passives de base de données doivent respecter les conditions dans la colonne suivante.

Vérifier le vidage de réplication

L’API de garantie des données permet également de valider qu’un nombre préalablement requis de copies de base de données ont relu les journaux des transactions requis. Ceci est vérifié en comparant l'horodatage du dernier journal relu à celui de validation du service d'appel (dans la plupart des cas, c'est l'horodatage du dernier fichier journal qui contient les données requises) plus cinq secondes supplémentaires (pour tenir compte des variations ou des décalages de l'horloge système). Si l’horodatage de relecture est supérieur à l’horodatage de validation, le paramètre DataMoveReplicationConstraint est satisfait. Si l’horodatage de relecture est inférieur à l’horodatage de validation, dataMoveReplicationConstraint n’est pas satisfait.

Avant de déplacer un grand nombre de boîtes aux lettres vers ou à partir de bases de données de réplication au sein d’un DAG, nous vous recommandons de configurer le paramètre DataMoveReplicationConstraint sur chaque base de données de boîtes aux lettres en fonction des éléments suivants :

Si vous déployez...	Définissez DataMoveReplicationConstraint sur...
Des bases de données de boîtes aux lettres qui ne possèdent aucune copie de base de données	`None`
Un DAG au sein d'un seul site Active Directory	`SecondCopy`
Un DAG dans plusieurs centres de données à l'aide d'un site Active Directory étiré	`SecondCopy`
Un DAG qui s’étend sur deux sites Active Directory, et vous aurez des copies de base de données hautement disponibles dans chaque site	`SecondDatacenter`
Un DAG qui s'étend sur deux sites Active Directory et que vous avez seulement des copies de base de données retardées sur le second site	`SecondCopy` En effet, l'API de garantie des données ne garantira pas des données en cours de validation avant la relecture du fichier journal dans la copie de base de données et, en raison de la nature de la copie de base de données étant retardée, cette contrainte va faire échouer la demande de déplacement, à moins que la valeur de ReplayLagTime de la copie de base de données retardée soit inférieure à 30 minutes.
Un DAG qui s'étend sur trois sites Active Directory ou plus, et que chaque site contient des copies de base de données à haute disponibilité	`AllDatacenters`

Équilibrage des copies de base de données

De par la nature inhérente des groupes de disponibilité de base de données, lorsqu’un basculement ou une permutation de base de données se produit, les copies de base de données de boîtes aux lettres actives changent d’hôte plusieurs fois tout au long du cycle de vie d’un groupe de disponibilité de base de données. Par conséquent, les groupes de disponibilité de base de données se trouvent en déséquilibre au niveau de la distribution des copies de base de données de boîtes aux lettres actives. Le tableau suivant illustre un exemple de groupe de disponibilité de base de données comportant quatre bases de données et quatre copies de chacune (pour un total de 16 bases de données sur chaque serveur) avec une distribution inéquitable des copies de base de données actives.

Groupe de disponibilité de base de données avec une distribution inéquitable des copies actives

Serveur	Nombre de bases de données actives	Nombre de bases de données passives	Nombre de bases de données montées	Liste de décompte des préférences
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
Ex3	12	4	12	13, 2, 1, 0
EX4	1	15	1	1, 1, 5, 9

Dans l'exemple précédent, on dénombre quatre copies de chaque base de données et donc, seulement quatre valeurs possibles pour la préférence d'activation (1, 2, 3 ou 4). La colonne Liste de décompte des préférences indique le nombre de bases de données avec chacune de ces valeurs. Par exemple, sur EX3, il existe 13 copies de base de données avec la préférence d'activation 1, deux copies avec la préférence d'activation 2, une copie avec la préférence d'activation 3 et aucune copie avec la préférence d'activation 4.

Comme vous pouvez le voir, ce groupe de disponibilité de base de données n'est pas équilibré en termes de nombre de bases de données actives hébergées par chaque membre du groupe, de nombre de bases de données passives hébergées par chaque membre du groupe ou de décompte de préférences d'activation des bases de données hébergées.

Vous pouvez utiliser le script RedistributeActiveDatabases.ps1 pour équilibrer les copies de base de données de boîtes aux lettres actives sur un DAG. Ce script déplace les bases de données d'une copie vers une autre afin d'essayer d'obtenir un nombre équitable de bases de données montées sur chaque serveur dans le groupe de disponibilité de base de données. Si nécessaire, le script essaie également d'équilibrer les bases de données actives dans les sites.

Le script inclut deux options permettant d'équilibrer les copies de base de données actives dans un groupe de disponibilité de base de données :

BalanceDbsByActivationPreference : lorsque cette option est spécifiée, le script tente de déplacer les bases de données vers leur copie préférée (en fonction de la préférence d’activation) sans tenir compte du site Active Directory.
BalanceDbsBySiteAndActivationPreference : lorsque cette option est spécifiée, le script tente de déplacer les bases de données actives vers leur copie préférée, tout en essayant d’équilibrer les bases de données actives au sein de chaque site Active Directory.

Après avoir exécuté le script avec la première option, le groupe de disponibilité déséquilibré précédent est rééquilibré, comme l’illustre le tableau suivant.

Groupe de disponibilité de base de données avec une distribution équitable des copies actives

Serveur	Nombre de bases de données actives	Nombre de bases de données passives	Nombre de bases de données montées	Liste de décompte des préférences
EX1	4	12	4	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
Ex3	4	12	4	4, 4, 4, 4
EX4	4	12	4	4, 4, 4, 4

Comme indiqué dans le tableau précédent, ce groupe de disponibilité de base de données est à présent équilibré en termes de nombre de bases de données actives et passives sur chaque serveur et de préférence d'activation sur les serveurs.

Le tableau suivant répertorie les paramètres disponibles pour le script RedistributeActiveDatabases.ps1.

Paramètres du script RedistributeActiveDatabases.ps1

Paramètre	Description
DagName	Indique le nom du groupe de disponibilité de base de données que vous souhaitez rééquilibrer. Si ce paramètre est omis, le groupe de disponibilité de base de données dont fait partie le serveur local est utilisé.
BalanceDbsByActivationPreference	Indique que le script doit déplacer les bases de données vers leur copie préférée, indépendamment du site Active Directory.
BalanceDbsBySiteAndActivationPreference	Indique que le script doit essayer de déplacer les bases de données actives vers leur copie préférée, tout en essayant d'équilibrer les bases de données actives dans chaque site Active Directory.
ShowFinalDatabaseDistribution	Indique qu'un rapport de distribution des bases de données actuelles doit s'afficher une fois la redistribution terminée.
AllowedDeviationFromMeanPercentage	Spécifie l'écart autorisé des bases de données actives dans les sites, exprimé en pourcentage. La valeur par défaut est de 20 %. Par exemple, si 99 bases de données ont été distribuées entre trois sites, la distribution idéale serait de 33 bases de données dans chaque site. Si l'écart autorisé est de 20 %, le script tente d'équilibrer les bases de données afin que chaque site ne contienne pas plus de 10 % par rapport à ce nombre. 10 % de 33 équivaut à 3,3, chiffre arrondi à 4. Par conséquent, le script essaie d'avoir entre 29 et 37 bases de données dans chaque site.
ShowDatabaseCurrentActives	Indique que le script doit créer, pour chaque base de données, un rapport indiquant la manière dont celle-ci a été déplacée et si elle est maintenant active sur sa copie préférée.
ShowDatabaseDistributionByServer	Indique que le script doit générer un rapport décrivant la distribution des bases de données pour chaque serveur.
RunOnlyOnPAM	Indique que le script s'exécute uniquement sur le membre du groupe de disponibilité de base de données exerçant actuellement le rôle de gestionnaire Active Manager principal (PAM). Le script vérifie qu'il est exécuté à partir du gestionnaire Active Manager principal. Si tel n'est pas le cas, le script prend fin.
LogEvents	Indique que le script consigne un événement (événement 4115 MsExchangeRepl) contenant un résumé des actions.
IncludeNonReplicatedDatabases	Indique que le script doit inclure les bases de données non répliquées (bases de données sans copies) lors de la détermination du mode de redistribution des bases de données actives. Même si les bases de données non répliquées ne peuvent pas être déplacées, elles peuvent influencer la distribution des bases de données répliquées.
Confirm	Le commutateur Confirm peut être utilisé pour supprimer la boîte de dialogue de confirmation qui s'affiche par défaut lorsque ce script est exécuté. Pour supprimer la boîte de dialogue de confirmation, utilisez la syntaxe de -Confirm:$False. Vous devez inclure un signe deux-points ( : ) dans la syntaxe.

Exemples de script RedistributeActiveDatabases.ps1

Cet exemple illustre la distribution des bases de données actuelles pour un groupe de disponibilité de base de données, notamment la liste de décompte des préférences.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

Cet exemple illustre la redistribution et l'équilibrage des copies de base de données de boîtes aux lettres actives dans un groupe de disponibilité de base de données utilisant la préférence d'activation sans intervention de l'utilisateur.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

Cet exemple illustre la redistribution et l’équilibrage des copies de base de données de boîtes aux lettres actives dans un groupe de disponibilité de base de données utilisant la préférence d’activation, ainsi que la création d’un récapitulatif de la distribution.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Surveillance des copies de base de données

Une copie de base de données est votre premier recours en cas de panne touchant la copie active de la base de données. Il est donc essentiel de surveiller l’intégrité et l’état des copies de base de données pour vous assurer qu’elles seront disponibles si nécessaire. En examinant les détails d'une copie de base de données dans le CAE, vous pouvez consulter une variété d'informations, dont la longueur de la file d'attente de copie, la longueur de la file d'attente de relecture et des informations sur l'état de la copie et de l'index de contenu. Vous pouvez également utiliser l’applet de commande Get-MailboxDatabaseCopyStatus dans l’interpréteur de commandes pour afficher diverses informations d’état pour une copie de base de données.

Pour plus d'informations sur la surveillance des copies de base de données, consultez la rubrique Surveillance des groupes de disponibilité des bases de données.

Suppression d’une copie de base de données

Une copie de base de données peut être supprimée à tout moment à l’aide du CENTRE d’administration Exchange ou de l’applet de commande Remove-MailboxDatabaseCopy dans l’interpréteur de commandes. Après suppression d'une copie de base de données, vous devez manuellement supprimer tout fichier journal de transaction et de base de données du serveur sur lequel la copie de base de données est en cours de suppression. Pour savoir en détail comment supprimer une copie de base de données, consultez la rubrique Supprimer une copie de base de données de boîtes aux lettres.

Permutation de base de données

Le serveur de boîtes aux lettres qui héberge la copie active de la base de données est le maître de la base de données de boîtes aux lettres. Le processus d'activation d'une copie de base de données active modifie le maître de la base de données de boîtes aux lettres et convertit la copie passive en nouvelle copie active. Ce processus est appelé basculement de base de données. Dans un basculement de base de données, la copie active de la base de données est démontée d'un serveur de boîtes aux lettres et une copie passive de cette base est montée en tant que nouvelle base de données de boîtes aux lettres active sur un autre serveur de boîtes aux lettres. Lorsque vous effectuez un basculement, vous pouvez éventuellement remplacer les paramètres de numérotation de montage de la base de données sur le nouveau maître de la base de données de boîtes aux lettres.

Vous pouvez rapidement identifier le serveur de boîtes aux lettres qui est actuellement le maître de la base de données de boîtes aux lettres en examinant la colonne de droite sous l'onglet Copies de base de données dans le CAE. Vous pouvez effectuer un basculement à l’aide du lien Activer dans le CENTRE d’administration Exchange ou à l’aide de l’applet de commande Move-ActiveMailboxDatabase dans l’interpréteur de commandes.

Plusieurs vérifications internes sont effectuées avant l’activation d’une copie passive :

L'état de la copie de base de données est contrôlé. Si la copie de base de données est en état d'échec, le basculement est bloqué. Vous pouvez remplacer ce comportement et contourner le contrôle d’intégrité à l’aide du paramètre SkipHealthChecks de l’applet de commande Move-ActiveMailboxDatabase . Ce paramètre vous permet de déplacer la copie active vers une copie de base de données en état d’échec.
La copie de base de données active est vérifiée pour voir si elle est actuellement une source d'amorçage pour toute copie de base de données passive. Si la copie active est actuellement utilisée comme source d'amorçage, le basculement est bloqué. Vous pouvez remplacer ce comportement et contourner la vérification de la source d’amorçage à l’aide du paramètre SkipActiveCopyChecks de l’applet de commande Move-ActiveMailboxDatabase . Ce paramètre vous permet de déplacer une copie active qui est utilisée comme source d'amorçage. L'utilisation de ce paramètre entraîne l'annulation de l'opération d'amorçage qui est alors considérée défectueuse.
Les longueurs de la file d'attente de copie et de relecture de la copie de base de données sont contrôlées afin de veiller à ce que les valeurs correspondent aux critères configurés. De même, la copie de base de données est vérifiée pour s'assurer qu'elle n'est pas utilisée actuellement comme source d'amorçage. Si les valeurs des longueurs de file d'attente ne font pas partie des critères configurés ou si la base de données est actuellement utilisée comme source d'amorçage, le basculement est bloqué. Vous pouvez remplacer ce comportement et contourner ces vérifications à l’aide du paramètre SkipLagChecks de l’applet de commande Move-ActiveMailboxDatabase . Ce paramètre permet d'activer une copie disposant de files d'attente de relecture et de copie en dehors des critères configurés.
L'état du catalogue de recherche (index du contenu) de la copie de base de données est contrôlé. Si le catalogue de recherche n'est pas à jour, n'est pas en bon état ou est endommagé, le basculement est bloqué. Vous pouvez remplacer ce comportement et contourner la vérification du catalogue de recherche à l’aide du paramètre SkipClientExperienceChecks de l’applet de commande Move-ActiveMailboxDatabase . Grâce à ce paramètre, la recherche n'effectue pas le contrôle d'état du catalogue. Si le catalogue de recherche de la copie de base de données que vous activez n'est pas en bon état ou est inexploitable et que vous utilisez ce paramètre pour passer le contrôle d'état du catalogue et activer la copie de base de données, il vous faudra à nouveau analyser ou amorcer le catalogue de recherche.

Lorsque vous effectuez un basculement de base de données, vous avez également la possibilité de remplacer les paramètres de numérotation de montage configurés pour le serveur qui héberge la copie de base de données passive en cours d’activation. L’utilisation du paramètre MountDialOverride de l’applet de commande Move-ActiveMailboxDatabase indique au serveur cible de remplacer ses propres paramètres de numérotation de montage et d’utiliser ceux spécifiés par le paramètre MountDialOverride .

Pour obtenir la procédure détaillée de basculement d'une copie de base de données, consultez la rubrique Activer une copie de la base de données de boîtes aux lettres.