Communications

Réplication continue de secours (SCR) dans Exchange Server 2007 Service Pack 1

Scott Schnoll

Vue d'ensemble:

• Configuration de la réplication continue de secours
• Importance de la redondance
• Réduction des interruptions de service par SCR

Service Pack 1 contient de nouvelles fonctionnalités et améliorations pour Exchange 2007. Une de ces nouvelles fonctionnalités, la réplication continue de secours (SCR), est conçue pour offrir aux organisations la redondance intégrée au centre de données et la résilience de site. Comme son nom l'indique, la SCR est conçue

pour des scénarios qui utilisent ou permettent l'utilisation de serveurs de récupération de secours.

Si vous connaissez la version RTM (release to manufacturing) d'Exchange 2007, vous savez qu'elle offre la redondance intégrée au centre de données via ses fonctionnalités d'envoi de journaux et sa prise en charge des clusters de basculement Windows®. Dans la version RTM, la copie des journaux de transactions (connu officiellement sous le nom de réplication continue) est disponible sous deux formes : la réplication locale continue (LCR), comme illustré à la Figure 1 et la réplication continue en cluster (CCR), comme illustré à la Figure 2.

Figure 1** Réplication locale continue **

Figure 2** La CCR envoie les journaux vers un deuxième serveur dans un cluster de basculement Windows **

La réplication continue assure la disponibilité et la redondance des données en permettant aux administrateurs de mettre en service et de maintenir en ligne une deuxième copie de chaque base de données de boîtes aux lettres. Cette copie de la base de données représente une première ligne de défense contre les défaillances, les pertes ou la corruption d'une base de données de production. Au lieu de perdre votre temps à essayer de rechercher une bande de sauvegarde pour restaurer les données, une copie de la base de données peut être activée et transformée en base de données de production en quelques minutes.

SCR étend les scénarios dans lesquels vous pouvez obtenir une disponibilité des services et des données optimale pour votre organisation. Les nouveaux scénarios vous permettent de séparer les topologies haute disponibilité des topologies de résilience de site et vous permettent également de déployer des configurations adaptées aux besoins spécifiques de votre organisation pour chaque zone.

La version RTM d'Exchange 2007 offre la redondance intégrée au centre de données et la résilience de site, mais dans la mesure où la LCR et la CCR ne fournissent qu'une copie supplémentaire de chaque base de données, vous devez choisir entre la résilience et la redondance. Par exemple, considérons les fonctionnalités de disponibilité des services et des données offertes par la CCR. Le déploiement des nœuds actifs et passifs dans un centre de données unique fournit des services intégrés dans le centre de données et la disponibilité des données mais pas la résilience de site (puisque les deux nœuds se trouvent dans le même site physique). Le déploiement du nœud actif dans un centre de données et le nœud passif dans un deuxième centre de données vous offre la résilience de site, mais pas la disponibilité intégrée au centre de données (puisque le nœud passif, qui offre ces fonctionnalités, se trouve dans un deuxième centre de données).

Avec la SCR de Service Pack 1, la possibilité de créer des copies supplémentaires de chaque base de données signifie que la haute disponibilité et la résilience de site ne s'excluent pas mutuellement ; vous pouvez obtenir les deux. Vous pouvez par exemple associer la SCR à la CCR pour répliquer des groupes de stockage localement dans un centre de données principal (en utilisant la CCR pour la haute disponibilité) et à distance dans un centre de données secondaire ou de sauvegarde (en utilisant la SCR pour la résilience de site), comme illustré à la figure 3. Le deuxième centre de données contient un cluster autonome qui peut être activé et rapidement doté d'un serveur de boîtes aux lettres en cluster de remplacement dans un scénario de récupération de site.

Figure 3** CCR déployée dans le centre de données Redmond et SCR déployée dans le centre de données Quincy **(Cliquer sur l'image pour l'agrandir)

La figure 3 illustre un déploiement d'entreprise avec deux centres de données, chacun avec son propre site Active Directory® : Redmond et Quincy. Le site Redmond se trouve dans le centre de données principal (production) et le site Quincy se trouve dans le centre de données secondaire (sauvegarde). La CCR est déployée à Redmond pour obtenir la redondance intégrée au centre de données. Avec les éléments d'infrastructure nécessaires pour Exchange 2007, les cibles SCR sont configurées sur un cluster autonome à Quincy pour obtenir la résilience de site. Ces éléments d'infrastructure supplémentaires, incluant les serveurs d'accès au client et de transport Hub, Active Directory et les serveurs DNS ainsi que l'accès à Internet, peuvent être des ressources dédiées ou non. Les ressources dédiées sont les ressources destinées à prendre en charge uniquement les utilisateurs du centre de données dans lequel elles résident. Les ressources non dédiées sont celles qui prennent en charge les utilisateurs du centre de données local ainsi que les utilisateurs d'autres emplacements. Vous devez décider si les ressources seront dédiées ou non, en fonction de ce qui est le plus avantageux pour votre organisation. Pour plus d'informations sur les ressources dédiées et non dédiées, consultez la rubrique « Site Resilience Configurations » du fichier d'aide d'Exchange Server 2007 à l'adresse technet.microsoft.com/bb201662.aspx. Notez également l'utilisation d'un nouveau type de quorum de jeu de nœud majoritaire. Dans Exchange Server 2007, la CCR utilise le quorum de jeu de nœud majoritaire avec témoin de partage de fichiers au lieu du nœud d'inscription traditionnel, comme vous pouvez le voir à la figure 3.

A la figure 4, un environnement CCR et SCR conçu avec la résilience à l'esprit offre plusieurs couches de redondance pour les boîtes aux lettres et les services hébergés sur le serveur EXCLUS1, protégeant ainsi les boîtes aux lettres contre les défaillances, petites, grandes voire irrémédiables.

Figure 4** Serveurs de boîtes aux lettres autonomes utilisant la SCR pour répliquer des groupes de stockage les uns sur les autres **(Cliquer sur l'image pour l'agrandir)

Les petites et moyennes entreprises peuvent également tirer parti de la SCR. Une organisation peut par exemple déployer deux serveurs de boîtes aux lettres autonomes (EXMBX1 et EXMBX2) et utiliser la SCR pour répliquer certains ou tous les groupes de stockage d'un serveur de boîtes aux lettres vers un autre, comme illustré à la figure 4.

Dans cet exemple, EXMBX1 et EXMBX2 sont des serveurs de production avec cinq groupes de stockage actifs. Chaque groupe de stockage est une source SCR avec une cible SCR correspondante sur l'autre serveur. En cas de défaillance de stockage, lorsqu'un groupe de stockage actif configuré en tant qu'une source SCR est indisponible, la copie cible SCR peut être rapidement activée à l'aide de quelques tâches administratives dans Exchange Management Shell. Avec Microsoft® Office Outlook ® 2007, la portabilité de la base de données et les fonctionnalités Autodiscover d'Exchange 2007, le temps d'interruption de service en cas de perte de groupe de stockage actif (ou, de perte de plusieurs groupes de stockage actifs) pourrait se compter en minutes.

Sources et cibles SCR

Comme la LCR et la CCR, la SCR utilise également le concept de copies actives et passives d'un groupe de stockage, mais elles sont respectivement appelées sources et cibles SCR. Cependant, les sources et cibles SCR sont des copies de groupe de stockage. (Les groupes de stockage de récupération ne peuvent pas être activés pour la SCR).

Le point de départ pour la SCR (la source SCR) est tout groupe de stockage sur un serveur de boîtes aux lettres autonome ou sur un serveur de boîtes aux lettres en cluster dans un environnement CCR ou de cluster à copie unique. Veuillez noter que si la source SCR peut être un serveur de boîtes aux lettres en cluster, la SCR elle-même n'est pas une solution en cluster et ne nécessite pas le service de cluster de Windows. Le point de terminaison la pour SCR (la cible SCR) peut être soit un serveur de boîtes aux lettres autonome soit un nœud dans un cluster de basculement où le rôle de boîte aux lettres est installé mais où aucun serveur de boîtes aux lettres mis en cluster n'a été configuré dans le cluster.

Relations source et cible

Chaque groupe de stockage de source SCR peut avoir un nombre illimité de cibles SCR. Par exemple, une source peut avoir une cible qui réside dans le même centre de données que la source et une deuxième cible dans un centre de données distinct. Cependant, Microsoft recommande de ne pas utiliser plus de quatre cibles par source. Si vous décidez d'utiliser plus de quatre cibles, vous devez évaluer l'impact probable sur le serveur source SCR en termes de mémoire, de processeur et des ressources disque, et planifier en conséquence. Chaque ordinateur cible SCR peut avoir plusieurs serveurs source. Les ordinateurs source et cible doivent exécuter Service Pack 1 pour Exchange 2007. Le système d'exploitation doit être un système d'exploitation pris en charge par Service Pack 1 pour Exchange 2007 (par exemple, Windows Server® 2008 ou Windows Server 2003 SP2). Cependant, quel que soit le système d'exploitation utilisé, la SCR ne prend pas en charge plusieurs systèmes d'exploitation. Le système d'exploitation sur la source SCR doit correspondre au système d'exploitation sur toutes les cibles SCR pour cette source. Ainsi, si la source SCR exécute Windows Server 2003, toutes les cibles SCR pour cette source doivent également exécuter Windows Server 2003.

La SCR est disponible dans l'édition Standard d'Exchange 2007. Si un serveur de boîtes aux lettres en cluster d'un environnement SCC ou CCR est utilisé en tant que source SCR, l'édition Enterprise d'Exchange 2007 est nécessaire. Chaque cible SCR prend en charge au maximum 50 instances (50 groupes de stockage répliqués) lorsqu'elle utilise Exchange 2007 Enterprise Edition et au maximum 5 instances lorsqu'elle utilise Exchange 2007 Standard Edition.

Les cibles SCR doivent également satisfaire certaines exigences. Tout d'abord, les ordinateurs source et cible doivent se trouver sur le même domaine Active Directory, bien qu'ils puissent être dans les mêmes sites Active Directory ou dans des sites Active Directory différents. De plus, les chemins d'accès au fichier journal et au fichier de la base de données sur la source et toutes ses cibles doivent correspondre à chaque groupe de stockage répliqué avec la SCR. Enfin, lorsqu'un nœud ou un serveur est configuré en tant que cible SCR, vous ne pouvez pas mettre la LCR en service pour le groupe de stockage sur l'ordinateur cible SCR. Vous ne pouvez pas non plus ajouter de serveur de boîtes aux lettres en cluster au cluster de basculement de secours.

Comparaison de la SCR avec la CCR et la LCR

La SCR (comme illustré à la figure 5) utilise la même technologie de relecture et de copie des journaux de transactions que celle utilisée par la LCR et la CCR pour offrir de nouvelles options et configurations de déploiement. Comme avec la LCR et la CCR, les groupes de stockage mis en service pour la SCR ne peuvent pas contenir plus d'une base de données. De même, la SCR ne peut pas être utilisée pour une base de données de dossiers publics s'il existe plus d'une base de données de dossiers publics dans l'organisation Exchange.

Figure 5** La SCR copie les journaux de transactions sur un autre serveur ou sur un nœud passif d'un cluster de basculement **

L'un des différences clés avec la SCR réside dans le fait qu'elle prend en charge plusieurs cibles par groupe de stockage, tandis que la LCR et la CCR ne prennent en charge qu'une seule cible (la copie passive). Autre différence clé : contrairement à une copie CCR ou LCR, vous ne pouvez pas sauvegarder une copie SCR. Lorsque vous utilisez la SCR, les en-têtes de base de données pour les cibles SCR sont mis à jour et les fichiers journaux sont tronqués lorsque les sauvegardes prises en charge sont effectuées sur le groupe de stockage source SCR (ou, dans le cas de la CCR et de la LCR, lorsque les sauvegardes sont effectuées sur les copies actives ou passives du groupe de stockage source SCR).

Comme avec la LCR et la CCR, la copie des journaux de transaction avec la SCR est continue et utilise un modèle d'extraction. Dès qu'un nouveau fichier journal est fermé et est nommé avec le numéro de fichier journal de séquence nouvelle génération, le Service de réplication Microsoft Exchange s'exécutant sur l'ordinateur cible SCR extrait les fichiers journaux de transactions fermés de l'ordinateur source SCR, les inspecte et les valide, puis les transfère vers leur dossier de fichiers journaux de groupes de stockage correspondants sur l'ordinateur cible SCR.

Délai d'attente de relecture

Une fois les fichiers journaux copiés sur l'ordinateur cible SCR, la SCR exécute une opération que la LCR et la CCR n'effectuent pas. Au lieu de relire immédiatement les fichiers journaux dans la copie de la base de données, la SCR applique un délai de relecture prédéfini de 50 fichiers journaux et 24 heures. La SCR vous permet également de spécifier un délai supplémentaire au delà de ces délais prédéfinis. Le délai de relecture est utile dans de nombreux scénarios. Par exemple, en cas de corruption logique d'une base de données active, un délai peut prévenir la corruption logique de la base de données cible SCR.

Le délai de relecture contrôlé par l'administrateur est défini à l'aide d'un paramètre appelé ReplayLagTime, qui dicte la durée d'attente du service de réplication d'Exchange avant la relecture des fichiers journaux copiés sur l'ordinateur cible SCR. Le format est Jours.Heures:Minutes:Secondes et la valeur par défaut est 24 heures. Le paramètre admissible maximum pour cette valeur est sept jours. Le paramètre admissible minimum est zéro seconde. La définition de cette valeur sur zéro seconde supprime tout délai dans l'activité de relecture du journal au-delà du délai par défaut de 50 fichiers journaux.

Outre le paramètre ReplayLagTime, Exchange dispose d'un délai prédéfini et codé en dur de 50 fichiers journaux, quelle que soit la valeur du paramètre ReplayLagTime. Pour déterminer le moment où un fichier journal doit être relu, Exchange utilise le paramètre ReplayLagTime le plus important ou x fichiers journaux, où x = 50. Il s'agit d'une garantie supplémentaire contre la nécessité de réamorçage d'un groupe de stockage dans les situations où une source SCR qui utilise la réplication continue (par exemple, un serveur de boîtes aux lettres en cluster dans un environnement CCR) rencontre un basculement et où un ou plusieurs groupes de stockage doi(ven)t être mis en ligne à l'aide de l'applet de commande Restore-StorageGroupCopy. (Le réamorçage est le processus permettant d'utiliser les API de sauvegarde en continu ESE (Extensible Storage Engine) pour mettre en ligne une copie de la base de données source SCR sur l'ordinateur cible SCR). En retardant l'activité de relecture sur les cibles SCR, lorsqu'un basculement avec perte se produit pour une source SCR, la nécessité de réamorcer les copies SCR sera limitée vu que la nature de la perte de données sur la source SCR rapproche les deux copies dans le temps.

Délai de troncation

Dans la version RTM d'Exchange 2007, les règles sont appliquées dans un environnement de réplication continue. Par conséquent, un fichier journal n'est pas supprimé à moins qu'il ait été sauvegardé et relu dans la copie de la base de données. Lorsque vous utilisez la SCR, cette règle est modifiée. La SCR (qui introduit le concept de copies de base de données multiples) permet aux fichiers journaux d'être tronqués sur l'ordinateur source SCR dès qu'ils sont inspectés par tous les ordinateurs cibles SCR. La troncation de journaux au niveau du serveur source SCR n'attend pas la relecture de tous les journaux dans les cibles SCR du fait que les copies cibles SCR peuvent être configurées avec des délais de relecture importants pour les journaux.

Vous pouvez également ajouter un délai supplémentaire à la troncation de journaux à l'aide d'un nouveau paramètre appelé TruncationLagTime, qui spécifie la durée d'attente du service de réplication d'Exchange (au format Jours.Heures:Minutes:Secondes) avant la troncation des fichiers journaux copiés sur l'ordinateur cible SCR et relus dans la copie de la base de données. La période commence dès que les fichiers journaux ont été relus avec succès dans la copie de la base de données. Le paramètre admissible maximum pour cette valeur est sept jours, tandis que le paramètre minimum est zéro seconde, bien que zéro seconde élimine en fait tout délai dans l'activité de troncation des journaux.

Dans un environnement SCR, un thread d'arrière-plan s'exécute toutes les trois minutes pour déterminer si un fichier journal doit être tronqué. Si la séquence de génération de fichier journal n'a pas atteint le point de vérification du fichier journal pour le groupe de stockage et que le fichier journal est plus ancien que les paramètres ReplayLagTime + TruncationLagTime, un fichier journal de la cible SCR sera tronqué.

Dans un environnement LCR ou CCR étendu avec SCR, un fichier journal de la cible SCR sera tronqué si les quatre critères suivants sont satisfaits : le fichier journal a été sauvegardé, la séquence de génération du fichier journal n'a pas atteint le point de vérification du fichier journal pour le groupe de stockage, la copie passive du groupe de stockage est dans un état permettant la troncation du fichier journal et toutes les cibles SCR ont inspecté le fichier journal.

Mise en service et gestion de la SCR

La SCR est mise en service à l'aide de l'applet de commande Enable-StorageGroupCopy dans Exchange Management Shell, mis à jour dans SP1 avec certains nouveaux paramètres. Comme décrit ci-dessus, les paramètres ReplayLagTime et TruncationLagTime vous permettent de contrôler une partie du comportement des cibles SCR. Un autre paramètre, SeedingPostponed, peut être utilisé pour ignorer l'amorçage initial de la cible SCR. Dans certaines situations, il peut être utile de différer l'amorçage. Par exemple, disons que la base de données du groupe de stockage qui est mise en service pour la SCR fait 100 Go. Vous ne souhaiterez peut-être pas que 100 Go de données traversent le réseau pendant les heures de production maximale. Le paramètre SeedingPostponed vous permet de mettre immédiatement la SCR en service et d'exécuter une tâche d'amorçage ultérieurement. Lorsque vous êtes prêt, vous pouvez amorcer manuellement la cible SCR à l'aide de l'applet de commande Update-StorageGroupCopy.

Bien que les paramètres mentionnés ci-dessus soient facultatifs, un paramètre d'Enable-StorageGroupCopy est nécessaire pour la SCR : StandbyMachine. Il spécifie le nom de l'ordinateur qui contiendra la cible SCR. La valeur de ce paramètre est définie dans le cadre de la valeur pour l'attribut msExchStandbyCopyMachines du stockage mise en service pour la SCR. L'attribut msExchStandbyCopyMachines est une chaîne unicode de plusieurs valeurs ajoutée au schéma Active Directory lorsqu'Exchange 2007 SP1 est introduit dans l'organisation Exchange, ce qui est une des raisons pour lesquelles SP1 nécessite une mise à jour du schéma pour Active Directory.

Le paramètre StandbyMachine est central à la SCR. Plusieurs applets de commande ont été mises à jour dans SP1 pour utiliser ce paramètre pour la mise en service et la gestion des cibles SCR. Les applets de commande mises à jour sont décrites à la figure 6.

Figure 6 Applet de commande qui utilise le paramètre Stand­by­Machine

Activation des cibles SCR

La SCR offre une ou plusieurs copies à jour des données, qui peuvent être utilisées si les données d'origine sont perdues ou deviennent inutilisables. Le processus consistant à prendre une copie cible SCR et à effectuer un redéploiement en tant que base de données de production est connu sous le nom d'activation. L'activation survient dans le cadre d'un processus de récupération, qui prendra la forme d'une portabilité de la base de données ou d'une des deux options de récupération d'installation (/m:RecoverServer pour récupérer un serveur autonome ou /RecoverCMS pour récupérer un serveur de boîtes aux lettres en cluster).

Comment utiliser la SCR

Voyons comment une entreprise fictive pourrait utiliser la SCR et la portabilité de la base de données pour récupérer d'une défaillance de base de données de boîtes aux lettres. Lorsque la base de données de production s'avère endommagée, l'administrateur active la base de données SCR à l'aide de la portabilité de la base de données.

L'organisation a déployé Exchange 2007 avec SP1 et a décidé d'utiliser la SCR pour fournir une copie d'un groupe de stockage sur un serveur de boîtes aux lettres distant. Les serveurs de boîtes aux lettres cible et source se trouvent dans le même site Active Directory et sont configurés pour utiliser les serveurs DNS intégrés à Active Directory. L'intervalle de réplication Active Directory est défini sur 15 minutes.

Mise en service de la SCR et préparation de la récupération

La SCR est configurée pour que les fichiers journaux des transactions soient répliqués pour un groupe de stockage unique, SG1, qui contient une base de données unique, MBX1. Les chemins pour les fichiers de groupe de stockage et le fichier de base de données sont C:\SG1 et C:\SG1\MBX1.EDB. Dans le cas présent, EXMBX1 est la source SCR et EXMBX2 la cible SCR. Voici la configuration que vous obtenez :

Enable-StorageGroupCopy EXMBX1\SG1 
-StandbyMachine EXMBX2

Après la mise en service de la SCR, l'intégrité et l'état de la SCR pour SG1 ont été vérifiés à l'aide de l'applet de commande Get-StorageGroupCopyStatus :

Get-StorageGroupCopyStatus EXMBX1\SG1 
-StandbyMachine EXMBX2

