SharePoint 2010 upgrade and migration


Published on

SharePoint 2010 upgrade and migration

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • New service application topology as opposed to SSP’sClaims based authentication provides challenges
  • Gradual upgrade:As each group of site collections is upgraded, the data in the groups is copied from the original database to a new database before the data is upgraded to Windows SharePoint Services 3.0. The original Windows SharePoint Services 2.0 data is maintained in the original database until the server administrator explicitly deletes it. Because of this, upgraded sites can be easily rolled back to the previous version, if necessary. All sites are available to site visitors during the upgrade.The upgrade process redirects the original URLs to the upgraded version of the sites. This way, users can continue to use the same URLs that they used before the upgrade.Note: The URLs that are used to access the SharePoint site continue to work throughout the upgrade process. However, because URL mapping occurs during a gradual upgrade, users might notice that the original URL has changed.
  • SharePoint 2010 upgrade and migration

    1. 1. Upgrade and Migration with SharePoint 2010 Ricardo Marshall
    2. 2. Topics  Upgrade and Migration Overview  Plan & Prepare For Upgrade  Upgrade Approaches  Upgrading Shared Services Providers  Upgrading Customisations2
    3. 3. SharePoint 2010 Upgrade Philosophy  Detect issues early  Provide tools to administrators and keep them informed  Report critical issues at start of upgrade  No data loss  Real or perceived (visual upgrade)  Minimize and mitigate downtime  Continue when possible3
    4. 4. Core Upgrade Improvements  Upgrade preparation tools and enhancements  Pre-upgrade checker and EnumAllWebs  Test-SPContentDatabase cmdlet  Minimizing downtime  Parallel upgrade  Read-only databases  Reliability  Resume capability  SQL command timeouts removed 4
    5. 5. Core Upgrade Improvements (continued)  Visual upgrade  A feature that separates data upgrade from UI upgrade  Data and code upgrade happens all at once  Site UI has two modes: this version and previous version  Administrator’s experience  Logging  Separate log per session  Separate log containing just errors ( -error.log)  Upgrade logs always have same columns of data making reporting easier to automate5
    6. 6. Product Feature Change Considerations  The following key features introduce changes that affect the upgrade process:  Service applications  Claims-based authentication6
    7. 7. Requirements & Supported Scenarios  Hardware requirement: 64-bit  Operating system requirement: Windows Server 2008 or Windows Server 2008 R2  Database requirement: 64-bit SQL Server 2005 SP3, SQL Server 2008 SP1 or SQL Server 2008 R2  Additional cumulative updates are required (later slides)7
    8. 8. Unsupported Upgrade Scenarios  Upgrade from earlier than WSS 3.0/MOSS 2007 SP2  Direct upgrade from WSS 2.0/SPS 2003 or earlier  Gradual upgrade8
    9. 9. Supported Upgrade Scenarios  In-place upgrade  Database attach upgrade  Hybrid upgrade9
    10. 10. Plan & Prepare for Upgrade Requirements & Pre-requisites  Determine Upgrade Approach  Key decision for upgrade  In-Place  Database Attach  Hybrid  The approach chosen will affect your planning and the preparation required for upgrade  Equally, you may find that planning and preparation will indicate you need to take a particular upgrade approach  Each approach has its own pros and cons  later slides10
    11. 11. Minimum System Requirements for Upgrade11
    12. 12. SharePoint 2010 Prerequisites Note : The Microsoft SharePoint Products Preparation Tool checks for the presence of prerequisites, and installs and configures any programs that are required.12
    13. 13. Client Software13
    14. 14. Supported and Unsupported Upgrade Paths  Supported editions for upgrade  Standard - Standard  Standard - Enterprise  Enterprise - Enterprise  Unsupported topologies for upgrade  Migrating from a stand-alone server to a server farm  Migrating from 32-bit hardware  Supported cross-product upgrades  WSS 3.0 SP2 – SharePoint Server 2010 (database attach only)  SharePoint Foundation 2010 – SharePoint Server 2010  Search Server 2008 – Search Server 2010/SharePoint Server 2010  Forms Server 2007/PerformancePoint Server 2007 –14 SharePoint Server 2010
    15. 15. Performing Pre-Upgrade Steps Pre-Upgrade Checker Stsadm operation shipped with WSS 3.0 SP2  –o preupgradecheck [-localonly]  More updated rules released in later CU’s Checks for pre-requisites and known upgrade issues Read-only Generates a report15
    16. 16. Performing Pre-Upgrade Steps Clean-up Existing Content  Identify large site collections  stsadm -o enumsites -url http://portal >sites.xml  Address large numbers of site collections in a content database  Apply quota templates to large site collections  Clean-up versions  Use the site auto-confirmation deletion feature  Manually remove sites  Address large lists  List query throttling feature in SharePoint 2010  Address large ACLs  Remove unused templates, features, and Web Parts16
    17. 17. Performing Pre-Upgrade Steps Detect & Repair Data Issue  Detect orphans  stsadm -o databaserepair -url http://portal -databasename Content  stsadm -o enumallwebs -databasename Content - databaseserver DBSERV > info.txt  Detects content database orphans  Included in WSS 3.0 SP2  Delete orphans  stsadm -o databaserepair -url http://portal -databasename Content -deletecorruption  stsadm -o deletesite -force  stsadm -o deleteweb -force  Check variations17  stsadm -o variationsfixuptool
    18. 18. UPGRADE APPROCAHES  In-Place Upgrade  Database Attach Upgrade  Hybrid Approaches18
    19. 19. In-Place Upgrade  Simple: Next, Next, Wizard approach!  Same hardware – content and settings upgraded in place  Does require WSS 3.0/MOSS 2007 to be 64-bit  Previous version must be manually removed  Same URLs remain after upgrade  All sites are unavailable during upgrade  Upgrade cannot be paused or rolled back  Warning: Some settings are not migrated  Settings for user profile synchronization  Blocked file types19
    20. 20. In-Place Upgrade (Continued)  Improvements from previous version in-place upgrade  Restartable  Common blocking time outs removed  Only recommended in limited situations  Small farms  Test environments  Further considerations for in-place upgrade is available on TechNet20
    21. 21. In-Place Upgrade Process  1. Run setup on server with Central Administration  In-place automatically selected due to previous version  2. Run setup on remaining servers  3. Run PSConfig on the server with Central Administration  This server, the configuration database, the services, and the content databases are upgraded sequentially  A timer job schedules the upgrade process to run for each site collection  4. Run PSConfig on remaining servers  5. Confirm successful upgrade  6. Use visual upgrade for sites21
    22. 22. In-Place Upgrade Process (Continued) During in-place upgrade, you are given the choice of visual upgrade experience to apply to the farm. You can choose to either: • Change existing SharePoint sites to use the new user experience. Administrators control the user experience for end users. • Preserve the look and feel of existing SharePoint sites, and allow end users to update their sites user experience. If you choose to change all existing sites you are given two additional options: • Preserve customized pages, but update template and application pages to use the new UI. • Reset all customized pages to their original templates. This option will delete modifications from customized pages and cannot be undone.22
    23. 23. In-Place Upgrade Process (Continued) After the SharePoint Products Configuration Wizard has finished, you can monitor the upgrade process for each site from the Upgrade Status page in SharePoint Central Administration or by using the localupgradestatus operation in Stsadm.exe23
    24. 24. In-Place Upgrade (Pros & Cons)24
    25. 25. Database Attach Upgrade  New hardware – move content to a new farm  Detach individual databases from old farm and attach to new SharePoint 2010 farm  The upgrade process runs and upgrades the whole database  Attach databases in order of priority, size and so on  Can upgrade multiple databases at a time  Can use the old environment for roll-back if the migration fails25
    26. 26. Database Attach Upgrade (continued)  Before you can migrate your content into a new environment, you must create that new environment  Customizations and configuration settings must be manually moved and reconfigured  Databases that can be attached  Content  SSP  Databases that cannot be attached  Configuration & Central Administration content  Search26
    27. 27. Database Attach Upgrade Process (continued)  Two log files created per database attached  -error.log file only created if errors are present  Header in *.log file provides content database name  Progress is reported27
    28. 28. Database Attach (Pros & Cons)28
    29. 29. Hybrid Approaches  A hybrid approach let’s you upgrade your farm in the way that suits you and your organization  Lets you avoid or minimize downtime and some of the other disadvantages of the standard approaches  Options include:  Parallel database upgrade  Read-only databases  Detach databases  Detach databases (multiple farms)  Database attach with AAM redirection29
    30. 30. Shared Services Upgrade  In-place Upgrade with Services  Database Attach Upgrade with Services30
    31. 31. In-place Upgrade with Services  Before In-place upgrade  Collect any settings that must be reapplied  Review your services architecture  Existing SSPs are converted to Service Applications and Service Application proxies  SSP database is upgraded  Data copied into new databases  SSP Admin site is upgraded  Mostly blank, can most likely be deleted31
    32. 32. In-place Upgrade with Services32
    33. 33. After In-place Upgrade  Certain services will require configuration post-in-place upgrade:  Document Conversion Services  User Profile Service  Excel Services  Business Connectivity Services  Enable new services that may be needed33
    34. 34. Database Attach Upgrade with Services  SSP database can be upgraded  But only the profile information in that database will be upgraded  You cannot upgrade Search databases by using the database attach upgrade approach  When you configure the new farm, you must also configure the new service applications  This includes service application proxies and the settings for all services that you want to use34
    35. 35. During Database Attach Upgrade Attach and upgrade the content databases Also attach and upgrade the SSP database  This upgrades the profile information in the database  This results in:  SSP database: Only contains user profile data, no search or other services data.  Taxonomy database: If the Managed Metadata service was configured before upgrading, and if multi-valued user profile properties existed in the SSP database, this database contains that data.35
    36. 36. After Database Attach Upgrade  Reapply administrator permissions for services  Certain services will require configuration post upgrade:  My Sites  Search  Document Conversion Services  User Profile Service  Business Connectivity Service  Excel Services  InfoPath Forms Services  Enable new services36
    37. 37. My Sites Upgrade  During an in-place upgrade, the My Site host is upgraded when the profile services are upgraded, along with the My Site Web sites themselves at the same time. No additional configuration is required post-upgrade  Database attach:  Upgrade user profiles  Create My Site host Web application and configure the My Site host URL  Attach the content database(s) hosting the My Site Web sites to the My Site host Web Application37
    38. 38. Search  The Search system architecture has changed significantly in SharePoint 2010  Before you perform an in-place upgrade, you should plan for adjusting your Search topology after upgrade  You cannot upgrade search data by using the database attach method for upgrading38
    39. 39. Search Services  During In-Place Upgrade:  For each SSP that hosts the Search service a new service application is created  The administrative settings from the OSearch service in an SSP are copied to the corresponding new Search service application  The index server becomes a crawl server with the crawl component on the same server  Any query servers become query components on the same servers, all in the same index partition  Upgrade will be faster if you scale down to one query server before you upgrade39
    40. 40. Search Databases  In MOSS 2007, for each SSP, there are two databases:  The SSP database containing the administrative settings  The search database containing crawler internal data, (such as crawl logs), the property store etc.  In SharePoint Server 2010, the Search service uses three databases:  Search administration database: contains Search administration settings  Search Service Crawl Store database: contains crawl history information  Search Service Property Store database (reused Search40 database): contains the metadata for search
    41. 41. Managing Customizations in Upgrade  Wide flexibility for customizations in the prior version of SharePoint is a strength, but also can provide significant challenges for an administrator when upgrading  The biggest issue is lack of insight into:  Customizations that are installed  References to customizations  All existing customizations must be addressed in order to move forward with upgrade41
    42. 42. Managing Customizations (continued)  SharePoint 2010 contains object model upgrades that are designed to be backwards compatible  Some namespaces, classes, and methods are now obsolete, but they are still available and will continue to work as expected in custom code  The user interface (UI) has changed significantly  The backward compatibility visual mode provides a way to preserve your visual customizations until you can adopt the enhancements to the UI42
    43. 43. Managing Customizations (continued)43
    44. 44. Identifying Customizations  Pre-Upgrade checker (stsadm –o preupgradecheck)  List all webs (stsadm –o enumallwebs)  File level comparison  Web.config  Use the SharePoint Central Administration site to find deployed solutions44
    45. 45. Evaluating Customizations  Does the customization serve a useful business need?  Is the customization widely deployed and used?  Is the customization a SharePoint supported customization, or does it introduce risk into your environment?  Does the customization follow best practices?45
    46. 46. Testing Customizations  Understand what changes, if any, will need to be made to the customizations  Core functionality and UI modifications of customizations should be examined46
    47. 47. Final Determination - Customizations  Keep the customizations as is  Redesign the customizations  Discard the customizations47
    48. 48. References  Microsoft Workshop for SharePoint 2010 Upgrade and Migration  TechNet us/sharepoint/ee51721448