• Article

Au cœur de SharePointCréation de votre infrastructure SharePoint

Pav Cherny

Télécharger le code de cet article: SharePoint2008_05.exe (412KB)

Tout comme la messagerie électronique a transformé la communication d'entreprise, la collaboration Web modifie la façon dont les gens collaborent et partagent des informations. À titre d'exemple, regardez ce qu'offre la technologie SharePoint. Avec Microsoft Windows SharePoint Service (WSS) 3.0 et Microsoft Office SharePoint Server

(MOSS) 2007, vous pouvez créer des sites d'équipe, des portails, des solutions de gestion de contenu Web, des bibliothèques de documents et des centres de recherche, sans oublier l'intégration du système Microsoft® Office 2007, les formulaires basés sur XML, les flux de travail, la prise en charge de la mobilité, et ainsi de suite.

Cependant, il n'est pas toujours facile de démarrer avec SharePoint®. La terminologie peut prêter à confusion. L'architecture système peut être complexe et SharePoint nécessite que vous gériez des composants multiples, notamment IIS, Microsoft .NET Framework, SQL Server® et éventuellement d'autres technologies, telles que Business Intelligence, InfoPath® Forms Services, Rights Management Services (RMS), Exchange Server et ForefrontTM Security.

Vous pouvez vous perdre rapidement avec les intégrations et les personnalisations étant donné les nombreuses approches que vous pouvez prendre pour créer des solutions SharePoint, que ce soit par l'intermédiaire de l'interface utilisateur intégrée ou par programmation. De plus, lorsqu'une application SharePoint ne fonctionne pas, le dépannage peut être compliqué. Souvent, il faut penser comme un développeur d'applications pour comprendre les composants impliqués et la façon dont ils interagissent. Avec tous ces défis, par où commencer lorsque l'on souhaite créer une infrastructure SharePoint robuste, évolutive et facile à gérer ?

Dans cet article, je vous montrerai comment démarrer en commençant par créer une fondation avec une discussion sur une architecture de haut niveau, puis en plongeant dans le déploiement de WSS, avec notamment des personnalisations de base. À l'aide de la fonctionnalité Gestion de sites libre-service de WSS 3.0, vous verrez comment déléguer des permissions pour la création et la gestion de sites SharePoint à des utilisateurs individuels tout en conservant un contrôle administratif centralisé sur l'infrastructure SharePoint.

En commençant par observer l'architecture SharePoint, il devient plus facile de comprendre les étapes de déploiement et de configuration nécessaires pour implémenter une infrastructure flexible et évolutive. Jetons donc un œil aux dépendances, puis passons au déploiement de WSS 3.0. Pour obtenir des instructions de déploiement détaillées, reportez-vous aux documents d'accompagnement. Vous trouverez ces documents dans la section de téléchargements du site Web TechNet Magazine à l'adresse technetmagazine.com.

Architecture SharePoint

Il est conseillé d'envisager la technologie SharePoint du point de vue d'un architecte système. Vous n'avez pas à savoir les moindres détails, mais si vous connaissez les dépendances globales qui résultent de l'architecture SharePoint, vous arriverez à des solutions plus vite parce que vous pourrez prévoir ce que vous aurez besoin de configurer et pour quelles raisons.

SharePoint est une technologie qui fournit des services à des applications et des sites Web. C'est une solution de site Web basée sur IIS, s'intégrant à IIS par ASP.NET et utilisant un serveur principal de bases de données SQL Server pour enregistrer des données de configuration et du contenu. En bref, SharePoint combine essentiellement trois architectures différentes (IIS, .NET et SQL Server), comme illustré à la figure 1.

Figure 1 Architecture WSS 3.0 basée sur IIS 6.0 et ASP.NET 3.0

Figure 1** Architecture WSS 3.0 basée sur IIS 6.0 et ASP.NET 3.0 **(Cliquer sur l'image pour l'agrandir)

Ne vous laissez pas intimider par le diagramme. L'architecture peut paraître insurmontable au premier abord, si l'on considère le nombre de composants. Mais tous ces composants s'intègrent dans une structure logique qui, lorsqu'elle est examinée de façon systématique, permet de mieux voir les dépendances des composants.

Comme mentionné, SharePoint compte sur IIS et ASP.NET pour gérer les requêtes et les réponses HTTP. Les composants IIS standard, tels que le pilote en mode noyau HTTP (http.sys) et le Processus de travail (w3wp.exe), exécutent la mise en file d'attente et le routage initiaux des requêtes jusqu'à ce qu'elles arrivent au filtre ISAPI ASP.NET (aspnet_isapi.dll). Lorsque vous installez .NET Framework, la routine d'installation inscrit aspnet_isapi.dll dans la métabase IIS (C:\Windows\System32\Inetsrv\metabase.xml), comme ceci :

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

Une fois qu'IIS charge le filtre ISAPI ASP.NET, toutes les requêtes entrantes pour un site Web peuvent être transférées à ASP.NET. C'est important car SharePoint doit recevoir au final ces requêtes par ASP.NET. Pour accomplir ceci, SharePoint étend la configuration du site Web sélectionné en ajoutant un mappage d'applications génériques qui achemine toutes les requêtes entrantes, quelle que soit l'extension du fichier, vers le filtre ISAPI ASP.NET.

Vous pouvez voir ceci dans le Gestionnaire IIS une fois que vous avez installé WSS 3 à l'aide de l'option d'installation de base. La routine d'installation de WSS désactive le site Web IIS par défaut sur le serveur et crée un nouveau site Web par défaut sur le port 80 pour lequel le mappage d'applications génériques ASP.NET est défini, comme illustré à la figure 2.

Figure 2 Mappage d'applications génériques pour filtre ISAPI ASP.NET

Figure 2** Mappage d'applications génériques pour filtre ISAPI ASP.NET **(Cliquer sur l'image pour l'agrandir)

Pour qu'ASP.NET transfère des requêtes vers SharePoint, SharePoint doit également étendre la chaîne de requête HTTP par l'intermédiaire d'un objet HttpApplication personnalisé, implémenté au moyen d'une classe appelée SPHttpApplication dans l'assembly Microsoft.SharePoint. SharePoint définit cet objet d'application personnalisée dans le fichier d'application ASP.NET (global.asax), que vous pouvez trouver dans le système de fichiers du dossier racine des sites Web étendus SharePoint. Le code suivant répertorie le contenu d'un tel fichier global.asax :

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

ASP.NET analyse de façon dynamique et compile ce fichier pour instancier l'objet d'application SharePoint.

Pour chaque requête reçue, ASP.NET déclenche une série d'événements que l'application Web peut traiter, tels que BeginRequest, AuthenticateRequest, ProcessRequest et EndRequest. Les détails de traitement d'événements n'entrent pas dans le déploiement et la gestion de SharePoint, pourtant il est important de savoir que, en plus de SPHttpApplication spécifiée dans global.asax, SharePoint implémente des gestionnaires HTTP personnalisés et des modules définis dans le fichier web.config pour le site. Ainsi, SharePoint utilise un module HTTP basé sur la classe SPRequestModule, enregistré comme le premier module HTTP avant les modules ASP.NET standard. SPRequestModule initialise l'environnement d'exécution SharePoint, en enregistrant par exemple un composant SPVirtualPathProvider avec ASP.NET. SPRequestModule est destiné à une utilisation SharePoint interne, mais les développeurs de solutions SharePoint peuvent modifier le fichier web.config pour inscrire d'autres composants, tels que les gestionnaires et les modules HTTP. Avec à la fois des modules HTTP personnalisés et standard, SharePoint utilise ASP.NET, tout en conservant un contrôle serré sur toutes les requêtes adressées aux applications SharePoint.

Notez que lorsque vous créez une application Web à l'aide du site d'administration centrale SharePoint 3.0, WSS ajoute le mappage d'applications génériques ASP.NET au site Web IIS sélectionné et crée les fichiers global.asax et web.config dans le dossier racine du site Web. Chaque application Web utilise son propre groupe de fichiers global.asax et web.config de niveau supérieur.

Pour traiter des requêtes et renvoyer des informations significatives aux navigateurs, WSS 3.0 et MOSS 2007 comptent sur l'analyseur de pages ASP.NET standard, qui compile les pages ASP.NET demandées ou les traite dans aucun mode de compilation. Mais les pages ASP.NET que SharePoint transfère à l'analyseur ASP.NET ne se trouvent pas nécessairement où elles semblent être. Par exemple, vous ne pourrez pas trouver un fichier default.aspx dans le dossier racine d'un site Web étendu SharePoint, tel que le site d'administration centrale de SharePoint 3.0. Toutefois, vous ouvrez default.aspx lorsque vous affichez la page d'accueil de ce site Web. C'est le composant SPVirtualPathProvider qui virtualise l'environnement en chargeant le contenu de la page depuis le système de fichiers local ou une base de données de contenus SQL Server et en le transférant sous la forme d'un fichier virtuel à l'analyseur de page ASP.NET. Pour le site d'administration centrale, SharePoint charge le fichier default.aspx depuis le dossier C:\Program Files\lCommon Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin.

