Installation d'une réplication continue en cluster
S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Dernière rubrique modifiée : 2007-10-30
Avant de déployer une réplication continue en cluster, il est recommandé de lire attentivement la rubrique Réplication continue en cluster. En outre, assurez-vous que vous satisfaites à toutes les exigences énoncées dans la rubrique Planification de la réplication continue en cluster. L'installation d'un environnement de réplication continue en cluster (CCR) sous Windows Server 2003 se déroule en plusieurs phases :
Configuration de l'installation du matériel, démarrage avec la formation et la configuration d'un réseau de clusters.
Formation du cluster, d'abord le premier nœud, puis le deuxième.
Configuration et sécurisation du témoin de partage de fichiers, puis configuration des réseaux de clusters et de la tolérance pour les interrogations de cluster manquées.
Installation des rôles serveur de boîtes aux lettres actif et passif dans le cluster. Le serveur de boîtes aux lettres en cluster (CMS) est créé lors de l'installation du rôle serveur de boîtes aux lettres actif.
Notes
Il est recommandé d'achever chaque phase avant d'entamer la suivante. Une fois toutes les phases accomplies, il est recommandé de vérifier la solution CCR avant de l'utiliser pour la production.
Certaines tâches destinées au serveur de boîte aux lettres en cluster, consécutives à l'installation, doivent également être exécutées :
réglage des paramètres de contrôle du basculement ;
réglage de la configuration par défaut du conteneur de dépôt de transport ;
vérification de la possibilité de déplacer un serveur de boîtes aux lettres en cluster entre les différents nœuds du cluster ;
activation d’un ou plusieurs réseaux mixtes pour l’envoi et l’amorçage de journaux.
Les sections suivantes décrivent chaque phase d'installation de façon plus détaillée.
Formation et configuration d'un réseau
Vous devez posséder un nombre suffisant d'adresses IP statiques lorsque vous créez des serveurs de boîtes aux lettres en cluster dans un environnement de CCR à deux nœuds. Des adresses IP sont requises pour les réseaux publics et privés et toutes les adresses IP de chaque réseau de clusters doivent figurer sur le même sous-réseau. La configuration requise pour les adresses privées et publiques est la suivante :
Adresses privées Chaque noeud requiert une adresse IP statique pour chaque carte réseau utilisée pour le réseau privé en cluster. Vous ne devez pas utiliser d'adresses IP statiques qui se trouvent sur le même sous-réseau ou réseau que l'un des réseaux publics. Il est recommandé d'utiliser 10.10.10.10, et 10.10.10.11 avec un masque de sous-réseau de 255.255.255.0 pour les adresses IP privées des nœuds.
Adresses publiques Chaque noeud requiert une adresse IP statique pour chaque carte réseau utilisée pour le réseau public en cluster. Par ailleurs, des adresses IP statiques sont requises pour le cluster de basculement et le serveur de boîtes aux lettres en cluster, de façon à ce que les clients et les administrateurs puissent y accéder. Vous ne devez pas utiliser d'adresses IP statiques qui se trouvent sur le même sous-réseau ou réseau que l'un des réseaux privés.
Meilleures pratiques réseau pour les serveurs de boîtes aux lettres en cluster
Il est également recommandé de suivre les pratiques suivantes pour votre réseau en cluster :
Utilisation de noms significatifs La création d'un cluster vous fournit de nombreuses occasions de donner des noms significatifs aux nœuds de cluster, aux interfaces réseau de clusters, aux clusters et aux serveurs de boîtes aux lettres en cluster. Par exemple, le réseau utilisé pour communiquer avec d'autres serveurs et clients Exchange peut s'appeler Public. Le réseau utilisé pour communiquer entre les noeuds de cluster peut s'appeler Privé. Attribuez des noms de façon à ne pas devoir se référer à une carte topologique. Une autre convention utile consiste à associer les nœuds d'un cluster au nom du serveur de boîtes aux lettres en cluster. Par exemple, utilisez mbx01, mbx01-node1 et mbx01-node2, respectivement pour le serveur de boîtes aux lettres en cluster et les deux nœuds.
Utilisation d'adresses IP privées pour les interfaces réseau privé Pour obtenir une liste des plages d'adresses IP et des masques de sous-réseau utilisables pour les interfaces de réseau privé, consultez le tableau suivant.
Plages d'adresses et masques de sous-réseau pour les interfaces de réseau privé
Réseau Plage d'adresses IP Masque de sous-réseau Privé 1
10.10.10.10-255
255.255.255.0
Privé 2
10.10.10.11-255
255.255.255.0
Considérez les informations suivantes :
Si votre réseau public utilise un réseau 10.x.x.x et un masque de sous-réseau 255.255.255.0, il est recommandé d'utiliser des adresses IP de réseau privé et un masque de sous-réseau alternatifs.
Il n'est pas recommandé d'utiliser un type quelconque de carte tolérante aux pannes ou de groupement pour le réseau privé. Si vous avez besoin de redondance pour votre réseau privé, utilisez plusieurs cartes réseau définies sur Communications internes uniquement et définissez leur priorité réseau dans la configuration de cluster. Avant d'utiliser cette technologie, il est important de vérifier que vos microprogramme et pilote sont les plus récents. Contactez le fabricant de votre carte réseau pour obtenir des informations sur la compatibilité sur un cluster de serveurs. Pour plus d'informations sur l'utilisation d’un groupement de cartes réseau dans des déploiements de clusters de serveurs, consultez l'article 254101 de la Base de connaissances Microsoft relatif à l'utilisation d'équipes de cartes réseau et au clustering de serveur.
Pour configurer les réseaux dans le cluster à utiliser avec une solution de CCR Microsoft Exchange Server 2007, configurez les réseaux privés et publics en effectuant les étapes décrites dans la rubrique Procédure de configuration de connexions réseau pour une réplication continue en cluster.
Formation du cluster de basculement
Un cluster avec basculement est formé lorsque le premier noeud est ajouté au cluster. Grâce à ce processus, le cluster dispose d'un nom de réseau et d'une adresse IP de réseau uniques. Le nom de réseau et l'adresse IP, qui forment ensemble l'identité réseau du cluster, se déplacent entre les noeuds du cluster à mesure que ceux-ci sont mis en ligne et hors connexion. Généralement, l'identité réseau du cluster est rarement utilisée dans l'administration d'un serveur de boîtes aux lettres en cluster.
Si vous êtes habitué à déployer des clusters avec basculement ou des clusters Exchange à partir de versions précédentes, vous trouverez que le déploiement d'un cluster pour une solution de CCR est une opération très différente. Si les solutions de cluster sont pour vous une nouveauté, vous constaterez que le déploiement est une opération beaucoup moins complexe qu'une configuration de cluster classique.
Vous pouvez créer un cluster en suivant les instructions énoncées dans la rubrique Procédure de création d'un cluster de basculement Windows Server 2003 pour la réplication continue en cluster. Cette procédure comprend des instructions relatives à l’interface utilisateur graphique et à l’interface de ligne de commande pour former le cluster de basculement, ajouter le deuxième nœud au cluster de basculement et en configurer le cluster afin d’utiliser un quorum jeu de nœud majoritaire (MNS).
Notes
La réplication continue en cluster (CRR) sous Windows Server 2003 requiert un modèle quorum appelé quorum MNS associé à un témoin de partage de fichiers. Ce modèle quorum est disponible dans Windows Server 2003 Service Pack 2 (SP2) qui est requis pour Exchange 2007 Service Pack 1 (SP1). Pour utiliser le quorum MNS associé au témoin de partage de fichiers avec la version de publication (RTM) d’Exchange 2007 et d’Windows Server 2003 SP1, vous devez installer un correctif sur chaque nœud avant de déployer la réplication continue en cluster (CRR). Ce correctif est décrit dans l'article 921181 de la Base de connaissances relatif à la mise à jour disponible qui permet d'ajouter aux clusters de serveurs Microsoft Windows Server 2003 Service Pack 1 des fonctionnalités de témoin de partage de fichiers et d'interrogations de cluster configurable. Pour obtenir la procédure détaillée d'installation du correctif, consultez la rubrique Procédure d'installation de la fonctionnalité Témoin de partage de fichiers pour un jeu de nœud majoritaire.
Configuration du cluster de basculement consécutive à son installation
Une fois le cluster de basculement formé avec les deux nœuds et configuré à l’aide d’un quorum MNS, des tâches consécutives à l’installation sont nécessaires avant d’installer Exchange sur chaque nœud. Vous devez configurer les réseaux de clusters, la tolérance pour les interrogations de cluster manquées et le composant de témoin de partage de fichiers du quorum MNS.
Configuration de réseaux en cluster
Une fois les deux nœuds ajoutés au cluster, les composants de cluster suivants doivent être configurés. Plus particulièrement, les paramètres de réseaux de clusters, de priorité de réseau de clusters et de tolérance pour les interrogations de cluster manquées doivent être configurés. Le tableau suivant détaille les options disponibles pour configurer des réseaux de clusters.
Options de configuration de réseaux de clusters
| Option | Description |
|---|---|
Accès client uniquement (réseau public) |
Activez cette option si vous voulez que le service de clusters utilise uniquement cette carte réseau pour la communication externe avec d'autres clients. Aucune communication inter-noeuds ni aucun trafic de mise à jour de base de données en cluster n'a lieu sur cette carte réseau. |
Communications internes du cluster uniquement (réseau privé) |
Sélectionnez cette option si vous voulez que le service de cluster utilise ce réseau uniquement pour la communication inter-noeuds en cluster et le trafic de mise à jour de base de données en cluster. |
Toutes les communications (réseau mixte) |
Sélectionnez cette option si vous voulez que le service de cluster utilise la carte réseau pour la communication inter-noeuds en cluster et le trafic de mise à jour de base de données en cluster, ainsi que pour la communication avec des clients externes. Cette option est activée par défaut pour tous les réseaux. |
Les serveurs de boîtes aux lettres en cluster déployés dans un environnement de réplication continue en cluster requièrent au moins deux cartes réseau dans chaque nœud pour être pris en charge. Dans un environnement de CCR, il est recommandé de configurer un des deux réseaux comme réseau privé et le deuxième réseau comme réseau mixte. Si un réseau est configuré comme réseau privé et si l'autre réseau est configuré comme réseau public, le réseau privé représente un point de défaillance unique pour le serveur de boîtes aux lettres en cluster.
Pour obtenir la procédure détaillée de configuration des composants de réseau de clusters, consultez la rubrique Procédure de configuration des composants de réseau et de l'ordre de priorité du cluster.
Configuration des paramètres de tolérance pour les interrogations de cluster manquées
Une fois les paramètres de communications de cluster et de priorité réseau configurés, il est recommandé de configurer les paramètres de tolérance spécifiques pour les interrogations de cluster manquées. Cette opération configure la surveillance de connectivité réseau du service de cluster entre les noeuds de cluster pour tolérer des interruptions mineures. Cela empêche les basculements en cas de panne de réseau brève. Il est recommandé de configurer des réseaux de clusters privés et mixtes sur les deux nœuds pour qu'ils rendent compte de 10 interrogations manquées. Ce niveau de paramétrage correspond à environ 12 secondes.
Pour obtenir la procédure détaillée de configuration de la tolérance du service de cluster pour les interrogations manquées, consultez la rubrique How to Configure Tolerance Settings for Missed Cluster Heartbeats.
Configuration du témoin de partage de fichiers
Une fois le cluster formé et configuré, vous devez configurer le témoin de partage de fichiers. La CCR utilise le témoin de partage de fichiers sur un troisième ordinateur pour éviter toute occurrence de partition de réseau à l'intérieur du cluster, également appelée Split-Brain Syndrome. Ce problème survient dans un environnement de CCR lorsque :
tous les réseaux désignés pour assurer les communications à l'intérieur du cluster échouent ;
les noeuds ne peuvent pas échanger de signaux de pulsations ;
Les deux nœuds deviennent actifs en mettant ou en tentant de mettre en ligne le serveur de boîtes aux lettres en cluster.
Le partage de fichiers pour le témoin de partage de fichiers peut être hébergé sur tout serveur exécutant le système d'exploitation Microsoft Windows. Toutefois, il est recommandé d'utiliser un serveur de transport Hub du site du service d'annuaire Active Directory contenant les noeuds de cluster pour l'héberger. Il est recommandé d'utiliser un serveur de transport Hub pour s'assurer qu'un administrateur Exchange dispose d'un contrôle et d'une autorité complets sur le partage. Pour obtenir la procédure détaillée de configuration du partage de fichiers à utiliser comme témoin de partage de fichiers, consultez la rubrique Procédure de configuration du témoin de partage de fichiers.
Configuration et installation d'un serveur de boîtes aux lettres en cluster
Vous pouvez installer un rôle serveur de boîtes aux lettres sur un cluster en exécutant quelques opérations sur chaque noeud. Une fois le cluster formé et validé et après que vous l'avez configuré pour utiliser le quorum jeu de nœud majoritaire (MNS) avec le témoin de partage de fichiers, vous devez commencer par installer le rôle serveur de boîtes aux lettres sur le nœud actif. L’installation du nœud actif est un processus impliquant l’installation du rôle serveur de boîtes aux lettres sur le nœud, puis la création d’un serveur de boîtes aux lettres en cluster sur le nœud.
Pour obtenir la procédure détaillée d'installation du rôle serveur de boîtes aux lettres sur le noeud actif, consultez la rubrique Procédure d'installation du rôle de boîtes aux lettres en cluster actif dans un environnement de CCR sous Windows Server 2003.
Notes
Si vous installez le nœud actif sur un ordinateur exécutant Windows Server 2003 et n’étant pas situé dans le même site Active Directory que le contrôleur de domaine auquel est attribué le rôle contrôleur de domaine principal, vous devez commencer par créer un compte d’ordinateur avec le nom prévu pour le serveur de boîtes aux lettres en cluster. Le compte d’ordinateur doit être activé et l’objet ordinateur doit être disponible dans le site Active Directory local. Si aucun compte d’ordinateur n’existe pour le serveur de boîtes aux lettres en cluster et si le contrôleur de domaine principal ne se trouve pas dans le site Active Directory local, l’installation ne se poursuit pas.
Après avoir installé le rôle serveur de boîtes aux lettres sur le noeud actif, il est recommandé de vérifier que la configuration de la base de données et des journaux des transactions du premier groupe de stockage est telle que vous l'avez prévue. Il se peut que vous deviez les déplacer avant de passer au deuxième noeud. Par défaut, le groupe de stockage et la base de données initiaux sont placés dans %ProgramFiles%\Microsoft\Exchange Server\Mailbox\Premier groupe de stockage.
Pour obtenir la procédure détaillée de configuration du premier groupe de stockage pour un cluster, consultez la rubrique Procédure de déplacement d'un groupe de stockage et de sa base de données.
Après avoir installé le rôle serveur de boîtes aux lettres et un serveur de boîtes aux lettres en cluster sur le nœud actif, puis vérifié la configuration du premier groupe de stockage, vous devez installer le rôle serveur de boîtes aux lettres sur le nœud passif. L’installation du nœud passif est un processus impliquant l’installation du rôle serveur de boîtes aux lettres sur le nœud. Pour obtenir la procédure détaillée d'installation du rôle serveur de boîtes aux lettres sur le noeud passif, consultez la rubrique Procédure d'installation du rôle serveur de boîtes aux lettres en cluster passif dans un environnement de CCR sous Windows Server 2003.
Tâches consécutives à l'installation
Une fois le rôle serveur de boîtes aux lettres installé sur les deux nœuds et un serveur de boîtes aux lettres en cluster créé, vous devez exécuter des tâches consécutives à l'installation. Ces tâches sont les suivantes :
réglage des paramètres de contrôle du basculement ;
réglage de la configuration par défaut du conteneur de dépôt de transport ;
vérification de la possibilité de déplacer un serveur de boîtes aux lettres en cluster entre les différents nœuds du cluster ;
activation de plusieurs réseaux pour une activité de réplication continue.
Réglage des paramètres de contrôle du basculement
La réplication continue en cluster inclut des attributs permettant de contrôler le comportement de basculement d'un serveur de boîtes aux lettres en cluster. Vous pouvez configurer ces attributs à l'aide de la cmdlet Set-MailboxServer. Ces attributs sont fournis afin que vous puissiez contrôler les deux algorithmes de décision suivants :
Algorithme 1 L'algorithme 1 contrôle si une base de données est montée au moment du basculement. Au moment du basculement, s'il apparaît que la base de données a perdu moins de journaux que les journaux configurés, elle est montée automatiquement. Il est possible de configurer le nombre acceptable de journaux perdus à l'aide d'une valeur appelée AutoDatabaseMountDial. Ce paramètre, représenté dans Active Directory par un attribut Exchange Server appelé msExchDataLossForAutoDatabaseMount, peut prendre trois valeurs : Lossless, Good Availability et Best Availability. Lossless correspond à aucune perte de journaux, Good Availability correspond à la perte de 3 journaux et Best Availability (paramètre par défaut) correspond à la perte de 6 journaux. Lors de la configuration du système sur Good Availability et Best Availability, n'utilisez pas d'espaces. Par exemple, utilisez GoodAvailability et BestAvailability.
Algorithme 2 L'algorithme 2 permet de déterminer s'il est plus important d'être en ligne avec des anciennes données que d'être hors connexion. Si le montage de la base de données sur la base de l'algorithme 1 échoue, vous pouvez fixer le laps de temps après lequel effectuer une deuxième vérification. Le temps d'attente est configuré par l'attribut ForcedDatabaseMountAfter. La valeur est exprimée en unités d'heures et la valeur par défaut est illimitée.
Important
Une fois la valeur de ForcedDatabaseMountAfter atteinte, la base de données est montée, indépendamment du fait que la copie du groupe de stockage soit en retard d'un journal, de dix journaux ou de 1 000 journaux, ce qui pourrait entraîner une perte de données significative. C'est pourquoi ce paramètre ne doit pas être utilisé si les contrats de niveau de service (contrats SLA) garantissent un maximum sur le volume de la perte de données qui peut être encourue.
Pour plus d'informations sur le réglage d'un basculement, consultez la rubrique Procédure de réglage des paramètres de basculement et de montage pour la réplication continue en cluster.
Réglage du conteneur de dépôt de transport
Le conteneur de dépôt de transport est une fonctionnalité du rôle serveur de transport Hub qui soumet des messages remis récemment après une interruption non programmée. Le conteneur de dépôt de transport doit toujours être activé en cas d'utilisation d'une CCR ou d'une réplication continue locale (LCR). Le conteneur de dépôt de transport est activé à l'échelle de l'organisation en définissant la quantité de stockage disponible par groupe de stockage et le temps pendant lequel conserver les messages dans le conteneur de dépôt de transport.
Le serveur de transport Hub gère une file d'attente des messages récemment remis à un serveur de boîtes aux lettres en cluster. Dans l'hypothèse d'un basculement entraînant des pertes, la CCR demande automatiquement à chaque serveur de transport Hub du site de soumettre de nouveau les messages de la file d'attente du conteneur de dépôt de transport. La banque d'informations supprime automatiquement les doublons et remet de nouveau les messages perdus. La console de gestion Exchange ou la cmdlet Set-TransportConfig dans l'environnement de ligne de commande Exchange Management Shell permet de modifier les paramètres de configuration par défaut du conteneur de dépôt de transport qui s'appliquent au niveau du groupe de stockage.
Il est recommandé de configurer le paramètre MaxDumpsterSizePerStorageGroup, qui spécifie la taille maximale de la file d'attente du conteneur de dépôt de transport pour chaque groupe de stockage, sur une taille équivalant à 1,5 fois la taille maximale de message pouvant être envoyé. Par exemple, si la taille maximale de message est 10 Mo, vous devez attribuer au paramètre MaxDumpsterSizePerStorageGroup la valeur 15 Mo. Il est également recommandé de configurer le paramètre MaxDumpsterTime, qui spécifie le délai pendant lequel un message électronique doit rester dans la file d'attente du conteneur de dépôt de transport, sur la valeur 7.00:00:00, soit 7 jours. Cela doit être suffisant pour éviter toute perte de messages électroniques en cas d'interruption prolongée. En cas d'utilisation de la fonctionnalité de conteneur de dépôt de transport, un espace disque supplémentaire est nécessaire sur le serveur de transport Hub pour héberger les files d'attente du conteneur de dépôt de transport. La quantité d'espace de stockage requise est plus ou moins égale à la valeur de MaxDumpsterSizePerStorageGroup multipliée par le nombre de groupes de stockage sur tous les serveurs de boîtes aux lettres en cluster dans un environnement de CCR et tous les groupes de stockage activés pour la LCR dans le site Active Directory contenant le serveur de transport Hub.
Pour obtenir la procédure détaillée d'activation et de configuration du conteneur de dépôt de transport, consultez la rubrique Procédure de configuration de la benne de transport.
Vérification de la solution CCR
Après l'installation d'une solution de réplication continue en cluster ou l'apport de modifications de configuration importantes, il est recommandé de vérifier que les deux nœuds sont correctement configurés pour prendre en charge le serveur de boîtes aux lettres en cluster, ainsi que l'intégrité et l'état du serveur de boîtes aux lettres en cluster.
L'exécution des cmdlets Get-StorageGroupCopyStatus et Get-ClusteredMailboxServerStatus est la manière recommandée pour vérifier l'intégrité et l'état du serveur de boîtes aux lettres en cluster.
La cmdlet Get-StorageGroupCopyStatus fournit des informations sur l'état de réplication actuel pour chaque groupe de stockage. Pour obtenir la procédure détaillée d'affichage de l'état des groupes de stockage dans un environnement de CCR, consultez la rubrique Procédure d'affichage de l'état d'une copie de réplication continue en cluster à l'aide d'Exchange Management Shell.
La cmdlet Get-ClusteredMailboxServerStatus fournit un état opérationnel de base pour le serveur de boîtes aux lettres en cluster. Pour plus d'informations sur l'obtention de l'état opérationnel de base pour un serveur de boîtes aux lettres en cluster, consultez la rubrique Procédure d'affichage de l'état d'un serveur de boîtes aux lettres en cluster.
La méthode recommandée pour vérifier que les deux nœuds sont capables de mettre le serveur de boîtes aux lettres en cluster en mode connexion consiste à utiliser la cmdlet Move-ClusteredMailboxServer pour déplacer le serveur de boîtes aux lettres en cluster vers chaque nœud.
Activation de plusieurs réseaux pour une activité de réplication continue
Dans la version de publication (RTM) d'Exchange 2007, toutes les activités de copie et d'amorçage de fichier journal ont lieu sur le réseau public. Dans Exchange 2007 SP1, tout réseau de clusters redondant configuré comme réseau mixte peut être activé pour une activité de réplication continue. Cette activité inclut un amorçage et réamorçage du groupe de stockage et un envoi de journal.
Dans Exchange 2007 SP1, seuls les réseaux de clusters désignés comme mixtes peuvent être activés pour la réplication continue. Un réseau mixte est tout réseau de clusters configuré pour un trafic de cluster (communication inter-noeud) et d'accès au client. Les réseaux de clusters configurés pour un accès au cluster mais pas pour un accès au client (parfois appelés réseaux privés) ne peuvent pas être activés pour la réplication continue.
La prise en charge de l'envoi de journal sur un réseau mixte est configurée à l'aide de la cmdlet Enable-ContinuousReplicationHostName. De même, cette fonctionnalité est désactivée à l'aide de la cmdlet Disable-ContinuousReplicationHostName. Quand un serveur de boîtes aux lettres en cluster existe dans un environnement de réplication continue en cluster, un administrateur peut exécuter la cmdlet Enable-ContinuousReplicationHostName sur les deux nœuds du cluster et spécifier deux adresses IP et noms d'hôte. Une fois cette opération effectuée, le système sélectionne de façon aléatoire un réseau mixte pour la copie de journal après la réussite de la configuration et après vérification du caractère opérationnel du réseau mixte.
Pour obtenir la procédure détaillée d'activation des réseaux de clusters pour une activité de réplication continue, consultez la rubrique Procédure d'activation de réseaux de clusters redondants pour l'amorçage et l'envoi de journaux sous Windows Server 2003.
Notes
Outre le nom d'hôte, l'adresse IP et le groupe de clusters créés sur le cluster de basculement, chaque fois que vous exécutez la cmdlet Enable-ContinuousReplicationHostName, vous créez un compte d'ordinateur dans le domaine Active Directory contenant le serveur de boîtes aux lettres en cluster. Par défaut, dans Windows Server 2003, le nombre maximal de comptes d'ordinateur que peut ajouter un utilisateur auquel n'ont pas été délégués de privilèges d'administrateur de domaine ni octroyées les entrées de contrôle d'accès (ACE) « Création d'objets ordinateur » et « Suppression d'objets ordinateur », est 10. Un administrateur Exchange exécutant fréquemment les cmdlets Enable-ContinuousReplicationHostName et Disable-ContinuousReplicationHostName et ne disposant pas de privilèges d'administrateur de domaine ou des ACE précitées pourrait atteindre rapidement la limite de 10. Il existe plusieurs solutions à ce problème décrites dans l'article 307532 de la Base de connaissances, Comment faire pour dépanner le compte de service de cluster lorsqu'il modifie des objets ordinateur. Des informations supplémentaires sont disponibles dans l'article 251335 de la Base de connaissances, Les utilisateurs d'un domaine ne peuvent pas joindre une station de travail ou un serveur à un domaine.
L'amorçage et le réamorçage dans un environnement de CCR s'effectue à l'aide de la cmdlet Update-StorageGroupCopy. Dans Exchange 2007 SP1, cette cmdlet a été étendue pour inclure un nouveau paramètre nommé DataHostNames. Ce paramètre est utilisé pour spécifier le réseau à utiliser pour l'amorçage et le réamorçage. La valeur est une liste de plusieurs valeurs de deux noms : soit un nom de domaine complet (FQDN), soit un nom d'hôte. L'un de ces noms doit identifier un noeud passif.