Concevoir l’architecture logique des sites de collaboration

Mise à jour : 2009-04-23

Dans cet article :

  • À propos des sites d’équipes dans un environnement intranet

  • Recommandations pour la conception des sites d’équipes

  • Héberger des sites d’équipes dans une application Web dédiée

  • Planifier les paramètres généraux de l’application Web

  • Déterminer s’il faut permettre aux utilisateurs de créer des collections de sites

  • Concevoir des paramètres de base de données de contenu pour les sites d’équipes

  • Supprimer automatiquement les sites inutilisés

  • Utiliser des chemins d’accès pour organiser les URL des sites d’équipes

  • Planifier les éléments personnalisés

  • Planifier les autorisations à appliquer aux sites d’équipes

Dans Microsoft Office SharePoint Portal Server 2003, les sites d’équipes disposaient de fonctionnalités limitées par rapport aux sites portail. Cela n’est pas le cas dans Microsoft Office SharePoint Server 2007. Dans Office SharePoint Server 2007, les sites de collaboration au sein d’un environnement intranet peuvent tirer parti des mêmes fonctionnalités qu’un site portail Intranet publié, sous réserve que les fonctionnalités soient disponibles dans l’environnement intranet. Dans le cadre de cet article, nous désignerons ces sites par l’ancien terme « Sites d’équipes ». Toutefois, gardez à l’esprit que ces sites ne sont pas aussi limités que dans la version précédente du point de vue des fonctionnalités qu’ils peuvent offrir. En fait, le terme « Sites d’équipes » implique que ces sites sont utilisés en groupes plus petits ou pour une collaboration plus appropriée, à la différence d’un site portail Intranet publié et contrôlé.

Les sites d’équipes sont une composante essentielle de la majorité des déploiements d’Office SharePoint Server 2007 et sont particulièrement importants pour les déploiements intranet. La collaboration que les sites d’équipes permettent et l’espace de stockage qu’ils offrent sont utiles pour les projets à long terme et à court terme, pour la communication et pour la collaboration entre les groupes. Si vous envisagez de proposer des sites d’équipes dans le cadre de votre déploiement, vous devez les inclure dans la conception initiale de l’architecture, afin de pouvoir planifier leur hébergement et leur gestion. Par exemple, vous devez planifier les bases de données de contenu nécessaires à l’hébergement du contenu des sites d’équipes, planifier l’archivage et la suppression des sites d’équipes des projets à court terme pour pouvoir accueillir davantage de projets et contrôler les sites de communication des équipes pour vous assurer que leur taille est facile à gérer dans le cadre d’opérations de sauvegarde et de récupération.

Cet article fournit des recommandations sur la conception de l’architecture logique en vue du déploiement de sites d’équipes dans une batterie de serveurs. Cet article ne traite pas de l’architecture des informations — autrement dit, de la structure interne — des sites d’équipes. Pour plus d’informations sur la conception de l’architecture des informations, voir Planifier la structure et la publication du site Web (Office SharePoint Server). Pour plus d’informations sur les sites d’équipes, voir Planifier les sites de collaboration.

À propos des sites d’équipes dans un environnement intranet

Dans un environnement intranet Office SharePoint Server 2007, vous pouvez connecter les sites d’équipes à votre site portail Intranet publié en les répertoriant dans l’annuaire de sites. Vous pouvez les créer par l’intermédiaire de l’annuaire de sites du site publié afin qu’ils partagent le même nom d’hôte, ou simplement ajouter des sites existants à l’annuaire de sites pour regrouper tous les sites d’équipe connexes au même endroit. Quelles que soient leurs URL, ils peuvent, de cette manière, apparaître comme faisant partie du portail intranet publié.

Étant donné que les sites d’équipes sont des sites SharePoint qui possèdent le même jeu de fonctionnalités que tous les sites publiés dans votre environnement, ils peuvent utiliser les dispositifs d’aide à la décision, les formulaires et les autres fonctionnalités disponibles dans votre environnement. Ces fonctionnalités peuvent influer sur l’architecture de vos sites d’équipes. Par exemple, si vous devez afficher des données métiers à partir du catalogue de données métiers dans un site d’équipe, vous devez vous assurer que ses membres sont en mesure d’afficher les données. Les fonctionnalités d’aide à la décision et la sécurité sont configurées au niveau du fournisseur de services partagés (SSP, Shared Services Provider), si bien que tous les sites d’équipes qui se connectent aux mêmes données métiers doivent utiliser le même fournisseur SSP et se trouver dans des applications Web qui lui sont associées.

Pour plus d’informations sur la planification de l’aide à la décision et des formulaires dans votre environnement, voir les ressources suivantes :

Recommandations pour la conception des sites d’équipes

Dans la plupart des organisations, le nombre de sites d’équipes et leur taille respective augmentent, parfois assez rapidement. La réorganisation des équipes, l’achèvement des projets ou le démarrage de nouveaux projets amènent les équipes à créer de nouveaux sites d’équipes et à abandonner les anciens ou à enrichir leurs sites d’équipes actuels pour qu’ils contiennent plus de données. Pour gérer ou contrôler cette croissance, vous devez soigneusement planifier la prise en charge des sites d’équipes.

Les objectifs conceptuels pour les sites d’équipes sont les suivants :

  • Optimisation des performances de l’ensemble de la batterie de serveurs

  • Création de divisions logiques des bases de données de sites d’équipes pour la maintenance régulière (autrement dit sauvegarde, récupération et mise à niveau)

  • Possibilité d’appliquer des stratégies et des paramètres appropriés aux sites d’équipes sans répercussion sur les autres types de sites de votre intranet

L’aide relative à la conception des sites d’équipes comprend les recommandations suivantes, chacune d’elles étant abordée en détail dans les sections suivantes :

  • Héberger les sites d’équipes dans une application Web dédiée

  • Appliquer des paramètres généraux aux applications Web, tels que des paramètres de quota et de gestion du cycle de vie au niveau de l’application Web pour gérer la croissance des sites d’équipes et maintenir leur contenu demeure à jour

  • Concevoir des paramètres de base de données de contenu conformes aux critères de stockage et d’échelle pour pouvoir sauvegarder et restaurer les bases de données de la taille conçue

  • Supprimer automatiquement les sites inutilisés

  • Utiliser des chemins d’accès pour organiser les URL des sites d’équipes

  • Planifier les stratégies et les autorisations appropriées

Héberger les sites d’équipes dans une application Web dédiée

Hébergez les sites d’équipes dans une application Web dédiée ou dans une application partagée avec les sites Mon site. Il est recommandé de ne pas héberger les sites d’équipes dans la même application Web que le site portail intranet publié. Le fait d’isoler les sites d’équipes du site portail Intranet facilite la récupération et la maintenance des données. (Si vous gérez la taille des bases de données de contenu, ce problème ne se pose pas.) L’illustration suivante montre l’application Web qui contient les sites d’équipes d’une solution intranet :

Architecture logique pour des sites de collaboration

Vous pouvez être amené à utiliser plusieurs applications Web dédiées pour l’hébergement de vos sites d’équipes. Prenons les exemples suivants :

  • Une société spécialisée dans les services bancaires d’investissement et les études des marchés actions aux États-Unis doit maintenir le site de la division des services bancaires d’investissement complètement isolé du site de la division des études des marchés actions pour se conformer aux réglementations édictées par la U.S. Securities and Exchange Commission. Dans cet exemple, l’entreprise doit utiliser deux applications Web, avec des ensembles de collections de sites d’équipes isolés pour les deux divisions. L’entreprise doit également utiliser des stratégies d’application Web et des fournisseurs SSP distincts afin que les utilisateurs d’une division ne voient pas le contenu créé par l’autre division.

  • Une société de recherche et fabrication doit en permanence surveiller rigoureusement sa propriété intellectuelle et les résultats des recherches. Dans cet exemple, la société peut héberger les sites d’équipes de recherche dans une application Web distincte et utiliser des stratégies d’application Web pour appliquer des autorisations et faire en sorte que seul le personnel de recherche voie le contenu des sites d’équipes de recherche.

  • Une organisation héberge à la fois des sites d’équipes internes (intranet) et externes (extranet) et souhaite les implémenter et les gérer différemment. Dans cet exemple, l’organisation planifie et implémente deux applications Web distinctes pour héberger les deux jeux de sites d’équipes, ce qui lui permet d’utiliser différentes méthodes d’authentification, différentes bases de données et différents journaux IIS pour chaque environnement en cas de problème. Pour plus d’informations sur la planification des extranets, voir Conception de la topologie de la batterie de serveurs extranet (Office SharePoint Server).

En règle générale, utilisez des applications Web dédiées pour effectuer les opérations suivantes :

  • séparer le contenu anonyme du contenu authentifié ;

  • isoler les utilisateurs ;

  • appliquer des autorisations ;

  • optimiser les performances ;

  • faciliter la gestion.

Pour plus d’informations sur le choix entre l’utilisation d’applications Web partagées ou l’utilisation d’applications Web dédiées, voir Modèle d’architecture logique : déploiement d’entreprise.

Prendre en compte les performances

Lorsque vous hébergez des sites d’équipes sur une application Web dédiée, vous disposez de plusieurs bases de données de contenu qui comportent uniquement des collections de sites d’équipes. Si les bases de données de contenu hébergent des sites dont les données présentent des caractéristiques similaires, le logiciel de gestion de base de données Microsoft SQL Server est plus efficace, car SQL Server choisit un plan de requête basé sur les caractéristiques d’une base de données. En revanche, si une base de données héberge des sites dont les données présentent des caractéristiques très différentes, il est possible que le plan de requête utilisé par SQL Server ne soit pas la méthode la plus efficace pour la totalité du contenu de la base de données. Par exemple, si une base de données héberge des sites d’équipes (autrement dit, un nombre élevé de sites de taille moyenne) et des sites de portail (autrement dit, un nombre réduit de sites très volumineux devant traiter de nombreuses demandes), le plan de requête choisi sera inefficace pour l’un des types de sites. Par conséquent, en plaçant le contenu des sites d’équipes dans des bases de données dédiées, vous pouvez optimiser les performances de SQL Server et, in fine, celles de l’ensemble de la batterie de serveurs.

Prendre en compte la facilité de gestion