La page d'accueil, comme la plupart des autres pages du site SharePoint, est reliée à une Page maître ASP.NET (default.master) qui implémente une disposition commune pour les menus et les commandes de navigation. Default.master se trouve dans le dossier C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global et inclut des espaces réservés nommés pour d'autres pages de contenus qui peuvent également se trouver dans le système de fichiers local ou dans une base de données de contenus SQL Server. Le point à retenir est le fait que lorsque vous ouvrez un site SharePoint dans un navigateur Web, vous affichez en fait des informations d'une collection de pages de contenus qui ne se trouvent pas forcément sur le serveur Web local et qui sont arrangées selon une disposition définie dans une page maître.

En règle générale, les pages sans altération (ou pages non personnalisées dans la terminologie SharePoint) existent sous la forme de modèles de pages sur le système de fichiers local de chaque serveur SharePoint et les pages personnalisées sont écrites dans la base de données de contenus de sorte que tous les serveurs de SharePoint dans une batterie de serveurs Web ont accès à la même série de pages (voir figure 3). On suppose que les pages non personnalisées sont identiques sur tous les serveurs et sites de la batterie de serveurs Web. Cependant, si vous personnalisez une page de contenu ou une page maître dans un site SharePoint, peut-être en utilisant Office SharePoint Designer 2007, SharePoint enregistre automatiquement la page personnalisée dans la base de données de contenus.

Figure 3 Pages ASP.NET personnalisées et non personnalisées dans une application SharePoint

Figure 3** Pages ASP.NET personnalisées et non personnalisées dans une application SharePoint **(Cliquer sur l'image pour l'agrandir)

En plus des pages personnalisées et d'autres contenus de sites Web, SharePoint enregistre également des données de configuration dans une base de données SQL Server. SharePoint garde les données de configuration dans un endroit distinct du contenu parce que les données de configuration sont globales de nature tandis que le contenu est spécifique à chaque ensemble d'applications et de sites Web individuel. En conséquence, un groupe de serveurs Web peut avoir une seule base de données de configuration mais plusieurs bases de données de contenus.

Tous les serveurs WSS du groupe de serveurs Web utilisent la même base de données de configuration pour partager les métadonnées, les paramètres de configuration et les informations sur chaque site Web IIS ayant été étendu via SharePoint dans le groupe de serveurs Web. Les applications Web individuelles, de leur côté, peuvent être associées à une ou plusieurs bases de données de contenus (bien que chaque base de données de contenu ne puisse être associée qu'à une seule application Web).

La relation entre les sites Web IIS, les applications Web, les collections de sites, les sites et les bases de données de contenus peut être déroutante. Dans la terminologie SharePoint, le terme application Web se rapporte à un site Web IIS étendu SharePoint. Une application Web peut inclure plusieurs collections de sites et chaque collection de sites peut inclure un site de niveau supérieur et des sites de niveau inférieur qui partagent les mêmes paramètres de configuration.

Entre autres choses, la création de plusieurs collections de sites vous permet de déléguer l'administration de la collection de sites à des utilisateurs et groupes différents. Une seule collection de sites ne peut pas couvrir plusieurs bases de données de contenus, mais une application Web peut utiliser plusieurs bases de données de contenus pour plusieurs collections de sites afin d'augmenter l'évolutivité et de mitiger l'impact de performance d'un gros site qui génère une quantité significative d'activité de base de données sur d'autres sites SharePoint. Cependant, il est déconseillé de placer chaque site SharePoint dans sa propre collection de sites parce que cette forme de déploiement restreint les fonctionnalités intersites.

WSS 3.0 ne prend pas en charge les recherches de contenus sur plusieurs ensembles de sites. De telles recherches nécessitent MOSS 2007 ou Microsoft Search Server 2008. Vous pouvez par exemple créer une application Web et un site de niveau supérieur pour http://contoso et un administrateur de collection de sites peut ensuite créer des sites de niveau inférieur en utilisant l'interface utilisateur SharePoint, avec par exemple http://contoso/info et http://contoso/events. Tous ces sites existent dans la même base de données de contenus parce qu'ils appartiennent au même ensemble de sites.

En tant qu'administrateur de batterie, vous pouvez également utiliser un chemin géré, tel que /sites, puis définir d'autres collections de sites, telles que http://contoso/sites/IT et http://contoso/sites/HR, dans l'administration centrale de SharePoint 3.0. Ces trois collections de sites (http://contoso, http://contoso/sites/IT et http://contoso/sites/HR) peuvent avoir des administrateurs de collection de sites, paramètres de configuration et bases de données de contenus différents, mais on y accède par le même site Web IIS (http://contoso) et ils utilisent la même identité de pool d'applications de l'application Web.

Bien entendu, il y a beaucoup d'autres détails, mais cette relation entre IIS, ASP.NET et SQL Server est particulièrement importante pour se familiariser avec SharePoint. Si vous souhaitez en savoir plus sur l'architecture SharePoint, je vous recommande l'article MSDN Magazine® de Ted Pattison intitulé « Découvrez les importantes améliorations de SharePoint Services 3.0 destinées aux développeurs » disponible à l'adresse https://www.microsoft.com/france/msdn/aspnet/Ameliorations-SharePoint-Services-30.mspx.

Éléments d'infrastructure SharePoint

Passons maintenant à une infrastructure SharePoint flexible. Comme vous l'avez certainement remarqué, nous avons besoin de Windows Server®, IIS, .NET Framework 3.0 (à la fois pour ASP.NET et Windows® Workflow Foundation), WSS 3.0 ou MOSS 2007 et SQL Server. Bien que vous ayez raison d'attendre avec impatience IIS 7.0 sur Windows Server 2008, nous utiliserons IIS 6.0 sur Windows Server 2003 dans cet exemple car à l'heure où j'écris cet article, c'est la version la plus couramment déployée. Nous garderons WSS 3.0 parce que nous n'avons pas besoin de fonctionnalités spécifiques à MOSS 2007 pour un premier pilote SharePoint.

Pour une approche minimaliste, vous pouvez installer WSS 3.0 avec tous les composants requis sur un seul ordinateur (comme décrit dans le document pdf disponible parmi les documents d'accompagnement de cet article). Ceci conviendra pour un serveur de laboratoire ou un petit environnement de groupe de travail. Cependant, si vous avez l'intention de vous concentrer sur la flexibilité de votre infrastructure SharePoint, ne démarrez pas avec un déploiement autonome dans votre environnement de production. Dans un but de disponibilité aussi bien que d'évolutivité, mieux vaut commencer avec une infrastructure sur plusieurs niveaux et ajouter de nouveaux serveurs si nécessaire.

La figure 4 montre l'infrastructure SharePoint que je recommande si vous cherchez une configuration système simple et flexible. Elle inclut une batterie de serveurs Web de deux serveurs SharePoint et un ordinateur séparé exécutant SQL Server. Cette configuration élimine une surcharge de traitement de bases de données sur les serveurs Web, augmente la disponibilité, l'évolutivité et facilite la maintenance système. Notez que vous avez besoin d'Active Directory® parce qu'il s'agit d'une exigence logicielle de WSS 3.0 dans un déploiement de batterie de serveurs Web. Pour obtenir des instructions de déploiement détaillées, consultez le fichier pdf sur l'infrastructure SharePoint de base parmi les documents d'accompagnement.

Figure 4 Infrastructure SharePoint de base pouvant prendre en charge une augmentation future

Figure 4** Infrastructure SharePoint de base pouvant prendre en charge une augmentation future **(Cliquer sur l'image pour l'agrandir)

Le compte de domaine que vous utilisez pour déployer SharePoint dans cette organisation requiert les permissions d'un administrateur local sur les serveurs Web. Il est également nécessaire d'ajouter ce compte aux rôles SQL Server dbcreator et securityadmin ainsi qu'au rôle de base de données db_owner pour la base de données principale dans SQL Server 2005, comme illustré dans le fichier pdf sur l'infrastructure SharePoint de base. Vous pouvez ensuite utiliser l'Assistant Configuration des produits et technologies SharePoint pendant l'installation de WSS 3.0 pour créer la base de données de configuration nécessaire pour la batterie de serveurs Web et une base de données de contenus pour le site de l'administration centrale de SharePoint 3.0. Autrement, un administrateur SQL Server doit configurer ces bases de données pour vous et ajouter les comptes de système WSS au rôle db_owner.

Il est important de se souvenir que le compte utilisateur que vous utilisez pour installer SharePoint n'est pas le compte que SharePoint utilise pour accéder à la base de données de configuration ou à la base de données de contenus pour le site d'administration centrale. SharePoint utilise le compte de système configuré comme l'identité du pool d'applications pour le site d'administration centrale de SharePoint 3.0.

L'Assistant Configuration des produits et technologies SharePoint vous invitera à saisir les informations de compte. Il est recommandé d'utiliser un compte d'utilisateur de domaine dévoué pour ceci, tel que CONTOSO\WssConfigAdmin. En général, j'utilise des comptes utilisateur dédiés individuels pour les applications Web supplémentaires que je crée ultérieurement. L'utilisation d'un pool d'applications distinct pour chaque application Web aide à garantir l'isolation des processus et l'utilisation d'un compte utilisateur différent pour chaque pool d'applications aide à garantir l'isolation de la sécurité. Notez cependant qu'il s'agit là simplement d'une approche possible et que la facilité de gestion et l'impact potentiel sur les performances doivent être évalués en fonction de votre propre environnement et de vos propres exigences métier.

Le compte de service de recherche est un autre compte système important qu'un administrateur de domaine doit créer pour vous. Vous pouvez utiliser le compte Administration centrale, mais pour des raisons de sécurité il vaut mieux utiliser un compte de recherche dédié, tel que CONTOSO\WssSearch, qui n'a pas d'autorisations administratives et ne peut pas modifier de contenu. L'autorisation d'écriture dans les bases de données de contenus n'est pas nécessaire parce que le service de recherche analyse uniquement les contenus à des fins d'indexation et il conserve les données de recherche dans une base de données distincte.

Lorsque vous créez une application Web dans une batterie de serveurs, vous pouvez associer cette base de données de contenus à un serveur de recherche, ce qui ajoute de façon implicite le compte du service de recherche correspondant à la stratégie de lecture complète de l'application Web. Les serveurs de recherche sont des serveurs SharePoint exécutant le service de recherche de Windows SharePoint Services. Si vous avez suivi les instructions détaillées du fichier pdf sur l'infrastructure SharePoint de base, vous avez configuré les deux serveurs Web comme des serveurs de recherche pour pouvoir distribuer la charge d'analyse et d'indexation de plusieurs bases de données de contenus. Cependant, il est également possible de configurer un serveur de recherche dédié dans une batterie de serveurs Web, exclue de l'équilibrage de la charge réseau et des connexions client afin que les connexions client ne soient pas affectées par les activités d'analyse.

Gestion de sites en libre-service

Avec une infrastructure SharePoint de base en place, nous pouvons déléguer l'administration de collections de sites et de sites à des départements et des utilisateurs individuels sans décentraliser le contrôle administratif d'Active Directory, de la batterie de serveurs Web ou des bases de données SQL Server. En tant qu'administrateur de batterie, vous collaborez avec des administrateurs Active Directory et SQL Server pour configurer des comptes de pool d'applications et des bases de données de contenus pour vos applications Web. À l'intérieur de ces applications Web, vous créez ensuite des collections de sites et désignez des administrateurs de collections de sites qui auront le droit de créer des sites de niveau inférieur. De cette façon, les administrateurs de collections au sein de départements individuels peuvent gérer leurs ressources SharePoint avec une participation minimale du service informatique, comme illustré à la figure 5.

Figure 5 Administration de site décentralisée dans une infrastructure SharePoint centralisée

Figure 5** Administration de site décentralisée dans une infrastructure SharePoint centralisée **(Cliquer sur l'image pour l'agrandir)

Il est également possible de donner aux utilisateurs la possibilité de créer des collections de sites sous des chemins gérés (tel que le chemin /sites ou les autres chemins gérés avec les inclusions de caractères génériques que vous créez dans l'administration centrale de SharePoint 3.0). Si vous activez la fonctionnalité Gestion de sites libre-service dans une application Web, les utilisateurs peuvent créer leurs propres collections de sites et gérer les groupes de sites et les autorisations au sein de l'interface utilisateur SharePoint. Contrairement aux sites de niveau inférieur, les collections de sites n'héritent pas des autorisations d'un site parent.

La gestion de sites libre-service n'est pas adaptée à tous les environnements SharePoint et elle est désactivée par défaut. Si vous l'activez, vous risquez de vous retrouver avec un grand nombre de collections de sites rarement utilisées dans vos bases de données de contenu. Cependant, cette fonctionnalité démontre très clairement la flexibilité de l'administration SharePoint et je vous recommande de la tester dans votre déploiement pilote. (Par ailleurs, il y existe des options dans SharePoint pour notifier les utilisateurs et/ou les administrateurs des sites inactifs pour qu'ils puissent les supprimer si nécessaire). Vous devez activer explicitement la Gestion de sites libre-service pour une application Web, comme décrit dans le fichier pdf sur l'activation de la gestion de sites libre-service dans les documents d'accompagnement.

Personnalisation de SharePoint

Ressources SharePoint

À ce stade, il est tout naturel de vouloir inclure le logo, le nom et les couleurs de l'entreprise dans l'interface utilisateur SharePoint. Soyez conscient, cependant, que vous êtes sur le point faire passer votre projet SharePoint au niveau de développeur ASP.NET. Il vous faut au minimum un système de développement, tel qu'un serveur WSS 3.0 autonome avec Microsoft Office SharePoint Designer 2007 (voir le fichier pdf sur l'installation de SharePoint Designer dans le matériel d'accompagnement) pour pouvoir créer et tester vos personnalisations sans affecter l'environnement de production. Nous vous recommandons également de visiter les Centres de développement Windows SharePoint Services à l'adresse msdn2.microsoft.com/sharepoint pour en savoir plus sur toutes les options de personnalisation dans SharePoint.

Bien que le développement de SharePoint n'entre pas dans le cadre de cet article, permettez-moi de mentionner quelques aspects que vous devez prendre en compte. SharePoint enregistre des pages personnalisées dans la base de données de contenus de la collection de sites correspondante. En d'autres termes, toutes les personnalisations que vous appliquez aux pages de sites, pages d'application, pages maîtres, feuilles de style, et ainsi de suite, dans un site SharePoint, s'appliquent uniquement à la collection de sites ou au niveau du site. C'est parfait pour les administrateurs de collections de sites individuelles qui souhaitent ajuster l'apparence de leurs sites à l'aide de SharePoint Designer 2007, mais ce n'est pas terrible pour l'administrateur de batterie qui souhaite appliquer l'identité d'entreprise sur l'ensemble des applications Web, des collections de sites et des sites d'une batterie de serveurs Web.

Vous pouvez créer des thèmes de sites personnalisés ou des définitions de sites personnalisées en fonction d'une copie d'un thème SharePoint standard ou d'une définition de site. Vous pouvez également créer des pages maîtres personnalisées et les ajouter dans la Galerie de pages maîtres. Cependant, aucune de ces options n'applique la personnalisation globale si la Gestion de sites libre-service est activée parce qu'un utilisateur autorisé à créer des collections de sites ou des sites peut toujours sélectionner un modèle de site standard qui n'affiche pas l'identité de l'entreprise.

Pour la personnalisation globale, il est nécessaire que vous remplaciez les composants SharePoint par défaut par vos composants personnalisés. Les développeurs font de gros efforts pour accomplir ceci sans modifier les fichiers originaux. Une approche consiste à modifier la configuration des répertoires virtuels dans le Gestionnaire IIS et à les orienter vers de nouveaux dossiers contenant des fichiers personnalisés. Une autre méthode consiste à implémenter un module HTTP ou un filtre ISAPI personnalisé qui réécrit les URL pour rediriger les requêtes de pages par défaut spécifiques vers des versions personnalisées.

Conclusion

Je me suis concentré sur les éléments essentiels de l'établissement d'une infrastructure SharePoint avec WSS 3.0. Je n'ai pas abordé d'autres fonctionnalités, telles que les flux de travail, les enquêtes, l'intégration de messagerie et l'antivirus, ni les fonctionnalités spécifiques à MOSS 2007 telles que les portails, les répertoires de sites et les catalogues de données métier. Les personnalisations pour l'administration de site et la promotion professionnelle ont touché uniquement aux possibilités au sein de SharePoint. Vous pouvez exécuter d'autres personnalisations avec WSS 3.0 en programmant des applications personnalisées dans Visual Studio®.

L'infrastructure est assez robuste pour prendre en charge une évolutivité future si vous ajoutez plus de serveurs Web ou de serveurs de bases de données. Et avec le déploiement pilote de quelques personnalisations, les utilisateurs peuvent créer des sites individuels et se familiariser généralement avec SharePoint. De cette façon, vous établissez les composants de base fondamentaux adoptés par l'utilisateur, ainsi que le matériel et le logiciel, qui sont assez flexibles pour permettre des modifications et servent de base pour un déploiement de production complet.

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.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.