Dû au changement d’architecture de SharePoint 2010 (x64 et non plus x86), toute migration de SharePoint 2007 vers SharePoint 2010 s’accompagne en général :
-
D’un changement de matériel, et donc de système d’exploitation,
-
D’une réinstallation uniquement du système d’exploitation en 64 bits, s’il ne l’est pas déjà et si le matériel est suffisamment performant modulo un peu de mémoire supplémentaire.
Du coup, qui dit installation de nouvel OS dit installation fraîche de SharePoint 2010.
Grâce à cela, la migration de l’existant se fait selon la procédure suivante :
-
Exécution sur la plateforme 2007 de la commande
1: stsadm –o PreUpgradeCheck
Cette commande (disponible dès le Service Pack 2 de SharePoint 2007) nous permet d’éventuellement détecter des problèmes qui pourraient se passer durant la migration.
-
Sauvegarde des bases de contenu de la plateforme 2007.
-
Installation de SharePoint 2010 sur le(s) nouveau(x) serveur(s).
-
Installation des derniers Cumulative Updates (Mars 2011 à date de ce billet, et elles sont vivement conseillées).
-
Démarrage des services applicatifs nécessaires (hors Profiles utilisateur si la base de profiles doit également être migrée depuis 2007).
-
Restauration des bases de données de contenu sur le nouveau serveur SQL (ou la nouvelle instance).
-
Création des Applications Web sur la nouvelle plateforme.
-
Déploiement des solutions qui existaient en 2007 (s’il y en avait bien entendu).
-
Montage des bases de contenu sur les Applications web grâce à la commande :
1: Mount-SPContentDatabse –Name NOM_BASE_CONTENU –WebApplication URL_WEB_APP
A ce moment-là, SharePoint détecte que les bases ne sont pas dans la bonne version, il les met donc à jour. Nous pourrons ainsi suivre la progression de la mise à jour via la console
PowerShell.
-
De toutes les migrations que j’ai été amené à faire depuis la sortie de SharePoint 2010 (ou dont on m’a parlé), en suivant la procédure grossièrement définie ci-dessus, tout s’est passé relativement bien.
Mais récemment, lors d’une migration, les serveurs étaient déjà en 64 bits, le serveur SQL avait déjà été migré en 2008 R2. Quelques barrettes de RAM avaient été ajoutées aux serveurs pour répondre aux exigences de SharePoint 2010. Bref, le mode de migration qui s’imposait ici était le « in-place »: j’installe SharePoint 2010 sur le SharePoint 2007 existant, et par magie (ou simplement grâce à l’assistant), la migration se passe. Vous voyez ou je veux en venir …. Ce fut assez catastrophique.
J’ai peut-être manqué un truc, mais la commande
1: stsadm –o PreUpgradeCheck
était dans le vert, aucune personnalisation depuis SharePoint Designer n’avait été effectuée, aucun package n’avait été déployé … et je me suis retrouvé avec pas mal d’erreurs.
J’ai fini par :
-
Effacer tous les services applicatifs démarrés par l’assistant (la recherche était notamment en erreur, les noms étaient complétement “fou”) pour les recréer moi-même.
-
Supprimer toutes les applications Web (hors console centrale d’administration) sans supprimer les bases de contenu, puis les recréer et remonter les bases (notamment dû à des problèmes au niveau des Web.config).
-
Faire beaucoup de nettoyage (suppression de l’application web des SSP par ex., qui n’est plus utile maintenant).
Avec du recul, j’aurais moins perdu de temps en faisant un backup des bases de contenu, puis une réinstallation de l’OS pour enfin suivre la procédure ci-dessus sur une installation fraîche de SharePoint 2010.
Dans le pire des cas, si pour une raison ou une autre j’avais dû faire un rollback, que je sois parti sur une migration « in-place » ou sur une « migration de bases de contenu» à partir d’une nouvelle installation SharePoint, j’aurais dû repasser par la case réinstallation de l’OS et de SharePoint 2007 puis remontage des bases (ou à partir d’un backup SharePoint).
Je pense réellement que le Mount-SPContentDatabase reste le meilleur ami de la migration.
Après, une fois de plus, j’ai peut-être manqué quelque chose …. Et ce billet réfère à mon expérience, cela ne fait pas foi dans des procédures de migration !