En hébergeant les sites d’équipes sur une application Web dédiée, vous pouvez faciliter la gestion des manières suivantes :

  • Vous pouvez gérer séparément les éléments suivants :

    • Paramètres de la base de données

    • Modèles de quotas

    • Paramètres de la Corbeille

    • Actions automatiques pour les sites inutilisés

    • Authentification

    • Stratégies

  • Vous pouvez gérer plus efficacement la croissance des sites d’équipes en les gérant séparément des autres types de sites.

  • Vous donnez la possibilité de négocier un contrat de niveau de service spécifique. Par exemple, avec votre contrat de niveau de service régissant le stockage hebdomadaire des sauvegardes complètes et le stockage quotidien des sauvegardes différentielles des bases de données de contenu, vous pouvez offrir une solution plus rapide pour la récupération des différents éléments du contenu à l’aide de la Corbeille secondaire.

Choisir un pool d’applications

Dans un environnement d’entreprise, les sites d’équipes peuvent partager un pool d’applications avec des applications Web dont les critères en matière de collaboration et d’isolation sont similaires. Par exemple, les sites d’équipes peuvent partager un pool d’applications avec des sites Mon site, car les deux sont utilisés pour la collaboration et le stockage d’informations et de documents, et leur étendue est généralement définie de la même manière à des fins d’isolation (autrement dit, ils sont tous deux disponibles pour l’ensemble de l’organisation).

En règle générale, vous avez besoin d’un pool d’applications dédié lorsque vous devez effectuer les opérations suivantes :

  • séparer le contenu authentifié du contenu anonyme ;

  • isoler les applications qui stockent les mots de passe des applications métiers externes et interagissent avec celles-ci (par exemple, les connexions au catalogue de données métiers) ;

  • isoler les applications qui offrent aux utilisateurs de nombreuses possibilités pour créer et administrer des sites et pour collaborer au contenu.

Pour plus d’informations sur les situations qui se prêtent à l’utilisation de pools d’applications dédiés, voir Modèle d’architecture logique : déploiement d’entreprise.

Dans un environnement d’hébergement où le contenu de plusieurs organisations est hébergé sur une seule batterie de serveurs, il est recommandé d’héberger tout le contenu d’une même organisation dans le même pool d’applications. Cela procure une meilleure évolutivité (moins de pools d’applications signifie moins de processus en cours d’exécution), ainsi qu’une isolation des processus entre les pools d’applications (de sorte qu’un arrêt du pool d’applications du client A n’a aucune incidence sur les sites du client B). Il va de soi que cela dépend du nombre d’organisations que vous gérez, des recommandations liées à votre planification des performances et de vos besoins en termes d’isolation.

Planifier les paramètres généraux de l’application Web

La page Paramètres généraux de l’application Web comprend plusieurs paramètres qui permettent de gérer la croissance des données et le degré de pertinence du contenu dans les sites d’équipes de votre environnement. Ces paramètres sont appliqués à tous les sites d’une application Web. Au minimum, envisagez d’implémenter les paramètres suivants, qui sont chacun décrits plus loin dans cette section :

  • définir et appliquer un modèle de quota pour limiter la taille maximale des sites d’équipe ;

  • établir une taille de téléchargement maximale. Choisissez une taille suffisante au regard des besoins de l’entreprise pour que les utilisateurs puissent collaborer facilement ;

  • activer les Corbeilles de site et utiliser la Corbeille secondaire.

Outre les paramètres répertoriés précédemment, évaluez tous les paramètres des fonctionnalités de la page Paramètres généraux de l’application Web afin de vous assurer que celles-ci sont appropriées pour les sites d’équipes de votre organisation. Par défaut, les fonctionnalités suivantes sont activées :

  • paramètres de présence et de balise active des noms de personnes (les informations de présence en ligne sont affichées) ;

  • alertes (les utilisateurs peuvent créer un maximum de 500 alertes, par défaut) ;

  • flux RSS (Really Simple Syndication) ;

  • API de blog (lien permettant de créer un blog).

Déterminer les paramètres de modèle de quota

Il n’existe aucun modèle de quota par défaut pour les sites d’équipes d’un environnement Office SharePoint Server 2007. Toutefois, les paramètres suivants sont recommandés comme point de départ :

  • Un message électronique est envoyé automatiquement à un propriétaire de site lorsque la taille du site atteint 450 mégaoctets (Mo).

  • Les utilisateurs ne peuvent pas télécharger de documents supplémentaires lorsque la taille d’un site atteint 500 Mo.

Ces paramètres peuvent fonctionner correctement pour votre organisation, mais vous devez évaluer la taille et le nombre d’éléments que les utilisateurs sont susceptibles de stocker dans les sites d’équipes, puis ajuster ces paramètres en conséquence pour que les sites d’équipes soient utilisés comme prévu dans votre organisation.

Par exemple, si votre organisation comprend des équipes de recherche ou de conception qui collaborent pour produire un volume important de contenu à stocker et à archiver, envisagez une augmentation des limites de quota. Par exemple, portez la limite de site à 5 ou 10 gigaoctets (Go). Dans ces scénarios, l’hébergement du contenu sur des sites d’équipes garantit que celui-ci est sauvegardé régulièrement et que toutes les personnes qui doivent y collaborer peuvent le faire. Vous pouvez également envisager de placer une collection de sites dont la taille est comprise entre 5 et 10 Go dans sa propre base de données de contenu, notamment si vous prévoyez une croissance rapide de la collection de sites.

En revanche, si vos sites d’équipes sont principalement utilisés pour des projets à court terme ou pour des sites de communication des équipes, envisagez l’utilisation d’une limite de quota inférieure. Cela encourage les équipes à stocker uniquement les informations nécessaires à l’accomplissement des projets à court terme (toutefois, veillez à ne pas appliquer une réduction trop importante afin d’éviter une augmentation des coûts associés aux demandes d’augmentation des quotas adressées au support technique). Dans ce scénario, vous encouragez les équipes à stocker le contenu d’équipe général ou le contenu d’un nouveau projet dans des sites d’équipes distincts.

