Présentation de la réplication de dossier public

S'applique à : Exchange Server 2010

Dernière rubrique modifiée : 2009-12-07

Une réplication de dossier public est le processus consistant à répliquer un contenu de dossier public et la hiérarchie de dossiers publics sur plusieurs serveurs à des fins d’efficacité et de tolérance de panne. Lorsque plusieurs bases de données de dossiers publics situées sur des serveurs distincts prennent en charge une arborescence de dossiers publics unique, Microsoft Exchange utilise la réplication des dossiers publics pour maintenir la synchronisation des bases de données. Le contenu des dossiers publics n’existe que dans les banques Exchange configurées pour avoir un réplica d’un dossier spécifique. Les informations de contenu et de hiérarchie sont répliquées séparément. Chaque base de données de dossiers publics conserve une copie de la hiérarchie, qui contient les listes des autres bases de données de dossiers publics conservant les réplicas de contenu de chaque dossier. Les réplicas de contenu n’existent que sur les bases de données de dossiers publics que vous spécifiez. Pour plus d’informations sur la configuration de la réplication de dossier public, consultez la rubrique Configurer une réplication de dossiers publics.

Remarque :

Contrairement à Exchange Server 2007, vous ne pouvez pas utiliser la réplication continue dans Exchange Server 2010 pour répliquer les dossiers publics. Dans Exchange 2010, la réplication continue est uniquement pour les bases de données de boîtes aux lettres. Une base de données de dossiers publics peut être hébergée sur un serveur de boîtes aux lettres dans un groupe de disponibilité de base de données (DAG), mais vous devez utiliser plusieurs bases de données de dossiers publics et la réplication des dossiers publics pour la redondance des données.

Les bases de données de dossiers publics répliquent deux types d’informations de dossiers publics :

• Hiérarchie   Une réplication de hiérarchie se produit lorsque les propriétés des dossiers et les informations d’organisation sur les dossiers ont été modifiées. Toutes les bases de données de dossiers publics contiennent une copie des informations de hiérarchie. La modification des informations de dossiers publics suivantes entraîne une réplication de hiérarchie :

  • Nom du dossier
  • Liste de réplicas
  • Position du dossier dans l’arborescence de dossiers publics (avec ses dossiers parents et enfants éventuels)
  • Autorisations

    Remarque :
    Aucune réplication de hiérarchie n’a lieu si vous modifiez les adresses de messagerie d’un dossier public à extension messagerie. Les adresses de messagerie sont stockées sur l’objet annuaire dans Active Directory. Une réplication de hiérarchie n’a lieu que suite à la modification des propriétés de la base de données de dossiers publics.

• Contenu   Une réplication de contenu a lieu lors de l’envoi de messages à des dossiers publics ou lors de l’ajout de données. Par exemple, l’envoi de messages électroniques à un dossier public à extension messagerie ou l’ajout d’un formulaire d’organisation à un dossier public entraîne une réplication de contenu. Pour répliquer du contenu, vous devez configurer un dossier de sorte qu’il réplique son contenu dans une base de données de dossiers publics ou une liste de bases de données déterminée. Seules les bases de données spécifiées auront des copies du contenu. La copie du dossier qui inclut le contenu est appelée réplica de contenu.

Contenu de cette rubrique

Fonctionnement de la réplication de dossier public

Messages de réplication

Demandes de renvoi et messages de renvoi

Exemples de cycles de réplication

Meilleures pratiques pour l’implémentation d’une réplication

Souhaitez-vous rechercher les tâches de gestion relatives aux dossiers publics ? Voir Gestion des dossiers publics.

Fonctionnement de la réplication de dossier public

Lorsque vous modifiez un dossier public ou son contenu, la base de données de dossiers publics contenant son réplica envoie un message électronique descriptif aux autres bases de données de dossiers publics hébergeant un réplica du dossier public. Pour réduire le trafic sur le réseau, Exchange inclut des informations sur plusieurs modifications dans un seul message électronique. La quantité d’informations incluses dans ces messages dépend de la limite de taille que vous définissez pour les messages de réplication. Si un message dépasse la limite de taille spécifiée, celui-ci est envoyé comme message de réplication séparé. Exchange route ces messages de réplication de la même manière que les autres messages électroniques.

