Migration vers SharePoint 2007

1. Migration vers SharePoint 2007 Florent Mathery Microsoft France Engagement Manager florentm@microsoft.com • Anthony MoillicQuest Software • Directeur Technique • anthony.moillic@quest.com

2. Objectifs de cette session • Présenter les différents chemins de migration • Comprendre les différentes options (pros/cons) • Comprendre les options pour conserver les personnalisations • Impact de certaines configurations • Montrer ce qu’il faut prévoir • Tâches de pré-migration • Pendant la migration • Exemple d’assistance partenaire : Quest Software

3. Agenda • Objectifs • Avant la migration • Différents chemins de migration : • In-Place Upgrade • Gradual Upgrade • Content DB Migration • Comparaison des différentes alternatives

4. Microsoft Office 2007SharePoint Servers ContentManagementServer 2002 SharePoint PortalServer 2003 Microsoft Windows SharePointServices ‘v3’ Microsoft Windows SharePoint Services v2 Roadmap CMS/SPS/WSS

5. Objectifs • Vous proposer une migration pérenne de Microsoft Office SharePoint Portal Server 2003 (SPS) vers Microsoft Office SharePoint Server 2007 (MOSS) • Pas de migration prévue pour SharePoint 2001 – version MOSS • Minimiser l’impact utilisateur • Réduire l’interruption de service • Limiter le nombre d’utilisateurs impactés lors d’une interruption • Supporter les personnalisation de SPS • Définition de sites personnalisés & web parts • Pages personnalisées en utilisant Microsoft Office FrontPage • Proposer des choix d’implémentation aux administrateurs • Possibilité de migrer une ferme existante … • … ou vers une nouvelle ferme • Proposer une interface utilisateur intuitive • Assistant graphique & ligne de commande • Approche homogène pour les 2 produits

6. Agenda • Objectifs • Avant la migration • Différents chemins de migration • In-Place Upgrade • Gradual Upgrade • Content DB Migration • Comparaison des différentes alternatives

7. Différentschemins de migration • In-place upgrade • Migration de l’existant : serveurs & bases de données • Solution la plus simple, plate-forme indisponible pendant la migration • Gradual upgrade : migration des collections de site • Granularité de migration : une ou plusieurs collections de sites en même temps • Anciennes & nouvelles versions fonctionnent en side-by-side; retour en arrière vers SPS supporté • Plus complexe -> effort significatif • Content DB migration : migration vers une autre ferme • Attachement de la BD de contenu SPS dans une ferme MOSS et lancement de la migration • SPS reste disponible et non impacté par la migration • Contenu seulement, nécessite une nouvelle ferme, nombreuses étapes manuelles -> effort important

8. Avant de migrerversMOSS • Migration de toute la ferme vers Office SharePoint SP2 – Obligatoire • Pré-requis d’installation : • Dernière version de Windows WorkflowFoundation • ASP.Net 2.0 Astuce : Tester vos web parts personnalisées avec ASP.Net 2.0 dans WSS SP2

9. Avant de migrervers MOSS (suite) • Faîtes une sauvegarde complète et testez la ! • Utilisez l’outil d’analyse pré-migration • Renvoie les problèmes connus que vous devez adresser avant la migration • Liste l’ensemble des définitions de site utilisées • Met à jour les listes WSS afin de pouvoir les migrer • Pré-requis pour la migration : WSS SP2 • L’outil d’analyse est installé avec le produit et sera disponible par téléchargement

10. Avant de migrervers MOSS : Gérer les personnalisations FrontPage • Choix important : garder les personnalisations ou migrer vers MOSS • Par défaut, les pages personnalisées sont conservées pendant la migration • Les thèmes SPS ne sont pas préservés • Attention : les pages personnalisées dénotent du reste du site • “Réinitialisation vers une définition de site” • Réinitialisation des pages en tant que ‘layout’ au sein d’une définition de site • Il existe une option qui permet de réinitialiser toutes les pages pendant la migration • Faire en sorte que les utilisateur nettoient l’environnement MOSS en amont • Disponible dans les paramètres du site ou dans SharePoint Designer • Fonctionne pour toute page éditée avec SharePoint Designer ou FrontPage

11. Example : conserver les personnalisations Avant migration Après migration

12. Example : conserver les personnalisations • Ne ressemble pas au reste du site • Ne dispose pas des dernières fonctionnalités : • Navigation • Menu Site actions • Poubelle • Etc…

13. Avant migration: Définitions de site personnalisées • Les sites existants basés sur des définitions de site personnalisées en SPS devraient fonctionner avec MOSS • Pour la création de nouveaux sites, il faut une définition de site MOSS • Pour migrer votre définition de site personnalisé • Créer une nouvelle définition de site MOSS • Créer un fichier de mapping – Définition de site SPS vers MOSS • Déployer les fichiers de mapping & définition de site MOSS dans le dossier d’installation MOSS et lancer la migration • Peut être fait après la migration en ligne de commande

14. Avant migration:Web Parts personnalisées • La plupart fonctionneront après la migration • Nécessité de les recompiler si vous avez utilisé des outils d’ “obfuscation” en ASP.Net 1.1 • Doivent être redéployées si: • Vous utilisez une nouvelle ferme (content DB migration) • Web part dans le répertoire bin & pas de migration in-place

15. Agenda • Objectifs • Avant la migration • Différents chemins de migration • In-Place Upgrade • Gradual Upgrade • Content DB Migration • Comparaison des différentes alternatives

16. Chemins de migration possibles • In-place upgrade • Migration des serveurs et bases existants • Solution la plus simple, plate-forme indisponible pendant la migration • La meilleure solution pour les petits environnements et les serveurs uniques • Gradual upgrade : migration des collections de site • Granularité de migration : une ou plusieurs collections de sites en même temps • Anciennes & nouvelles versions fonctionnent en side-by-side; retour en arrière vers SPS supporté • Plus complexe -> effort significatif • Préférable si nombreux sites et nécessité de limiter l’interruption de service • Content DB migration : migration vers une autre ferme • Attachement de la base de contenu SPS dans une ferme MOSS et lancement de la migration • SPS reste disponible et non impacté par la migration • Contenu seulement, nécessite une nouvelle ferme, nombreuses étapes manuelles • Préférable si utilisation de nouveau matériel

17. In-Place Upgrade Search + User Profiles Search + User Profiles • Lancer le Setup, choisir Upgrade In-Place • Tous les composants sont migrés: • Sites IIS, • Données locales, • BD config & content Web Server Web Server SPS Web App MOSS Web App SPS Web App MOSS Web App • Répéter le setup & la migration sur chaque serveur de la ferme MOSS Config DBs SPS Config DB SPS Content DB(s) MOSS ContentDB(s) • SPS n’est plus disponible après la migration MOSS SSP DBs SPS Search + User Profiles

18. In-Place Upgrade : les étapes • Suivez les étapes de pré-migration • Lancez le setup et choisir l’option migration • Installer les packs de langue si nécessaire • Réalisez la migration sur un frontal web • Etudiez les fichiers de log & résoudre les problèmes rencontrés • Pbs devraient être rares, les documents de migration contiennent des solutions de contournement pour les problèmes connus • Logs disponibles dans : program files\commonfiles\Microsoftshared\web server extensions\12\logs • Après le premier serveur, répétez le setup et la migration sur tous les serveurs de la ferme • Etudiez les résultats • les pages sont réinitialisées avec les définitions de site (version MOSS)

19. Chemins de migration possibles • In-place upgrade • Migration des serveurs et bases existants • Solution la plus simple, plate-forme indisponible pendant la migration • La meilleure solution pour les petits environnements et les serveurs uniques • Gradual upgrade : migration des collections de site • Granularité de migration : une ou plusieurs collections de sites en même temps • Anciennes & nouvelles versions fonctionnent en side-by-side; retour en arrière vers SPS supporté • Plus complexe -> effort significatif • Préférable si nombreux sites et nécessité de limiter l’interruption de service • Content DB migration : migration vers une autre ferme • Attachement de la base de contenu SPS dans une ferme MOSS et lancement de la migration • SPS reste disponible et non impacté par la migration • Contenu seulement, nécessite une nouvelle ferme, nombreuses étapes manuelles • Préférable si utilisation de nouveau matériel

