Lorsque vous mettez à niveau votre environnement vers SharePoint 2013, vous voulez limiter le temps d’arrêt auquel sont confrontés les utilisateurs. Il se peut aussi que vous rencontriez un cas particulier que vous devrez résoudre pendant la mise à niveau. Cet article décrit comment réduire le temps d’arrêt et comment traiter ces cas particuliers.

En plus des informations contenues dans cet article, lisez l’article Consulter les éditions et produits pris en charge pour la mise à niveau vers SharePoint 2013 afin de comprendre exactement quelles sont les situations dans lesquelles la mise à niveau est valide et sera couronnée de succès.

Comment réduire le temps d’arrêt pendant une mise à niveau

Le tableau suivant répertorie les techniques que vous pouvez utiliser pendant la mise à niveau pour réduire l’intervalle de temps pendant lequel les utilisateurs ne peuvent pas accéder à leur contenu ou pour accroître éventuellement les performances de la mise à niveau.

  • Bases de données en lecture seule  Vous pouvez utiliser les bases de données en lecture seule pour continuer à fournir un accès en lecture seule au contenu pendant le processus de mise à niveau. Pour cette approche, vous définissez les bases de données en lecture seule sur la batterie de serveurs originale pendant que la mise à niveau s’exécute sur une autre batterie de serveurs. Cette méthode réduit le temps d’arrêt perçu par les utilisateurs. De même, si vous rencontrez un problème lors de la mise à niveau, vous pouvez rétablir pour les utilisateurs l’accès en écriture et l’accès en restauration de la batterie en lecture seule pendant que vous redéfinissez vos plans avant de procéder à une nouvelle mise à niveau.

Les instructions sur l’utilisation de ces techniques sont incluses dans Attacher des bases de données et effectuer une mise à niveau vers SharePoint 2013.

Cas particuliers

Vous aurez peut-être d’autres exigences ou des objectifs supplémentaires à atteindre au moment d’effectuer une mise à niveau. Le tableau suivant répertorie des cas particuliers et décrit comment approcher la mise à niveau dans chaque cas.

Cas

Approche de mise à niveau

Mise à niveau d’un environnement qui utilise l’authentification par formulaire ?

La mise à niveau requiert des étapes supplémentaires lorsque vous utilisez l’authentification par formulaire. Pour plus d’informations, voir Configurer l’authentification basée sur les formulaires pour une application web basée sur les revendications dans SharePoint 2013.

Mise à niveau de bases de données très volumineuses ?

En général, la mise à niveau des bases de données très volumineuses, notamment les bases de données qui comportent des versions de document dont le nombre ou la taille sont élevés, prend plus de temps que celle des bases de données plus petites. Toutefois, c’est la complexité des données qui détermine la durée de la mise à niveau, et non la taille de la base de données proprement dite. Si le processus de mise à niveau arrive à expiration, cela est généralement dû à des problèmes de connexion. Pour plus d’informations sur la durée possible de la mise à niveau pour votre environnement, voir Planifier les performances pendant la mise à niveau vers SharePoint 2013.

Mise à niveau à partir de produits serveur de la version Office 2010 ?

Utilisez une méthode de mise à niveau avec liaison des bases de données pour effectuer une mise à niveau vers produits SharePoint 2010, puis réalisez une mise à niveau vers SharePoint 2013.

Mise à niveau à partir de SharePoint Foundation 2010 vers SharePoint Server 2013 ?

Attachez et mettez à niveau les bases de données de contenu à partir de SharePoint Foundation 2010 vers SharePoint Server 2013.

Changement de langue ?

Deux choix s’offrent à vous, selon qu’un seul site ou la totalité de votre environnement change de langue :

  • pour modifier la langue de l’interface utilisateur multilingue d’un site donné, procédez à la mise à niveau dans la même langue, puis installez le nouveau pack linguistique et effectuez le changement avec la nouvelle langue.

clip_image001

Attention :

Les packs de langue appropriés doivent être installés pour que vous puissiez mettre à niveau les sites en fonction d’une définition de site localisée. Si vous n’avez pas le nouveau pack de langue, les sites ne seront pas disponibles. Attendez que les nouveaux packs de langue soient proposés avant de mettre à niveau ces sites.

  • Pour modifier la langue d’installation de votre environnement, définissez votre nouvel environnement dans la nouvelle langue, puis attachez et mettez à niveau vos bases de données dans la nouvelle langue.

Voir aussi

Planifier les performances pendant la mise à niveau vers SharePoint 2013

Consulter les éditions et produits pris en charge pour la mise à niveau vers SharePoint 2013

Utiliser une mise à niveau d’évaluation vers SharePoint 2013 pour rechercher les problèmes éventuels

Vue d’ensemble du processus de mise à niveau vers SharePoint 2013

 

Créer un échéancier des personnalisations actuelles lors de la mise à niveau vers SharePoint 2013

Si vous avez effectué de nombreuses personnalisations dans vos sites basés sur les produits SharePoint 2010, vous devez déterminer la façon dont vous souhaitez gérer vos personnalisations lors de la mise à niveau vers SharePoint 2013. Votre approche dépendra de l’étendue des personnalisations, du type de personnalisation, de la complexité de votre site et de vos objectifs en termes de mise à niveau. Avant d’effectuer une mise à niveau, vous devez identifier, puis évaluer les personnalisations dans votre environnement et déterminer si vous allez les mettre à niveau et selon quelles modalités.

Identifier les personnalisations dans votre environnement

Dans le cadre d’un processus de test de la mise à niveau, vous devez créer un inventaire des personnalisations côté serveur dans votre environnement (solutions, fonctionnalités, composants WebPart, gestionnaires d’événements, pages maîtres, mises en page, fichiers CSS, etc.). Pour plus d’informations concernant la manière d’identifier des personnalisations, voir Utiliser une mise à niveau d’évaluation vers SharePoint 2013 pour rechercher les problèmes éventuels.

Vous pouvez utiliser la feuille de calcul relative à la planification de la mise à niveau pour répertorier les personnalisations spécifiques, puis enregistrer les résultats de votre évaluation dans la section suivante.

Évaluer les personnalisations