Si les modifications apportées à la hiérarchie de dossiers publics affectent plusieurs dossiers, il se peut que le processus de réplication exige une quantité de bande passante réseau considérable. Par exemple, pour déplacer des dossiers publics d’un serveur vers un autre, vous devez créer des réplicas sur le serveur vers lequel vous voulez déplacer les dossiers publics, attendre la réplication des changements de hiérarchie sur le serveur d’origine, puis la réplication du contenu sur les nouveaux réplicas. Une fois les réplicas synchronisés, vous devez supprimer les réplicas de l’ancien serveur. Même la suppression des réplicas de l’ancien serveur génère du trafic réseau parce que la suppression de réplicas doit être répliquée comme une modification de hiérarchie. Pour plus d’informations sur la manière dont ces modifications apportées à la hiérarchie de dossiers publics peuvent affecter votre système, consultez la section « Demandes d’état et messages d’état » plus loin dans cette rubrique.

Processus de réplication de contenu et de hiérarchie de base

La figure suivante et le texte explicatif qui suit décrivent le processus de base par lequel une hiérarchie de dossiers publics et un contenu de dossier public sont répliqués.

Processus de réplication de base

Les détails du processus sont les suivants :

1. Un utilisateur modifie le dossier public.
2. La base de données de dossiers publics locale enregistre la modification.
3. Lors du cycle de réplication planifié suivant (déterminé par l’intervalle de réplication défini pour la base de données de dossiers publics), la base de données de dossiers publics vérifie les propriétés du dossier pour déterminer les autres serveurs qui contiennent un réplica de ce dossier. S’il existe d’autres réplicas, la base de données détermine les informations à répliquer vers ces réplicas. Ces informations deviennent la mise à jour des réplicas.
   La réplication de dossiers publics est basée sur les objets. Si une propriété d’un objet est modifiée, l’objet entier doit être répliqué. Comme la base de données qui réplique la modification ne peut pas supposer que tous les réplicas de destination sont à jour, elle doit répliquer l’objet entier. Les implications pour les différents types de réplications sont les suivantes :
   • Réplication de hiérarchie   La réplication de nouveaux changements de hiérarchie intervient lors de la création ou de la suppression d’un dossier public, ou lors de la modification des propriétés d’un dossier public (telle qu’une modification de la liste de réplicas, d’autorisations de client, d’une description, d’une note administrative ou de limites de stockage).
   • Réplication de contenu   Si un nouveau message est publié ou si un message existant est modifié, la mise à jour concerne l’ensemble du message et de ses propriétés.
4. La base de données de dossiers publics attribue un numéro de modification à la mise à jour.
   Lorsqu’un dossier réplique une mise à jour vers un autre serveur, le numéro de modification est compris dans la mise à jour. Le serveur de réception utilise ensuite le numéro de modification pour déterminer si la mise à jour représente une nouvelle modification et si des données sont manquantes.
5. La base de données de dossiers publics rassemble les mises à jour dans un message de réplication. Les numéros de modification de toutes les mises à jour du message sont appelées jeux de numéros de modification (CNSet*)*.
   Outre les mises à jour, la base de données de dossiers publics rassemble des informations à partir des entrées du dossier dans la table des états de réplication, notamment les CNSets appliqués précédemment au réplica. Pour plus d’informations sur la table des états de réplication, consultez la section « Table des états de réplication » plus loin dans cette rubrique.
6. Pour réduire le trafic des messages, la base de données de dossiers publics rassemble plusieurs mises à jour de hiérarchie dans un seul message de réplication. De la même manière, la base de données rassemble plusieurs mises à jour de contenu du même dossier dans un seul message de réplication. Toutefois, la base de données ne peut pas rassembler les mises à jour de hiérarchie dans le même message de réplication que les mises à jour de contenu et chaque message de réplication de contenu comporte les mises à jour d’un seul dossier.
7. La base de données de dossiers publics envoie le message de réplication aux autres bases de données de dossiers publics qui hébergent les réplicas du dossier mis à jour. La base de données envoie le message ainsi que tous les autres messages rassemblés depuis le cycle de réplication précédent.
   Pour la remise des messages de réplication, la base de données de dossiers publics dépend des composants de routage internes d’Exchange. Elle ne tente pas de scinder les messages de réplication en fonction des informations de topologie. Si le contenu d’un dossier est modifié et si ce dernier possède cinq autres réplicas, la base de données génère un seul message de réplication qu’elle adresse aux cinq bases de données qui hébergent les réplicas. Les composants de routage déterminent le mode d’acheminement et de remise du message.
8. La base de données de dossiers publics reçoit le message de réplication.
9. La base de données de dossiers publics de destination dissocie les informations de mise à jour et d’état du message de réplication.
10. La base de données compare les numéros de modification des nouvelles mises à jour à la liste des numéros de modification déjà en sa possession, puis identifie les mises à jour non reçues précédemment.
11. La base de données applique les nouvelles mises à jour aux réplicas de dossier appropriés.
12. Pour chaque réplica mis à jour, la base de données met à jour la table des états de réplication avec les numéros de modification de la mise à jour actuelle ainsi que les informations d’état du dossier provenant du message de réplication.
    Si les informations de la table des états de réplication indiquent que d’autres CNSets ont été appliqués à d’autres réplicas du dossier mais pas aux réplicas de cette base de données, la base de données enregistre les CNSets manquants dans un emplacement appelé pile de renvoi et prépare l’envoi d’une demande de renvoi. Pour plus d’informations sur les demandes de renvoi, consultez la section « Demandes de renvoi et messages de renvoi » plus loin dans cette rubrique.

Retour au début

Messages de réplication

Le processus de réplication utilise les attributs Active Directory des bases de données de dossiers publics et non les attributs Active Directory de dossiers publics individuels. Les attributs Active Directory des dossiers publics individuels ne sont utilisés que pour envoyer des messages électroniques réguliers vers ou à partir des dossiers. Un objet base de données de dossiers publics est configuré et géré automatiquement et réside dans le conteneur Configuration d’Active Directory.

Les messages de réplication se distinguent des autres messages électroniques classiques dans la mesure où Exchange traite les messages de réplication en tant que messages système. Cela signifie que les restrictions appliquées aux messages électroniques des utilisateurs, notamment les restrictions de taille et de remise, ne s’appliquent pas aux messages de réplication.

Le tableau suivant répertorie les différents types de messages de réplication utilisés par Exchange.

Remarque :
Les valeurs indiquées entre parenthèses dans le tableau suivant sont la notation hexadécimale des types de message. Ces notations sont utilisées dans des événements et des journaux. Vous pouvez utiliser la valeur hexadécimale pour résoudre des problèmes de réplication.

Types de messages de réplication de dossiers publics et cas d’emploi

Type de message*	Cas d’emploi
Hiérarchie (0x2)	Réplique des modifications de hiérarchie à partir de la base de données de dossiers publics locale vers toutes les autres bases de données de dossiers publics qui prennent en charge la même hiérarchie. Bien qu’Exchange ne gère pas les modifications de hiérarchie de la même façon que les modifications de réplicas de contenu, il considère la hiérarchie comme un autre dossier. Dans certains messages d’événements et d’autres opérations, Exchange fait référence à la hiérarchie sous la forme Dossier 1-1.
Contenu (0x4)	Réplique les modifications de contenu d’un réplica vers tous les réplicas de contenu de ce dossier. Un message de contenu ne contient que les informations qui s’appliquent à un seul dossier.
Demande de renvoi (0x8)	Demande des données manquantes dans des CNSets d’autres bases de données. Ceci inclut une hiérarchie et des numéros de modification de contenu.
Réponse de renvoi (0x80000002 ou 0x80000004)	Envoie des données manquantes dans des CNSets à une base de données qui a demandé des mises à jour manquées.
État (0x10)	Envoie les CNSets actuels d’un dossier vers un ou plusieurs autres réplicas de ce dossier. Ceci inclut une hiérarchie et des numéros de modification de contenu.
Demande d’état (0x20)	Demande la réplication de CNSets ou le renvoi de messages d’état. Ceci inclut une hiérarchie et des numéros de modification de contenu.

Table des états de réplication

Chaque base de données de dossiers publics gère une table des états de réplication pour assurer le suivi de l’état de chaque réplica dans la base de données. La table des états de réplication stocke les informations suivantes :

• informations de base requises pour construire des mises à jour de chaque réplica ;
• informations sur la dernière mise à jour de chaque réplica provenant de la base de données locale, notamment le numéro de modification de la mise à jour ;
• groupes de mises à jour appliqués à tous les autres réplicas connus du dossier. Des numéros de modification permettent d’identifier les mises à jour de chaque groupe. L’ensemble des numéros de modification de toutes les mises à jour d’un groupe s’appelle un CNSet. Des informations de mise à jour sont transmises d’une base de données à une autre dans le cadre du processus de réplication.

Les tableaux suivants fournissent un exemple du fonctionnement des tables des états de réplication. Dans cet exemple, les bases de données de dossiers publics situées sur le serveur A et le serveur B disposent de réplicas d’un dossier nommé Projets. Sur chaque serveur, la table des états de réplication suit non seulement l’état du réplica situé sur ce serveur, mais également celui du réplica situé sur l’autre serveur. Grâce à ces informations, le serveur A détermine si son réplica du dossier Projets est synchronisé avec le réplica du dossier Projets situé sur le serveur B. De même, le serveur B peut également suivre l’état de son réplica par rapport à celui du serveur A.

Exemples de données provenant de la table des états de réplication du serveur A

Réplica	Données
Dossier Projets sur le serveur A (réplica local)	Dernière mise à jour envoyée : A-100
Dossier Projets sur le serveur B	Mise à jour de A-100 reçue Mise à jour de B-50 reçue

Exemples de données provenant de la table des états de réplication du serveur B

Réplica	Données
Dossier Projets sur le serveur A	Mise à jour de A-100 reçue Mise à jour de B-50 reçue
Dossier Projets sur le serveur B (réplica local)	Dernière mise à jour envoyée : B-50

En combinant les listes de bases de données de dossiers publics contenant les réplicas de contenu avec les informations de la table des états de réplication, chaque base de données de dossiers publics peut déterminer son état de mise à jour par rapport aux autres bases de données de dossiers publics qui prennent en charge l’arborescence de dossiers publics.

Retour au début

Demandes de renvoi et messages de renvoi

Le renvoi se produit lorsqu’une base de données de dossiers publics détermine qu’elle n’a pas reçu toutes les mises à jour pour un dossier répliqué, ou pour la hiérarchie, et doit récupérer les mises à jour manquantes d’une autre base de données de dossiers publics.

Pour optimiser le processus de renvoi, Exchange stocke les informations sur les mises à jour manquantes dans la pile de renvoi.

Les événements suivants peuvent avertir une base de données de dossiers publics que des mises à jours sont manquantes et doivent être renvoyées :

• Les informations d’état contenues dans un message de réplication entrant indiquent que le réplica situé dans la base de données de dossiers publics à l’origine du message possède des mises à jour manquantes dans la base de données de réception. La base de données de réception identifie les numéros de modification manquants et les stocke dans sa pile de renvoi.
• Une base de données de dossiers publics démarre pour la première fois. La nouvelle base de données envoie des demandes d’état pour obtenir des informations sur les autres bases de données de la hiérarchie. Une fois les messages d’état correspondants arrivés, la base de données remplit sa table des états de réplication et, au besoin, la pile de renvoi. Cette dernière peut contenir des entrées pour la hiérarchie et tous les réplicas de contenu que la base de données doit héberger.
• Un message de hiérarchie entrant indique qu’un nouveau réplica de contenu doit être placé dans la base de données de dossiers publics. La nouvelle base de données envoie des demandes d’état pour obtenir des informations sur le contenu éventuellement disponible de ce réplica dans les autres bases de données de la hiérarchie. Une fois les messages d’état correspondants arrivés, la base de données remplit la table des états de réplication et, au besoin, la pile de renvoi.

