Utility Spotlight: Upgrade Toolkit for SharePoint Sites and Templates

Article
08/24/2016

Coup de projecteur sur les utilitairesBoîte à outils de mise à niveau pour les sites et modèles SharePoint

Luis Câmara Manoel and Peter Skjøtt Larsen

Télécharger le code de cet article: Upgrade Toolkit for Windows SharePoint Services Sites and Templates (699KB)

Avec l’arrivée récente de Windows SharePoint Services (WSS) 3.0, bon nombre d’administrateurs sont confrontés à la tâche de mise à niveau de leurs sites et données WSS 2.0 vers leurs nouveaux environnements WSS 3.0. Même si WSS 3.0 fournit des outils étendus, qui permettent d’effectuer, de manière appropriée, la migration des données de site et

de mettre à niveau la structure des sites, il peut être nécessaire d’effectuer des opérations supplémentaires pour mettre à niveau la structure des sites ou des modèles de sites personnalisés.

Cependant, des opérations supplémentaires peuvent être nécessaires à la mise à niveau de la structure des sites ou modèles de sites personnalisés. Heureusement, l’équipe Microsoft® Solution Accelerator a publié le Guide de boîte à outils de mise à niveau pour les sites et modèles Windows® SharePoint® Services, qui fournit des aides et des outils concernant cette pratique (voir l’encadré « Ressources WSS »). Cet article traite de certains des défis et des solutions associés à la mise à niveau de sites personnalisés vers des environnements WSS 3.0. Mais tout d’abord, reportez-vous à l’encadré « Terminologie WSS » pour obtenir la définition de termes courants.

Le processus de mise à niveau

Pourquoi devez-vous procéder à la mise à niveau ? Il y a de nouvelles fonctionnalités WSS 3.0 qui peuvent inciter les propriétaires de sites à effectuer une mise à niveau :

La Corbeille, qui permet aux utilisateurs de récupérer des documents supprimés par inadvertance.
La sécurité au niveau des éléments de dossier, qui permet aux administrateurs du site de contrôler les personnes ou les groupes qui ont accès aux dossiers.
L’envoi de courriers électroniques à des listes, qui permettent à des listes comme des listes de publication de blog sur un site SharePoint de recevoir du contenu par courrier électronique.
Le bouton Actions du site, qui permet aux utilisateurs de créer facilement des sites et des pages, de modifier des pages et de gérer les paramètres du site.
Les barres de navigation, qui fournissent un contexte de navigation immédiat à l’utilisateur.
Les vues mobiles, qui permettent aux utilisateurs mobiles de tirer parti de fonctions de synchronisation hors ligne pratiques.
Les fils RSS, qui permettent aux programmes compatibles RSS comme Internet Explorer 7.0 et Outlook® 2007 d’extraire des informations de listes.
La gestion des versions des bibliothèques de documents, qui permet une gestion des versions et un contrôle limités pour la vérification des documents avant la modification.

Dans la mesure où le processus de mise à niveau des sites et des modèles dépend du respect d’étapes spécifiques avant et après la mise à niveau réelle du serveur vers WSS 3.0 (voir la Figure 1), les exigences de mise à niveau de la définition du site et du modèle constituent une étape importante dans la stratégie de mise à niveau globale vers WSS 3.0. Les propriétaires de sites et les responsables de serveurs doivent collaborer pour déterminer les sites et les modèles qui doivent être instanciés et mis à niveau vers un environnement WSS 3.0. Une fois que ces sites personnalisés ont été sélectionnés, le travail de mise à niveau peut commencer.

Figure 1 Flux d’opérations de mise à niveau du site WSS et du modèle de site

Figure 1** Flux d’opérations de mise à niveau du site WSS et du modèle de site **(Cliquer sur l'image pour l'agrandir)

Identifier les modèles de site personnalisé

Comment déterminez-vous si les sites ont été personnalisés ? WSS 3.0 fournit l’outil d’analyse pré-mise à niveau, qui génère un rapport sur les modifications apportées aux modèles de sites pour la ferme entière. Vous devez exécuter cet outil avant de commencer la migration pour sélectionner les modèles de site qui nécessitent une attention particulière.

L’outil fournit un rapport au format XML comme indiqué à la Figure 2. L’élément unghostedPage indique qu’un site a été personnalisé.

Figure 2 Rapport de l’outil d’analyse pré-mise à niveau sur les modifications apportées aux modèles de sites

<?xml version=”1.0” encoding=”utf-8”?>
<summary>
  <sites>
    <site url=”http://mscc-shr-v3-01” storage=”172767226”>
      <webs>
        <web url=”http://mscc-shr-v3-01/Board of Directors-Basic”>
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/default.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/EditForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/Upload.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/WebFldr.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and 
                Business Planning/Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and 
                Business Planning/Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and 
                Business Planning/Forms/EditForm.aspx” />

Définitions de site personnalisé

La plupart des sites WSS 2.0 personnalisés que vous souhaitez mettre à niveau ont probablement été générés à l’aide de modèles créés à partir de définitions de site WSS standard. Il est possible, cependant, que certains modèles de sites personnalisés aient été générés à partir de définitions de site personnalisé. Cela peut être le cas si les développeurs de votre entreprise ont créé des définitions de site personnalisé ou si vous avez acheté des applications tierces ou des modèles créés à partir de définitions de site personnalisé. Cet article ne décrit que le scénario de définition de site standard. Pour plus d’informations sur le scénario de modèles de sites personnalisés, reportez-vous à l’encadré « Ressources WSS ».

Après avoir vérifié que vos fichiers .stp et vos sites sont vraiment créés à partir de définitions de site standard (ce qui signifie que les définitions de site de mise à niveau existent dans WSS 3.0) vous pouvez poursuivre l’installation et l’instanciation de vos sites.

Pour mettre à niveau des modèles de site WSS 2.0 spécifique, vous devez d’abord installer les modèles sur un serveur WSS 2.0 (voir l’étape 1 de la Figure 1). Ensuite, vous devez créer des sites basés sur chacun des modèles installés.

Pour rationaliser le processus d’installation de plusieurs fichiers .stp, d’instanciation de plusieurs sites et le nettoyage des fichiers temporaires sur le serveur une fois que le processus de mise à niveau est terminé, l’accélérateur de solution fournit un ensemble de scripts qui réutilisent Stsadm.exe (pour plus d’informations, voir l’encadré « Scripts de solution »). Stsadm.exe est une application de ligne de commande qui propose une série complète d’opérations WSS pour gérer des serveurs et des sites SharePoint. Les scripts de solution automatisent ce processus en vous permettant d’installer et d’instancier par lot ou d’effectuer ces tâches séquentiellement. Les gains de temps peuvent être considérables si de nombreux fichiers .stps doivent être installés et si de nombreux sites doivent être instanciés.

Scripts de solution

Le processus d’installation et de création de sites utilise deux scripts qui exécutent Stsadm.exe:

Miginststp.cmd installe les modèles de sites à l’aide de l’opération addtemplate de Stsadm.exe. Cette opération comporte les paramètres _SOURCEFILELOCATION, _SOURCEFILENAME et _FILETITLE.
MigMakeSite_1.cmd crée les sites. MigMakeSite_1.cmd exécute l’opération createweb de Stsadm.exe. Cette opération comporte les paramètres _SERVERURL, _SITENAME, _SITETEMPLATENAME et _SITETITLE.

Exécutez ces scripts sur le serveur local WSS 2.0 avec l’accès à l’emplacement de vos fichiers de modèle de site (.stp) enregistrés. Pour exécuter ces scripts, vous devez être membre du groupe local Administrateurs sur le serveur ou membre du groupe Administrateurs WSS avec des droits de création de sites. Le Guide de boîte à outils de mise à niveau pour les sites et modèles Windows SharePoint Services décrit en détail comment tirer pleinement parti de ces scripts. Avec vos sites .stps installés et instanciés, vous êtes maintenant prêt à continuer la mise à niveau du serveur. Les approches de la mise à niveau WSS 3.0 sont expliquées en détail dans « Mise à niveau vers Windows SharePoint Services 3.0 » (voir le lien figurant dans l’encadré « Ressources WSS »).

Terminologie WSS

Windows Sharepoint Services possède sa propre terminologie. Voici un glossaire court des termes généralement utilisés.

Définition de site Série de fichiers qui définit un type de site spécifique. Une définition de site inclut des fichiers .xml, .aspx, .ascx et des fichiers Page maître, ainsi que des fichiers de modèles de liste et des fichiers de contenu stockés dans un dossier spécial sur le serveur Web frontal. WSS est fourni avec une série de définitions de site standard, prêtes à l’emploi, dont Site d’équipe, Site vide et Espace de travail du document. À l’origine, ce sont les seuls modèles de sites enregistrés dans la galerie de modèles de sites et qui sont disponibles dans la liste Sélectionnez un modèle dans Nouveau site Sharepoint.

Modèle de site Les modèles de sites indiquent comment instancier un site Sharepoint. Pour créer un site Sharepoint, vous devez sélectionner un modèle de site qui sert de base au site. Par exemple, vous pouvez créer un site appelé « Conseil d’administration », basé sur le modèle standard « Site vide ». Vous pouvez ensuite ajouter des listes, des bibliothèques, des composants WebParts et d’autres personnalisations au site instancié. Pour que ces personnalisations soient disponibles pour d’autres personnes, vous pouvez enregistrer ce site comme modèle appelé « Conseil d’administration », basé sur la définition de site « Site vide ». WSS enregistre le modèle de site personnalisé sous forme de fichier .stp (modèle de site), le place dans la galerie des modèles de sites et l’affiche dans la liste « Sélectionnez un modèle » de la page Nouveau site Sharepoint afin que les utilisateurs puissent par la suite créer des sites basés sur ce modèle. Les modèles de sites contiennent une série de fichiers de configuration de site, dont les fichiers .xml, .aspx, image et d’autres fichiers, qui sont ensuite compressés en un seul fichier .stp (les fichiers .stp possèdent les mêmes fonctions que les fichiers .cab). Le plus important de ces fichiers est le fichier Manifest.xml, qui contient des informations critiques telles que la structure du site et la navigation, les listes et les bibliothèques, le positionnement des composants WebPart, les définitions de liste personnalisées et la définition de site sur lequel le modèle de site personnalisé est basé.

Modèle d’application Modèles de site Windows SharePoint Services développés pour répondre aux besoins de processus métier ou de tâches spécifiques. Ils sont publiés par Microsoft et peuvent être téléchargés gratuitement par les clients de WSS.

Site personnalisé Site Sharepoint avec une interface utilisateur modifiée.

Page maître Zone dans laquelle les informations de disposition par défaut, comme la bannière, les commandes de navigation et les autres menus peuvent être enregistrés pour que l’interface soit cohérente sur tout le site.

Pages dupliquées Pages dont le contenu n’est pas enregistré dans la base de données WSS, mais plutôt lu à partir d’un fichier de définition de site. Les pages dupliquées n’ont pas été personnalisées.

Pages non dupliquées Pages qui ont été modifiées dans le fichier de définition de site et dont le contenu est stocké dans la base de données WSS.

Après la mise à niveau du serveur : contrôle du site

Vous êtes maintenant arrivé à l’étape 2 du flux d’opérations de mise à niveau (voir la Figure 1). Les étapes à suivre pour mettre à niveau le site et le modèle sont les suivantes :

Ouvrez et vérifiez les sites mis à niveau.
Appliquez la page maître par défaut.
Corrigez les problèmes de fonctionnalité et de disposition au niveau des nouveaux sites.
Enregistrez les sites corrigés sous formes de nouveaux modèles de sites WSS 3.0.
Redéployez les nouveaux modèles de sites WSS 3.0 sur le serveur.
Créez des sites à partir des modèles de sites redéployés.
Ouvrez les nouveaux sites et vérifiez qu’ils fonctionnent de la manière escomptée.
Lancez le processus de nettoyage.

Réinitialisation de la définition de site

Lorsque vous ouvrez votre site mis à niveau pour la première fois, vous découvrez qu’il ressemble toujours beaucoup à un site WSS 2.0. Pour que le site se présente davantage comme un site WSS 3.0, vous devez d’abord réinitialiser la définition de site sur votre nouveau site WSS 3.0. Cette opération corrige la plupart des problèmes de disposition et vous ne perdez pas les personnalisations apportées aux composants WebParts, sous réserve que ces composants se trouvent déjà dans une zone WebPart qui existe dans la page de définition de site. Cette action applique également la page maître par défaut à toutes les pages de vos sites.

Une page maître, comme son nom l’indique est une zone dans laquelle les informations de disposition par défaut, comme la bannière, les commandes de navigation et les autres menus peuvent être enregistrées pour préserver la cohérence de l’apparence. Cela permet d’apporter des modifications à la conception dans la page maître et que ces modifications soient répercutées sur tout le site. En appliquant des pages maîtres, toutes les fonctionnalités WSS 3.0 natives seront activées dans vos sites mis à niveau.

Même si le site doit dorénavant se présenter et fonctionner comme un site WSS 3.0 natif, vous pouvez toujours rencontrer des aspects qui posent problème comme les forums de discussion, les composants WebPart personnalisés, les liens hypertextes et les thèmes.

Correction des éléments défaillants

Des problèmes peuvent survenir dans les modèles de sites mis à niveau et personnalisés. Voici certains des problèmes les plus courants et quelques idées simples pour les corriger.

C’est la feuille de style WSS 2.0 par défaut qui continue à être appliquée à un site. Supprimez l’ancienne feuille de style dans Sharepoint Designer.

Des composants WebPart manquent ou ne se trouvent pas au bon endroit. Déplacez ou insérez les composants WebPart à l’aide de SharePoint Designer.

Les composants WebPart ne fonctionnent pas correctement. Supprimez les composants WebPart qui ne sont pas compatibles avec WSS 3.0 et prenez contact avec le développeur WebPart pour demander si des composants WebPart correspondants ont été générés pour les environnements WSS 3.0.

L’apparence des listes et des bibliothèques personnalisées n’est pas correcte. Enregistrez vos données existantes. Ensuite recréez la liste ou la bibliothèque personnalisée, et importez les données enregistrées.

Les fonctionnalités WSS 3.0 activées ne sont pas disponibles. Les fonctions de collaboration d’équipe ont peut-être été activées explicitement dans les fonctionnalités du site.

Les liens hypertextes ne fonctionnent plus. Les liens hypertextes codés en dur peuvent nécessiter une mise à jour manuelle.

Le thème a été modifié. Appliquez le thème WSS approprié.

Opération presque terminée

Comme la fin des processus approche et que les problèmes ont tous été corrigés, il est temps d’effectuer une vérification finale des sites. Vous devez enregistrer les sites corrigés sous forme de modèles de sites WSS 3.0, exécuter une nouvelle installation et une nouvelle instanciation de site .stp (vous pouvez également utiliser les scripts pratiques ici) et, enfin, ouvrir le site pour vérifier que tous les problèmes ont été pris en compte et que vos sites mis à jour et vos fichiers .stps sont prêts à être distribués dans votre environnement de travail.

Alternatives à la mise à niveau

La mise à niveau des modèles à l’aide des outils et des processus automatisés décrits ici ne constitue peut-être pas toujours la meilleure approche. Si vous utilisez des modèles de tiers très personnalisés, vous n’arriverez peut-être pas à mettre à niveau les modèles tout seul et il peut être plus approprié d’attendre une nouvelle version du modèle. Dans d’autres cas, il peut être préférable de créer un modèle totalement nouveau dans WSS 3.0, puis de mettre en œuvre les fonctionnalités de l’ancien modèle.

Modèles d’application

Il existe un ensemble de modèles d’application développés par Microsoft, disponibles pour WSS 2.0 et WSS 3.0. Le nouvel ensemble WSS 3.0 inclut des versions mises à niveau de certains modèles d’application WSS 2.0. Si vous avez utilisé l’un de ces modèles, vous pouvez transférer la version WSS 3.0 mise à niveau dans votre environnement WSS 3.0.

Si vous avez utilisé l’un des modèles d’application WSS 2.0 qui n’a pas été mis à niveau pour WSS 3.0, l’accélérateur de solution met à votre disposition un ensemble de modèles d’applications WSS 2.0 qui ont été mis à niveau de manière à fonctionner dans un environnement WSS 3.0.

Résumé

La boîte à outils de mise à niveau pour les sites et modèles Windows SharePoint Services peut s’avérer extrêmement utile pour vous aider à conserver vos modèles, sites et personnalisations WSS 2.0 dans votre environnement WSS 3.0. Pour plus d’informations à ce sujet et pour vous procurer la boîte à outils, visitez les sites indiqués dans l’encadré « Ressources WSS ».

Nous souhaitons remercier Betty Houser pour ses précieuses contributions à cet article et à l’accélérateur de solution.

Ressources WSS

Luis Câmara Manoel est responsable de programme au sein du groupe Microsoft Solution Accelerator. Il travaille chez Microsoft depuis un an. Auparavant, Luis travaillait comme chef de projet et responsable de programme chez Novell Inc et Volera à Provo (Utah). Vous pouvez prendre contact avec Luis à l’adresse : luiscam@microsoft.com.

Peter Skjøtt Larsen est responsable de produit au sein du groupe Microsoft Solution Accelerator. Il travaille chez Microsoft depuis plus de quatre ans et occupe des fonctions de développement et de marketing. Auparavant, il développait des logiciels client et serveur pour les secteurs de la finance, de l’ingénierie et des télécommunications. Vous pouvez prendre contact avec Peter à l’adresse : petela@microsoft.com.

Ressources supplémentaires