Présentation des dossiers publics

 

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

Dernière rubrique modifiée : 2016-11-28

Les dossiers publics, introduits dans la première version de Microsoft Exchange, sont conçus pour un accès partagé et offrir une manière simple et efficace de collecter, organiser et partager des informations avec d'autres personnes dans votre groupe de travail ou votre organisation. Les dossiers publics sont organisés de façon hiérarchique, stockés dans des bases de données dédiées et peuvent être répliqués entre des serveurs exécutant Exchange.

Les dossiers publics ne sont pas conçus aux fins suivantes :

  • Archivage de données   Les dossiers publics ne sont pas conçus pour l'archivage de données. Les utilisateurs auxquels des limites de taille de boîte aux lettres sont affectées utilisent parfois les dossiers publics plutôt que les fichiers (.pst) de leurs dossiers personnels pour archiver des données. Cette pratique est déconseillée car elle affecte le stockage sur les serveurs de dossiers publics et va à l'encontre de l'objectif des limites de boîtes aux lettres.

  • Partage de documents et collaboration   Les dossiers publics ne sont pas conçus pour le partage de documents et la collaboration. Les dossiers publics n'intègrent pas de fonction de contrôle de version ou d'autres fonctions de gestion des documents, telles que la fonctionnalité d'archivage et d'extraction, et les notifications automatiques de modification du contenu.

Dans Exchange Server 2010, les dossiers publics constituent une fonctionnalité facultative. Si tous les ordinateurs clients de votre organisation exécutent Microsoft Outlook 2010 ou Office Outlook 2007, les fonctionnalités telles que les informations de disponibilité et les téléchargements de carnets d’adresses en mode hors connexion ne sont pas tributaires des dossiers publics. Pour les téléchargements de carnets d’adresses en mode hors connexion et les informations de disponibilité, Exchange 2010 n’utilise pas les dossiers publics : ces fonctionnalités sont gérées par le service de découverte automatique, le service de surveillance du système de Microsoft Exchange et le service de distribution de fichiers de Microsoft Exchange.

Tant que tous les ordinateurs clients de votre organisation exécutent Outlook 2010 ou Outlook 2007, vous devez continuer à utiliser les dossiers publics.

Contenu de cette rubrique

  • Création de base de données de dossiers publics en cours d'installation

  • Arborescences de dossiers publics

  • Réplication des dossiers publics

  • Redirections de dossiers publics

  • Dossiers publics à extension messagerie

  • Accès aux dossiers publics

  • Considérations relatives aux organisations mixtes Exchange 2010 et Exchange 2007

  • Considérations relatives aux organisations mixtes Exchange 2010 et Exchange 2003

  • Mise à jour de la hiérarchie de dossiers publics

  • Réplication du contenu des dossiers publics

  • Meilleures pratiques

Création de base de données de dossiers publics en cours d'installation

Les ordinateurs exécutant Outlook 2003 et des versions antérieures ou Microsoft Entourage nécessitent une base de données de dossiers publics (précédemment appelée banque de dossiers publics) pour la connexion à Exchange. Par conséquent, dans une organisation Exchange 2010 pure, lorsque vous installez le rôle serveur de boîte aux lettres sur le premier serveur, le programme d’installation vous pose la question suivante : Votre organisation comporte-t-elle des ordinateurs clients exécutant Outlook 2003 ou une version antérieure ou Entourage ? Si la réponse est oui, une base de données de dossiers publics est créée. Si la réponse est non, aucune base de données de dossiers publics n'est créée.

Lorsque vous installez le deuxième serveur, vous n'êtes pas invité à répondre à la question, et le programme d'installation ne crée pas de base de données de dossiers publics. La nécessité de disposer d'une base de données de dossiers publics dans l'organisation n'est tranchée que lorsque vous installez le premier serveur. Ensuite, toutes les bases de données de dossiers publics sont facultatives. Si vous ne créez pas de base de données de dossiers publics durant l'installation, vous aurez toujours la possibilité d'en créer une une fois l'installation terminée. Pour plus d'informations sur la création d'une base de données de dossiers publics, voir Créer une base de données de dossiers publics.

Dans un environnement Exchange mixte, le programme d'installation ne vous pose pas la question. Dans ce type d’organisation, pour garantir la compatibilité descendante avec les versions d’Exchange antérieures à Exchange Server 2007, une base de données de dossiers publics est créée par défaut. En particulier, du fait qu’Exchange 2010 est installé dans son propre groupe d’administration, cette base de données de dossiers publics prend en charge la fonctionnalité héritée de disponibilité de Schedule+.

Pour plus d'informations sur l'installation d'Exchange 2010, voir Déploiement d'Exchange 2010.

Création de base de données de dossiers publics en cours d'installation

Arborescences de dossiers publics

L'arborescence de dossiers MAPI comprendre les deux sous-arborescences suivantes :

  • Dossiers publics par défaut (également appelée IPM_Subtree)   Les utilisateurs peuvent accéder à ces dossiers directement à l'aide d'applications clientes telles qu'Outlook.

  • Dossiers publics système (également appelée Non_IPM_Subtree)   Les utilisateurs ne peuvent pas accéder directement à ces dossiers à l'aide de méthodes conventionnelles. Des applications clientes telles qu'Outlook utilisent ces dossiers pour stocker des informations comme des données de disponibilité, des carnets d'adresses en mode hors connexion et des formulaires d'organisation. D'autres dossiers système contiennent les informations de configuration utilisées par des applications personnalisées ou par Exchange. L'arborescence de dossiers publics contient des dossiers système supplémentaires, tels que le dossier EFORMS REGISTRY, qui n'existent pas dans les arborescences de dossiers publics générales. Les dossiers système sont les suivants :

    • EFORMS REGISTRY et Events Root   Par défaut, un réplica de contenu de chacun de ces dossiers réside dans la base de données de dossiers publics par défaut sur le premier serveur Exchange installé dans le premier groupe d'administration. Il s’agit de l’emplacement où se trouvent les formulaires d’organisation pour les clients hérités d’Outlook (clients qui utilisent une version d’Outlook antérieure à Outlook 2007).

    • Carnet d'adresses en mode hors connexion et Schedule+ Libre/Occupé.   Ces dossiers contiennent un sous-dossier pour chaque groupe administratif (ou site) dans votre topologie. Par défaut, un réplica de contenu d'un dossier de groupe d'administration réside sur le premier serveur installé dans le groupe d'administration. Ils sont utilisés pour stocker les informations de disponibilité et les données OAB pour les clients hérités d'Outlook. Les clients Outlook hérités ne prennent pas en charge les nouvelles fonctionnalités d’Exchange 2010 ou d’Exchange 2007 qui gèrent les informations de disponibilité et les données de carnet d’adresses en mode hors connexion. (Ces fonctionnalités comprennent le service de disponibilité, le service de découverte automatique et la distribution de carnet d'adresses en mode hors connexion sur les serveurs d'accès au client.)

    • OWAScratchPad   Chaque base de données de dossiers publics possède un dossier OWAScratchPad qui permet de stocker temporairement les pièces jointes accessibles à l’aide de Microsoft OfficeOutlook Web App. Ne modifiez pas ce dossier.

    • StoreEvents   Chaque base de données de dossiers publics a un dossier StoreEvents qui contient des informations d’inscription associées aux événements de base de données Exchange personnalisés. Ne modifiez pas ce dossier.

    • Autres dossiers   Pour prendre en charge les opérations internes de base de données Exchange, une arborescence peut contenir plusieurs dossiers système, tels que schema-root. Ne modifiez pas ces dossiers.

Création de base de données de dossiers publics en cours d'installation

Réplication des dossiers publics

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

  • Hiérarchie   Les propriétés des dossiers et les informations d'organisation relatives aux dossiers (y compris la structure de l'arborescence). Toutes les bases de données de dossiers publics contiennent une copie des informations de hiérarchie. Pour un dossier spécifique, la base de données de dossiers publics peut utiliser les informations de hiérarchie pour identifier les éléments suivants :

    • les autorisations sur le dossier ;

    • les serveurs qui contiennent les réplicas de contenu du dossier ;

    • l'emplacement du dossier dans l'arborescence de dossiers publics (y compris l'emplacement de ses dossiers parent et enfant, le cas échéant).

  • Contenu   Messages qui forment le contenu des dossiers. 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.

RemarqueRemarque :
La réplication du contenu des dossiers publics n'est pas gérée par les groupes de disponibilité de base de données. Vous pouvez disposer de bases de données de dossiers publics sur des serveurs comportant des groupes de disponibilité de base de données ; cependant, les dossiers publics utiliseront leurs propres méthodes de réplication des dossiers publics en dehors du groupe de disponibilité de base de données.

Pour plus d'informations sur la réplication de dossiers publics, consultez la rubrique Présentation de la réplication de dossier public.

Création de base de données de dossiers publics en cours d'installation

Redirections de dossiers publics

Quand une application cliente telle Outlook, tente d’ouvrir un dossier public Exchange, le serveur Exchange détermine le réplica de dossier auquel l’application cliente doit accéder. Ce processus est appelé redirection de dossiers publics. Si un réplica du contenu demandé existe sur le serveur Exchange qui dessert la demande, l’application cliente accède au réplica local. Si le réplica ne se trouve pas sur le serveur local, Exchange tente de trouver un réplica dans le même site Active Directory. Vous pouvez modifier le flux du trafic d'utilisateur pour autoriser les redirections sur certains connecteurs en spécifiant une liste de serveurs de redirection et en affectant un coût de routage pour chaque serveur.

Pour plus d'informations sur les redirections de dossiers publics, voir Présentation des redirections de dossiers publics.

Création de base de données de dossiers publics en cours d'installation

Dossiers publics à extension messagerie

Le fait de doter un dossier public d'une extension messagerie apporte aux utilisateurs un niveau de fonctionnalité supplémentaire. Outre la possibilité de publier des messages dans le dossier, les utilisateurs peuvent échanger des messages électroniques avec le dossier. Si vous développez des applications personnalisées, vous pouvez utiliser cette fonctionnalité pour déplacer des messages ou des documents à l'intérieur ou à l'extérieur de dossiers publics.

Un dossier à extension messagerie est un dossier public doté d'une adresse de messagerie. Selon la manière dont le dossier est configuré, il peut figurer dans la liste d'adresses globale (LAG). Chaque dossier à extension messagerie a un objet dans Active Directory qui mémorise ses adresses de messagerie, le nom de sa liste d’adresses et d’autres attributs de messagerie.

Étant donné que les messages envoyés aux dossiers publics sont dirigés vers la base de données de dossiers publics et non vers une boîte aux lettres de la base de données de boîtes aux lettres, Exchange route les messages électroniques à l’aide d’une méthode légèrement différente de celle utilisée pour router les messages électroniques vers une boîte aux lettres traditionnelle.

Création de base de données de dossiers publics en cours d'installation

Accès aux dossiers publics

Dans Exchange 2010, les applications clientes répertoriées ci-dessous peuvent accéder aux dossiers publics :

  • Outlook 2010

  • Outlook 2007

  • Outlook 2003

Pour plus d'informations sur la création et la gestion de dossiers publics à l'aide d'Outlook 2007, voir Créer et partager un dossier public (cette page peut être en anglais).

Pour plus d’informations sur la création et la gestion de dossiers publics à l’aide d’Outlook 2003, visitez la page relative à l’utilisation de dossiers publics.

Création de base de données de dossiers publics en cours d'installation

Considérations relatives aux organisations mixtes Exchange 2010 et Exchange 2007

Dans une organisation mixte Exchange 2010 et Exchange 2007, vous devez gérer les dossiers publics et les bases de données de dossiers publics à partir d'Exchange 2010. Les serveurs Exchange 2007 ne reconnaissent pas les bases de données de dossiers publics Exchange 2010 en raison de modifications apportées au schéma Active Directory. Le tableau suivant décrit les comportements attendus lorsque vous effectuez certaines tâches de gestion des dossiers publics sur des serveurs Exchange 2007 et Exchange 2010.

Tâches Serveurs Exchange 2007 Serveurs Exchange 2010

Création d'une base de données de dossiers publics

Si votre organisation comprend des bases de données de boîtes aux lettres Exchange 2010 et que l'attribut msExchHomePublicDB n'est pas renseigné, le serveur Exchange 2007 ne peut pas mettre à jour le paramètre msExchHomePublicDB de la base de données de boîtes aux lettres Exchange 2010. Vous recevez un message d’erreur, mais la base de données de dossiers publics est créée.

Une fois que vous avez créé la base de données de dossiers publics, vous devez modifier la base de données de dossiers publics par défaut. Vous devez effectuer cette procédure à partir d'un serveur Exchange 2010. Pour plus d'informations, voir Modifier la base de données de dossiers publics par défaut en une base de données de boîtes aux lettres.

Fonctionne toujours.

Suppression de la base de données de dossiers publics par défaut

Si des bases de données de boîtes aux lettres pointent vers la base de données de dossiers publics que vous tentez de supprimer, vous recevez un message d'erreur indiquant que vous devez modifier la base de données de dossiers publics par défaut. Pour modifier la base de données de dossiers publics par défaut, effectuez les opérations suivantes :

  1. Sur un serveur Exchange 2010, modifiez la base de données de dossiers publics par défaut de la base de données de boîtes aux lettres. Pour plus d'informations, voir Modifier la base de données de dossiers publics par défaut en une base de données de boîtes aux lettres.

  2. Sur le serveur Exchange 2007, supprimez tous les réplicas de cette base de données de dossiers publics. Pour plus d'informations, voir Supprimer plusieurs dossiers publics à partir d'une base de données de dossiers publics.

  3. Sur le serveur Exchange 2007, supprimez la base de données de dossiers publics. Pour plus d’informations, consultez la rubrique Supprimer des bases de données de dossiers publics.

RemarqueRemarque :
Si la nouvelle base de données de dossiers publics par défaut vers laquelle pointent les bases de données de boîtes aux lettres est une base de données de dossiers publics Exchange 2010, consultez la tâche « Définition d'une base de données de dossiers publics Exchange 2010 comme base de données de dossiers publics par défaut d'une base de données de boîtes aux lettres Exchange 2007 » ci-après dans ce tableau.

Fonctionne sur les serveurs Exchange 2007 et Exchange 2010 à condition que la base de données de dossiers publics que vous tentez de supprimer ne soit définie par défaut pour aucune base de données de boîtes aux lettres.

Suppression de la dernière base de données de dossiers publics de l'organisation

S’il s’agit de la dernière base de données de dossiers publics Exchange 2007 de l’organisation, la cmdlet Remove-PublicFolderDatabase doit mettre à jour la propriété msExchFirstInstance sur la base de données de dossiers publics Exchange 2010 en définissant $true. Cette opération échoue, car la version de l’objet Exchange 2010 est supérieure.

Exécutez la cmdlet Remove-PublicFolderDatabase sur le serveur Exchange 2010.

Fonctionne sur les serveurs Exchange 2007 et Exchange 2010 à condition que la base de données de dossiers publics que vous tentez de supprimer ne soit définie par défaut pour aucune base de données de boîtes aux lettres.

Définition d'une base de données de dossiers publics Exchange 2010 comme base de données de dossiers publics par défaut d'une base de données de boîtes aux lettres Exchange 2007

La modification de la base de données de dossiers publics par défaut ne fonctionne pas sur un serveur Exchange 2007 si la base de données de boîtes aux lettres ou la base de données de dossiers publics est une base de données Exchange 2010.

Étant donné que les serveurs Exchange 2007 ne reconnaissent pas les bases de données de dossiers publics Exchange 2010, la cmdlet Set-MailboxDatabase doit être exécutée sur un serveur Exchange 2010.

Sur le serveur Exchange 2010, modifiez la base de données de dossiers publics par défaut de la base de données de boîtes aux lettres Exchange 2007. Pour plus d'informations, voir Modifier la base de données de dossiers publics par défaut en une base de données de boîtes aux lettres.

Fonctionne toujours et doit être utilisée pour modifier les bases de données de dossiers publics par défaut si votre base de données de dossiers publics et votre base de données de boîtes aux lettres sont associées avec des versions d'Exchange différentes.

Création de base de données de dossiers publics en cours d'installation

Considérations relatives aux organisations mixtes Exchange 2010 et Exchange 2003

Lorsque vous installez Exchange 2010 dans une organisation Exchange 2003, le programme d’installation crée automatiquement un groupe d'administration et un groupe de routage au sein de l’organisation Exchange 2003. Les serveurs Exchange 2010 ajoutés à votre organisation sont inclus dans les nouveaux groupes d’administration et de routage. Comme mentionné précédemment, le programme d’installation installe également une base de données de dossiers publics sur le premier serveur de boîtes aux lettres Exchange 2010. Dans cette base de données de dossiers publics, le programme d'installation crée un dossier de disponibilité pour le nouveau groupe d'administration. La propriété legacyExchangeDN pour les utilisateurs dont les boîtes aux lettres ont été créées sur un serveur Exchange 2010 (et non migrées à partir d’Exchange 2003) établit une correspondance avec le nom du groupe d’administration Exchange 2010, et donc avec le dossier de disponibilité. Par défaut, pour faciliter les recherches de disponibilité à partir d’Outlook 2003 et des utilisateurs de clients antérieurs dont les boîtes aux lettres résident sur un serveur Exchange 2003, les informations de disponibilité des utilisateurs du client sont publiées dans le dossier public de disponibilité.

Gestion

Dans une organisation mixte Exchange 2010, Exchange 2007 et Exchange 2003, vous pouvez utiliser le Gestionnaire système Exchange pour gérer les dossiers publics. Les scénarios suivants sont pris en charge :

  • Le Gestionnaire système Exchange ne soit se connecter à la base de données de dossiers publics Exchange 2003 qu’à des fins d'administration. À partir de là, les modifications sont répliquées sur Exchange 2010.

  • Dans un environnement Exchange 2010 pur ou dans une organisation mixte Exchange 2010 et Exchange 2007, vous ne pouvez pas réinstaller le Gestionnaire système Exchange pour gérer les dossiers publics. Vous devez utiliser l’environnement de ligne de commande Exchange Management Shell.

  • Lorsque vous vérifiez la réplication de la hiérarchie ou affichez la valeur de limite d’âge du réplica local d’un dossier, il est recommandé d’utiliser le Gestionnaire système Exchange pour les dossiers publics existant sur un serveur Exchange 2003, et d’utiliser l’environnement de ligne de commande pour les dossiers publics existant sur un serveur Exchange 2010 ou Exchange 2007.

Outlook Web App

Dans une organisation mixte Exchange 2010, Exchange 2007 et Exchange 2003, l’un des serveurs d’accès au client Exchange 2010 et Exchange 2007 possède un répertoire virtuel nommé /public. Vous disposez d'un accès complet aux dossiers publics à partir d'Outlook Web App sans qu'il soit nécessaire d'utiliser le répertoire virtuel /public.

ImportantImportant :
Les clients Exchange 2010 Outlook Web App ne peuvent pas afficher de dossiers publics se trouvant sur des serveurs Exchange 2003.

En outre, les fonctionnalités de dossier public suivantes sont disponibles dans Outlook Web App :

  • Accès complet aux dossiers publics des serveurs de boîtes aux lettres Exchange 2010 sans qu’il soit nécessaire de garder un serveur de boîtes aux lettres Exchange 2003 disponible pour l’accès aux dossiers publics à partir d’Outlook Web App

  • Capacités de recherche de dossier public

  • Prise en charge de WebPart

Création de base de données de dossiers publics en cours d'installation

Mise à jour de la hiérarchie de dossiers publics

Si vous constatez que la hiérarchie de dossiers publics d'un serveur diffère de celle des autres serveurs, vous pouvez synchroniser la hiérarchie. Dans Exchange 2003 Service Pack 2 (SP2), la commande Synchronize Hierarchy permettait de synchroniser la hiérarchie de dossiers publics d’un serveur Exchange 2003 avec les autres serveurs de l’organisation. Dans Exchange 2010, la cmdlet Update-PublicFolderHierarchy permet de synchroniser la hiérarchie de dossiers publics du serveur Exchange 2010 avec les autres serveurs de l’organisation.

RemarqueRemarque :
Vous ne pouvez pas exécuter la commande Synchronize Hierarchy sur un serveur Exchange 2010. De même, vous ne pouvez pas exécuter la cmdlet Update-PublicFolderHierarchy sur un serveur Exchange 2003. Toutefois, l'exécution de chacune de ces commandes permet de mettre à jour la hiérarchie de dossiers publics dans l'ensemble de l'organisation.

Pour plus d'informations, consultez la rubrique Mettre à jour une hiérarchie de dossiers publics.

Création de base de données de dossiers publics en cours d'installation

Réplication du contenu des dossiers publics

Pour arrêter les erreurs de réplication de contenu de dossier public dans votre organisation, vous pouvez suspendre la réplication de contenu de dossier public. La suspension de réplication vous permet de reconfigurer la hiérarchie de dossiers publics et les planifications de réplication.

Pour suspendre ou reprendre la réplication du contenu des dossiers publics dans une organisation mixte, sur un serveur Exchange 2010, exécutez la cmdlet Suspend-PublicFolderReplication ou Resume-PublicFolderReplication dans l’environnement de ligne de commande. Bien que vous exécutiez ces cmdlets sur un serveur Exchange 2010, elles suspendent ou reprennent la réplication du contenu des dossiers publics sur tous les serveurs de votre organisation mixte. Pour plus d'informations sur l'utilisation de l'environnement de ligne de commande pour suspendre ou reprendre la réplication du contenu des dossiers publics, consultez les rubriques suivantes :

Création de base de données de dossiers publics en cours d'installation

Meilleures pratiques

Cette section décrit les meilleures pratiques à prendre en considération lors de l’exécution des tâches suivantes relatives aux dossiers publics dans votre organisation Exchange :

  • Création des bases de données de dossiers publics

  • Création de la hiérarchie de dossiers publics

  • Exécution d'une maintenance nocturne

Création des bases de données de dossiers publics

Lorsque vous planifiez le nombre de bases de données de dossiers publics à créer dans votre organisation, tenez compte des meilleures pratiques suivantes :

  • Pour les topologies d'entreprise importantes au sein desquelles les dossiers publics sont utilisés de manière intensive, déployez des serveurs de dossiers publics dédiés. Cette pratique recommandée est répertoriée dans les meilleures pratiques généralement appliquées pour dédier des ressources du processeur et du disque à des fonctions serveur isolées.

  • Des bases de données de dossiers publics moins nombreuses mais de plus grande taille sont plus adaptées et plus faciles à gérer que des bases de données de dossiers publics plus petites et plus nombreuses. En réduisant le nombre de bases de données de dossiers publics, vous pouvez diminuer le temps nécessaire pour effectuer la sauvegarde et la restauration d'un grand nombre de bases de données peu volumineuses. Vous réduisez également la quantité de trafic de réplication d'arrière-plan. En outre la maintenance de moins de bases de données plus volumineuses en ligne est plus rapide que la maintenance de plusieurs bases de données plus petites en ligne. Qui plus est, il est plus facile de gérer un petit nombre de bases de données de dossiers publics en ce qui concerne l'application d'autorisations, l'accès au contenu et l'implémentation d'une réplication et de redirections efficaces.

    La meilleure pratique consistant à avoir des bases de données de dossiers publics en moindre nombre mais de plus grande taille est particulièrement utile lorsque vous considérez votre topologie au niveau l'organisation. Toutefois, au niveau du serveur, certaines tâches de gestion et de maintenance, telles que les processus de sauvegarde et de restauration, peuvent être exécutées plus rapidement si vous disposez de plusieurs bases de données de plus petite taille. Le nombre de bases de données de dossiers publics que vous déployez doit finalement résoudre vos besoins d'entreprise. Comme vous déterminez le nombre de bases de données que vous souhaitez déployer, vous devez régler le coût de trafic de réplication aux coûts de maintenance de sauvegarde de base de données et restaurer des heures.

Conception de la hiérarchie de dossiers publics

Lorsque vous créez votre hiérarchie de dossiers publics, vous devez reconnaître l'effet de réplication de hiérarchie dans votre environnement. Les hiérarchies de dossiers publics présentent une meilleure évolutivité que les hiérarchies larges. Une hiérarchie profonde se compose de nombreux dossiers imbriqués verticalement, et non de nombreux dossiers de niveau supérieur. Une hiérarchie large se compose de nombreux dossiers de niveau supérieur avec peu de sous-dossiers imbriqués verticalement.

Par exemple, pensez à la manière dont 250 dossiers peuvent être organisés dans une hiérarchie spécifique. Une hiérarchie large peut contenir 250 sous-dossiers directs sous un dossier parent. Une hiérarchie profonde peut comporter cinq dossiers de niveau supérieur, chacun possédant cinq sous-dossiers directs. Chaque sous-dossier peut comporter dix sous-dossiers.

Il y a 250 dossiers (5 × 5 × 10 = 250) dans ces deux exemples. Toutefois, la hiérarchie profonde offre des performances supérieures à la hiérarchie large pour les raisons suivantes :

  • La manière dont la réplication gère les dossiers auxquels des autorisations différentes sont appliquées est plus efficace dans les hiérarchies profondes.

  • Les actions des ordinateurs clients (tri, recherche et développement) effectuées pour un dossier comportant dix sous-dossiers sont beaucoup moins coûteuses que pour un dossier comportant 250 sous-dossiers.

Bien que les hiérarchies profondes présentent une meilleure évolutivité que les hiérarchies larges, il est recommandé de ne pas dépasser 250 sous-dossiers par dossier. Dans le cas contraire, il est probable que l'expérience des clients sera affectée négativement lorsqu'un ordinateur client sollicite l'accès.

Lors de l'implémentation d'une hiérarchie, vous devez prendre en compte l'incidence des autorisations sur les utilisateurs lorsque ces derniers veulent accéder à des dossiers publics. Lorsque chaque sous-dossier de dossier public a ses propres entrées de liste de contrôle d’accès (ACL) définies, chaque fois que le serveur Exchange reçoit un nouveau message de réplication de dossiers publics, l’ACL du dossier public parent doit être évalué pour identifier les utilisateurs autorisés à afficher les modifications apportées au dossier public parent. Si le dossier public parent contient une entrée de liste de contrôle d'accès discrétionnaire (DACL) volumineuse, la mise à jour de la vue de chaque abonné de dossiers publics peut prendre un certain temps.

RemarqueRemarque :
La liste de contrôle d’accès discrétionnaire (DACL,Discretionary Access Control List) du dossier parent est constituée de la somme des DACL de tous les sous-dossiers de dossier public.

Vous pouvez disposer de plusieurs mégaoctets (Mo) de données DACL à analyser lorsque les conditions suivantes sont remplies :

  • Un dossier public parent comporte de nombreux sous-dossiers.

  • Sa propre liste de contrôle d'accès est définie pour chacun des sous-dossiers.

Cette donnée DACL doit être distribuée permet la mise à jour de l'affichage pour tous les abonnés de dossiers publics chaque heure de réception d'un message de réplication de dossiers publics.

Par conséquent, il est recommandé d'organiser votre hiérarchie de dossiers publics en fonction des ensembles d'utilisateurs autorisés à accéder aux dossiers parents. Par ailleurs, n'implémentez pas de modèles d'autorisation complexes dans vos hiérarchies de dossiers publics.

Exécution d'une maintenance nocturne

Pour vous assurer que vos bases de données continuent à fonctionner efficacement, il est recommandé d'effectuer une maintenance nocturne des bases de données de boîtes aux lettres et des bases de données de dossiers publics. Les serveurs de boîtes aux lettres Exchange automatisent les tâches en fonction de la planification que vous définissez.

Création de base de données de dossiers publics en cours d'installation

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