Le tableau de renvoi stocke ces informations pendant une période spécifiée (appelée délai de renvoi). Si les mises à jour manquantes arrivent dans des messages de réplication ultérieurs pendant ce laps de temps, elles sont supprimées du tableau de renvoi. Le tableau suivant répertorie les valeurs de délai de renvoi par défaut, qui dépendent de l’emplacement des mises à jour manquantes et de leur éventuelle demande précédente.

Délais par défaut utilisés pour les demandes de renvoi

Type de demande	il y a du contenu dans une base de données du site Active Directory local ;	il y a du contenu dans une base de données du site Active Directory distant.
Renvoi initial	6 heures	12 heures
Première tentative de renvoi	12 heures	24 heures
Tentatives de renvoi suivantes	24 heures	48 heures

Si le délai de renvoi expire et si les mises à jour sont toujours manquantes, Exchange crée une ou plusieurs demandes de renvoi, puis détermine quels sont les serveurs à utiliser comme sources de renvoi.

Pour sélectionner les serveurs à utiliser comme source de renvoi, Exchange crée d’abord une liste de tous les serveurs possédant des réplicas du dossier, puis trie cette liste en fonction de la séquence de critères ci-dessous :

1. Tri d’après l’état du serveur. Les serveurs qui sont arrêtés ou indisponibles sont placés à la fin de la liste.
2. Tri en fonction du serveur de renvoi préféré (éventuel). Exchange vérifie l’objet base de données de dossiers publics dans Active Directory pour identifier un serveur de renvoi préféré. Ce paramètre est rarement utilisé. Dans la plupart des cas, le processus de renvoi est plus efficace si Exchange sélectionne automatiquement un serveur de renvoi. La plupart des déploiements d’Exchange n’ont pas besoin d’un serveur de renvoi préféré. Les services de support technique de Microsoft peuvent fournir un script qui définit un serveur de renvoi préféré si votre déploiement le nécessite.
3. Tri d’après le coût de transport (du plus faible au plus élevé). Les serveurs d’un même groupe de routage sont prioritaires par rapport aux serveurs de sites Active Directory distants.
4. Tri d’après la version d’Exchange (de la plus récente à la plus ancienne).
5. Tri d’après le nombre de modifications nécessaires qui sont disponibles sur le serveur (du plus grand au plus petit). Les serveurs qui n’ont aucune des modifications manquantes sont supprimés de la liste.

Si un serveur ne possède pas toutes les modifications requises, Exchange sélectionne le serveur suivant dans la liste triée, puis envoie également une demande de renvoi à ce serveur. Ce processus est répété jusqu’à ce que toutes les modifications aient été demandées.

Si le serveur sélectionné ne répond pas à la demande de renvoi, la base de données le signale comme étant indisponible, puis recommence le processus de sélection. Les serveurs marqués comme indisponibles sont placés à la fin de la liste.

Demandes d’état et messages d’état

Outre les informations d’état contenues dans chaque message de réplication, Exchange utilise des demandes et des messages d’état pour déterminer si des dossiers publics doivent envoyer des demandes de renvoi.

Une base de données de dossiers publics envoie une demande d’état dans les cas suivants :

