Déploiement de SharePoint 2010 : Préparez-vous à la mise à niveau vers SharePoint 2010
Vous êtes peut-être tenté de vous lancer directement dans la mise à niveau SharePoint 2010. Elle doit pourtant d'être soigneusement planifiée. Ces informations vous guident à travers le processus de planification de la mise à niveau.
Brien Posey
La mise à niveau vers SharePoint 2010 ne ressemble à aucune autre. Avant même de commencer le processus de planification de cette mise à niveau, vous devez vous familiariser avec les configurations requises pour SharePoint 2010. Contrairement aux versions précédentes, SharePoint 2010 est en version 64 bits seulement. Vous devrez par conséquent installer SharePoint 2010 en plus d'une version 64 bits de Windows Server 2008 ou de Windows Server 2008 R2.
SharePoint nécessite une base de données SQL Server, qui ne doit pas impérativement résider sur le même serveur. SharePoint 2010 requiert toujours SQL Server, mais Microsoft a apporté d'importantes modifications. Avec SharePoint 2010, la base de données doit exécuter une édition 64 bits de SQL Server 2005 ou 2008, que la base soit ou non installée localement sur le serveur SharePoint.
Bien qu'il n'y ait pas d'exigence technique à ce niveau, vous pouvez également prendre en considération les navigateurs Web que vous utilisez. SharePoint 2010 est conçu pour optimiser les normes Web. De ce fait, l'expérience utilisateur doit être cohérente, que le navigateur choisi soit Internet Explorer ou Firefox (3.x ou version ultérieure). Il est toutefois important de savoir que SharePoint 2010 propose une prise en charge limitée pour Internet Explorer 6. Les utilisateurs d'IE6 pourront afficher correctement le contenu SharePoint, mais ils devront disposer d'IE7 ou d'une version ultérieure pour la création de contenu (ou Firefox 3.x ou version ultérieure).
Mises à niveau sur place
Comme vous le savez peut-être, SharePoint 2010 permet de procéder à des mises à niveau sur place à partir de Microsoft Office SharePoint Server (MOSS) 2007. Cependant, étant donné que SharePoint 2010 est une version 64 bits, vous pouvez procéder à une mise à niveau sur place uniquement si votre MOSS 2007 existant s'exécute sur une version 64 bits de Windows Server 2008. Si vos serveurs SharePoint existants correspondent à la configuration système requise, vous pouvez procéder à une mise à niveau sur chaque serveur de votre batterie SharePoint.
Bien que SharePoint prenne entièrement en charge ces mises à niveau, je recommande une mise à niveau sur place seulement si votre déploiement SharePoint est simple et si vous n'avez pas procédé à une personnalisation. Les migrations complètes sont recommandées dans les environnements plus complexes, ce qui vous procure davantage de contrôle sur le processus de mise à niveau. Elles sont également recommandées pour les environnements dans lesquels vous avez effectué des personnalisations. Elles évitent en effet d'écraser accidentellement ces personnalisations.
En général, une migration implique la création d'une batterie de serveurs SharePoint entièrement nouvelle exécutant SharePoint 2010. Une fois cette batterie créée, vous pouvez y attacher vos bases de données SharePoint existantes. Vous pouvez également utiliser une stratégie de migration hybride combinant des mises à niveau sur place et des nouveaux serveurs SharePoint 2010.
Vérification préalable à la mise à niveau
Qu'il s'agisse d'une mise à niveau sur place ou d'une migration, vous devez consacrer du temps à la planification et à la préparation avant de lancer réellement le processus. Parmi les étapes de préparation à la mise à niveau vers SharePoint 2010, la vérification préalable est l'une des plus importantes. Avant de mettre à disposition MOSS 2007, Microsoft proposait l'utilitaire Prescan.exe pour vous aider à vérifier l'intégrité de votre déploiement SharePoint avant la mise à niveau vers MOSS 2007.
Cet utilitaire performant n'est aujourd'hui pas adapté pour l'analyse préalable au déploiement de SharePoint 2010. C'est la raison pour laquelle Microsoft propose un nouvel outil : l'outil de vérification de pré-mise à niveau. Ce nouvel outil constitue une amélioration considérable par rapport à Prescan.exe. Pour commencer, l'outil de vérification de pré-mise à niveau est en lecture seule, ce qui écarte le risque d'apporter des modifications à vos serveurs SharePoint.
L'intérêt principal cet outil est qu'il détecte les problèmes de manière beaucoup plus pointue que son prédécesseur Prescan.exe. Il présente aussi l'avantage d'être évolutif. Il est fourni avec un ensemble de règles utilisées pour analyser vos serveurs SharePoint. Ces règles sont au format XML, ce qui vous permet de créer vos propres règles personnalisées en cas de besoin. Ce format facilite également la mise à jour de l'outil par Microsoft, en cas de modification des bonnes pratiques recommandées.
Bien sûr, le plus intéressant est incontestablement l'information que l'outil de vérification de pré-mise à niveau compile. Bien que conçu par Microsoft pour préparer un système à une mise à niveau vers SharePoint 2010, certaines entreprises utilisent cet outil à d'autres fins. Une entreprise utilise par exemple l'outil de vérification de pré-mise à niveau dans le cadre de son plan de récupération d'urgence. En soi, l'outil ne contribue pas à sauver un serveur SharePoint en échec, mais les informations qu'il recueille peuvent s'avérer inestimables si vous devez reconstruire un déploiement SharePoint (l'outil doit avoir été exécuté avant la défaillance).
Une autre entreprise a, quant à elle, utilisé cet outil pour vérifier que ses serveurs SharePoint étaient configurés de manière cohérente. Exécuter l'outil sur chacun des serveurs SharePoint lui a en effet permis de comparer les rapports générés pour chaque serveur et de vérifier si des éléments de configuration individuels ne respectaient pas la stratégie de l'entreprise.
Comment se procurer l'outil de vérification de pré-mise à niveau ? Il est probable que vous l'ayez déjà ! Microsoft a inclus cet outil dans MOSS 2007 SP2. Mais, contrairement à ce que vous attendiez peut-être, l'outil de vérification de pré-mise à niveau n'est pas un outil autonome. Il est intégré à l'utilitaire STSADM.EXE. Pour ma part, après avoir appliqué SP2, j'ai dû redémarrer mon serveur de test plusieurs fois avant que Windows m'autorise à accéder à la nouvelle fonctionnalité STSADM.EXE.
Ceci dit, je veux vous montrer le fonctionnement de l'outil de vérification de pré-mise à niveau. Comme je l'ai expliqué précédemment, l'outil analyse un fichier de règles XML. Ces règles lui servent de base pour analyser votre déploiement SharePoint. L'outil de vérification de pré-mise à niveau est fourni avec un ensemble de règles intégré. Ces règles, basées sur Best Practice Analyzer, sont répertoriées dans un fichier nommé OssPreUpgradeCheck.xml. La Figure 1 vous donne un aperçu de ce fichier.
Figure 1 L'outil de vérification de pré-mise à niveau utilise un fichier de règles XML.
Lorsque vous appelez la vérification de pré-mise à niveau, vous ne devez pas expressément appeler ce fichier de règles. L'outil l'appelle par défaut. Vous pouvez également utiliser des fichiers de règles personnalisées. La syntaxe complète pour l'outil de vérification de pré-mise à niveau est la suivante :
STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “<rule file name>”] [-ListRuleFiles]] [-LocalOnly]
Comme vous le voyez dans la syntaxe précédente, les seuls paramètres requis sont –O et les mots PreUpgradeCheck. Le paramètre –RuleFiles est facultatif et il sert uniquement si vous souhaitez spécifier manuellement un fichier de règles à utiliser. De la même manière, vous pouvez utiliser le paramètre –ListRuleFiles pour afficher les fichiers de règles qui sont à votre disposition. Enfin, vous pouvez utiliser le paramètre –LocalOnly pour exécuter les règles seulement sur le serveur SharePoint local.
Pour avoir une meilleure idée du fonctionnement de l'outil de vérification de pré-mise à niveau, consultez la Figure 2. Comme le montre la figure, j'ai d'abord ouvert une fenêtre d'invite de commande et navigué dans la structure de répertoire jusqu'à C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN. Depuis cet emplacement, j'ai exécuté la commande suivante :
STSADMIN.EXE –O PreUpgradeCheck]
.jpg)
Figure 2 L'outil de vérification de pré-mise à niveau teste votre déploiement SharePoint.
Comme indiqué dans la Figure 2, l'outil de vérification de pré-mise à niveau effectue différents tests du déploiement SharePoint. Les résultats des tests utilisent un codage de couleur. La couleur rouge indique que le test a échoué et la couleur verte que le test est réussi. Les éléments d'information s'affichent en jaune.
À l'évidence, ce résultat n'est pas très détaillé. La capture d'écran de la Figure 2 indique uniquement si un test a réussi ou échoué. Vous n'obtenez aucune information détaillée. En bas de la capture d'écran, vous remarquez toutefois un message indiquant que vous pouvez consulter les résultats sur un fichier HTML situé dans le dossier C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs.
À chaque exécution de l'outil de vérification de pré-mise à niveau, trois fichiers journaux distincts sont créés : le fichier HTML indiqué au bas des résultats de la mise à niveau, un fichier journal et un fichier XML. Vous pouvez utiliser ces trois fichiers. Le fichier HTML est cependant le plus facile à lire.
Comme mentionné précédemment, l'outil de vérification de pré-mise à niveau compile une grande quantité d'information. C'est pour cette raison qu'il n'est pas possible de présenter les fichiers journaux dans leur intégralité. Vous pouvez toutefois voir à quoi ressemblent les journaux HTML dans la Figure 3.
.jpg)
Figure 3 Les résultats de la vérification de pré-mise à niveau peuvent être affichés à l'aide d'un navigateur Web.
Identifiez vos personnalisations
Identifier les personnalisations apportées aux serveurs SharePoint constitue une autre étape critique du processus de planification de la mise à niveau. Qu'il s'agisse d'une mise à niveau sur place ou d'une migration, il y a toujours un risque d'écraser accidentellement vos personnalisations. C'est pourquoi vous devriez documenter vos personnalisations et effectuer une sauvegarde de ces fichiers afin de pouvoir les réappliquer après la mise à niveau, en cas de besoin.
Avec un peu de chance, vous avez soigneusement documenté toutes les personnalisations au fur et à mesure de l'évolution de l'environnement SharePoint. En réalité, il peut s'avérer difficile de garder une trace de toutes les modifications. Je vous conseille donc de prendre le temps nécessaire pour examiner votre journal de personnalisation même si vous pensez que toutes les personnalisations ont été correctement documentées. SharePoint ne comporte malheureusement pas d'outils intégrés permettant d'identifier les personnalisations. Cela ne signifie pas pour autant que vous devrez réviser manuellement chaque fichier de vos serveurs SharePoint.
Pour identifier les personnalisations, vous pouvez utiliser la technique de comparaison. L'idée est de créer un serveur de stockage MOSS 2007 (en veillant à ce qu'il exécute les mêmes correctifs que vos serveurs de production), puis d'utiliser un programme de différenciation pour identifier les fichiers de vos serveurs de production qui diffèrent de ceux d'un serveur SharePoint non modifié.
Microsoft recommande d'utiliser WinDiff, mais il existe différents outils de différenciation et certains disposent d'un plus grand nombre de fonctionnalités.
Testez le processus de mise à niveau
Au cours de la préparation à la transition vers SharePoint 2010, vous devrez inévitablement établir un planning de l'exécution de la mise à niveau. Si vous avez résolu les problèmes signalés par l'outil de vérification de pré-mise à niveau, le processus de mise à niveau devrait se dérouler sans heurts. Veillez tout de même à ne rien laisser au hasard.
Déployez MOSS 2007 dans un environnement de laboratoire isolé et tester votre plan de mise à niveau en laboratoire avant de tenter de mettre à niveau vos serveurs de production. De cette manière, vous vous familiarisez avec le processus de mise à niveau et vous êtes en mesure d'identifier les éléments qui pourraient poser problème pendant la mise à niveau réelle.
L'approche la plus adaptée pour les PME consiste à préparer des serveurs virtuels, puis à restaurer les sauvegardes de vos serveurs de production sur les serveurs de laboratoire. Cela vous permet de tester votre plan de mise à niveau dans un environnement quasiment identique à votre environnement de production.
Dans les grandes entreprises, il est souvent impossible de reproduire exactement le déploiement SharePoint. Dans ce cas, vous pouvez créer un environnement à petite échelle, configuré d'une façon similaire à votre déploiement de production. Vous pouvez également essayer de restaurer des sauvegardes de certains de vos serveurs SharePoint dans un environnement de laboratoire. Cette approche vous semble laisser trop de place au hasard ? Réfléchissez : la conversion de l'intégralité de votre déploiement vers SharePoint 2010 ne se fera pas en une seule fois. Concentrez-vous sur un domaine à la fois.
Vérifiez vos sauvegardes
La dernière étape avant de commencer la mise à niveau vers SharePoint 2010 consiste à vérifier que vos sauvegardes fonctionnent correctement. Cette semaine, j'ai aidé une personne qui pensait avoir correctement sauvegardé ses serveurs, mais qui s'est aperçu trop tard que les sauvegardes étaient inadéquates. Ne prenez pas ce risque. Testez vos sauvegardes et vérifiez qu'elles peuvent être restaurées.
.jpg)
*Brien Posey,***MVP, est un auteur technique indépendant avec à son actif des milliers d'articles et des dizaines de livres. Vous pouvez visiter son site Web à l'adresse brienposey.com.