Une fois les personnalisations identifiées, songez à l’effet de mise à niveau potentiel de chacune d’entre elles. Le tableau suivant décrit les types de personnalisations et le genre d’effet qu’elles peuvent engendrer lors de la mise à niveau.

Catégorie de personnalisation

Type de personnalisations

Effet potentiel sur la mise à niveau

Conséquences visuelles

Pages maîtres

Thèmes

Pages web

Composants WebPart

JavaScript personnalisé

Fichiers CSS personnalisés

Ne devraient pas affecter la mise à niveau de la base de données.

Dans le cas de mises à niveau de sites : susceptibles de fonctionner correctement en mode 2010, mais nécessitent des modifications pour fonctionner en mode 2013.

À tester soigneusement dans les deux modes.

Conséquences sur la structure des données

Types de contenu

Types de liste

Modèles web

Définitions de site

Peuvent avoir des conséquences sur la mise à niveau de la base de données si le contenu ou les noms de types de liste entrent en conflit avec du nouveau contenu ou des nouveaux types de liste dans le produit, ou si les modèles ou définitions font défaut.

Sans conséquence visuelle

Services Web

Service Windows

Gestionnaire HTTP

Module HTTP

Éventuellement non compatibles avec SharePoint 2013. À tester soigneusement afin d’en déterminer les effets. Soyez prêt à les supprimer ou à les remplacer.

À présent que vous connaissez les personnalisations dont vous disposez et leurs types, vous pouvez décider ce que vous devez en faire. Les questions suivantes vous permettent d’évaluer les personnalisations :

  • La personnalisation est-elle toujours importante ?
    • Répond-elle à un besoin d’entreprise utile ?
    • Est-elle largement déployée et utilisée ?
    • Génère-t-elle des actions que les fonctionnalités standard ne permettent pas d’effectuer dans le produit ?
  • La personnalisation est-elle correctement conçue ?
    • Repose-t-elle sur des définitions de site prédéfinies prises en charge ?
    • Suit-elle les meilleures pratiques en termes de personnalisations ?
    • S’agit-il d’un type de personnalisation pris en charge ou représente-t-elle un risque pour votre environnement ?

Considérations pour des personnalisations spécifiques

Outre prendre une décision globale quant à la façon dont les personnalisations doivent être traitées dans votre environnement pendant la mise à niveau, vous devez examiner les types spécifiques de personnalisations pour déterminer si vous devez effectuer des actions supplémentaires afin qu’elles fonctionnent dans l’environnement mis à niveau.

Le tableau suivant répertorie certaines personnalisations courantes et indique une recommandation pour le traitement du type de personnalisation concerné.

Type de personnalisation

Recommandation

Modèles de sites (fichiers STP)

Les fichiers STP constituent une fonctionnalité obsolète dans SharePoint Server 2010. Les nouveaux modèles de sites dans SharePoint Server 2010 sont enregistrés en tant que fichiers WSP (packages de solution).

Un site qui a été mis en service à l’aide d’un modèle de site sera mis à niveau, mais vous ne pourrez pas créer de sites basés sur ce modèle. Pour créer des sites, vous pouvez créer et déployer un package de solution.

Définition de site

Migrez les sites vers une définition de site prédéfinie prise en charge, puis appliquez les fonctionnalités personnalisées à l’aide d’un déploiement de solution.

Vous pouvez également continuer à utiliser une définition de site personnalisée. Vous n’avez pas besoin de créer une définition de site basée sur SharePoint Server 2010.

Toutefois, si vous devez effectuer des opérations de mise à niveau personnalisées pour la définition, vous pouvez être amené à créer un fichier de définition de mise à niveau pour cette définition de site. Pour plus d’informations, voir Fichiers de définition de mise à niveau (http://go.microsoft.com/fwlink/?linkid=182339&clcid=0x40C) sur MSDN.

Fonctionnalité

Effectuez une évaluation, puis, si nécessaire, une remise à plat ou un redéploiement.

Flux de travail et contrôles serveur

Dépend de la solution. Contactez le fournisseur pour déterminer s’il existe une solution mise à jour. Si un flux de travail est compatible avec la nouvelle version, effectuez un redéploiement.

Gestionnaire d’événements

Effectuez une réécriture et un redéploiement en tant que fonctionnalité.

Chemins d’accès gérés (inclusions/exclusions)

Recréez les inclusions pour une mise à niveau avec liaison des bases de données. Les exclusions sont prises en compte et n’ont pas besoin d’être recréées.

Thèmes

En raison des nombreuses modifications apportées à l’interface utilisateur, les thèmes personnalisés basés sur Office SharePoint Server 2007 ne fonctionneront pas dans SharePoint Server 2010. Utilisez la mise à niveau visuelle pour continuer à utiliser les sites dans l’ancienne expérience utilisateur jusqu’à ce que vous puissiez créer et appliquer un thème basé sur SharePoint Server 2010.

Actions liées à la barre d’outils

Déplacer vers le Ruban (interface utilisateur Fluent).

Pages maîtres et fichiers CSS

Modifier la conception de manière à prendre en charge la nouvelle expérience utilisateur.

JavaScript

Effectuez un test pour déterminer si des actions sont requises. Dans certains cas, vous pouvez être amené à ajuster les scripts afin qu’ils fonctionnent avec le nouveau modèle de page. Vérifiez le fonctionnement sur un site mis à niveau, puis dans les deux modes de mise à niveau visuelle.

Fournisseur de recherche ou découpage de sécurité

Effectuez un test pour déterminer si des actions sont requises.

Composants WebPart

Effectuez un test pour déterminer si des actions sont requises. Vous pouvez être amené à ajuster les composants WebPart afin qu’ils fonctionnent avec le mode XHMTL strict.

Si un composant WebPart se trouve sur une page, mais pas dans une zone de composant WebPart (de sorte qu’il s’agisse schématiquement de code HTML directement incorporé dans une page), il ne fonctionnera pas si vous redéfinissez la page sur le modèle par défaut.

Services

Effectuez un test pour déterminer si des actions sont requises. Recréez ou ajustez le code, selon vos besoins.

Fournisseurs d’authentification

Effectuez un test pour déterminer si des actions sont requises. Redéployez le fournisseur sur une batterie de serveurs de test et vérifiez qu’il fonctionne correctement avec l’authentification par revendications.

Les types de personnalisations suivants ne sont pas pris en charge. Si votre environnement en comporte, vous devez les remplacer par un type de personnalisation pris en charge avant d’effectuer la mise à niveau. Sinon, vous risquez de rencontrer des problèmes de mise à niveau insolubles :

  • Définitions de site, fonctionnalités ou fichiers prédéfinis ayant été modifiés.

clip_image002

Avertissement :

Certains types de fichiers prédéfinis, tels que les actions ou les icônes de document, peuvent être modifiés et, bien qu’ils ne soient pas mis à niveau, ces modifications peuvent être répercutées de manière à ce qu’elles soient prises en charge. Les modifications apportées aux autres fichiers prédéfinis, tels que les pages ASPX côté serveur, seront perdues pendant la mise à niveau si vous réappliquez le modèle de site. Suivant les fichiers modifiés et l’étendue de ces modifications, l’expérience de mise à niveau peut varier sensiblement. Il est fortement recommandé de rétablir toutes les modifications dans tous les fichiers sur le disque.

  • Bases de données SharePoint ayant été modifiées, par modification directe des données ou par modification du schéma, au moyen d’opérations telles que l’ajout ou la suppression de déclencheurs, de tables, de vues ou d’index.

Si vous possédez des personnalisations de ces types, supprimez-les et remplacez-les par des personnalisations prises en charge avant de procéder à la mise à niveau. Cette meilleure pratique garantit le bon fonctionnement de votre mise à niveau actuelle et une meilleure souplesse des mises à niveau futures. La modification des fichiers et des bases de données prédéfinis demeurera non prise en charge.

 

SharePoint Upgrade Planning Checklist

The following checklist will help with the upgrade planning and testing process:

  • Document Farm and Setup accounts & passwords
  • Document farm architecture & components (include server names & IP address)
    • SharePoint Web Front End servers (Qty & services running on each)
    • SharePoint Application servers (Qty & services running on each)
    • SharePoint Index servers (Qty & services running on each)
    • SharePoint Database servers (Qty & services running on each)
    • Identify server details (for each server listed above)
      • OS & version
      • CPU (32-bit/64-bit)
      • RAM
      • Identify the IIS version and any special settings
      • Identify the .NET version
      • Local disks or SAN
  • Define any Extranet or External sites or connections
  • List all solutions installed (free, 3rd party, or Microsoft provided, but not default OOTB)
  • List all custom features or web parts (not installed as solutions)
  • List any customizations including custom applications or integration with other systems
  • Identify any custom branding, themes or style sheets
  • If Reporting Services is being used, list # of reports & details of report servers
  • Capture configuration details of SSP’s
  • List each SharePoint Web Application & port used
  • List all SharePoint Site Collections
  • Document Content Databases – list each by name & include size
  • List any libraries or lists using custom forms
    • Identify any InfoPath forms in use
  • List any Business Data Catalog usage or connections to external data
  • Identify system criticality, down-time restrictions, and business expectations
  • Identify key contacts for system/network access, dba, business and project leads
  • List all Workflows – custom, SPD, 3rd party, and standard SharePoint workflows
  • Indicate the number of audiences and how they are being used.

 

Nettoyer un environnement avant une mise à niveau vers SharePoint 2013

SharePoint 2013

Autres versions

Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Office Store ou SharePoint Store ne sont peut-être pas encore disponibles dans votre région.

Résumé : Vérifiez votre environnement et supprimez les éléments inutiles avant de procéder à la mise à niveau vers SharePoint 2013.

S’applique à :  SharePoint Foundation 2013 | SharePoint Server 2013 

Avant de commencer la mise à niveau depuis les produits SharePoint 2010 vers SharePoint 2013, vous devez vous assurer que votre environnement fonctionne correctement et veiller à supprimer tout contenu qui n’a pas lieu d’être mis à niveau. Vous pouvez également prendre le temps nécessaire pour supprimer ou réorganiser du contenu de manière à disposer de la structure souhaitée au terme de la mise à niveau.

 

Nettoyage de votre environnement avant la mise à niveau (SharePoint Server 2010)

SharePoint 2010

Autres versions

Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Mise à jour : 4 juin 2010

Avant de commencer la mise à niveau depuis Microsoft Office SharePoint Server 2007 vers Microsoft SharePoint Server 2010, vous devez vous assurer que votre environnement est sain et veiller à supprimer tout contenu qui n’a pas lieu d’être mis à niveau. Vous pouvez également prendre le temps nécessaire pour supprimer ou réorganiser du contenu de manière à disposer de la structure souhaitée au terme de la mise à niveau.

Dans cet article :

Collé à partir de <http://technet.microsoft.com/fr-fr/library/ff382641(v=office.14).aspx>

lundi 8 juillet 2013

15:35

Estimer la durée du processus de mise à niveau et l’espace dont vous avez besoin (SharePoint Server 2010)

SharePoint 2010

Autres versions

Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Publié : 12 mai 2010

Une partie importante de la planification de la mise à niveau depuis Microsoft Office SharePoint Server 2007 vers Microsoft SharePoint Server 2010 consiste à déterminer la durée du processus de mise à niveau et la quantité d’espace de stockage nécessaire. Chaque environnement est unique et présente des possibilités matérielles et des caractéristiques de site spécifiques. L’espace et la durée dont vous avez besoin pour exécuter une mise à niveau varient considérablement en fonction de votre environnement. La meilleure approche pour estimer ces facteurs consiste à effectuer une mise à niveau de test, puis à passer en revue l’espace et la durée qui ont été nécessaires. Pour plus d’informations sur la façon d’exécuter une mise à niveau de test, voir Utiliser une mise à niveau d’évaluation pour rechercher les problèmes potentiels (SharePoint Server 2010).

Dans cet article :

 

Estimer l’espace dont vous avez besoin pour la mise à niveau

Utiliser une mise à niveau d’évaluation pour rechercher les problèmes potentiels (SharePoint Server 2010)

 

Avant de commencer la mise à niveau entre Microsoft Office SharePoint Server 2007 et Microsoft SharePoint Server 2010, il est conseillé de la tester pour vous assurer que vous savez exactement ce qu’il faut à une mise à niveau réussie. Une mise à niveau d’essai vous permet de déterminer :

  • les personnalisations dont vous disposez dans votre environnement, afin de pouvoir planifier leur prise en compte au cours de la mise à niveau ;
  • l’opportunité de mettre à niveau votre matériel afin de faciliter et d’accélérer la mise à niveau ;
  • le moment le plus opportun pour votre mise à niveau, ou la durée que prendra la mise à niveau compte tenu de votre environnement ;
  • les éléments que vous devez planifier, par exemple les ressources requises.

Par ailleurs, vous pouvez utiliser cette mise à niveau d’essai pour vous familiariser avec les outils de mise à niveau et le processus lui-même, de sorte que vous sachiez à quoi vous attendre lorsque vous procéderez à la véritable mise à niveau. Ce test vous permet de déterminer :

  • quels critères particuliers s’appliquent à votre environnement et quelle approche sera la plus efficace pour votre mise à niveau ;
  • à quoi ressemblera l’interface utilisateur de la mise à niveau et comment savoir quand passer d’une phase à la suivante ;
  • où se trouvent les fichiers journaux, comment les lire et quelles informations ils contiennent ;
  • quelles techniques vous pouvez utiliser pour réduire les temps morts.

Cet article fournit les étapes de base du test de la mise à niveau, ainsi que des recommandations pour interpréter les résultats et ajuster vos plans de mise à niveau en fonction de ces résultats.

 

Meilleures pratiques pour tester la mise à niveau (SharePoint Server 2010)

 

Pour comprendre votre environnement avant d’effectuer une mise à niveau et pour planifier avec précision la durée nécessaire à celle-ci, vous devez effectuer une ou plusieurs mises à niveau d’évaluation. L’objectif du test d’une mise à niveau est de rechercher les problèmes à l’avance et de les résoudre afin que vous puissiez avoir confiance en votre processus et en son issue lorsque vous effectuez la mise à niveau réelle. Pour effectuer un test précis et utile du processus de mise à niveau depuis Microsoft Office SharePoint Server 2007 vers Microsoft SharePoint Server 2010, suivez les meilleures pratiques suivantes :

  1. Faites en sorte que l’environnement de test ressemble le plus possible à l’environnement réel.
    Dans la mesure du possible, utilisez le même type de matériel et configurez-le à l’aide des mêmes paramètres, des mêmes URL, etc. Pour obtenir une configuration optimale, réduisez au minimum les différences entre l’environnement de test et l’environnement réel. Plus vous introduisez de différences, plus vous êtes susceptible de consacrer du temps à la détection de problèmes disparates afin qu’ils ne se produisent pas pendant la mise à niveau réelle.
  2. Déterminez le contenu de votre environnement. Procédez au préalable à une enquête complète.
    Prenez le temps de documenter le matériel et les logiciels présents dans votre environnement, les personnalisations côté serveur installées et utilisées, leur emplacement et les paramètres requis. Cela vous permettra de réaliser une planification plus complète et d’effectuer une récupération en cas d’échec de la mise à niveau. Une feuille de calcul est à votre disposition, dans laquelle vous pouvez enregistrer les informations relatives à votre environnement lorsque vous préparez la mise à niveau. Téléchargez la feuille de calcul à partir de l’adresse http://go.microsoft.com/fwlink/?linkid=179928&clcid=0x40C (éventuellement en anglais).
  3. Utilisez des données réelles.
    Utilisez des copies de vos bases de données réelles pour exécuter les tests. Lorsque vous effectuez un test à l’aide de données réelles, vous pouvez identifier les zones problématiques et déterminer les performances de la mise à niveau. En outre, vous pouvez évaluer la durée de différentes actions et séquences de mise à niveau sur différents types de données. Si vous ne pouvez pas tester toutes les données, testez un sous-ensemble de données représentatif afin de vous assurer d’avoir détecté les problèmes susceptibles d’affecter les différents types et tailles de sites, de listes, de bibliothèques et de personnalisations présents dans votre environnement.
  4. Exécutez plusieurs tests.
    Un simple test peut vous indiquer si vous allez rencontrer des problèmes sérieux, mais plusieurs tests garantissent que vous avez détecté tous les problèmes susceptibles de se présenter et peuvent également vous fournir une chronologie plus précise du processus. En exécutant plusieurs tests, vous pouvez déterminer les approches de mise à niveau les plus appropriées pour votre environnement, les techniques de limitation de temps morts à utiliser et l’incidence possible sur le processus ou les performances de la résolution des problèmes détectés dans vos premiers tests. Le résultat du test final indique si vous avez résolu toutes les erreurs et si vous êtes prêt à mettre à niveau votre environnement de production.
  5. N’ignorez pas les avertissements.
    Même s’il ne constitue pas une erreur, un avertissement peut aboutir à des problèmes ultérieurement dans le processus de mise à niveau. En plus de passer les erreurs en revue, analysez tout avertissement pour mesurer son incidence éventuelle.
  6. Testez l’environnement mis à niveau, pas seulement le processus de mise à niveau.
    Vérifiez les applications de service et les services. Exécutez une analyse de recherche et passez en revue les fichiers journaux. Vérifiez que les sites Mon site fonctionnent.
  7. Vérifiez les sites dans les deux modes de mise à niveau visuelle.
    Ne partez pas du principe que le site fonctionnera correctement dans un mode dès lors qu’il peut être correctement prévisualisé dans l’autre mode. Vérifiez l’expérience utilisateur dans sa version précédente et dans sa nouvelle version.
  8. Envisagez un environnement de prévisualisation.
    Vous pouvez créer un environnement de prévisualisation dans lequel les utilisateurs peuvent vérifier leurs sites après une mise à niveau de test, vous aidant ainsi à vérifier la mise à niveau et à rechercher les problèmes. Vous pouvez utiliser un environnement en lecture seule ou vous pouvez autoriser les utilisateurs à apporter des modifications, auquel cas vous devez indiquer à ceux-ci qu’aucune modification apportée ne sera enregistrée. Envisagez de limiter cet environnement de prévisualisation à un ensemble réduit de sites représentatifs et de limiter l’accès à des parties intéressées uniquement, afin de réduire la durée pendant laquelle l’environnement de prévisualisation devra être hébergé et la quantité de commentaires reçue.

Pour plus d’informations sur le test de la mise à niveau, voir Utiliser une mise à niveau d’évaluation pour rechercher les problèmes potentiels (SharePoint Server 2010) et le poster relatif au test du processus de mise à niveau disponible à l’adresse http://go.microsoft.com/fwlink/?linkid=166303&clcid=0x40C (éventuellement en anglais).

 

Effectuer les étapes antérieures à la mise à niveau (SharePoint Server 2010)

Une partie importante de la planification de la mise à niveau depuis Microsoft Office SharePoint Server 2007 vers Microsoft SharePoint Server 2010 consiste à déterminer la durée du processus de mise à niveau et la quantité d’espace de stockage nécessaire. Chaque environnement est unique et présente des possibilités matérielles et des caractéristiques de site spécifiques. L’espace et la durée dont vous avez besoin pour exécuter une mise à niveau varient considérablement en fonction de votre environnement. La meilleure approche pour estimer ces facteurs consiste à effectuer une mise à niveau de test, puis à passer en revue l’espace et la durée qui ont été nécessaires. Pour plus d’informations sur la façon d’exécuter une mise à niveau de test, voir Utiliser une mise à niveau d’évaluation pour rechercher les problèmes potentiels (SharePoint Server 2010).

Collé à partir de <http://technet.microsoft.com/fr-fr/library/cc262891(v=office.14).aspx>

Avant de commencer la mise à niveau depuis Microsoft Office SharePoint Server 2007 vers Microsoft SharePoint Server 2010, vous devez vous assurer que votre environnement est sain et veiller à supprimer tout contenu qui n’a pas lieu d’être mis à niveau. Vous pouvez également prendre le temps nécessaire pour supprimer ou réorganiser du contenu de manière à disposer de la structure souhaitée au terme de la mise à niveau.

Collé à partir de <http://technet.microsoft.com/fr-fr/library/ff382641(v=office.14).aspx>

Même après avoir testé le processus de mise à niveau pour identifier les problèmes potentiels, vous risquez de rencontrer des problèmes inattendus pendant une mise à niveau depuis Microsoft Office SharePoint Server 2007 vers Microsoft SharePoint Server 2010. Si vous rencontrez des problèmes après la mise à niveau, plus vite vous les détecterez et les résoudrez, meilleure sera l’expérience de l’utilisateur final.

 

SharePoint 2013 : Préparer la migration des développements spécifiques

Cet article fait partie d’un ensemble d’articles traitant de la migration d’environnements SharePoint (2007 et 2010) vers SharePoint 2013.

La page d’accueil de cette série d’articles se trouve ici :  Comment migrer sous SharePoint 2013 ?

Nous allons voir dans cet article comment se préparer à la migration des développements SharePoint, ou en tout cas voir quelques points intéressants dans le cadre d’une migration de développements spécifiques vers SharePoint 2013.

Introduction

Les migrations SharePoint – et celle vers 2013 n’échappe pas à la règle – sont l’occasion de passer un coup d’aspirateur à vos développements SharePoint : migration, adaptation, nettoyage ou suppression de parties du code, la présence de dévs spécifiques offre toujours son lot de "surprises".

Les sujets traités dans cet article sont les suivants :

  • Suis-je préparé pour ces migrations ?
  • Quoi de neuf avec cette double structure 14/15 ?
  • Quoi de neuf concernant le GAC ?
  • Si je déploie un WSP développé pour SharePoint 2007, est-ce que çà fonctionne ?

Point 1 : Suis-je préparé pour ces migrations ?

La première question à se poser c’est: "Ai-je bien en ma possession tout ce qui va me permettre de préparer/modifier/réinstaller mes dévs sur ma ferme SharePoint 2013" :

  • Documentation d’installation,
  • Sources des projets,
  • Descriptif du contenu des projets – Pour savoir si on utilise encore telle ou telle fonctionnalité, ou si elle peut être remplacée par une fonctionnalité "standard" de SharePoint 2013,
  • Et une question subsidiaire : suis-je certain que ce qui se trouve dans mon GAC et dans mon 12/14 provient bien du déploiement de mes WSP et non de copies effectuée "à la mano".

Les points 2 et 4 sont probablement les plus "rigolos", surtout quand on se rend compte à la réinstallation que ce qui est déployé ne correspond pas aux sources, et on se retrouve à faire du Reflector pour comparer le code, voir même pour tenter de reconstruire le code quand on a pas les sources. Du bonheur.

Point 2 : Quoi de neuf avec cette double structure 14/15 ?

Comme vous le savez peut-être déjà, SharePoint 2013 supporte nativement SharePoint 2010 (voir l’article "SharePoint 2013 : Focus sur la coexistence avec SharePoint 2010").

Cette coexistence se traduit "physiquement" par la présence d’un répertoire "14"  (SP2010) et d’un répertoire "15" (SP2013).

clip_image003

Si cette fonctionnalité peut s’avérer bien pratique à l’usage, elle ne vas pas sans poser problème; en effet si vous jetez un n’oeil dans IIS, vous observez que des répertoires virtuels supplémentaires sont créés pour le "15" :

clip_image004

Le problème induit est que les références faites dans votre code à "/_layouts/…." pointent sur l’arborescence de SharePoint 2010, et non celle de SharePoint 2013, que vous déployiez dans le le 14 ou dans le 15.

Toujours en rapport avec ces répertoires, si vous utilisez la méthode "SPUtility.GetGenericSetupPath", sachez que celle-ci est désormais obsolète :

clip_image005

Et doit être remplacée par "SPUtility.GetVersionedGenericSetupPath" dans le cadre de SharePoint 2013 :

clip_image006

Point 3 : Quoi de neuf concernant le GAC ?

Si vous savez déjà développé sous SharePoint, le mot "GAC" doit maintenant faire partie de votre vocabulaire courant. Avec cette nouvelle release de SharePoint, les choses changent concernant son utilisation, puisque du à l’utilisation de .Net 4 les assemblies sont désormais gérées en 2 endroits (dans 2 GAC).

Le GAC voit donc désormais double : un gére le CLR 2.0 (.NET 2.0 et 3.5) et un autre le CLR 4.0 (.Net 4 et +), ce mécanisme étant conçu pour éviter les conflits entre les 2.

Extrait de l’article Understanding The CLR Binder :

Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GACs for each runtime

La localisation des dll se fait donc soit :

  • Dans "C:\Windows\Assembly" pour les assemblies basées sur une version de .net <= à 3.5

clip_image007

  • Dans "C:\Windows\Microsoft.NET\Assembly" pour les assemblies basées sur une version de .net > à 3.5  (SharePoint 2013, donc)

clip_image008

Point 4 : Si je déploie un WSP développé pour SharePoint 2007, est-ce que çà fonctionne ?

Pour cet exemple je génère un WSP depuis un serveur SharePoint 2007 à l’aide de Visual Studio 2008.

Le projet (simple) contient les éléments suivants :

  • Un texte qui affiche le résultat de "GetGenericSetupPath" sur le répertoire "TEMPLATE\IMAGES",
  • Le déploiement d’une image dans le 14/15,
  • Une feature déployant une WebPart affichant cette image depuis le répertoire "_layouts/Images" ainsi que depuis le répertoire "_layouts/15/Images",

clip_image009

  • Un EventReceiver qui se déclenche lorsqu’un item de liste est ajouté, et qui modifie son titre,

clip_image010

  • Une dll dans le GAC.

Dans un premier temps, j’ajoute et déploie le WSP via PowerShell mais sans préciser de paramètre "CompatibilityLevel", résultat : tout fonctionne, et c’est l’image du "14" qui est affichée.

La raison est que si vous ne précisez pas de "CompatibilityLevel", le déploiement va se baser sur le paramètre "SharePointProductVersion" (inexistant, 14 ou 15) présent dans le manifest de la solution.

clip_image011

Dans un deuxième temps, j’ajoute et déploie le WSP via PowerShell avec le paramètre "CompatibilityLevel" à "15", résultat : tout fonctionne, et c’est bien l’image du "15" qui est affichée.

clip_image012

Par contre, la dll est toujours dans le GAC "Old School" (C:\Windows\Assembly) – Ce qui est normal étant donné qu’elle a été compilée en .Net 2.0 et que ce n’est pas le paramètre "CompatibilityLevel" qui va y changer quoi que ce soit.

Conclusion

Nous avons vu dans cet article quelques-uns des (nombreux !) points à prendre en compte dans le cadre de migrations spécifiques vers SharePoint 2013.

Bien sûr, ces points sont triviaux en comparaison des migrations de code qui peuvent être … Bippppp

 

SharePoint 2013 : Migration d’un site SharePoint 2007 simple

avril 19, 2013spasipePoster un commentaireAller aux commentaires

Rate This

Cet article fait partie d’un ensemble d’articles traitant de la migration d’environnements SharePoint (2007 et 2010) vers SharePoint 2013.

La page d’accueil de cette série d’articles se trouve ici :  Comment migrer sous SharePoint 2013 ?

Nous allons voir dans cet article comment migrer un site SharePoint 2007 simple vers SharePoint 2013.

Introduction

Vous avez peut-être lu ou entendu que la migration d’un site SharePoint 2007 vers SharePoint 2013 n’était pas supportée.

Ce qui n’est pas supporté (enfin, qui n’est en fait pas possible) c’est de migrer directement un site de 2007 vers 2013.

Le support de SharePoint 2010 sur une ferme SharePoint 2013 (voir cet article) ne permet malheureusement pas de se passer de l’étape SP2010.

Si vous tentez d’être plus têtu que SharePoint et rattachez une base SharePoint 2007 à une application web créée sous SharePoint 2013, voici ce qui vous attend :

clip_image013

Le message est explicite : il vous faut un serveur ayant une version de SharePoint supérieure ou égale à 14.0.4762.1000, ce qui correspond à la version RTM de SharePoint 2010.

La  collection de sites utilisée dans cet article est la suivante, un site d’équipe dans lequel j’ai :

  • Créé une bibliothèque "Docs techniques" et ajouté quelques documents,
  • Ajouté cette bibliothèque en page d’accueil, les documents étant regroupés par type,
  • Ajouté une image,
  • Ajouté un lien "Microsoft" à droite de la page
  • Ajouté un événement dans le calendrier.

clip_image014

La base de données associée à cette collection se nomme "MOSS2007_VIA_2010".

Prérequis

  • Une ferme SharePoint 2007 patchée SP2 minimum (pour l’exécution du "pre-upgrade checker"),
  • Une ferme SharePoint 2010,
  • Une ferme SharePoint 2013.

Préparation de l’upgrade SP2007 vers SP2010

1. Sur le serveur SharePoint 2007, lancez le "pre-upgrade checker", et utilisez le rapport pour préparer la migration.

Je considère ici que c’est OK.

2. Répertoriez les customisations utilisées dans la ferme.

Ici : RAS

3. Nettoyez votre environnement :check

  • Sites orphelins ou collections de site plus utilisées,
  • Listes contenant un nombre très élevés d’éléments,
  • Bases de contenu contenant un grand nombre de collections de site (> 5000),
  • Listes ou bibliothèques ayant un grand nombre des droits mis en place au niveau des items,
  • Documents ayant un nombre de versions important,
  • Templates, features et webparts inutilisés.

Ici : RAS

4. Réorganisez les collections de site dans les bases de contenu

Ici : RAS

Préparation de la ferme SharePoint 2010

1.  Installez et configurez votre ferme SharePoint 2010; si vous n’avez pas de licence vous pouvez utiliser une version trial (180 jours).

2. Installez les language packs nécessaires.

3. Mettez à jour la ferme avec les dernières mises à jour disponibles,

4. Configurez les applications de service nécessaires,

5. Recréez l’application web (au singulier ici) , idéalement avec la même URL que celle de départ.

6. Installez les développements spécifiques et déployez les sur l’application web (ici : RAS).

Procédure d’upgrade vers SharePoint 2010

Pour migrer de 2007 à 2013, vous devez rattacher votre base de contenu sur une application web créée sous SharePoint 2010 afin de l’upgrader.

Vous pouvez ensuite reprendre le cours "normal" de la migration de SP2010 vers SP2013.

L’exemple est pris ici avec la base de données nommée "MOSS2007_VIA_2010".

1.  Lancez le "pre-upgrade checker"

2. Backupez la base depuis le serveur SQL de SharePoint 2007 (alors mise en lecture seule)

3. Restaurez la base sur le serveur SQL de SharePoint 2010

4. Lancez la commande ‘Test-SPContentDatabase" (ici aucun dév. n’est utilisé, donc RAS)

5. Rattachez la base à une application web SharePoint 2010

clip_image015

Fin du rattachement :

clip_image016

Vérification de l’upgrade

1. Dans l’administration centrale vérifiez que la base est rattachée à l’application web et que la collection de site est bien comptée

clip_image017

2. Vérifiez dans le répertoire"\14\LOGS"  le fichier de logs Upgrade-YYYYMMDD-HHMMSS-SSS.log et éventuellement un autre fichier nommé Upgrade-YYYYMMDD-HHMMSS-SSS-error.log) que la migration s’est bien déroulée - Cherchez les "ERROR" et les "WARNING".

En bas du fichier Upgrade-YYYYMMDD-HHMMSS-SSS.log se trouve un récapitulatif de la migration :

clip_image018

3. Sinon (ou en plus !) vérifiez le statut de la migration via l’administration centrale (Update and Migration / Check upgrade status) et en cliquant sur le statut de la ligne à vérifier

clip_image019

Je ne mets qu’ici une partie des informations affichées dans le tableau :

clip_image020

Test du site et finalisation de la migration

1. La collection "2007 style" est accessible :

clip_image021

2. Lancez un Visual Upgrade : la collection s’affiche correctement en version SharePoint 2010 :

clip_image022

Procédure de migration sous SharePoint 2013

Je ne détaille pas ici le processus car la procédure complète se trouve dans l’article "SharePoint 2013 : Migration d’un site SharePoint 2010 simple".

Au final :

1. Si vous jetez un n’oeil à la table "Versions" de votre base de données vous retrouvez les 2 étapes d’upgrade :

clip_image023

2 Le site "SharePoint 2007" s’affiche correctement dans sa mouture SharePoint 2013 !

clip_image024

We’re done !

Conclusion

La migration d’un site SharePoint 2007 vers SharePoint 2013 est donc possible, mais nécessite de passer par un serveur SharePoint 2010 afin d’upgrader la base de contenu.

La collection de sites utilisée ici est simpliste, dans le cas d’utilisation de développements spécifiques les choses peuvent rapidement se compliquer …

Références

 

Testing and troubleshooting upgrade (SharePoint Server 2010)

SharePoint 2010

Published: May 12, 2010

Before you upgrade from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 2010, you should take time to test your upgrade process and understand what issues you might face in your actual upgrade. This section includes information about how to test upgrade and use the information from that test to predict how much time and how much space you will need for upgrade, and what steps you can take to clean up your environment before you perform your actual upgrade.

During and after upgrade, use the articles in this section to address any issues and resume the upgrade process.

In this section:

In addition, the following resources can be helpful when you test your upgrade process:

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Server 2010

Resource Center: Upgrade and Migration for SharePoint Server 2010

Collé à partir de <http://technet.microsoft.com/en-us/library/ff382642(v=office.14).aspx>

vendredi 26 juillet 2013

08:21

Clean up an environment before upgrade (SharePoint Server 2010)

SharePoint 2010

Published: May 12, 2010

Before you begin upgrading from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 2010, you should make sure that your environment is functioning in a healthy state and that you clean up any content that you do not have to upgrade. You can also take the time to remove or rearrange content so that you will have the structure that you want after you perform the upgrade.

In this article:

Items to clean up