Pour gagner du temps lors du processus d'activation de la cible SCR, EXMBX2 est préconfiguré avec un groupe de stockage, SG1PORT et une base de données, MBX1PORT, qui seront utilisés dans le cadre des opérations de portabilité de la base de données. SG1PORT et MBX1PORT sont séparés du groupe de stockage et des fichiers de base de données de la cible SCR. Par conséquent, les chemins pour SG1PORT et MBX1PORT sont configurés avec un chemin temporaire qui n'entre pas en conflit avec les chemins de la cible SCR. SG1PORT et MBX1PORT seront uniquement utilisés comme objets de portabilité de la base de données. Les fichiers de groupe de stockage et de base de données réels pour SG1PORT ne sont pas nécessaires. De ce fait, l'administrateur démonte MBX1PORT et supprime tous les fichiers du groupe de stockage. Les objets de la base de donnés et du groupe de stockage restent dans Active Directory parce qu'ils seront utilisés ultérieurement pour la portabilité de la base de données lors du processus de récupération.

Activation et récupération

Une entrée du journal des événements d'applications indique que la base de données de la source SCR est physiquement endommagée. Comme la SCR a été mise en service pour SG1, vous devez effectuer une activation manuelle de la base de données de la cible SCR pour SG1 et utiliser la portabilité de la base de données pour restaurer la disponibilité des données. L'activation de la copie cible SCR commence par le démontage de MBX1 dans SG1 à l'aide de l'applet de commande suivante :

Dismount-Database EXMBX1\SG1\MBX1

La base de données cible SCR est ensuite rendue viable pour le montage et les boîtes aux lettres initialement présentes sur MBX1 sont rapatriées vers MBX1PORT.

Le processus consistant à mettre la SCR hors service et à rendre la base de données cible SCR viable pour le montage implique l'exécution de l'applet de commande Restore-StorageGroupCopy. Cette tâche marque la base de données du groupe de stockage comme montable et fournit un rapport sur la perte de données, le cas échéant, entraînée par le montage de la base de données dans le groupe de stockage. Elle vérifie également la présence de tous les fichiers journaux produits par la copie active du groupe de stockage dans l'emplacement du fichier de groupe de stockage de la copie passive. Si un fichier journal est absent, l'opération tentera également de le copier. L'applet de commande suivante est utilisée pour rendre la base de données cible SCR viable pour le montage :

Restore-StorageGroupCopy EXMBX1\SG1 
-StandbyMachine EXMBX2