• La base de données est informée d’une modification de la liste des bases de données qui contiennent des réplicas d’un dossier. Par exemple, si vous ajoutez une base de données à la liste ou supprimez une base de données de la liste, Exchange réplique cette modification à l’aide de messages de mise à jour de hiérarchie. Dans ce cas, la base de données envoie une demande d’état qui oblige toutes les bases de données contenant un réplica du dossier à répondre.
• Une nouvelle base de données a démarré pour la première fois. Dans ce cas, la base de données demande l’état de la hiérarchie de dossiers publics. La base de données envoie une demande d’état qui oblige toutes les bases de données prenant en charge l’arborescence des dossiers publics à répondre.
• Une base de données restaurée à l’aide de l’utilitaire de sauvegarde Windows Server démarre pour la première fois après la fin de la restauration. Dans ce cas, la base de données demande l’état de la hiérarchie de dossiers publics et de tous les dossiers pour lesquels elle contient des réplicas de contenu. Cette demande d’état répertorie deux ou trois bases de données en tant que répondeurs requis. Les répondeurs requis sont des bases de données qui prennent en charge cette hiérarchie et qui sont, en fonction d’un processus de sélection interne, des sources fiables pour le contenu du dossier.

Pour indiquer l’état actuel d’un dossier particulier dans la base de données d’envoi, la base de données de dossiers publics envoie un message d’état à une autre base de données dans les circonstances suivantes :

• En réponse à une demande d’état envoyée par une autre base de données. Le message d’état n’est adressé qu’à la base de données à l’origine de la demande et uniquement si les conditions suivantes sont vraies :
  • La base de données qui a reçu la demande d’état figure dans la liste des répondeurs requis.
  • La table des états de réplication indique que la base de données ayant reçu la demande d’état dispose de mises à jour manquantes dans la base de données ayant envoyé la demande.
• Vingt-quatre heures après la réception de la mise à jour la plus récente d’un dossier, s’il n’y a aucune mise à jour ultérieure. Chaque fois que la base de données reçoit une mise à jour pour un dossier spécifique, l’horloge est réinitialisée à 24 heures. Ce message d’état est adressé aux autres bases de données de dossiers publics qui possèdent des réplicas du dossier mis à jour.

Si une base de données de dossiers publics reçoit un message qui indique que la base de données d’envoi contient des informations plus récentes sur le dossier, la base de données de réception crée une demande de renvoi. S’il s’avère que les numéros de modification sont identiques (ou que ceux du serveur de réception sont plus récents), aucune action n’est exécutée. Par exemple, lorsqu’une nouvelle base de données de dossiers publics s’exécute pour la première fois, elle envoie des messages de demande d’état à chaque base de données prenant en charge la hiérarchie de dossiers publics. Chaque base de données répond en envoyant des informations sur l’état de la hiérarchie (suivi effectué par cette base de données). La nouvelle base de données utilise ces informations pour identifier les réplicas (le cas échéant) qu’elle doit se procurer. Elle peut ensuite adresser les demandes de renvoi nécessaires pour remplir le contenu de réplicas.

Retour au début

Exemples de cycles de réplication

La figure suivante représente un scénario simplifié basé sur deux serveurs, qui illustre la séquence des événements déclenchés lorsque vous ajoutez un réplica de contenu à une base de données de dossiers publics. Cette action permet d’ajouter la base de données de dossiers publics à la liste des réplicas du dossier. Remarquez que la séquence des étapes dépend de facteurs tels que le moment des intervalles de réplication et la topologie du routage.

Séquence des événements lors de l’ajout d’un réplica à une base de données de dossiers publics

Les détails du processus sont les suivants :

1. En travaillant sur ServEx01, un administrateur ajoute ServEx01 à la liste de réplicas d’un dossier.
2. ServEx01 envoie un message de hiérarchie.
3. ServEx02 ajoute ServEx01 à la copie locale de la liste de réplicas du dossier.
4. ServEx01 envoie une demande d’état à ServEx02.
5. ServEx02 envoie un message d’état à ServEx01 qui comprend le CNSet complet du dossier.
6. ServEx01 détermine que l’ensemble du contenu du dossier est manquant et enregistre les entrées appropriées dans la pile de renvoi.
7. Si le contenu est toujours manquant lors de l’expiration du délai de renvoi, ServEx01 crée une demande de renvoi qu’il adresse à ServEx02.
8. ServEx02 compile les messages de contenu et les envoie à ServEx01.
9. ServEx01 utilise les messages de contenu entrants pour mettre à jour le contenu du dossier et les informations de suivi connexes.
10. Si des numéros de modification semblent encore être manquants, ServEx01 attend 24 heures, puis envoie une demande de renvoi mise à jour. Si un serveur autre que ServEx02 est disponible, ServEx01 peut envoyer la demande à ce serveur.

