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.
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.
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 :
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.
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
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 :
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 :
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.
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:
SharePoint 2013
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.
SharePoint 2010
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
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 :
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 :
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 :
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.
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 :
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).
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.
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 :
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" :
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).
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" :
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 :
Et doit être remplacée par "SPUtility.GetVersionedGenericSetupPath" dans le cadre de SharePoint 2013 :
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 :
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 :
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.
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.
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
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 :
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 :
La base de données associée à cette collection se nomme "MOSS2007_VIA_2010".
Prérequis
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
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
Fin du rattachement :
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
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 :
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
Je ne mets qu’ici une partie des informations affichées dans le tableau :
Test du site et finalisation de la migration
1. La collection "2007 style" est accessible :
2. Lancez un Visual Upgrade : la collection s’affiche correctement en version SharePoint 2010 :
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 :
2 Le site "SharePoint 2007" s’affiche correctement dans sa mouture SharePoint 2013 !
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
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:
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.
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:
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:
Other Resources
Downloadable book: Upgrading to SharePoint Server 2010
Resource Center: Upgrade and Migration for SharePoint Server 2010
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
SharePoint 2013 Products Preview - Test Your Upgrade Process model
See a visual display of information about how to test the upgrade process.
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.
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
Upgrade and Migration Resource Center for SharePoint 2013 Products
Visit the Resource Center to find additional information about upgrades to SharePoint 2013.
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>