Dans cet exemple, les fichiers journaux du groupe de stockage source SCR sont disponibles pour la copie. Si ces fichiers ne sont pas disponibles (par exemple, parce que l'ordinateur source SCR est en panne), le paramètre Force doit être ajouté à la tâche Restore-StorageGroupCopy. Sinon, Restore-StorageGroupCopy tentera toujours de se connecter à la source SCR pour copier tout fichier journal manquant et si la source SCR n'est pas disponible, la tâche Restore-StorageGroupCopy échouera et la base de données ne sera pas rendue viable pour le montage. L'ajout du paramètre Force indique à la tâche Restore-StorageGroupCopy que les fichiers sources ne sont pas disponibles. Dans ce cas, elle ignore la tentative de connexion et rend la base de données cible SCR viable pour le montage.

Une fois la commande Restore-StorageGroupCopy exécutée, l'administrateur doit vérifier que la base de données est dans un état d'arrêt correct. Si la base de données est dans un état d'arrêt incorrect (voir technet.microsoft.com/aa996757.aspx), elle doit être arrêtée correctement. Si le préfixe du fichier journal pour le groupe de stockage (par exemple, E00 ou E01) est le même pour la source SCR (EXMBX1\SG1) et le groupe de stockage sur la cible SCR (SG1PORT) qui sera utilisé pour la portabilité de la base de données (EXMBX2\SG1PORT), il n'est pas nécessaire d'exécuter Eseutil en mode de récupération. L'opération de montage de la base de données finale amènera la base de données à un état d'arrêt correct après la relecture de tous les fichiers journaux copiés. Si la base de données est dans un état d'arrêt incorrect, le mode de récupération (Eseutil /r) des utilitaires de la base de données d'Exchange Server (Eseutil) doit être exécuté sur la base de données.

Une fois la base de données arrêtée correctement, vous pouvez exécuter deux commandes qui mettent à jour Active Directory avec les nouveaux emplacements pour les fichiers de groupes de stockage et le fichier de base de données. Ces commandes modifient les chemins pour SG1PORT et MBX1 de leurs chemins originaux aux chemins pour le groupe et la base de données de stockage montés (SG1 PORT et MBX1PORT) :

Move-StorageGroupPath EXMBX2\SG1PORT 
-SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT 
-EdbFilePath C:\SG1\MBX1PORT.EDB 
–ConfigurationOnly

Le paramètre –ConfigurationOnly doit être inclus dans les commandes mentionnées ci-dessus pour que seuls les paramètres de configuration pour ces objets soient mis à jour dans Active Directory. Aucune donnée ni aucun fichier n'est déplacé(e) ou ne doit être déplacé(e) parce que la SCR a déjà copié les données vers C:\SG1 sur EXMBX2.

L'étape suivante consiste à configurer la base de données (MBX1PORT) pour l'autoriser à être écrasée lors d'une opération de restauration. Cette opération peut être effectuée en sélectionnant la case à cocher pour le paramètre « Cette base de données peut être écrasée par une restauration » dans les propriétés d'objet de base de données de la console de gestion Exchange ou à l'aide de la commande suivante dans Exchange Management Shell :

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT 
-AllowFileRestore:$true

Après avoir configuré la base de données pour qu'elle s'autorise à être écrasée, l'étape suivante consiste à monter la base de données à l'aide de la commande suivante :

Mount-Database EXMBX2\SG1PORT\MBX1PORT

Après le montage de la base de données, les boîtes aux lettres hébergées sur la base de données source SCR (SG1\MBX1) doivent être rapatriées pour pointer vers MBX1PORT sur EXMBX2. Il vous suffit d'exécuter l'applet de commande Get-Mailbox et de diriger les résultats vers l'applet de commande Move-Mailbox. Pendant ce processus, il est important que la Surveillance du système Exchange et les boîtes aux lettres système ne soient pas incluses dans les résultats de l'applet de commande Get-Mailbox qui est redirigé vers l'applet de commande Move-Mailbox. Ces objets de boîtes aux lettres n'ont pas besoin d'être rapatriés et ne doivent pas l'être. La commande suivante est exécutée pour rapatrier toutes les boîtes aux lettres des utilisateurs et exclure les boîtes aux lettres système :

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|
ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly 
-TargetDatabase EXMBX2\SG1PORT\MBX1PORT

À ce stade, l'accès client à MBX1PORT est désormais possible. Cependant, le fait que les utilisateurs puissent effectivement accéder à leurs boîtes aux lettres après qu'elles aient été déplacées de XMBX1\SG1\MBX1 vers EXMBX2\SG1PORT\MBX1PORT dépend de la latence de réplication d'Active Directory. En fonction du nombre de serveurs d'annuaire, la mise à jour peut prendre un certain temps pour se propager dans l'environnement. De plus, les méthodes d'accès au client sont importantes. Les clients de messagerie exécutant Outlook 2007 et les clients n'utilisant pas Outlook auront accès à la boîte aux lettres de l'utilisateur une fois les serveurs d'annuaire utilisés par le serveur d'accès au client de l'utilisateur mis à jour avec les nouveaux chemins. Les clients de messagerie exécutant Outlook 2003 et les versions précédentes nécessiteront la mise à jour du profil de messagerie de l'ordinateur de l'utilisateur avec le nouveau nom du serveur.

Etapes finales

Une fois que les clients peuvent accéder à leurs boîtes aux lettres et à leurs données de boîtes aux lettres, l'étape finale consiste à établir la redondance en remettant la SCR en service. Il faut pour cela supprimer tous les groupes de stockage et tous les fichiers de base de données restants d'EXMBX1. Une fois les fichiers supprimés, les chemins pour EXMBX1\SG1\MBX1 peuvent être transférés à un emplacement temporaire et EXMBX1 peut devenir une cible SCR d'EXMBX2.

Scott Schnoll est rédacteur technique principal au sein de l'équipe Exchange Server chez Microsoft, et responsable du contenu pour Exchange Server 2007. Avant de rejoindre Microsoft, Scott a écrit Exchange Server 2003 Distilled (Addison-Wesley Professional, 2004) et était le principal auteur d'Exchange 2000 Server: The Complete Reference (McGraw-Hill/OsborneMedia, 2001).

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.