La figure suivante représente un scénario simplifié basé sur deux serveurs, qui illustre la séquence des événements déclenchés lorsque vous supprimez un réplica d’une base de données de dossiers publics. (Cette action permet de supprimer la base de données de dossiers publics de la liste des réplicas du dossier.) Notez que la séquence des étapes dépend de facteurs tels que le nombre de serveurs présents dans la topologie.

Séquence des événements lors de la suppression d’un réplica d’une base de données de dossiers publics

Les détails du processus sont les suivants :

1. En travaillant sur ServEx01, un administrateur supprime ServEx01 de la liste de réplicas d’un dossier.
2. ServEx01 marque son réplica (copie du dossier sur ServEx01) comme Suppression en attente.
   Les clients ne peuvent plus accéder au dossier à l’aide de cette base de données.
3. ServEx01 envoie un message de hiérarchie.
4. ServEx02 met à jour sa copie de la liste de réplicas du dossier pour indiquer que la suppression du dossier est suspendue sur ServEx01.
   ServEx02 ne renvoie plus à ServEx01 les clients qui recherchent ce dossier.
5. ServEx01 envoie une demande d’état à ServEx02.
6. ServEx02 envoie un message d’état à ServEx01. Si le réplica présent sur ServEx02 n’est pas à jour, ServEx02 place les entrées appropriées dans la pile de renvoi. Dans les cinq minutes qui suivent, ServEx02 envoie la demande de renvoi correspondante à ServEx01.
7. ServEx01 vérifie que le réplica du dossier sur ServEx02 contient toutes les informations du réplica dont la suppression est suspendue. Si ce n’est pas le cas, ServEx01 envoie les mises à jour de contenu appropriées et revient à l’étape 5. Sinon, ServEx01 passe à l’étape 8.
   Ce processus permet de s’assurer que tant que d’autres réplicas existent, la suppression de l’un d’entre eux ne risque pas d’entraîner une perte de contenu.
8. ServEx01 marque son réplica comme élément à supprimer maintenant. Le cycle de maintenance suivant supprime le réplica de ServEx01.
9. ServEx01 envoie un message de hiérarchie.
10. ServEx02 supprime ServEx01 de sa copie de la liste de réplicas du dossier.

Retour au début

Meilleures pratiques pour l’implémentation d’une réplication

La réplication de dossier public dans Exchange peut être une opération consommant une quantité importante de ressources. La réplication sollicite le réseau, le processeur et les ressources de disque. En mettant en œuvre une solution qui permet une réplication efficace des dossiers publics, en particulier au sein d’organisations faisant un usage intensif des dossiers publics, vous pouvez améliorer sensiblement la charge du réseau, du processeur et du disque dans votre organisation Exchange.

Il est généralement recommandé de réduire la réplication au sein de l’organisation. En réduisant la réplication, vous minimisez la quantité de données transmise sur votre réseau. En outre, en réduisant la réplication, il est moins probable que plusieurs utilisateurs puissent accéder à des versions différentes de données sur plusieurs réplicas. Vous devez toutefois noter qu’en réduisant la réplication, vous diminuez la disponibilité des données de dossiers publics parce que moins de réplicas du dossier sont disponibles pour les clients en cas d’échec d’une base de données de dossiers publics. Si la disponibilité sur une grande échelle est requise pour des données dans un dossier public spécifique, plusieurs réplications peuvent être nécessaires.

Retour au début