SharePoint 2010 upgrade and migration

1. Upgrade and Migration
with SharePoint 2010
Ricardo Marshall
uk.linkedin.com/in/ricardomarshall/

2. Topics
 Upgrade and Migration Overview
 Plan & Prepare For Upgrade
 Upgrade Approaches
 Upgrading Shared Services Providers
 Upgrading Customisations
2

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 possible
3

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. 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 automate
5

6. Product Feature Change Considerations
 The following key features introduce changes that
affect the upgrade process:
 Service applications
 Claims-based authentication
6

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. Unsupported Upgrade Scenarios
 Upgrade from earlier than WSS 3.0/MOSS 2007 SP2
 Direct upgrade from WSS 2.0/SPS 2003 or earlier
 Gradual upgrade
8

9. Supported Upgrade Scenarios
 In-place upgrade
 Database attach upgrade
 Hybrid upgrade
9

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 slides
10

11. Minimum System Requirements for
Upgrade
11

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. Client Software
13

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. 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 report
15

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 Parts
16

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 variations
17  stsadm -o variationsfixuptool

18. UPGRADE APPROCAHES
 In-Place Upgrade
 Database Attach Upgrade
 Hybrid Approaches
18

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 types
19

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 TechNet
20

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 sites
21

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. 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.exe
23

24. In-Place Upgrade (Pros & Cons)
24

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
fails
25

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
 Search
26

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 reported
27

28. Database Attach (Pros & Cons)
28

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 redirection
29

30. Shared Services Upgrade
 In-place Upgrade with Services
 Database Attach Upgrade with Services
30

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 deleted
31

32. In-place Upgrade with Services
32

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 needed
33

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 use
34

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. 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 services
36

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 Application
37

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 upgrading
38

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
upgrade
39

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 Search
40
database): contains the metadata for search

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 upgrade
41

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 UI
42

43. Managing Customizations (continued)
43

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 solutions
44

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. Testing Customizations
 Understand what changes, if any, will need to be made to
the customizations
 Core functionality and UI modifications of customizations
should be examined
46

47. Final Determination -
Customizations
 Keep the customizations as is
 Redesign the customizations
 Discard the customizations
47

48. References
 Microsoft Workshop for SharePoint 2010 Upgrade and
Migration
 TechNet http://technet.microsoft.com/en-
us/sharepoint/ee517214
48