20. Gradual Upgrade Search & Job Server(s) • Créer une nouvelle ferme sur le matériel existant : • Vérifiez l’espace disque et la consommation mémoire • Lancez le setup et choisissez Gradual Update sur tous les serveurs Web • Pour SPS, lancez le setup & la migration sur les serveurs ‘Job’ puis sur les serveurs de recherche Web Server(s) SPS Web App MOSS Web App Portal site Portal site Team sites Team sites MySites MySites • Pour chaque application web : • Créez une nouvelle application web MOSS • Créez une base de contenu MOSS par base de contenu SPS • les application virtuelles existantes sont déplacées et des redirections de sites sont mises en place • Déployez manuellement les web parts dans le répertoire bin MOSS ConfigDBs SPS ConfigDB SPS Content DB(s) MOSS Content DB(s) • Migration de groupe de collections de sites : • Le site racine (root) en premier • Puis migrez 1 à N sites • Outil disponible via ligne de commande SPS Search/User Profile DB(s) MOSS SSP DB(s)

21. Gradual UpgradeRedirection d’URL La migration déplace les serveurs virtuels SPS vers un nouveau domaine d’adresse (URL) Une redirection vers le nouveau domain SPS est mise en place pour tous les sites Une fois le site migré, la redirection est supprimée La navigation via l’adresse d’origine fonctionne toujours Le nouveau domaine est nécessaire jusqu’à la fin de la migration Avant Pendant Après SPS via //domain SPS via //domain_oldMOSS via //domain MOSS via //domain Creation URL //domain_old Requêtes pour //domain/sites/WSS Redirections plus nécessaires une fois migration terminée et résultats validés Sites accessibles via //domain/sites/WSS Redirigées vers //domain_old/sites/wss jusqu’à la fin de la migration

22. Gradual Upgrade : les étapesCréerune architecture MOSS Sur le matériel existant : • Déroulez les étapes standard de pré-migration • Préparez un domaine secondaire (URL) pour chaque application web • Lancez le setup, choisir Gradual Upgrade sur un serveur Web • Création d’un site central d’administration MOSS et d’une base de configuration • Migration locale du serveur • Lancez le setup & choisir Gradual sur tous les autres serveurs de la ferme • Migration locale de tous les serveurs • Analysez les fichiers logs

23. Gradual Upgrade : les étapesMigration du serveurvirtuel SPS • Le domaine qui sera utilisé par SPS est demandé pendant la migration • Recommandation : création automatique des bases • Peut-être configuré manuellement si nécessaire • Nécessite une base de contenu MOSS pour chaque base de contenu SPS plus une base de donnée temporaire par instance SQL Server • Nécessite 30-50% d’espace disque supplémentaire • Création de redirection pour tous les sites à ce stade • Le site IIS SPS est reconfiguré pour utiliser le nouveau domaine ou port • Création d’application web MOSS utilisant le domaine existant • Choisir le SSP pour l’application web • Redéployer les web parts présentes dans le répertoire bin

24. Gradual Upgrade : les étapesMigration du contenu • Choisir si réinitialisation des fichiers à partir des définitions de sites • Choix possible au niveau de chaque groupe de sites migré • Sélectionner un premier groupe de sites à migrer • Le premier groupe doit contenir le site racine du domaine • Noter le stockage (taille en MB) qui doit être migré • Après la migration, la redirection vers l’URL WSS v2 est supprimée • Le site WSS v3 est maintenant disponible • Automatique – pas d’actions manuelles nécessaires • Analysez les fichiers log à la fin de la migration de chaque groupeAstuce : la durée de migration est affichée dans les logs. Le ratio [taille en MB / durée de migration] donne une bonne approximation pour les migrations suivantes. • Répétez les étapes 1 à 3 pour tous les sites • Automatisable via ligne de commande