Si une équipe ou un groupe particulier de votre organisation a, du point de vue de l’entreprise, besoin de stocker un volume de contenu supérieur sur son site d’équipe, vous pouvez ajuster les limites de quota d’une collection de sites spécifique. Pour ce faire, dans la page Quotas et verrous de collection de sites, sélectionnez la collection de sites qui correspond à l’équipe ou au groupe. Affectez au modèle de quota actuel la valeur Quota individuel, puis spécifiez les limites appropriées.

Lors de la planification des modèles de quota, choisissez des limites qui fonctionnent pour la plupart des sites d’équipes de votre organisation. Pour faciliter la gestion, ajustez uniquement les quotas utilisateur par utilisateur lorsqu’il est nécessaire de répondre à un besoin de l’entreprise.

Déterminer la taille de téléchargement maximale

La taille maximale de téléchargement par défaut est 50 Mo. 50 Mo est considéré comme une limite offrant aux utilisateurs toute la souplesse dont ils ont besoin pour télécharger des documents de différents types et de différentes tailles sans incidence sur les performances. Si les utilisateurs de votre organisation doivent stocker des fichiers plus volumineux dans leurs sites d’équipes, envisagez d’ajuster ce paramètre et veillez à surveiller les paramètres de délai IIS si certains utilisateurs disposent de connexions plus lentes.

Déterminer les paramètres de la Corbeille

L’activation de la Corbeille est un moyen simple pour faciliter la gestion des sites d’équipes. La Corbeille permet aux propriétaires de sites de récupérer des éléments supprimés, sans nécessité d’une intervention administrative centrale (autrement dit, une restauration à partir de bandes de sauvegarde).

La liste suivante décrit les paramètres par défaut de la Corbeille, qui fonctionnent correctement pour la plupart des organisations :

  • État de la Corbeille : activé

  • Supprimer les éléments de la Corbeille : après 30 jours

  • Corbeille secondaire : ajoutez 50 pour cent de quota de site actif pour les éléments supprimés dans la Corbeille secondaire

La Corbeille secondaire stocke les éléments que les utilisateurs ont supprimés de leur Corbeille. Seuls les administrateurs de collections de sites peuvent restaurer les éléments à partir de la Corbeille secondaire. La taille spécifiée pour la Corbeille secondaire augmente la taille totale du site d’équipe. Par exemple, si la limite du site d’équipe est de 500 Mo et la Corbeille secondaire est définie sur 50 pour cent, le montant total utilisable par le site est de 750 Mo ; pensez à planifier la capacité de vos bases de données en conséquence.

Comme dans le cas de la Corbeille, les éléments dans la Corbeille secondaire sont automatiquement supprimés lorsque la période de conservation des éléments supprimés est atteinte (30 jours par défaut). Toutefois, lorsque la limite de taille de la Corbeille secondaire est atteinte, les éléments sont automatiquement supprimés de celle-ci, du plus ancien au plus récent. Les administrateurs de collections de sites peuvent également vider la Corbeille secondaire manuellement.

Lorsque vous utilisez la fonctionnalité Corbeille, vous devez absolument déterminer s’il est nécessaire de recourir à la Corbeille secondaire et évaluer la quantité d’espace à allouer à celle-ci. Envisagez d’allouer au moins une petite quantité d’espace (telle que 10 %) à la Corbeille secondaire pour répondre aux situations où un utilisateur supprime par erreur un document important, un dossier dans une bibliothèque de documents ou une colonne dans une liste.

Planifier la méthode de création de site

Vous pouvez décider de créer des collections de sites pour vos sites d’équipes de manière centralisée ou de laisser les utilisateurs créer leurs propres collections de sites à l’aide de la gestion de sites libre-service. Chaque approche comporte des compromis.

Si vous autorisez les équipes à créer des collections de sites par le biais de la gestion de sites libre-service, elles peuvent facilement créer un site, selon leurs besoins, sans l’aide d’un administrateur. Toutefois, cette approche présente les inconvénients suivants :

  • Vous perdez l’opportunité d’implémenter une taxonomie réfléchie.

  • L’application peut devenir difficile à gérer.

  • Les sites sont facilement abandonnés.

  • Vous ne pouvez pas partager les modèles et la navigation entre projets ou équipes qui pourraient sinon partager une collection de sites.

NoteRemarque :

Si vous souhaitez utiliser la gestion de sites libre-service, mais souhaitez limiter les modèles disponibles pour les sites créés à l’aide de cette méthode, vous pouvez modifier le fichier webtempsps.XML (situé à l’emplacement %programfiles%\Common Files\Microsoft Shared\Web server extensions\12\TEMPLATE\1033\XML) de manière à masquer les modèles auprès du processus de gestion de sites libre-service.

En revanche, si vous créez des collections de sites de manière centralisée, suivant la façon dont votre organisation fonctionne, vous pouvez implémenter une taxonomie réfléchie qui permet de structurer la gestion et la croissance des sites d’équipes. En outre, il est plus facile de partager les modèles et la navigation entre projets et équipes qui partagent une collection de sites. Grâce à cette approche, une fois la collection de sites initiale créée, les équipes peuvent créer des sites dans la collection de sites en fonction de leurs besoins. Toutefois, des ressources informatiques sont consommées chaque fois qu’un utilisateur souhaite créer un site.

Pour des exemples d’utilisation de chaque méthode, voir Modèle d’architecture logique : déploiement d’entreprise. Pour plus d’informations sur la planification de la création de sites, voir Planifier le processus de création de sites (Office SharePoint Server).

Si votre organisation a choisi de créer des collections de sites pour les sites d’équipes, au lieu de laisser les utilisateurs créer leurs propres collections de sites d’équipes, utilisez la feuille relative aux chemins d’accès aux sites (en anglais) (https://go.microsoft.com/fwlink/?linkid=73149&clcid=0x40C) (en anglais) pour déterminer le niveau auquel les sites d’équipes sont créés : sites de niveau supérieur dans leurs propres collections de sites ou collection de sites volumineuse comportant plusieurs sous-sites. Pour plus d’informations sur la procédure à suivre pour déterminer s’il convient de créer de nombreuses collections de sites ou uniquement quelques collections de sites comportant de nombreux sous-sites, voir la section consacrée à la détermination du choix entre des collections de sites spécifiques ou des sous-sites dans une seule collection de sites, dans l’article Determine sites and subsites needed [Windows SharePoint Services] de la Bibliothèque technique Windows SharePoint Services 3.0 . Pour plus d’informations sur les types de sites disponibles dans Office SharePoint Server 2007, voir Définir des sites et des sous-sites.

Concevoir les paramètres de base de données de contenu pour les sites d’équipes

Dans le Modèle d’architecture logique : déploiement d’entreprise, les sites d’équipes sont stockés dans des bases de données dédiées, à raison d’une par collection de sites. Cette approche permet de gérer la base de données de chaque collection de sites de manière indépendante pour les opérations de sauvegarde, de récupération et de migration. En outre, lorsqu’un projet est terminé, vous pouvez facilement archiver la base de données qui lui est associée. Bien que cette approche vous amène à créer de nombreuses bases de données, vous pouvez contrôler individuellement la base de données correspondant à chaque collection de sites.

Notez toutefois que les performances de SQL Server peuvent pâtir du nombre de bases de données par instance de SQL Server. En d’autres termes, si vous envisagez au moins 300 collections de sites d’équipes, le stockage de chacune d’elles dans une base de données dédiée peut entraîner une dégradation des performances de SQL Server. Cela est dû au fait que chaque base de données représente une connexion entre le pool d’applications et SQL Server. Lorsque vous ajoutez des serveurs Web et des bases de données, le nombre de connexions actives augmente. Si vous ajoutez un nombre trop élevé de connexions, SQL Server peut ne plus répondre.

Par conséquent, si vous envisagez plus de 300 collections de sites d’équipes, vous ne devez pas utiliser de bases de données dédiées. Au lieu de cela, vous devez stocker plusieurs collections de sites dans chaque base de données. Notez que 300 bases de données est le nombre utilisé par le service informatique de Microsoft. Ce nombre ne constitue pas un point de défaillance, mais plutôt une estimation basée sur les données SharePoint Portal Server 2003, au regard desquelles 300 bases de données représentaient pour le service informatique de Microsoft un niveau de confiance quant au nombre de collections de sites pouvant être hébergées en toute sécurité sur chaque serveur. Dans votre cas, le nombre peut varier en fonction de certains paramètres, dont le nombre de bases de données. Par exemple, le fait de devoir ou non utiliser des bases de données dédiées peut également dépendre des facteurs suivants :

  • Les équipes ont-elles différents contrats de niveau de service (répondant par exemple à différentes contraintes de sauvegarde) ?

  • Les équipes ont-elles besoin de plus de 8 Go de stockage ?

  • Les équipes suivent-elles plusieurs plannings de projet ? Le mélange d’équipes engagées dans des projets de courte durée avec des équipes engagées dans des projets de longue durée peut compliquer l’archivage des sites et leur retrait de l’environnement de production s’ils partagent la même base de données.

  • Vos équipes s’attendent-elles à un niveau d’autonomie et d’indépendance élevé pour les opérations qui se produisent au niveau de la base de données ?

Si vous répondez Oui à au moins une question ci-dessus, vous devez envisager des bases de données dédiées pour les collections de sites.

Si vous choisissez de stocker plusieurs collections de sites dans chaque base de données, vous pouvez calculer le nombre de collections à stocker dans chacune en déterminant la taille maximale de la base de données et la taille maximale de chaque collection de sites (en fonction de la valeur limite de stockage de modèle de quota et de l’espace alloué à la Corbeille). Notez que même si vous accordez à tout le monde des quotas de 500 Mo, tout le monde n’utilise pas la totalité du quota, si bien que vous risquez de créer trop de bases de données de contenu. Utilisez les estimations de quotas comme critère lors de la planification des bases de données, mais veillez à effectuer le suivi de votre utilisation réelle et à vous adapter en conséquence. Si vous disposiez d’un environnement comportant SharePoint Portal Server 2003 ou Windows SharePoint Services 2.0, vous pouvez également examiner les tailles que présentaient ces collections de sites et créer des bases de données basées sur ces tailles plutôt que sur les estimations de quotas.

Dans un environnement géré, les limites de taille des bases de données sont souvent déterminées par les deux facteurs suivants :

  • le temps nécessaire pour sauvegarder une base de données. Au-delà d’une certaine taille de base de données, les opérations de sauvegarde deviennent inefficaces, trop longues et sont soumises à d’autres perturbations. En outre, cela peut être le stade auquel vous décidez d’ajouter plusieurs serveurs de base de données à votre environnement ;

  • la fenêtre de service (autrement dit la durée) autorisée pour la restauration du contenu, telle que déterminée par le contrat de niveau de service. Par exemple, si la fenêtre de service définie pour la restauration du contenu est de quatre heures, la taille de la base de données est limitée à un volume qui peut être restauré dans cet intervalle de temps.

Pour déterminer la taille de base de données gérable maximale pour les collections de sites d’équipes, déterminez les valeurs répertoriées dans le tableau suivant.

Élément Facteur Valeur

A

Fenêtre de service pour la restauration du contenu

h

B

Volume de contenu pouvant être restauré dans la fenêtre de service, en fonction de la méthode et des outils de récupération choisis

Go

C

Fenêtre de temps cible pour la sauvegarde des bases de données

h

D

Volume de contenu pouvant être sauvegardé dans la fenêtre cible, en fonction de la méthode et des outils de sauvegarde choisis

Go

La taille de base de données gérable maximale pour votre organisation est la plus petite des deux valeurs de volume du contenu (B et D).

Une fois déterminée la taille cible des bases de données de contenu, vous pouvez calculer le nombre de collections de sites pouvant être prises en charge dans chaque base de données. Le tableau suivant indique le nombre de collections de sites par base de données en fonction des limites de taille des bases de données et des collections de sites. Les limites de taille des collections de sites incluent l’espace alloué à la Corbeille secondaire.

Taille de la base de données Limite de taille de collection de sites de 500 Mo Limite de taille de collection de sites de 750 Mo Limite de taille de collection de sites de 1 Go Limite de taille de collection de sites de 2 Go Limite de taille de collection de sites de 5 Go Limite de taille de collection de sites de 10 Go

25 Go

50

33

25

12

5

2

50 Go

100

66

50

25

10

5

100 Go

200

133

100

50

20

10

200 Go

400

266

200

100

40

20

500 Go

800

533

500

250

100

50

1 téraoctet

1 600

1 066

1 000

500

200

100

NoteRemarque :

Si une collection de sites atteint une taille supérieure à 10 Go, songez à la placer dans une base de données dédiée pour faciliter sa gestion (par exemple, pour accélérer la sauvegarde et la récupération).

Lorsque vous créez l’application Web pour vos sites d’équipes, dans la page Gérer les bases de données de contenu associée à la première base de données de contenu, indiquez le nombre maximal de collections de sites en fonction de la taille de base de données cible et des limites de taille des collections de sites (Nombre maximal de sites). En outre, spécifiez le nombre de sites à partir duquel un avertissement est déclenché (Avertissement relatif au niveau du site). Lorsque la valeur d’avertissement relatif au niveau du site est atteinte, créez une base de données avec les mêmes paramètres. Lorsque le nombre maximal de collections de sites est atteint, aucune nouvelle collection de sites n’est créée dans la base de données. Si aucune autre base de données n’a été créée, la création de site échoue.

Supprimer automatiquement les sites inutilisés

Vous pouvez augmenter la pertinence du contenu des sites d’équipes en supprimant automatiquement les sites inutilisés. Cela peut également vous aider à contrôler la croissance globale des sites d’équipes. Si les sites d’équipes sont hébergés dans une application Web distincte, vous pouvez gérer les sites d’équipes inutilisés différemment des sites personnels, par exemple en leur accordant une durée de vie plus longue avant de rechercher les sites Web inutilisés.

Par défaut, les paramètres permettant de supprimer les sites automatiquement ne sont pas activés. Pour gérer les paramètres de suppression de site, dans la page Gestion des applications, dans la section Gestion des sites SharePoint, cliquez sur Confirmation et suppression de l’utilisation de sites.

Si vous activez cette fonctionnalité, les paramètres par défaut sont les suivants :

  • Des notifications par courrier électronique sont envoyées aux propriétaires de collections de sites 90 jours après la confirmation de la création ou de l’utilisation des collections de sites. En d’autres termes, si au terme d’un délai de 90 jours, l’utilisation d’un site n’a pas été confirmée, son propriétaire reçoit une notification.

  • Le système vérifie s’il existe des collections de sites non confirmées et envoie des avis quotidiens à minuit.

  • L’option permettant de supprimer automatiquement les collections de sites non confirmées n’est pas sélectionnée. Si ce paramètre est sélectionné, les sites sont automatiquement supprimés après l’envoi de 28 avis. Si vous préférez, vous pouvez spécifier le nombre d’avis.

D’après les paramètres par défaut, une collection de sites inutilisée pendant 90 jours est supprimée après l’envoi de 28 avis, soit 118 jours après la dernière confirmation du site. Vous pouvez spécifier des paramètres appropriés pour votre organisation.Comme cette fonctionnalité repose sur des confirmations et non sur le suivi de l’utilisation réelle du site, vous devez tenir compte d’absences éventuelles des propriétaires de sites et ne pas définir trop strictement les délais avant expiration et suppression. En outre, prévoyez systématiquement plusieurs administrateurs de collections de sites afin qu’un administrateur de remplacement puisse confirmer l’utilisation du site au cas où l’administrateur principal de la collection de sites s’absenterait pour une période prolongée.

La suppression automatique des sites permet de contrôler votre environnement, mais vous risquez qu’un site automatiquement supprimé contienne des données stratégiques. Pour atténuer ce risque, il est recommandé de prendre les dispositions suivantes :

  • Exigez un contact secondaire pour tous les sites. De la sorte, si le propriétaire du site n’est pas disponible ou s’il quitte votre organisation, un contact est toujours à même de vérifier si un site est en cours d’utilisation. Si vous ne disposez pas d’un contact secondaire et réduisez le nombre de jours ou le nombre d’avis émis avant la suppression d’un site inutilisé, vous risquez de supprimer accidentellement un site nécessaire. Implémentez cette recommandation dès l’activation de la gestion de sites libre-service, ou sous la forme d’un processus métier de création de collections de sites à partir de l’Administration centrale.

  • Archivez les sites avant leur suppression automatique. De nombreuses organisations qui implémentent la suppression automatique des sites inutilisés investissent également dans le développement d’un outil qui archive tous les sites avant leur suppression automatique, ce qui permet de les restaurer facilement s’ils contiennent des informations stratégiques. Une autre solution consiste à stocker les bases de données de contenu à long terme, ce qui permettra de restaurer un site supprimé.

Utiliser les chemins d’accès ou les noms d’hôtes pour organiser les URL des sites d’équipes

En fonction de votre organisation et de l’utilisation des sites d’équipes, envisagez de recourir à des chemins d’accès pour organiser les URL de vos sites d’équipe. Par exemple, si vous souhaitez des URL différentes pour les sites d’équipes associés à des divisions différentes, vous pouvez utiliser des URL de la forme http://nom_société/nom_division/sites ou http://nom_société/research/sites. De même, vous pouvez clairement indiquer le lien avec un site intranet publié à l’aide de l’URL http://nom_intranet/teamsites. Si vous utilisez la gestion de sites libre-service, l’URL par défaut pour les sites d’équipes est http://nom_serveur/sites, mais vous pouvez également créer une inclusion générique pour http://nom_serveur/team ou le préfixe de votre choix pour vos sites d’équipes.

NoteRemarque :

Si vous choisissez une inclusion générique autre que celle par défaut (/sites), vous devez la suivre en guise de personnalisation de votre plan de récupération en cas d’urgence. Étant donné que ces informations sont stockées dans la base de données de configuration, elles ne sont pas automatiquement restaurées et vous devez recréer l’inclusion générique pour restaurer l’ensemble de votre environnement.

Pour plus d’informations sur les chemins d’accès, voir les ressources suivantes :

Vous pouvez également créer des sites nommés par l’hôte si les sites d’équipes jouent un rôle plus important dans votre organisation. Par exemple, si votre site Web des ressources humaines est un site d’équipe qui ne fait pas partie de votre site intranet publié, vous pouvez créer pour ce site un site d’équipe nommé par l’hôte http://rhsite ou http://ressourceshumaines.

NoteRemarque :

Certaines fonctionnalités, telles que les noms d’hôte de substitution, sont incompatibles avec les collections de sites nommées par l’hôte.

Planifier les éléments personnalisés

Les personnalisations peuvent compliquer votre environnement, en particulier lorsque vous envisagez de tester tous les packs de solution plusieurs fois : avant de les déployer, lorsque vous devez appliquer une mise à jour et lorsque vous êtes prêt à mettre à niveau votre environnement. Vous devez définir la stratégie adoptée par votre organisation en matière d’utilisation d’éléments personnalisés tels que fonctionnalités, modèles ou composants WebPart, et planifier les critères de gestion, de prise en charge et d’utilisation de ces éléments dans votre environnement.

  • Facilité de gestion   Si vous devez sauvegarder et restaurer la totalité de votre environnement (par exemple dans un scénario de récupération d’urgence ou si vous modifiez la configuration matérielle), vous devez prévoir des sauvegardes pour tous les éléments personnalisés (tels qu’un composant WebPart personnalisé développé pour votre environnement ou une définition de site personnalisée) et penser à les rajouter à votre environnement lors de la restauration. En effet, vous ne pouvez pas restaurer la base de données de configuration, qui contient toutes les références à ces éléments personnalisés ; par conséquent, vous devez les rajouter à votre environnement restauré. Par exemple, vous devez rajouter les définitions de site personnalisées et installer les composants WebPart personnalisés. Si vous oubliez un élément personnalisé lorsque vous installez un nouveau serveur ou restaurez un serveur, vous pouvez provoquer des erreurs dans les sites d’équipes des utilisateurs, qui vous obligent à rechercher le code nécessaire pendant que les utilisateurs patientent.

  • Capacité de prise en charge   L’existence d’éléments personnalisés dans votre environnement peut allonger le temps nécessaire à la résolution des problèmes. Chaque partie de code personnalisée est unique, peut être complexe ou simple et peut consommer de la mémoire supplémentaire pour s’exécuter. Prenez en compte le nombre d’emplacements auxquels le code personnalisé est utilisé et évaluez son impact sur le système. En outre, déterminez dans quelle mesure vous pouvez établir que les personnalisations ne sont pas la cause principale d’un problème lors de sa résolution. Si vous créez le code personnalisé vous-même, veillez à le concevoir de telle sorte que les erreurs liées aux personnalisations soient enregistrées à la fois dans le journal des événements — pour les événements Microsoft Operations Manager (MOM) — et dans les autres emplacements utilisés par votre organisation pour la résolution des problèmes, afin que vous puissiez résoudre les erreurs.

  • Facilité d’utilisation    Prenez en compte la facilité d’utilisation de vos solutions, des composants WebPart et des modèles. Si les modèles personnalisés des sites d’équipes de votre environnement sont nombreux au point que la liste des modèles ou des composants WebPart occupe plusieurs écrans (par exemple, 50 représente une quantité qui complique la lecture et la différenciation), déterminez si vous avez besoin de tous ces éléments personnalisés, si vous pouvez scinder la liste ou si vous devez les rassembler dans des Feature Packs courants afin d’en faciliter l’exploration et le suivi.

Certaines organisations mettent en place plusieurs stratégies pour les personnalisations. Par exemple, elles peuvent opter pour un système à deux ou trois niveaux, dans lequel le niveau 1 représente les sites bruts (utilisant des modèles standard uniquement), le niveau 2 permet certaines personnalisations (grâce à un autre contrat de niveau de service) et le niveau 3 héberge le matériel, mais l’équipe propriétaire des sites d’équipes est chargée de l’exécution et de la gestion de son propre environnement personnalisé sur ce matériel. Il s’agit d’un autre cas dans lequel plusieurs applications Web peuvent héberger vos sites d’équipes, avec différents contrats de niveau de service pour chaque application Web.

Planifier les autorisations à appliquer aux sites d’équipes

Les autorisations et les stratégies appliquées aux sites d’équipes déterminent :

  • qui peut créer des sites d’équipes ;

  • qui peut afficher les sites d’équipes et y collaborer ;

  • qui n’est pas autorisé à accéder au contenu des sites d’équipes.

Il est recommandé d’utiliser des groupes de sécurité pour gérer les autorisations. Le tableau suivant fournit de l’aide sur la configuration des autorisations et indique où les paramétrer.

Autorisation Aide Configuration

Créer des collections de sites d’équipes

Par défaut, seuls les membres du groupe Administrateurs de batterie peuvent créer des collections de sites pour les sites d’équipes.

Si vous souhaitez que davantage d’utilisateurs puissent créer des collections de sites d’équipes, utilisez la fonctionnalité Gestion de sites libre-service dans l’Administration centrale. Pour plus d’informations, voir Planifier le processus de création de sites (Office SharePoint Server).

Une autre solution consiste à activer la gestion de sites libre-service pour un sous-ensemble de personnes dans votre organisation ; pour ce faire, activez cette fonctionnalité, mais limitez l’autorisation Création de sites libre-service à un ou plusieurs groupes de sécurité, ou limitez l’accès de la page Gestion de sites libre-service - Nouveau site SharePoint (Scsignup.aspx) à des groupes de sécurité spécifiques.

Sur le site Administration centrale, dans la page Gestion des applications, dans la section Sécurité des applications, cliquez sur Gestion de sites libre-service.

Les utilisateurs et les groupes disposant de l’autorisation Utiliser la création de sites libre-service peuvent créer des collections de sites lorsque la gestion de sites libre-service est activée.

Créer des sous-sites dans les collections de sites

Par défaut, les membres d’un site d’équipe qui disposent de l’autorisation Créer des sous-sites (incluse dans le niveau d’autorisation Contrôle total) peuvent créer des sous-sites dans une collection de sites. Il est recommandé d’autoriser les propriétaires de sites à gérer les autorisations liées à la création de sous-sites, plutôt que d’empêcher globalement les utilisateurs de créer des sous-sites.

Dans la page Paramètres du site Web, ajoutez ou supprimez des membres qui appartiennent au groupe Propriétaires.

Afficher les sites d’équipes et y collaborer

Même si un employé n’est pas autorisé à créer un site d’équipe, il peut afficher des documents sur d’autres sites d’équipes et y collaborer, en fonction des autorisations appliquées par les propriétaires de sites. Il est recommandé d’autoriser les propriétaires de sites à gérer les autorisations sur le contenu de leurs sites, plutôt que d’empêcher globalement les utilisateurs à participer à ce type de collaboration.

Dans la page Paramètres du site Web, ajoutez ou supprimez des membres qui appartiennent au groupe Visiteurs.

Accès interdit au contenu des sites d’équipes

Vous pouvez empêcher les utilisateurs de votre organisation d’accéder à la totalité du contenu des sites d’équipes en créant une stratégie pour l’application Web. Utilisez cette option avec précaution, car elle empêche toute collaboration sur les sites d’équipes avec les utilisateurs bloqués. Une stratégie appliquée à l’application Web substitue toutes les autres autorisations configurées dans celle-ci.

Dans la page Gestion des applications, dans la section Sécurité des applications, cliquez sur Stratégie de l’application Web. Dans la page Stratégie de l’application Web, sélectionnez les utilisateurs que vous souhaitez bloquer, cliquez sur Modifier les autorisations des utilisateurs sélectionnés, puis, dans la page Modifier l’utilisateur, dans la section Niveaux de stratégies d’autorisation, sélectionnez Refuser tout.

Télécharger ce livre

Cette rubrique est incluse dans le livre à télécharger suivant pour une lecture et une impression plus faciles :

Vous trouverez la liste complète des livres disponibles sur Livres à télécharger pour Office SharePoint Server 2007.