Many of these items can be removed or repaired by using Stsadm.exe commands.

clip_image001[1]

Important:

To run the Stsadm command-line tool, you must be a member of the Administrators group on the local computer.

Delete unused or underused site collections and subwebs

You do not want to upgrade content that you do not have to keep. If it has been unused for a long time and will not be needed in the future, back it up, and then delete it to free storage and administrative resources, improve upgrade performance, and reduce upgrade risk. Be sure to communicate with site owners or organizational contacts regarding the site status — you want to make sure that the site is not needed before you delete it (for example, you do not want to delete sites that are required for compliance, such as emergency procedures, even though they may not be updated frequently).

For more information about how to delete site collections and subwebs, see:

Address large lists

By default, large list query throttling is applied after an upgrade to SharePoint Server 2010. If a list is very large, and users use a view or perform a query that exceeds the limit or throttling threshold, the view or query will not be permitted. Check any large lists in your environment and have the site owner or list owner address the issue before upgrade. For example, they can create indexed columns by using filtered views, organize items into folders, set an item limit on the page for a large view, or use an external list. For more information about how to address issues with large lists, see Manage lists and libraries with many items (http://go.microsoft.com/fwlink/p/?LinkId=182370) on Office Online.

Address large numbers of site collections in a content database

If you have 5,000 or more site collections in a database, consider breaking them out into multiple databases. In Office SharePoint Server 2007, there was a default warning at 9,000 site collections and a hard limit at 15,000 site collections. In SharePoint Server 2010, these values change to 2,000 site collections for the warning and 5,000 site collections for the limit. To avoid errors during upgrade or broken sites after upgrade, we recommend that you move some site collections into separate databases. If you have multiple content databases, you can also speed up your upgrade process by upgrading multiple databases in parallel.

For more information about site collection limits, see SharePoint Server 2010 capacity management: Software boundaries and limits. For more information about moving site collections to a new database, see Move site collections to a new database (split a content database) (Office SharePoint Server 2007).

Address large ACLs

Using item-level permissions frequently can result in large access control list (ACL) entries, which can in turn create performance problems on your servers. For information about this issue and for tips on how to handle lots of users, see Knowledge Base Article 953132: How to add lots of users to a site, to a list, or to a document library in Windows SharePoint Services 3.0 and in SharePoint Server 2007 (http://go.microsoft.com/fwlink/p/?LinkId=182327).

Remove extraneous document versions

Large numbers of document versions can slow down an upgrade significantly. If you do not have to keep multiple versions, you can have users delete them manually or use the object model to find and remove them. For more information about how to programmatically remove extraneous versions, see Versions Web Service (http://go.microsoft.com/fwlink/p/?LinkId=182330) on MSDN.

Remove unused templates, features, and Web Parts

First, verify that no sites are using the template, feature, or Web Part. You can use the pre-upgrade checker (Stsadm -o preupgradecheck) and the Stsadm -o EnumAllWebs operation to identify these customizations in your environment. Both of these operations were updated in the October 2009 Cumulative Update (CU) and now identify Web Parts, features, event handlers, and setup files that are being used in your environment. The pre-upgrade checker specifies which server-side files exist in your environment and how many times they are used. The EnumAllWebs command specifies which files are used by which sites.

For more information about how to identify customizations in your environment, see Use a trial upgrade to find potential issues (SharePoint Server 2010). If customizations are not being used, delete them. For more information about how to manage these kinds of customizations, see Features and Templates (http://go.microsoft.com/fwlink/p/?LinkId=182338) and Solutions and Web Part Packages (http://go.microsoft.com/fwlink/p/?LinkId=182332) on MSDN.

Repair data issues

Make sure that you repair any issues in your databases or site content before you upgrade. In particular, check the following items:

  • Check databases for duplicate or orphaned site collections
    Make sure that site collections exist in only one content database. Occasionally, site collections can leave behind duplicate or orphaned references in old content databases if they are moved to new ones, or if a duplicate copy of a database was attached to the farm, or if there was an error when a site collection was provisioned. If a site collection is referenced in more than one content database or there is more than one instance of the site collection in a content database, it can cause issues when you upgrade by using the database attach upgrade method. If you upgrade a duplicate version of the site collection first, the site map in your configuration database might end up pointing to that version of the site rather than the current version.
    Before you upgrade, use the pre-upgrade checker tool to identify all site collections and look for any duplicate or orphaned sites – any sites with the same URL or the same GUID as another site. For more information, see Run the pre-upgrade checker (SharePoint Server 2010). Also, use the enumallwebs operation in Stsadm.exe to find out which sites are in which content databases and compare the results. For more information, see Enumallwebs: Stsadm operation (Office SharePoint Server). If you find duplicate or orphaned sites, you can use the deletesite operation in Stsadm.exe to remove the duplicate or orphaned sites from the database. To delete a site from a specific content database, use the following command:
    Copy
    Stsadm -o deletesite -force -siteid <SiteID> -database <databasename> –databaseserver <Servername>
    For more information, see Deletesite: Stsadm operation (Office SharePoint Server).
  • Check variations
    In publishing environments, check for any variations that must be fixed. For more information, see Variationsfixuptool: Stsadm operation (Office SharePoint Server).

Making structural changes

If you want to make structural changes to your environment, such as moving site collections around or changing how your databases are allocated, you can use the following methods:

  • Stsadm -o mergecontentdbs   Use this to move site collections between databases. Upgrade is most efficient when databases contain similar data. Therefore, it is best if any site collections that share a content database are similar types. You can also use this operation to divide large databases if they contain multiple site collections. This can also help increase upgrade efficiency.
    For more information, see Mergecontentdbs: Stsadm operation (Office SharePoint Server).
  • Export and import sites   Use this method to move subwebs or site collections within a farm or between farms. For more information, see Import and export: Stsadm operations (Office SharePoint Server).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Server 2010

Resource Center: Upgrade and Migration for SharePoint Server 2010

 

Test and troubleshoot an upgrade to SharePoint 2013

SharePoint 2013

Updated: May 21, 2013

Summary: Find resources about how to test and troubleshoot an upgrade from SharePoint 2010 Products to SharePoint 2013.

Applies to:  SharePoint Foundation 2013 | SharePoint Server 2013 

Before you upgrade from SharePoint 2010 Products to SharePoint 2013, you should take time to test an upgrade process and understand the issues that you might face in an actual upgrade. After you perform a test upgrade, or after you upgrade your actual databases, you might find issues that have to be addressed. After you address issues, you can restart the upgrade to try again.

The following downloadable resources, articles on TechNet, video recordings, and related resources provide information about how to test and troubleshoot upgrade.

Downloadable resources about how to test and troubleshoot upgrade

Download the following content for information about how to test and troubleshoot upgrade.

Content

Description

clip_image025

SharePoint 2013 Products Preview - Test Your Upgrade Process model

See a visual display of information about how to test the upgrade process.

clip_image025[1]

SharePoint 2013 Products Preview Upgrade Worksheet

Use this worksheet to record information about your environment while you test upgrade.

TechNet articles about how to test and troubleshoot upgrade

The following articles about how to test and troubleshoot upgrade are available to view online. Writers update articles on a continuing basis as new information becomes available and as users provide feedback.

clip_image026

Content

Description

Use a trial upgrade to SharePoint 2013 to find potential issues

Find out how to plan for success by testing upgrade by using your actual data in either a physical or virtual environment.

Troubleshoot database upgrade issues in SharePoint 2013

Follow these recommendations to troubleshoot any issues that occur during database-attach upgrade. You can also look up common issues and discover how to address them.

Troubleshoot site collection upgrade issues in SharePoint 2013

Follow these recommendations to troubleshoot any issues that occur during a site collection upgrade. You can also look up common issues and discover how to address them.

Branding issues that may occur when upgrading to SharePoint 2013

Learn how to address issues with branding in an upgraded site, such as custom CSS, custom themes, and custom master pages and page layouts.

Restart a database-attach upgrade or a site collection upgrade to SharePoint 2013

If you encounter errors during upgrade, you can address them by using the troubleshooting article, and then use this article to restart or resume upgrade.

Additional resources about how to test and troubleshoot upgrade

The following resources about how to test and troubleshoot upgrade are available from other subject matter experts.

Content

Description

clip_image027

Upgrade and Migration Resource Center for SharePoint 2013 Products

Visit the Resource Center to find additional information about upgrades to SharePoint 2013.

See also

Best practices for upgrading to SharePoint 2013

Clean up an environment before an upgrade to SharePoint 2013

Plan for performance during upgrade to SharePoint 2013

Collé à partir de <http://technet.microsoft.com/en-us/library/ff382642(v=office.15).aspx>

Last edited Oct 13, 2013 at 2:17 PM by EROL, version 1