25. Gradual Upgrade : les étapesRetour à SPS Lorsque le résultat de la migration n’est pas satisfaisant, l’action “Retour” supprime MOSS et réinitialise la redirection vers SPS • Vérifiez que le site SPS existe toujours • Faîtes une copy de MOSS en utilisant la commande stsadm Export / Import • Le retour à SPS se fait via le site web ou commande en ligne • Web : Select Sites for Upgrade > Revert Site • Ligne de commande : stsadm –o upgrade -revert Corrigez la copie de MOSS en utilisant SharePoint Designer • Une fois terminé, re-migré l’original • Utilisez SharePoint Designer pour fusionner les modifications des versions “corrigées” et “re-migrées”

26. Chemins de migration possibles • In-place upgrade • Migration des serveurs et bases existants • Solution la plus simple, plate-forme indisponible pendant la migration • La meilleure solution pour les petits environnements et les serveurs uniques • Gradual upgrade : migration des collections de site • Granularité de migration : une ou plusieurs collections de sites en même temps • Anciennes & nouvelles versions fonctionnent en side-by-side; retour en arrière vers SPS supporté • Plus complexe -> effort significatif • Préférable si nombreux sites et nécessité de limiter l’interruption de service • Content DB migration : migration vers une autre ferme • Attachement de la base de contenu SPS dans une ferme MOSS et lancement automatique de la migration • SPS reste disponible et non impacté par la migration • Contenu seulement, nécessite une nouvelle ferme, nombreuses étapes manuelles • Préférable si utilisation de nouveau matériel

27. Content Database Migration Search + Job Server(s) Application Server(s) • Créez une nouvelle ferme MOSS • Initialisez les applications web MOSS • Copiez manuellement les personnalisations • Modèles • Web parts (BIN & GAC) Web Server Web Server SPS Web App MOSS Web App SPS Web App MOSS Web App MOSS Config DBs SPS Config DB • Attachez les bases de données de contenu SPS Content DB(s) MOSS Content DB(s) MOSS SSPDBs SPS Search + User Profiles

28. Content DB Migration : les étapes 1 • Déroulez les étapes standard de pré-migration • Créez une nouvelle ferme MOSS sur le nouveau matériel • Configurez SSP • Créez une nouvelle application web pour chaque site virtuel SPS • Ré-appliquez manuellement les paramètres de configuration • Vérifiez que toutes les inclusions sont re-créé sur MOSS • Déployez toutes les définitions de site personnalisées • Déployez les web parts dans le GAC ou le rep. BIN • Configurez le serveur e-mail, les permissions spéciales • Re-créez les modèles de quota

29. Content DB Migration : les étapes 2 • Sauvegardez la base de contenu SPS en utilisant SQL Server • Remonter la copie dans la ferme MOSS • Associez la base de contenu à une application web via interface web ou ligne de commande • Vérifiez que le site racine est présent dans la première base • Web : Application Management > Manage Content Databases > Add Content Database • Ligne de commande : stsadm –o addcontentdb • Analysez les fichiers de logs • Répétez pour toutes les bases de contenu et de recherche / profils utilisateurs

30. Content DB MigrationPoints divers • Paramétrez les bases de contenu SPS en mode lecture seule (read-only) • Evite les fusions manuelles après la migration • Note: les utilisateurs seront informés de ce statut (warnings) • Vous avez utilisé ISA Server pour rediriger les URLs SPS • Une fois la base de contenu migrée, les URL sont à rediriger vers la ferme MOSS • Effort significatif : redirection à refaire manuellement • La reconfiguration des inclusions, web parts personnalisées et des définitions de sites personnalisées est critique • Procédure entièrement manuelle • Livre blanc (Whitepaper) en préparation pour la détailler • Les inclusions (ex:/teams, /mysites) sont souvent oubliées

31. Agenda • Objectifs • Avant la migration • Différentschemins de migration • In-Place Upgrade • Gradual Upgrade • Content DB Migration • Comparaison des différentes alternatives

32. Comparaison des alternatives

33. URLs, Fermes et effort d’administration In Place Même adresse URL Même ferme de serveurs Effort minimal Gradual Nouvelles adresses URL Même ferme de serveurs Effort modéré DB Migration Nouvelles adresses URL Nouvelle ferme de serveurs Effort significatif

34. Démo Migration de portail

50. Partenaire Quest Software Anthony Moillic Directeur Technique Microsoft Solutions anthony.moillic@quest.com www.quest.com