Archive
Migrer vers SharePoint 2013 : Upgrade des collections de sites (UI et PowerShell)
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 ?
Introduction
Nous allons voir dans cet article comment upgrader une collection de sites vers SharePoint 2013, via l’UI et via PowerShell.
Il remplace l’article SharePoint 2013 : Premiers pas vers les migrations, publié en septembre 2012 qui détaille les étapes d’upgrade.
Je considère au départ de cet article que je suis arrivé à l’étape où ma collection de site a été migrée sur le serveur SharePoint 2013 et est actuellement en mode « SharePoint 2010 »; comme ceci :
J’ai divisé les fonctionnalités en plusieurs « Points », chacun comportant une section * PowerShell Party * qui détaillera les modifications ou interactions possibles en PowerShell.
Point 1 : Eligiblité du site à l’upgrade en self-service
Pour accéder aux options d’upgrade en self-service, votre collection de site doit y être éligible, à savoir respecter 2 règles définies au niveau de l’application web :
- Une taille maximale (10 MB par défaut),
- Un nombre maximal de sous-sites (10 par défaut).
Si elle ne respecte pas une des règles, il faudra la migrer via PowerShell.
* PowerShell Party *
- Récupération des paramètres de l’application web
$webApp = Get‐SPWebApplication <URL web app>
$webApp.SiteUpgradeThrottleSettings
- Modification des paramètres de l’application web
$webApp = Get‐SPWebApplication ‐URL <URL web app>
$webApp.SiteUpgradeThrottleSettings.UsageStorageLimit = <valeur>
$webApp.SiteUpgradeThrottleSettings.SubwebCountLimit = <valeur>
$webApp.Update()
Point 2 : Le bandeau utilisateur
Lorsque vous naviguez sur le site, un message en haut de page vous indique que le site peut être migré; 2 options s’offrent alors à vous :
- « Start now » : Accès à la page permettant de migrer le site ou de demander un site d’évaluation,
- « Remind me later » : Fait disparaître le bandeau, pour une durée de 30 jours par défaut.
* PowerShell Party *
1. Empêcher les utilisateurs d’utiliser l’upgrade en self-service :
$site = GetSPSite <URL>
$site.AllowSelfServiceUpgrade = $FALSE
2. Modifier la durée de rappel / forcer l’upgrade
$webApp = Get‐SPWebApplication <URL Web App>
$webApp.UpgradeReminderDelay <Nombre de jours>
$webApp.Update();
Si vous passez le paramètre « UpgradeReminderDelay » à 0 :
- Le lien pour masquer le bandeau disparaît,
- Le message se modifie pour indiquer à l’utilisateur que l’upgrade est désormais requis
Point 3 : Health checks
Les « Health Checks » sont une étape importante de la migration, car identifiant les points potentiellement bloquants :
- Fichiers customisés/unghostés,
- Types de contenu,
- Galleries de base disponibles,
- Templates de site disponible,
- Language packs disponibles,
- Eléments MUI (multi-user interface) disponibles.
N’hésitez pas à lancer ces checks avant et après avoir migré la collection (Pour voir pourquoi, il faudra venir voir ma démo à la Conf’ SharePoint :)).
Pour lancer les « Health Checks » :
1. Lancez le « site collection health checks » depuis les « Site Settings » :
2. Un clic sur « Start checks » et les vérifications démarrent.
3. Le résumé des vérifications s’affiche, 2 problèmes sont remontés :
- Le type de contenu « Vidéo » en conflit avec l’existant – Supprimez ou renommez le,
- Une webpart – Dans ce cas vous avez la possibilité de corriger ce problème en cliquant sur « Reset page to default ».
Lors du clic sur le lien « Reset page to default », vous avez la possibilité de réinitialiser une page spécifique ou toutes les pages du site en utilisant le template du site utilisé.
* PowerShell Party *
- Test‐SPSite : Lance les Health Checks sur une collection de sites, en spécifiant si vous le souhaitez une des règles à vérifier.
Test‐SPSite ‐Identity <SiteURL> [‐Rule <RuleID>]
- Repair‐SPSite : Lance la réparation des problèmes rencontrés, en spécifiant si vous le souhaitez une des règles à corriger.
Repair‐SPSite ‐Identity <SiteURL> [‐Rule <RuleID>]
Point 4 : Accès à la page de migration/Demande de site d’évaluation
En cliquant sur « Start now » :
Vous accédez à la page de migration :
Point 5 : Demande de site d’évaluation
Une des nouveautés concernant la migration vers SharePoint 2013 est la possibilité de demander un site d’évaluation, qui sera une copie de votre site version SharePoint 2013.
Ce site sera disponible pendant une durée (par défaut et modifiable) de 30 jours, avant d’être supprimé par l’intermédiaire d’un timer job (1 par application web).
Note : Aucune donnée ne sera répliquée du site source vers la copie, ou l’inverse; les utilisateurs doivent donc bien être informés qu’il s’agit d’un site « éphémère ».
Concernant le processus de création de site d’évaluation, 2 possibilités :
- Votre version de SQL Server supporte les snapshots (version Entreprise ou Datacenter) et dans ce cas c’est un snapshot qui est utilisé,
- Ce n’est pas le cas, et c’est un backup-restore qui sera utilisé – Prendre en compte dans ce cas le fait que la collection de site sera en lecture seule pendant la phase de backup.
Depuis l’interface :
1. Cliquez sur « TRY A DEMO UPGRADE » pour effectuer une demande de site d’évaluation
2. Un clic sur le bouton
3. Le ou les administrateur(s) de la collection est/sont alors averti(s) de la réception d’un mail quand la copie upgradée sera disponible.
Pourquoi 1 jour ou 2 ? Parceque les processus de création des sites d’évaluation sont gérés par des timer jobs (1 par application web) qui s’exécutent une fois par jour :
* PowerShell Party *
- Demande de site d’évaluation
Request‐SPUpgradeEvaluationSiteCollection ‐Identity <URL de la collection de sites>
Point 6 : Lancement de la migration
1. Dans la page de migration, le lancement de la migration s’effectue en cliquant sur « Upgrade this Site Collection »
2. Un message de confirmation s’affiche, en invitant l’utilisateur à demander une copie upgradée s’il ne l’a pas encore fait.
3. La migration se lance alors, avec la possibilité d’ajouter un lien à droite dans le bandeau grâce à la propriété « UpgradeMaintenanceLink » de l’application web.
Exemple :
Donne comme résultat :
A noter : le lien s’ouvre dans la page actuelle.
Point 7 : Fin de la migration
1. La migration se termine, une page récapitulative s’affiche
Elle comporte :
- Un lien vers les fichiers de logs (verbeux + erreurs/warnings) stockés dans la bibliothèque masquée « Maintenance Log Library »,
- Un bouton « What’s New » qui redirige vers une page d’aide,
- Un bouton « Let’s see the new site » qui renvoie vers la page d’accueil.
2. Le site migré s’affiche alors correctement
* PowerShell Party *
- Lancement de l’upgrade d’une collection de site en PowerShell, en le démarrant immédiatement, même si les limites de throttling sont atteintes,
Upgrade-SPSite <URL de la collection> -VersionUpgrade -Unthrottled
- Même chose que le point précédent, mais en plaçant l’upgrade en file d’attente
Upgrade-SPSite <URL de la collection> -VersionUpgrade -QueueOnly
Point 8 : Gestion de la file d’upgrade
Un dernier point, et non des moindres : la possibilité pour l’administrateur SharePoint de gérer la file des upgrades des collections de site.
Et là, c’est du PowerShell only !
- Liste des collections de site dans la file (Notez les paramètres ShowInProgress/ShowCompleted/ShowFailed)
Get-SPSiteUpgradeSessionInfo -ContentDatabase <Nom dela BDD> -ShowInProgress -ShowCompleted -ShowFailed
Qui nous donne entre autre (c’est un extrait des informations) :
- Etat d’upgrade d’une collection de site
Get-SPSiteUpgradeSessionInfo -Site <URL de la collection>
Pour les infos remontées, cf. le screenshot ci-dessus.
- Ajouter une collection de site dans la file
Upgrade-SPSite <URL de la collection> -VersionUpgrade -QueueOnly
- Retirer une collection de site de la file (si son état le permet)
Remove-SPSiteUpgradeSessionInfo -Identity <URL>
Point 9 : Throttling
- Nombre d’upgrades simultanés autorisés par pool d’applications
$wa = Get‐SPWebApplication ‐URL <URL web app>
$wa.SiteUpgradeThrottleSettings.AppPoolConcurrentUpgradeSessionLimit=<Valeur>
- Nombre d’upgrades simultanés autorisés par pool base de données
$db = Get-SPContentDatabase <Nom de la BDD>
$db.ConcurrentSiteUpgradeSessionLimit
- Taille maximale pour mise à dispo de l’upgrade en self-service
$wa.SiteUpgradeThrottleSettings.UsageStorageLimit=<Valeur>
- Nombre maximum de sous-sites pour mise à dispo de l’upgrade en self-service
$wa.SiteUpgradeThrottleSettings.SubwebCountLimit=<Valeur>
Références
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). 
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 :
- Dans « C:\Windows\Assembly » pour les assemblies basées sur une version de .net <= à 3.5
- Dans « C:\Windows\Microsoft.NET\Assembly » pour les assemblies basées sur une version de .net > à 3.5 (SharePoint 2013, donc)
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 »,
- Un EventReceiver qui se déclenche lorsqu’un item de liste est ajouté, et qui modifie son titre,
- 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.
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
SharePoint 2013 : Migration d’un site SharePoint 2007 simple
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 :
- 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.
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
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
Comment migrer sous SharePoint 2013 ?
Comment migrer vos environnements existants vers SharePoint 2013 ?
C’est ce que la série d’articles présentée ici va tenter de vous expliquer, en balayant les différents points concernant la migration de sites SharePoint (2007 et 2010) vers SharePoint 2013.
La liste des articles ci-dessous est pour le moment incomplète, n’hésitez pas à revenir ou à vous abonner aux mises à jour afin d’être prévenus de la disponibilité de nouveaux articles !
Liste des articles
Cet article vous présente la création d’une application web (administration centrale et PowerShell), les nouveautés concernant l’authentification (en l’occurrence que les Claims sont le provider par défaut), ainsi que la partie qui concerne plus spécifiquement la migration vers SharePoint 2013 : la migration des applications web du mode « Classic » vers le mode « Claims ».
Cet article présente les étapes de migration d’un site SharePoint 2010 simple (site d’équipe), en partant d’un site présent sur une ferme SharePoint 2010 au site migré sur une ferme SharePoint 2013.
Cet article présente les étapes de migration d’un site SharePoint 2007 simple (site d’équipe), en partant d’un site présent sur une ferme SharePoint 2007 jusqu’au site migré sur une ferme SharePoint 2013.
Il ne détaille pas la migration comme le fait l’article précédent, mais il détaille (entre autre) le processus de rattachement et de migration de base de données.
Cet article présente les points d’attention à observer lors de la migration de vos développements vers SharePoint 2013.
Je vais remettre à jour ce (vieil !) article, mais vous pouvez le consulter pour découvrir comment migrer un site une fois qu’il est disponible en mode SharePoint 2010 sur la ferme SharePoint 2013.
Il présente en outre la méthode de migration, rattachement de base de données, migration de la collection, possibilité de migration des applications de service et best practices.
Cet article présent les étapes d’upgrade d’une collection de sites vers SharePoint 2013 ; il remplace l’article SharePoint 2013 : Premiers pas vers les migrations, publié en septembre 2012.
SharePoint 2013 supporte nativement l’hébergement de sites SharePoint 2010; découvrez comment dans cet article.
Directement lié à l’article précédent, le déploiement de solutions via la commande PowerShell « Install-SPSolution » évolue en se dotant d’un paramètre « CompatibilityLevel » qui lui permet de cibler la cible des déploiements : le 14, le 15, ou les 2.
Références
SharePoint 2013 : Migration d’un site SharePoint 2010 simple
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 2010 simple vers SharePoint 2013.
Introduction
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 »,
- Ajouté quelques documents à la bibliothèque « Shared Documents »,
- Ajouté une image,
- Ajouté un événement dans le calendrier.
La base de données associée à cette collection se nomme « SP_Content_2010 ».
Prérequis
- Une ferme SharePoint 2010,
- Une ferme SharePoint 2013.
Préparation de l’upgrade SP2010 vers SP2013
1. Sur le serveur SharePoint 2010, 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 :
- 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 2013
1. Installez et configurez votre ferme SharePoint 2013,
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 et avec le même mode d’authentification que pour SharePoint 2010 (Classic ou Claims),
6. Installez les développements spécifiques et déployez les sur l’application web (ici : RAS).
Pour ce dernier point, il va vous falloir utiliser le nouveau paramètre « CompatibilityLevel » de la commande « Install-SPSolution » (voir l’article SharePoint 2013 : Nouveauté concernant le déploiement des solutions – Le CompatibilityLevel).
Procédure d’upgrade vers SharePoint 2013
Pour migrer de 2010 à 2013, vous devez rattacher votre base de contenu sur une application web créée sous SharePoint 2013 afin de l’upgrader.
L’exemple est pris ici avec la base de données nommée « SP_Content_2010″.
1. Backupez la base depuis le serveur SQL de SharePoint 2010 (alors mise en lecture seule),
2. Restaurez la base sur le serveur SQL de SharePoint 2013,
3. Lancez la commande ‘Test-SPContentDatabase » afin d’identifier les éléments manquants.
Le seul point remonté ici est que notre application web utilise le mode « Classic » et non « Claims », désormais par défaut dans SharePoint 2013.
Voir :
- Paragraphe « Migration de l’application web vers le mode Claims » plus bas dans cet article,
- L’article SharePoint 2013 : Création et migration d’une application web (et nouveautés sur l’authentification)
4. Rattachez la base à une application web SharePoint 2013
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 »\15\LOGS » les fichier de logs Upgrade-YYYYMMDD-HHMMSS-SSS.log et 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 :
1 warning pour notre site simplissime ? Et oui, le même point identifié par la commande ‘Test-SPContentDatabase » :
Texte complet : « The [Migration2010] web application is configured with claims authentication mode however the content database you are trying to attach is intended to be used against a windows classic authentication mode. »
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 « 2010 style » est accessible
2. Le processus de migration via l’interface se trouve dans l’article SharePoint 2013 : Procédure d’upgrade des collections de site.
Cliquez sur le fichier de logs pour voir l’état de la migration (ici 0 erreurs et 0 warnings, le rêve !)
Ce fichier de logs est stocké dans le site, dans une bibliothèque nommée « Maintenance Log Library ».
En bas du fichier de logs est affiché le statut de la migration, ici le plan s’est déroulé sans acrocs
3. En complément, un autre fichier de logs se trouve dans le répertoire « 15\LOGS »
4. Au final, le site migré s’affiche correctement en version « SharePoint 2013 ».
Migration de l’application web vers le mode « Claims »
Ce point sera détaillé dans un autre article mais sur le principe :
Comme je l’avais expliqué dans l’article « SharePoint 2013 : Création et migration d’une application web (et nouveautés sur l’authentification) » :
le provider l’authentification par défaut est désormais Claims; le mode « Classic » est néanmoins toujours supporté mais il est obsolète.
Il va donc nous falloir (dans notre exemple) – si vous avez créé votre application web sous SharePoint 2010 en mode Claims c’est bien sûr OK – convertir notre application web en mode « Claims ».
Pour cela, plusieurs choix sont possibles :
- Sous SharePoint 2010, passez de « Classic » à « Claims », puis migrez sous SharePoint 2013,
- Sous SharePoint 2013, migrez l’application web SP2010 en la passant de « Classic » à « Claims »,
- Sous SharePoint 2013, migrez l’application web SP2013 en la passant de « Classic » à « Claims ».
Conclusion
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
- Comment migrer sous SharePoint 2013 ?
- SharePoint 2013 : Création et migration d’une application web (et nouveautés sur l’authentification),
- SharePoint 2013 : Procédure d’upgrade des collections de site,
- Upgrade databases from SharePoint 2010 to SharePoint 2013,
- Migrate from classic-mode to claims-based authentication in SharePoint 2013
[Conf’SharePoint] L’Agenda est en ligne !
Information relayée par Patrick Guimonet sur son blog, l’agenda de la Conf’SharePoint est désormais disponible !
Cliquez ici puis sur le jour de votre choix pour accéder au programme.
Pour ma part j’animerai avec Patrick le vendredi 24 la session « B08 – Quelle stratégie de migration vers SharePoint 2013 ? »
Au plaisir de vous y croiser !
SharePoint 2013 : Premiers pas vers les migrations
[UPDATE]
Cet article est désormais obsolète et remplacé par les articles suivants :
- Comment migrer sous SharePoint 2013 ?
- SharePoint 2013 : Migration d’un site SharePoint 2010 simple
- SharePoint 2013 : Migration d’un site SharePoint 2007 simple
- Migrer vers SharePoint 2013 : Upgrade des collections de sites (UI et PowerShell)
- SharePoint 2013 : Préparer la migration des développements spécifiques
[/UPDATE]
Il est peut-être trop tôt avec cette beta de SharePoint 2013 pour commencer à réfléchir aux migrations futures, mais je n’ai pas pu m’empêcher d’y jeter un premier oeil.
D’autres articles viendront ultérieurement étoffer ce sujet.
Pour l’exemple, je pars d’un Team Site sous SharePoint 2010, avec un document uploadé et un texte d’accueil :
Quelle méthode de migration ?
Le choix de la méthode de migration est simple, puisque la méthode « In place » n’est pas supportée.
Vous aurez donc à utiliser la méthode « Database-attach« , dans les grandes lignes :
1. Créez une nouvelle ferme sous SharePoint 2013,
2. Avec la ferme SharePoint 2010 et les bases de données en read-only, backupez (via SQL Server) les bases et copiez les sur le nouveau serveur SQL,
3. Restaurez les bases via SQL Server,
4. Créez toutes les applications web nécessaires,
5. Installez tous les composants serveurs (WSP, etc …),
6. Rattachez et migrez les bases de données, en utilisant :
On trouve d’ailleurs dans les résultats un avertissement concernant le mode d’authentification de l’application web (cet article présente les nouveautés concernant les applications web)
7. Les administrateurs de collection de sites peuvent ensuite migrer leur collection de sites.
Migration des collections de site
Lorsque les utilisateurs arrivent sur la ferme SharePoint 2013 pour la première fois, leur collection de site est en mode « SharePoint 2010 ».
Un message en haut de page leur indique que leur site peut être migré (mon texte de présentation a sauté entre temps) :
En cliquant sur « Start now » :
Il accède alors à la page de migration (et à l’humour de MS ?) :
Sinon, l’admin de la collection de site peut passer par les « Site Settings » pour dérouler les étapes de migration :
1. Lancez le « site collection health checks » afin de vérifier si la collection est prête pour la migration :
Un clic sur « Start checks » et les vérifications démarrent.
Le résumé des vérifications s’affiche : ici RAS, on peut migrer !
2. Il peut alors (c’est optionnel) demander à visualiser une copie de sa collection version 2013. Un timer job est alors chargé d’effectuer la copie+migration de la collection et envoie un mail à l’admin quand c’est terminé. Au bout d’une durée déterminée par un administrateur de la ferme, ce site est supprimé.
-
Dans les « Site Settings », il clique sur « Site collection upgrade » pour accéder à la page de migration :
-
Un clic sur « TRY A DEMO UPGRADE »
-
Un clic sur le bouton
-
L’administrateur de la collection est alors averti qu’il recevra un mail (dans 1 jour ou 2 ??) quand la copie upgradée sera disponible.
3. Dans la page de migration, l’admin de la collection lance la migration en cliquant sur « Upgrade this site collection »
- Un message de confirmation s’affiche, en invitant l’utilisateur à demander une copie upgradée s’il ne l’a pas encore fait.
- La migration est en cours …
4. Quand la migration est terminée, une page récapitulative s’affiche, « Let’s see the new site » !
Le site migré s’affiche alors :
Il est à noter que :
- Un administrateur de la ferme peut lancer les migrations des collections de site en PowerShell, via la commande Upgrade-SPSite,
- Il y a un cas particulier : celui des « My Sites »‘, pour lequel un admin de la ferme doit d’abord migrer la collection de sites « hôte », avant de soit migrer lui-même les « My Sites » soit laisser les utilisateurs le faire eux-même.
Migration des applications de service
Toutes les applications de service ne peuvent pas être migrées via la méthode « Database-attach », sont « migrables » :
- Business Data Connectivity,
- Managed Metadata,
- PerformancePoint Services,
- Search,
- Secure Store,
- User Profile.
Les Best Practices de migration
Ces best practices sont issues de Technet, et non de mon imagination débordante 🙂
- Migrez un environnement SharePoint 2010 fonctionnel ! Si vous avez déjà effectué des migrations sous SharePoint, ce conseil prend tout son sens : les migrations ne corrigent pas les problèmes …
- Effectuez d’abord une migration sur une ferme de test. Çà se tient non ?
- Préparez votre capacity planning. Votre ferme respecte-elle les prérequis et entre autre l’espace disque nécessaire pour les migrations ?
- Nettoyez votre ferme SharePoint 2010 : supprimez l’inutile et corrigez les problèmes,
- Backupez vos bases de données avant de lancer les migrations,
- Assurez-vous que votre ferme SharePoint 2010 respecte bien les limites de SharePoint 2013,
- Consultez post-migration le statut et les logs; validez les migrations des bases de données ainsi que le bon fonctionnement des sites,
- Et enfin migrez les sites une fois que vous avez installé les développements version SharePoint 2013; en attendant ils peuvent rester en mode « SharePoint 2010 ».
SharePoint by Benoît Jester (Asipe) 