Animé par: Arnault Nouvel et Antoine Dongois
Le processus à prendre :
- Apprendre (découvrir la plateforme)
- Préparer (documenter l’historique et choisir la méthode de MAJ)
- Test (Test de MAJ)
- Implémenter (Effectuer la MAJ)
- Valider (Valider la MAJ et MAJ des interfaces utilisateur)
Prérequis :
- Full X64 (SQL et SharePoint) et Windows 2008 uniquement (sur SharePoint)
- Uniquement migrable depuis SP 2007 SP2
- Pas de support IE6
Chemin de migration
- Exige X64 donc prévoir une première phase de migration des OS
- Pas de support de migration de SP2003 vers SP2010, passage obligé par SP2007
Anciennes méthodes d’Upgrade:
- InPlace (OneShot, pas de retour possible)
- DB Attach (base de contenu chargé avec MAJ)
- Gradual (MAJ par collection de site)
Nouvelles méthodes :
- Inplace (migration de l’environnement existant, indisponible pendant la migration, exige déjà une ferme full X64, …)
- DB Attach (préparation des solutions et personnalisations a effectuer au préalable)
Possibilité d’utiliser la seconde méthode pour laisser la ferme existante en read-only durant la migration.
Possibilité de faire la migration en ayant les DB détachées afin d’accélérer la migration InPlace, on réattache les ContentDB ensuite.
Préparation:
- Valider les personnalisations et WSP
- Pré-Upgrade Check
- Recompiler les DLL pour les fermes X86 en X64
- Contrôler les modifications des API
- Transformer les STP en WSP (plus de support des STP dans 2010) – Migrer un site 2007 issu du STP pour ensuite en générer un WSP
- Modifier les codes avec Custom action (doit passer dans le ruban)
- CSS à contrôler car tous ont changé
Nettoyage:
- STSADM databaseRepair
- Suppression des features et collections inutilisées
- Désactiver les locks
- STSADM PreUpgradeCheck (pour contrôler l’état de la ferme avant cette MAJ), pas de modification de la ferme
- Attention à la migration si WSS V3 avec SQL Server DB interne, car migration passe sur SQL Server Express (limité à 4GB)
Tester:
- Monter des fermes de test proches de la ferme de production avec données réelles
- Choisir la méthode de migration
- Commande PowerShell : “test-spcontentdatabase” pour valider la compatibilité avec SP2010
Démonstration faite sur une ferme :
- Site portail + Team Site + MySite
- STSADM PreupgradeCheck de la ferme
- Passage de la DB en readOnly et backup SQL (Content DB, ShareServicesDB et MySiteDB)
- Restore des ContentDB sur la ferme vierge 2010 (WebApp déjà créée mais vide) sans ReadOnly
- Test-SPContentDatabase pour valider les base de contenu avant intégration
- stsadm –addcontentDB (avec option de conservation de l’interface actuelle 2007) des bases de contenu
- Possibilité de voir le statut de la migration durant la tache via la centrale admin
- En cas d’erreur, on peut utiliser la commande PS “Upgrade-SPContentDatabase” pour refaire un chargement de la base de contenu
- Contrôle du résultat après migration pour activer la nouvelle interface (site par site ou par collection directement), avec preview, puis finalisation de la migration
Cas des “profils” et MySites spécifiques pour la migration
- Chargement de la base SSP 2007 dans SP2010
- Création de l’application service de profils dans 2010
- Configuration de l’hote MySite avec son paramétrage (URL et search)
- Utilisation de la commande “Update-SprofilePhotoStore” pour retailler et mettre à jour les photos des utilisateurs
- Chargement des skills, … via le chargement des mots dans le service de taxonomie (Terms Store) via commande PowerShell (SProxy|Move SPProfile …)
Contrôle après migration
- Fichiers de log + page de la centrale admin
- Vérification du code version en 14.xxxxx
Interface 2010 obligatoire pour MySite, Project Server et Report Services Viewer
Site spécifique sur TechNet pour cette problématique de migration
Conclusion:
Bonne session même si certains aspects sont abordés de manière idéale, il faut absolument valider cette problématique avant :)
Fabrice Romelard [MVP]
Commentaires
Enregistrer un commentaire