Au cœur de SharePointDécentralisation de l'administration de site
Pav Cherny
Télécharger le code de cet article: SharePoint2008_06.exe (1160KB)
Microsoft Windows SharePoint Service (WS) 3.0 et Microsoft Office SharePoint Server (MOSS) 2007 prennent en charge une administration et un modèle de sécurité flexibles qui permettent aux entreprises informatiques de centraliser le contrôle des composants d'infrastructure, comme les serveurs Web et les serveurs de base de données, et de décentraliser le contrôle de
collections de sites et sites hébergés. La centralisation de l'infrastructure SharePoint® contribue à réduire la maintenance, à consolider la logique métier, à fournir un seul point d'accès aux ressources SharePoint et à éviter des investissements inutiles dans les technologies.
Simultanément, la décentralisation de l'administration de site vous permet de garantir que chaque département conserve un contrôle autonome de ses collections de sites, sites, bibliothèques de documents, listes, solutions de flux de travail et autres ressources SharePoint. Cependant, un effet secondaire de la délégation de l'administration de site aux différents départements est l'augmentation de la complexité de la maintenance pour le service informatique. Par exemple, comment assurer le suivi de l'utilisation des ressources, des sites SharePoint expirés et du contenu dépassé dans une infrastructure centralisée si vous n'avez pas accès aux collections de sites et aux sites au sein de votre environnement ?
Dans cet article, j'aborde le modèle de sécurité de WS 3.0, y compris ses avantages et implications lors de la délégation du contrôle administratif à différents départements sur des sites SharePoint tout en maintenant un contrôle administratif centralisé sur l'infrastructure SharePoint. J'y explique comment fonctionne l'administration déléguée de site, comment les autorisations d'accès et la suppression de sécurité au niveau site, liste et élément contribuent à préserver un environnement de travail sécurisé et convivial, et comment les administrateurs de batteries de serveurs Web peuvent accéder aux statistiques de site nécessaires sans autorisations SharePoint élevées.
Si vous souhaitez suivre mes explications dans un laboratoire de test, téléchargez le matériel associé à cette rubrique sur technetmagazine.com. Ce matériel comprend des instructions de déploiement détaillées pour une batterie de serveurs Web basée sur Windows Server® 2008 assez semblable à l'environnement de production d'une entreprise comptant plusieurs services.
Infrastructure SharePoint et administration de collection de sites
Vous pouvez générer une infrastructure SharePoint fondée sur un déploiement sur serveur unique ou un déploiement sur batterie de serveurs Web. En fait, les entreprises possèdent souvent les deux. Le déploiement sur serveur unique convient pour les services nécessitant une solution de collaboration rapide et directe. Les exigences en matière de performances et de fiabilité sont minimes. Les utilisateurs ont tendance à être compréhensifs si un serveur SharePoint de service (souvent déployé sur du matériel de poste de travail) est indisponible parce que la maintenance système relève de la responsabilité du service et que les utilisateurs de ce services ne sont, après tout, pas des administrateurs informatiques.
Il en va tout à fait différemment des ressources serveur maintenues par le service informatique. Les performances et la fiabilité deviennent des facteurs cruciaux, nécessitant souvent le déploiement de solutions à grande disponibilité pour garantir la conformité au contrat de niveau de service (SLA). Les déploiements de batteries de serveurs Web à équilibrage de charge, les clusters de basculement de SQL Server® et les bases de données enregistrés sur des réseaux SAN peuvent contribuer à répondre aux besoins en matière de performances et de grande disponibilité de votre entreprise. Voir la figure 1 pour une illustration de cette architecture.
Figure 1** Infrastructure SharePoint avec cluster de basculement SQL Server et SAN **(Cliquez sur l'image pour l'agrandir)
Comme vous pouvez le voir à la figure 1, plusieurs types d'administrateurs doivent collaborer pour maintenir les ressources d'une infrastructure SharePoint centralisée. Toutefois, chacun de ces administrateurs appréhende l'environnement avec une perspective différente. Par exemple, les serveurs de l'infrastructure sont limpides pour les administrateurs de collection de sites. Les administrateurs de collection de sites travaillent avec l'interface utilisateur SharePoint standard. Cette interface ne change pas, que vous hébergiez les sites sur un ordinateur de poste de travail exécutant WSS 3.0 dans votre bureau ou sur une batterie de serveurs Web dans un centre de données.
L'infrastructure SharePoint est également limpide pour les administrateurs de base de données et les ingénieurs de stockage SAN. Pour ces administrateurs, les bases de données SharePoint ne sont pas différentes des autres bases de données SQL Server et les numéros d'unité logiques du cluster de basculement SQL Server ne différent pas d'un autre numéro d'unité logique. L'administrateur le plus directement concerné par l'infrastructure SharePoint est l'administrateur de batterie de serveurs Web, qui pourtant n'a aucun contrôle sur les collections de sites, les bases de données ou les numéros d'unité logiques.
Il est donc juste de dire que ces administrateurs de collection de sites de département ignorent généralement les détails d'infrastructure. Après tout, il n'est pas nécessaire de connaître ces détails pour configurer des sites et déléguer des autorisations d'accès aux équipes et groupes d'un service. Il est facile de créer un nouveau site et de commencer à collaborer et des sujets comme les coûts de stockage élevés associés à la technologie SAN viennent rarement à l'esprit.
Avec chaque projet et initiative, de nouveaux sites d'équipe apparaissent, des sites expirés subsistent et du contenu dépassé n'est pas supprimé. L'environnement SharePoint croît ainsi à un rythme impressionnant jusqu'à atteindre une ampleur que les administrateurs système ne peuvent plus ignorer. Par exemple, l'environnement interne SharePoint de Microsoft contenait plus de 180 000 sites avant que Microsoft IT lance une initiative de simplification en 2006.
La formation des administrateurs de collection de sites peut aider à conserver le contrôle dans une infrastructure SharePoint centralisée. Appliquer des quotas et des verrous de collection de sites est également utile, bien que ces méthodes ne soient pas très efficaces lorsqu'il s'agit de sites d'équipe dépassés et de contenu gaspillant de précieuses ressources de stockage et de sauvegarde.
Le contenu obsolète n'engendre pas nécessairement le dépassement du quota d'une collection de sites. Bien sûr, vous pouvez configurer SharePoint pour envoyer des notifications par courrier électronique aux propriétaires de collection de sites et supprimer automatiquement les collections de sites inutilisées après une période spécifique en utilisant la fonction Confirmer l'utilisation des sites et leur suppression sur le site d'administration centrale de SharePoint 3.0, mais cette fonction ne fonctionne pas au niveau des sites individuels. Une collection de sites peut contenir des sites actuels et désuets, mais la fonction Confirmer l'utilisation des sites et leur suppression ne fonctionne pas à ce niveau de granularité.
Plus tard, je vous montrerai comment identifier des sites inutilisés et du contenu obsolète en vérifiant la date de dernière modification des documents et d'éléments de liste, même sans autorisation d'accès à la collection de sites. Cette fonctionnalité de rapport n'est pas disponible d'emblée, mais n'est heureusement pas difficile à implémenter.
Administration de site SharePoint décentralisée
La délégation de privilèges d'administration de site SharePoint est très simple. En utilisant le site d'administration centrale de SharePoint 3.0, l'outil de ligne de commande Stsadm.exe, ou un outil de configuration personnalisé, vous pouvez créer des applications Web, des chemins gérés et des collections de sites dans l'infrastructure. En tant qu'administrateur de batterie de serveurs Web, vous pouvez spécifier des administrateurs de collection de sites primaires et secondaires lors de la création d'une collection de sites. Ces administrateurs de collection de sites peuvent être des utilisateurs de domaine réguliers. Ils n'ont pas besoin d'autorisations administratives sur la batterie de serveurs Web ou sur d'autres serveurs d'infrastructure. Ils utilisent leurs navigateurs Web pour exécuter les tâches d'administration de site directement dans l'interface utilisateur SharePoint.
La figure 2 illustre l'administration de site déléguée selon les instructions détaillées que vous trouverez dans les feuilles de travail du matériel associé. Dans cet exemple, l'administrateur de batterie de serveurs Web a configuré des collections de sites séparées pour le service des ressources humaines (HR) (https://sharepoint/hr) et le service informatique (IT) (https://sharepoint/it).
Figure 2** Administration déléguée de site SharePoint **(Cliquez sur l'image pour l'agrandir)
Les administrateurs HR et IT peuvent alors utiliser la fonction Sites et espaces de travail disponible dans le menu Actions du site dans l'interface utilisateur SharePoint pour créer des sites de niveau inférieur et appliquer des autorisations depuis le site parent ou définir de nouvelles autorisations administratives et utilisateur pour les sites de niveau inférieur. Notez qu'à moins d'une configuration clairement différente, l'administrateur de batterie de serveurs Web ne peut pas accéder à des sites de niveau supérieur ou inférieur, l'administrateur HR ne peut pas accéder aux sites IT, et l'administrateur IT ne peut pas accéder aux sites HR, bien que tous les sites soient hébergés dans le même environnement SharePoint.
La conception des collections et des hiérarchies de sites dépend des exigences organisationnelles. Dans l'exemple de la figure 2, je n'ai pas créé de site maître par-dessus de https://sharepoint/hr et https://sharepoint/it. En d'autres termes, il n'y a pas de collection de sites sur le chemin https://sharepoint. Mais vous pouvez facilement créer une collection de sites sur ce chemin ou utiliser d'autres chemins gérés, comme https://sharepoint/sites/hr et https://sharepoint/sites/it.
Vous pouvez également créer des applications Web distinctes pour HR et IT pour établir des URL de base plus intuitives, comme http://hr et http://it, configurer des sites de portail généraux pour les départements, puis utiliser des composants WebPart cumulés pour répertorier les informations des sites de niveau inférieur dans ces sites maîtres. Des collections de sites séparées facilitent une administration autonome, contribuent à limiter l'accès aux informations des services, offrent des capacités de personnalisation individuelle des pages maîtres, des mises en page, des modèles, des composants WebPart et des contrôles de navigation, peuvent être utilisées pour placer des données sensibles dans des bases de données de contenu dédiées séparées d'autres collections de sites et bases de données de contenu.
Rôles, autorisations de site et filtrage de sécurité
Une fois que les collections de sites existent et que les autorisations administratives ont été déléguées, un administrateur de collection de sites peut ouvrir un site de niveau supérieur et utiliser la fonction Paramètres du site du menu Actions du site pour gérer la collection de sites. Ceci comprend l'ajout (ou la suppression) d'autres administrateurs de collection de sites avec des autorisations complètes pour tous les sites de la collection de sites, la création de groupes, l'association de ces groupes à des rôles et l'ajout d'utilisateurs à ces groupes pour accorder des autorisations de lecture et de contribution. Cela inclut également la configuration de sites de groupe et d'équipe de niveau inférieur.
Bien que vous puissiez accorder individuellement des autorisations SharePoint à des utilisateurs, il vaut mieux créer des groupes SharePoint en fonction de rôles spécifiques. Par exemple, SharePoint compte trois groupes par défaut pour les rôles Visiteurs, Collaborateurs et Propriétaires. Les visiteurs ont un accès en lecture seule, les collaborateurs peuvent ajouter des éléments aux listes et bibliothèques de documents et personnaliser des pages Web et les propriétaires ont un contrôle total.
Autre fonction méritant votre attention : SharePoint exécute un filtrage de sécurité fondée sur le rôle d'utilisateur, ce qui signifie que les utilisateurs voient seulement les liens et éléments de l'interface utilisateur pour lesquels ils possèdent une autorisation d'accès. Si vous refusez à un utilisateur l'accès à une ressource, comme une liste (en configurant des autorisations explicites sous Paramètres de la liste) ou un élément de liste précis (en utilisant la commande Gérer les autorisations du menu contextuel de l'élément), la liste ou l'élément disparaît pour cet utilisateur. Si l'utilisateur saisit directement l'URL de l'élément dans le navigateur, il obtient la page Erreur : Accès refusé.
La figure 3 illustre le filtrage de sécurité en action. L'administrateur HR possède les autorisations complètes et peut accéder au menu Actions du site pour exécuter des tâches administratives. Le Visiteur HR, d'autre part, possède seulement des autorisations de lecture pour la collection de sites et ne voit pas ce menu.
Figure 3** Filtrage de sécurité fondé sur les rôles d'utilisateur dans l'interface SharePoint **(Cliquez sur l'image pour l'agrandir)
Le filtrage de sécurité est utile car il masque les fonctions, liens et éléments inaccessibles, mais elle implique également que les administrateurs de batterie de serveurs Web ne peuvent pas utiliser l'interface utilisateur SharePoint pour répertorier des sites et des ressources de sites s'ils ne possèdent pas d'autorisations d'accès. Vous ne pourrez pas voir ces ressources dans les pages Web ou les composants WebPart. De plus, les ressources inaccessibles ne s'affichent pas dans les résultats de la recherche parce que SharePoint Enterprise Search exécute le filtrage de sécurité au moment de la requête selon l'identité de l'utilisateur soumettant celle-ci.
Et la ligne de commande ?
Si l'interface utilisateur graphique ne fournit pas d'accès aux informations désirées sans autorisations élevées au niveau de la collection de sites, l'outil de ligne de commande Stsadm.exe offre peut-être la solution. Par exemple, vous pouvez penser pouvoir utiliser la commande
Stsadm -o enumsites -url https://sharepoint
pour lister toutes les collections et tous les propriétaires de sites dans l'application Web https://sharepoint. Alors vous devriez pouvoir lister tous les sites de niveau inférieur en utilisant cette commande :
Stsadm -o enumsubwebs -url <site collection>
Pourtant, dans un environnement de batterie de serveurs Web, Stsadm.exe réagit généralement par un message d'erreur indiquant que les autorisations d'accès à cette base de données manquent. Stsadm.exe ne peut pas énumérer les collections de sites bien que vous soyez un administrateur de batterie de serveurs Web et puissiez gérer les collections de sites dans l'administration centrale de SharePoint 3.0. Le message suivant est le message d'erreur que vous obtenez si vous utilisez Stsadm.exe sur une batterie de serveurs Web sans les autorisations d'accès SQL Server :
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url https://sharepoint
<Sites Count="2">
<Site Error="Cannot open database "WSS_Content" requested by the login. The login failed.
Login failed for user 'CONTOSO\SPAdmin'.">
<Site Error="Cannot open database "WSS_Content" requested by the login. The login failed.
Login failed for user 'CONTOSO\SPAdmin'." />
L'administrateur de batterie de serveurs Web reçoit ce message d'erreur parce que Stsadm.exe s'exécute dans le contexte de l'utilisateur connecté, comme CONTOSO\SPAdmin, tandis que le site d'administration centrale de SharePoint 3.0 accède aux bases de données SharePoint dans le contexte du compte de système associé au pool d'applications de l'administration centrale de SharePoint v3, comme CONTOSO\WssConfigAdmin. Bien qu'attribuer les autorisations pour la base de données de contenu dans SQL Server à votre compte db_owner vous permette d'exécuter la commande Stsadm -o enumsites -url https://sharepoint, vous ne pouvez toujours pas énumérer les sites de niveau inférieur dans les collections de sites. La commande Stsadm -o enumsubwebs -url <site collection> induit le message Access is denied (Accès refusé). (Exception de HRESULT: 0x80070005 (E_ACCESSDENIED)) et vous retournez à la case Départ. Cependant, il existe une meilleure méthode ne nécessitant pas d'autorisations SQL Server élevées.
Informations de site dans des bases de données de contenu
Si vous ne pouvez pas obtenir les informations requises via les interfaces et outils SharePoint standard, vous devez accéder directement aux bases de données de contenu SharePoint. Mais tout d'abord un petit avertissement : cette méthode doit être utilisée en dernier recours ! Les bases de données de contenu reposent sur des schémas de propriété et des structures de base de données que Microsoft n'a que partiellement décrits dans les kits de développement logiciel WS 3.0 pour tenter de décourager les utilisateurs de travailler directement avec les bases de données. Si possible, vous devriez utiliser l'interface utilisateur SharePoint, les outils de ligne de commande, le modèle objet ou les services Web pour accéder aux informations désirées.
Si vous n'avez pas d'autre choix et devez accéder directement aux bases de données, vous devez au moins vous limiter à un accès en lecture seule. La modification du schéma ou des structures des bases de données n'est pas prise en charge et peut causer de graves problèmes qui pourraient vous obliger à restaurer des collections de sites à partir d'une sauvegarde ou à réinstaller la batterie de serveurs Web SharePoint.
Une alternative possible à l'implémentation d'une solution de création de rapports qui accède directement aux bases de données de contenu est de définir le compte d'administrateur de batterie de serveurs Web comme propriétaire secondaire dans la configuration de la collection de sites. Les administrateurs de batterie de serveurs Web peuvent effectuer cette étape sur le site d'administration centrale SharePoint 3.0. Vous pouvez trouver le lien des administrateurs de collection de sites sous Gestion des sites SharePoint sur la page Gestion des applications.
En tant qu'administrateur secondaire de collection de sites, vous pouvez ouvrir la collection de sites dans votre navigateur Web, affichez les Paramètres du site, puis cliquer sur le lien Rapport sur l'utilisation du site sous Administration du site, à condition d'avoir activé Traitement de l'analyse de l'utilisation dans l'administration centrale de SharePoint 3.0. Consultez le point Journalisation et création de rapports sur la page Opérations si vous voulez suivre les données d'utilisation dans des fichiers journaux sur vos serveurs SharePoint. La fonction Rapport sur l'utilisation du site est désactivée par défaut.
Toutefois, la création manuelle de rapports sur l'utilisation du site pour des collections de sites individuelles n'est pas pratique dans des environnements comptant un grand nombre de collections de sites ou présentant des exigences strictes vous empêchant d'octroyer les autorisations requises à des administrateurs de batterie de serveurs Web. Une approche plus pratique consiste à implémenter une application de création de rapports ASP.NET simple répertoriant toutes les collections de sites et tous les sites de la base de données de contenu avec les statistiques importantes, comme le nombre d'éléments, la taille totale combinée de tous les éléments et la date de dernière modification des éléments, comme illustré à la figure 4.
Figure 4** Obtenir directement des statistiques de site depuis une base de données de contenu **(Cliquez sur l'image pour l'agrandir)
Si vous exécutez cette application sous l'identité du compte de pool d'applications de l'administration centrale SharePoint v3, vous pouvez obtenir l'accès aux bases de données de contenu sans autorisations SQL Server élevées. Comme nous l'avons dit plus haut, le compte Administration centrale possède déjà les autorisations SQL Server requises.
Le matériel associé inclut une solution de création de rapports simple qui utilise des requêtes SELECT à la base de données de contenu sur le serveur SQL, ainsi que des instructions détaillées pour déployer cette solution sur un serveur Web. Il est important de noter que je n'ai implémenté aucune vérification de sécurité. La solution s'exécute avec une authentification anonyme.
Il n'est pas nécessaire d'authentifier l'utilisateur parce que le compte Administration centrale fournit le contexte de sécurité nécessaire pour accéder aux bases de données de contenu. J'ai utilisé un port personnalisé pour le site Web de la solution, bloqué par le pare-feu Windows® sur Windows Server 2008, pour que seul un utilisateur local puisse ouvrir l'application Web. Cela répondait aux exigences de sécurité de mon environnement de test, mais dans un environnement de production, vous devez accroître la sécurité, par exemple en activant l'authentification Windows et en configurant des autorisations d'accès restreint au répertoire virtuel de l'application ASP.NET.
Conclusion
SharePoint offre des capacités flexibles de collections de sites et d'administration de site qui vous permettent de centraliser l'infrastructure SharePoint tout en décentralisant l'administration de site selon les besoins spécifiques de votre entreprise. Une infrastructure centralisée peut profiter à des entreprises de toute taille parce qu'un environnement consolidé contribue à réduire les coûts, facilite le partage d'informations dans et entre les services, fournit la base à l'exploitation ciblée de connaissances de pointe afin de maintenir l'environnement avec une sécurité, une fiabilité et une évolutivité élevées et offre aux utilisateurs un point d'accès unique aux sites et ressources SharePoint du réseau d'entreprise.
Simultanément, chaque service et division peut rester maître de ses ressources SharePoint. Les administrateurs de batterie de serveurs Web peuvent désigner des administrateurs de collection de sites qui exécutent alors des tâches d'administration de site dans leurs zones de responsabilité sans autre intervention du service informatique.
Toutefois, avec le transfert de contrôle aux services, les administrateurs de batterie de serveurs Web perdent également la possibilité de contrôler l'utilisation des ressources dans l'infrastructure à l'aide des fonctionnalités et outils SharePoint standard. Bien sûr, appliquer des quotas aux bases de données de contenu, envoyer des rappels par courrier électronique aux administrateurs de collection de sites et suivre les données d'utilisation pour créer des rapports peut atténuer le problème. Néanmoins, pour gérer efficacement l'infrastructure SharePoint, les administrateurs de batterie de serveurs Web ont besoin d'autres outils qui extraient les métadonnées de site requises directement dans les bases de données de contenu en mode de lecture seule.
Les options disponibles incluent le recours à SQL Server 2005 Reporting Services ou à une solution de création de rapports similaire au niveau de l'entreprise. Comme l'illustre l'exemple du matériel associé, vous pouvez également utiliser des requêtes SQL Server SELECT pour obtenir les informations requises.
Pav Cherny est un expert informatique et auteur spécialisé dans les technologies Microsoft pour la collaboration et la communication unifiée. Ses publications incluent des livres blancs, des manuels de produits et des livres avec un intérêt particulier pour les opérations informatiques et l'administration système. Pav est le président de Biblioso Corporation, une entreprise spécialisée dans la documentation gérée et les services de localisation.
© 2008 Microsoft Corporation and CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable..