Le Post Infeeny

Les articles des consultants et experts Infeeny

#SPC2012 : SharePoint 2013 Upgrade Deep Dive

Session de 9h à 10h15 Sean Livingston Senior Program Manager

Cette session permet de voir les différentes possibilités lors de l’upgrade, autant sur les sites (SPSite, SPWeb…), que les sites dits d’« Evaluation » (test du site mise à jour en 2013) que le déploiement de solution wsp.

Pour commencer, Sean fait un point sur le « Compatibility Level » et « Compatibility range ».

Le Compatibility Level permet d’indiquer la version du site :

  • 14 pour un site en 2010
  • 15 pour un site en 2013

Comme on l’a vu précédemment, la commande Get-SPSite permet de mettre en avant le compatibilityLevel de chaque site.

Par conséquent, tous les sites qui doivent être mise à jour sont les sites en compatibilityLevel à 14.

Les sous-site (SPWeb) sont obligatoirement dans la même version que celle de la collection de site.

Les fonctionnalités (features) peuvent être de la même version que le « compatibilityLevel » de la collection de site ou antérieur : On peut donc activer une feature 2010 sur un site 2013 mais pas l’inverse !

Le « CompatibilityRange » permet de donner une zone de « compatibilityLevel » : on définit la version minimal et maximal.

Dans le « Template Picker », ne sera affiché que les templates compatible avec le compatibilty range de la collection de site. Pour les sous-site, ne sera proposé que la version correspondant au « SPSite. compatibilityLevel ».

Il y a une notion de « UpgradeEvaluation » qui permet aux utilisateurs de faire une copie du site dans la nouvelle version. Peut être définie dans le SPWebApplication, et par SPSite.

Lors des migrations, attention à ne pas demander trop de mise à jour en même temps . Il vaut mieux le faire petit à petit, mettre les mises à jour en attente, mettre des quotas, faire un tri des migrations effectuées (supprimer les backups qui deviennent inutiles).

On va pouvoir, en PowerShell configurer tout à tas de chose. Get-SPSiteUpgradeSession => Montre les mises à jour en attente et indiquer celles qui sont terminées ou en « échec ». « Remove-SPSiteUpgradeSession » permet d’enlever une migration qui est en file d’attente.

Pour effectuer les mises à jour « Upgrade-SPSite » avec la possibilité de mettre les paramètres « –QueueOnly » pour mettre en file d’attente et « –Unthrottled » pour bypasser les limitations fixées de la BD de mises à jour.

On peut mettre des limitations sur les mises à jour à plusieurs niveaux :

  • Par WebApplication , on peut mettre en place les quotas autant pour le stockage (UsageStorageLimit) que le nombre de sous site (SubWebCountLimit),
  • Par website (pool d’application) : « AppPoolConcurrentUpgradeSessionLimit »
  • Par base de données (SPContentDatabase) : « ConcurrentSiteUpgraeSessionLimit » permettant de fixer le nombre maximum de mise à jour en parallèle sur la base de données.

On passe maintenant aux démonstrations. Dans l’exemple, il y a tout une série de sites en 2010 et en 2013 (via Get-SPSite avec CompatibilityLevel). Il demande la mise à jour d’un site en 15. Exécution de « Get-SPSiteUpgradeSessionInfo » permettant ainsi de voir que le site est bien en cours : la migration étant tellement rapide dans l’exemple qu’elle fut déjà finie ; on utilise alors le paramètre « –ShowCompleted ».

Maintenant est lancé la migration de tous les sites via Powershell (upgrade-SPSite avec le paramètre –QueueOnly). Le lancement de Get-SPSiteUpgradeSessionInfo permet donc de voir la progression de la mise à jour. Get-SPSite montre également que les sites passent en « CompatibilityLevel » à 15 au fur et à mesure.

Sur la SPSite, on peut définir « AlllowSelfServiceUpgrade ».

Les création des site de test (Site Collection Evaluation), permet de faire une copie du site pour faire la mise à jour. Si la base de données supporte les snapshot SQL, la migration utilise ce processus pour faire le backup et le clone. Sans le support du snapshot SQL, un backup du site est effectué puis le restore (avec le suffixe dans le nom du site « -Eval »). Le TimerJob permet de faire toutes les actions entre backup, copie, migration… Un nettoyage du backup peut finalement être fait après l’étape d’évaluation. Pour les sites d’évaluation, on indique le temps d’expiration (en jours) SPWebApplication.DaysToExpire (par défaut à30j).

Lors des mise à jour des solution, on peut indiquer le CompatibilityLevel (par défaut 14 et 15). Si on indique que 14, la solution sera déployé que dans le répertoire 14. Si on indique que « 14-15 », elle sera déployé à la fois dans le 14 et 15.

Sean nous explique le fonctionnement entre les répertoires 14, 15, les appels depuis le site (_layouts/14 ou 15). Il faudra récupérer le schéma pour bien voir tous les ponts entre le 14 et 15 en fonction de la version du wsp (indiqué à l’intérieur), de la version demandée lors du déploiement… Beaucoup de flèche et difficile à retranscrire pour le moment.

2013 ne supporte pas le « partial trusted code solution » (il faut faire du FullTrusted) ; ce qui ne veut pas dire que les sandbox ne fonctionnera plus dans SP2013.

Il est une fois de plus recommander de faire du claims en mode exclusif pour les nouvelles WebApplication.

Une session intéressante.

Jérôme

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :