Concevoir l'architecture logique de sites de collaboration (Windows SharePoint Services)

  • Article

Mise à jour : 2009-04-23

Dans cet article :

  • 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 d’une 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

La collaboration et l'espace de stockage possibles du fait des sites d'équipes s'avèrent utiles pour les projets à court et à long terme, la communication et la collaboration entre groupes. Lorsque vous créez la conception de l'architecture initiale pour les batteries de serveurs, vous devez planifier l'hébergement et la gestion des sites d'équipe. Par exemple, vous devez planifier les bases de données de contenu nécessaires à l'hébergement du contenu du site d'équipe, planifier l'archivage et la suppression des sites d'équipes des projets à court terme pour libérer de l'espace pour d'autres projets et surveiller les sites de communication d'équipe pour vous assurer que leur taille puisse être gérée pour la sauvegarde et la récupération.

Cet article contient des recommandations en matière de conception d'architecture initiale pour le déploiement de sites d'équipes dans une batterie de serveurs. Cet article ne traite pas de l'architecture d'information (c'est-à-dire, la structure interne) des sites d'équipe. Pour plus d'informations sur la conception de l'architecture d'information, voir la rubrique Planifier la structure et la publication d'un site Web (Windows SharePoint Services).

Recommandations pour la conception de sites d’équipes

Dans la plupart des organisations, le nombre de sites d'équipes augmente et la taille des sites d'équipes augmente, parfois rapidement. Lorsque les équipes sont réorganisées ou que de nouveaux projets commencent, les équipes créent des sites d'équipes et abandonnent les anciens sites, ou développent leurs propres sites d'équipes actuels pour contenir davantage de données. Pour gérer ou contrôler cette croissance, vous devez planifier soigneusement la prise en charge des sites d'équipes.

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

  • Optimisation des performances de la batterie de serveurs dans son ensemble

  • 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 les stratégies et les paramètres appropriés pour les sites d'équipes sans affecter les autres types de sites de l'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 autorisations appropriées

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

Utilisez un ou plusieurs applications Web dédiées pour héberger les sites d'équipe. Examinez les exemples suivants :

  • Une société de banque d'investissement et d'études de passif située aux États-Unis doit maintenir les sites de la division Banque d'investissement et de la division Études de passif complètement isolés pour se conformer aux réglementations de l'U.S. Securities and Exchange Commission. Dans cet exemple, la société doit utiliser deux applications Web comportant des ensembles de collections de sites isolés pour les deux divisions. Elle doit également utiliser des stratégies d'application Web pour s'assurer que les utilisateurs de chaque division ne peuvent pas visualiser le contenu généré par l'autre division.

  • Une société d'étude et de production doit maintenir un contrôle étroit de la propriété intellectuelle et des 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 les autorisations et s'assurer que seul le personnel de recherche peut visualiser le contenu des sites d'équipes de recherche.

  • Une organisation héberge 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 ensembles de sites d'équipe. Ainsi, elle peut disposer de différentes méthodes d'authentification et différents journaux de services Internet (IIS) en cas de problème. Pour plus d'informations sur la planification pour les sites extranet, reportez-vous à la rubrique Concevoir la topologie de la batterie de serveurs extranet (Windows SharePoint Services).

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 ;

  • optimiser la facilité de 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 Exemple de conception d'architecture logique : sites de collaboration.

Prendre en compte les performances

Lorsque vous hébergez des sites d'équipes dans une application Web dédiée, vous utilisez plusieurs bases de données de contenu qui ne contiennent que des collections de sites d'équipe. Si les bases de données de contenu hébergent des sites possédant des caractéristiques de données similaires, le logiciel de base de données Microsoft SQL Server 2005 fonctionne plus efficacement, car SQL Server 2005 utilise un plan de requête basé sur les caractéristiques d'une base de données. Par opposition, si une base de données héberge des sites comportant des caractéristiques de données très différentes, il se peut que le plan de requête utilisé par SQL Server 2005 ne soit pas la méthode la plus efficace pour tout le contenu de la base de données. Par conséquent, en plaçant le contenu destiné aux sites d'équipes dans des bases de données dédiées, vous pouvez optimiser les performances de SQL Server 2005, ce qui permet de bénéficier de meilleures performances pour la batterie de serveurs globale.

Prendre en compte la facilité de gestion

En hébergeant des sites d'équipes dans une application Web dédiée, vous pouvez améliorer la possibilité de gestion comme suit :

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

    • paramètres de base de données ;

    • modèles de quota ;

    • 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 site.

  • 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.

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

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

  • isoler des applications dans lesquelles les utilisateurs ont la liberté de créer et de gérer des sites et de collaborer au contenu.

Pour plus d’informations sur les situations qui se prêtent à l’utilisation de pools d’applications dédiés, voir Exemple de conception d'architecture logique : sites de collaboration.

Dans un environnement d'hébergement dans lequel du contenu pour plusieurs organisations est hébergé dans une seule batterie de serveurs, il est recommandé d'héberger tout le contenu d'une application dans le même pool d'applications. Cela facilite l'évolutivité (avec un nombre réduit de pools d'applications, un nombre réduit de processus sont exécutés) et permet d'isoler les processus entre les pools d'application (afin que, en cas d'arrêt du pool d'application d'un client A, cela n'affecte pas les sites d'un client B). Cela dépend, bien entendu, du nombre d'organisations impliquées, des recommandations de planification des performances et des exigences en matière d'isolation.

Planifier les paramètres généraux d’une application Web

Différents paramètres de la page Paramètres généraux de l'application Web peuvent vous aider à gérer la croissance des données et la position du contenu actuel dans les sites d'équipes dans l'environnement. Ces paramètres s'appliquent à tous les sites dans une application Web. Au minimum, envisagez d'implémenter les paramètres ci-dessous, qui seront décrits individuellement 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 indiqués ci-dessus, évaluez tous les paramètres des fonctionnalités dans la page Paramètres généraux de l'application Web pour vous assurer que les fonctionnalités sont appropriées pour les sites d'équipes de l'organisation. Par défaut, les fonctionnalités activées sont les suivantes :

  • balise active et état en ligne du nom de la personne (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)

  • interface de programmation d’application (API) de blog (lien pour créer un blog)

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

Il n'existe pas de modèle de quota par défaut pour les sites d'équipe. Cependant, les paramètres ci-dessous 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 l'organisation, mais vous devez évaluer la taille et le nombre d'éléments que les utilisateurs vont stocker dans les sites d'équipes et ajuster ces paramètres en conséquence pour vous assurer que les sites d'équipes sont utilisés de la manière escomptée dans l'organisation.

Par exemple, si l'organisation comprend des équipes de recherche ou de conception qui collaborent pour produire un contenu volumineux à stocker et à archiver, envisagez d'augmenter les limites de quota : par exemple, augmentez la limite à 5 ou 10 Go. Dans ces scénarios, l'hébergement du contenu dans des sites d'équipes permet de s'assurer que le contenu est sauvegardé régulièrement et que toutes les personnes qui doivent y contribuer sont en mesure de le faire. Vous pouvez également envisager de placer une collection de sites d'une taille de 5 à 10 Go dans sa propre base de données de contenu, en particulier si vous pensez que la collection de sites va croître rapidement.

D'autre part, si des sites d'équipes sont principalement utilisés pour des projets à court terme ou des sites de communication d'équipe, envisagez d'utiliser une limite de quota inférieure. Cela encourage les équipes à ne stocker que les informations nécessaires pour que les projets à court terme avancent (cependant, veillez à ne pas trop le réduire, ou vous risquez une augmentation des coûts associés aux demandes de support pour augmenter les quotas). 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 en particulier dans l'organisation possède un besoin métier de stocker un volume de contenu plus important sur son site d'équipe, vous pouvez ajuster les limites de quota pour une collection de sites donnée. Pour ajuster les limites de quota, dans la page Quotas et verrous de la collection de sites, sélectionnez la collection de sites correspondant à l'équipe ou au groupe. Modifiez le modèle de quota actuel sur Quota individuel, puis spécifiez les limites appropriées.

Lors de la planification des modèles de quota, sélectionnez les limites qui fonctionnent pour la plupart des sites d'équipes de l'organisation. Pour améliorer la facilité de gestion, n'ajustez les quotas que par utilisateur pour répondre à un besoin métier.

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

La taille maximale de transfert par défaut est de 50 Mo. Cette taille est considérée comme une limite large offrant aux utilisateurs la possibilité de transférer de nombreux types de documents de toute taille sans affecter les performances. Si des utilisateurs, au sein de l'organisation, doivent stocker des fichiers volumineux dans leurs sites d'équipe, envisagez d'ajuster ce paramètre et assurez-vous de surveiller les paramètres de dépassement de délai des services Internet (IIS) si des utilisateurs possèdent des connexions lentes.

Déterminer les paramètres de la Corbeille

L'activation de la Corbeille est un moyen simple d'améliorer la facilité de gestion des sites d'équipe. La Corbeille permet aux propriétaires de sites d'extraire des éléments qui ont été supprimés sans nécessiter l'intervention de l'Administration centrale (c'est-à-dire, une restauration à partir de bandes de sauvegarde).

La liste ci-dessous 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 dans leur Corbeille. Seuls les administrateurs de collections de sites peuvent restaurer des é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 que la Corbeille secondaire est définie sur 50 %, la quantité totale utilisable par le site est de 750 Mo. Par conséquent, planifiez la capacité de la base 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 les sites d'équipes de manière centralisée ou permettre aux utilisateurs de créer leurs propres collections de sites en utilisant la Gestion de sites libre-service. Chaque approche présente des inconvénients.

Si vous permettez aux équipes de créer des collections de sites par le biais de la gestion de sites libre-service, les équipes peuvent facilement créer un site, si nécessaire, sans l'assistance d'un administrateur. Cependant, cette approche présente de nombreux inconvénients, dont les suivants :

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

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

  • Les sites peuvent être 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 que vous souhaitez restreindre les modèles disponibles pour les sites créés, vous pouvez modifier le fichier webtempsps.XML (situé sous %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\TEMPLATE\1033\XML) pour masquer les modèles à partir de la procédure de gestion de sites libre-service.

Au lieu de cela, si vous créez des collections de sites de manière centralisée, en fonction du fonctionnement de l'organisation, vous avez la possibilité d'implémenter une taxonomie réfléchie, qui structure la gestion et la croissance des sites d'équipe. Il est également possible de partager les modèles et la navigation entre les projets et les équipes partageant une collection de sites. En utilisant cette approche, une fois que la collection de sites initiale est créée, les équipes peuvent créer des sites dans la collection de sites en fonction de leurs besoins. Cependant, vous dépensez des ressources informatiques chaque fois qu'un utilisateur souhaite créer un site.

Pour des exemples d’utilisation de chaque méthode, voir Exemple de conception d'architecture logique : sites de collaboration. Pour plus d’informations sur la planification de la création de sites, reportez-vous à la rubrique Planifier le processus de création de sites (Windows SharePoint Services).

Si l'organisation a décidé de créer des collections de sites pour les sites d'entreprise au lieu de permettre aux utilisateurs de créer des collections de sites d'équipe, utilisez la feuille de calcul de chemins de site (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 : plusieurs sites de niveau supérieur dans leurs propres collections de sites ou une grande collection de sites avec plusieurs sous-sites. Pour savoir comment déterminer si un grand nombre de collections de sites ou quelques collections de sites avec de nombreux sous-sites doivent être créées, voir le paragraphe « Decide whether to use individual site collections or subsites within one site collection » de la rubrique Déterminer les sites et les sous-sites nécessaires (Windows SharePoint Services) de la bibliothèque technique Windows SharePoint Services 3.0.

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

En fonction des considérations liées à l'échelle et à la facilité de gestion, vous pouvez utiliser des bases de données de contenu dédiées pour chaque collection de sites ou regrouper plusieurs collections de sites en une ou plusieurs bases de données de contenu. L'utilisation d'une base de données dédiée pour chaque collection de sites permet de gérer chaque base de données de collection de sites indépendamment pour la sauvegarde, la récupération et la migration. De même, lorsqu'un projet est terminé, vous pouvez facilement archiver la base de données associée au projet. Même si en utilisant cette approche vous créez un grand nombre de bases de données, vous avez la possibilité de contrôler individuellement la base de données pour chaque collection de sites.

Cependant, notez que les performances de SQL Server peuvent être affectées par le nombre de bases de données pour chaque instance de SQL Server. En d'autres termes, si vous envisagez d'utiliser 300 collections de sites d'équipes ou davantage, le stockage de chaque collection dans une base de données dédiée peut réduire les performances de SQL Server. Cela s'explique par le 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 trop grand nombre de connexion, SQL Server peut ne pas répondre.

Par conséquent, si vous envisagez d'utiliser plus de 300 collections de sites d'équipe, vous ne devez pas utiliser de bases de données dédiées. Au lieu de cela, stockez plusieurs collections de sites dans chaque base de données. 300 bases de données est la limite utilisée par le service informatique de Microsoft. Notez que 300 bases de données ne correspondent pas à un point d'échec. Il s'agit d'une estimation basée sur les données Windows SharePoint Services 3.0, dans lesquelles 300 bases de données représentent un niveau de confiance pour le service informatique de Microsoft pour ce qui est du nombre de collections de sites qui peuvent être hébergées en toute sécurité sur chaque serveur. Le nombre varie en fonction de plusieurs paramètres dont le nombre de bases de données. Par exemple, l'utilisation de bases de données dédiées peut également dépendre de facteurs comme les 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.

  • Les équipes attendent-elles un niveau d'autonomie et d'indépendance élevé pour les opérations qui ont lieu au niveau des bases de données ?

Si vous répondez oui à au moins une de ces questions, vous devez envisager des bases de données dédiées pour les collections de sites.

Si vous décidez 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 quota 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 utilisant Windows SharePoint Services 2.0, vous pouvez également envisager les tailles que présentaient ces collections de sites et créer des bases de données basées sur ces tailles et non sur les estimations de quota.

Dans un environnement géré, les limites de taille de base 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 ;

  • Fenêtre de service (autrement dit, intervalle de temps) autorisée pour la restauration du contenu, telle que déterminée par l’accord de niveau de service. Par exemple, si la fenêtre de service pour restaurer le 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 de bases de données

h

D

Volume de contenu qui peut être sauvegardé dans la fenêtre cible, compte tenu des outils et méthodes de sauvegarde choisis

Go

Étant donné les deux valeurs de volume du contenu (B et D), la taille maximale gérable de la base de données pour votre organisation est la plus faible des deux valeurs.

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 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 les sites d'équipe, modifiez les paramètres en utilisant la page Gérer les bases de données de contenu pour la première base de données de contenu avec le nombre maximal de collections de sites correspondant à la taille de base de données cible et aux limites de taille de collection de sites (Nombre maximal de sites). Spécifiez également le seuil du nombre de sites qui déclenchent un avertissement (Avertissement relatif au niveau du site). Lorsque l'avertissement relatif au niveau du site est atteint, créez une base de données possédant 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 sites échoue.

Supprimer automatiquement les sites inutilisés

Vous pouvez augmenter la devise du contenu dans les sites d'équipes en supprimant automatiquement les sites inutilisés. Cela permet également de contrôler la croissance globale des sites d'équipe. Si des sites d'équipes sont hébergés dans une application Web distincte, vous pouvez gérer des sites d'équipes inutilisés différemment de sites personnels, en leur donnant une durée de vie plus étendue, par exemple, avant de commencer à exécuter des requêtes pour 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 création de la collection de sites, ou l’utilisation est confirmée. En d’autres termes, si l’utilisation d’un site n’a pas été confirmée pendant 90 jours, le propriétaire du site 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 une fois que le système a envoyé 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 l'environnement. Cependant, vous risquez qu’un site automatiquement supprimé contienne des données stratégiques. Pour réduire 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 importantes. 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 l'organisation et de la manière dont vous utilisez les sites d'équipe, envisagez d'utiliser des chemins d'accès pour organiser les URL des sites d'équipe. Par exemple, si vous souhaitez utiliser des URL différentes pour les sites d'équipes associés à d'autres divisions, vous pouvez utiliser des URL comme http://nom_société/nom_division/sites ou http://nom_société/research/sites. Si vous utilisez la Gestion de sites libre-service, l'URL par défaut des sites d'équipes est http://nom_serveur/sites. Cependant, vous pouvez également créer une inclusion de caractères génériques pour http://nom_serveur/team ou un préfixe de votre préférence pour les sites d'équipe.

NoteRemarque :

Si vous utilisez 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, reportez-vous aux 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 l'organisation. Par exemple, si le site Web des ressources humaines est un site d’équipe, 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 l'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 l'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 l'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 l'environnement ou une définition de site personnalisée) et penser à les rajouter à l'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 à l'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 l'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 l'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 des solutions, des composants WebPart et des modèles. Si les modèles personnalisés des sites d’équipes de l'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 des 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.

Nous vous recommandons d’utiliser des groupes de sécurité pour gérer les autorisations. Le tableau suivant fournit des instructions pour la configuration des autorisations et indique où les autorisations sont configurées.

Autorisation Instruction 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 (Windows SharePoint Services).

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, au lieu 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, au lieu 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 à bloquer, cliquez sur Modifier les niveaux d’autorisation 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échargeable suivant pour une lecture et une impression plus faciles :

Consultez la liste des livres disponibles à l’adresse Livres à télécharger pour Windows SharePoint Services.