1. Upgrade And Migration From Windows Sharepoint Services V2 And Sharepoint Portal Server 2003 Allan Schweighardt Sr. Technology Specialist Microsoft Corporation

2. Session Objectives Explain the upgrade alternatives Understand the options & advantages Understand options for handling customizations Impact of special configurations Show whats needed to plan an upgrade Pre-upgrade tasks Executing the upgrade

3. Topics Design goals Before Upgrade Upgrade Approaches In-Place Upgrade Gradual Upgrade Content DB Migration Additional Considerations: SharePoint Portal Server Shared Services Post Upgrade Summary of Alternatives and Trade-offs

4. CMS/SPS/WSS Roadmap Content Management Server 2002 Office SharePoint Server 2007 Windows SharePoint Services v3 SharePoint Portal Server 2003 Windows SharePoint Services v2

5. Design Goals Provide clean v2/2003 to v3/2007 upgrade No upgrade plans for v1 – v3/2007 release Minimize user impact Reduce outage duration Limit number of users impacted for any outage Support customizations to v2/2003 Custom site definitions & web parts Pages customized using FrontPage Provide resource use choices to admins Enable upgrading existing farm Support migrating to new farm Provide single clear set of UI options Both GUI and command line Consistent approach for both products

6. Topics Design goals Before Upgrade Upgrade Approaches In-Place Upgrade Gradual Upgrade Content DB Migration Additional Considerations: SharePoint Portal Server Shared Services Post Upgrade Summary of Alternatives and Trade-offs

7. Understand Upgrade Options In-Place Upgrade Updates existing databases and servers Easiest approach, environment offline while it runs Gradual Upgrade: Upgrade Site Collections Granular control: one to many site collections at a time Run old & new versions side-by-side; rollback to v2/2003 supported More complex & resource intensive Content DB Migration: Upgrade Into Separate Farm Attach v2/2003 content db to v3/2007 farm & upgrade runs V2/2003 stays available and untouched by upgrade Content only, requires new farm, has many manual steps

8. Before Upgrade To V3/ 2007 Upgrade farm to SharePoint SP2 – required Install pre-requisites Windows Workflow Foundation(dotnetfx3.exe) ASP.Net 2.0 TIP: Test custom web parts with ASP.Net 2.0 in WSS SP2

9. Before Upgrade Run & test a full backup Run the Pre-Upgrade Scan Tool Reports common issues you must address Lists all site definitions in use Updates WSS lists so they can be upgraded Pre-requisite for upgrade, requires SP2 Scan tool is installed with product, and will be available as a download Coordinate with your customers Tip: Review WSS 2.0 to WSS 3.0 or SPS v2 to Office 2007 upgrade documentation

10. Before Upgrade Handling FrontPage Customizations Important consideration: keep customizations or move to v3/2007 Custom pages kept by default during upgrade v2/2003 Themes are not preserved Be aware: customized pages do not match rest of site Reset to Site Definition Returns page to layout in site definition Option exists to reset all pages during upgrade Gets users to clean v3/2007 environment sooner Available in site settings or within SharePoint Designer Works for any page edited in SharePoint Designer / FP

11. Maintaining Customizations Example Upgraded Pre-upgrade

12. Does not match rest of site Lacks new features: Navigation Site actions menu Security trimmed UI Recycle bin Etc…

13. Before Upgrade Custom Site Definitions Existing sites based on custom v2/2003 site definitions should work in v3/2007 V3/2007 site definition needed to create new sites Upgrade your custom site definitions Create new v3/2007 site definition Craft upgrade mapping – v2/2003 to v3/2007 site definition Deploy mapping file & v3/2007 site definition to v3/2007 install directory, and run upgrade Can be done post-upgrade using command line

14. Before Upgrade Custom Web Parts Most will work post-upgrade Must re-build custom parts if you used ASP.Net 1.1 obfuscation tools Must re-deploy web parts if Moving to a new server farm (content DB migration) Web part in the Bin & not upgrading in-place

15. Before Upgrade Shared Services Overview Choose an upgrade strategy Upgrade master, then each child Recommended; offers most flexibility Build temporary master, upgrade children Useful where customers want to upgrade smaller sites first Choose an upgrade method In-place Upgrade all components at once Gradual/Content DB Migration V2/2003 master continues to provide services to v2 sites V2 sites retain user experience User profile, audience data pushed from v3->v2 by scheduled job Two search crawls active (v2, v3) Maximize efficiency by removing v2 sites from v2 crawl after they are upgraded

16. Topics Design goals Before Upgrade Upgrade Approaches In-Place Upgrade Gradual Upgrade Content DB Migration Additional Considerations: SharePoint Portal Server Shared Services Post Upgrade Summary of Alternatives and Trade-offs

17. Available Upgrade Methods In-Place Upgrade Updates existing databases and servers Easiest approach, environment offline while it runs Best for small or single-server environments Gradual Upgrade: Upgrade Site Collections Granular control: one to many site collections at a time Run old & new versions side-by-side; rollback to v2 supported More complex & resource intensive Best where there are many sites, & must limit downtime Content DB Migration: Upgrade Into Separate Farm Attach v2 content db to v3 farm & upgrade runs V2 stays available and untouched by upgrade Content only, requires new farm, has many manual steps Best if moving to new hardware

18. In-Place Upgrade V2 Config DB V2 Content DB(s) Run Setup, Choose Upgrade In-Place All items upgraded: IIS sites, local data, config & content databases V3 Config DBs V3 Content DB(s) Repeat Setup & upgrade on each server in farm V2 no longer available after upgrade Web Server V2 Web App Web Server V3 Web App Search + User Profiles V2 Search + User Profiles V3 SSP DBs

19. In-Place Upgrade Steps Follow pre-upgrade steps Run setup and choose upgrade Install language packs if needed Upgrade one web server Review log files & resolve any issues Issues should be rare, upgrade docs will have recommended workarounds for common issues Logs in: program files\common files\microsoft shared\web server extensions\12\logs After completion on first server, repeat setup & upgrade on each server in the farm Review results Reset pages to (v3/2007) site definition versions

20. Available Upgrade Methods In-Place Upgrade Updates existing databases and servers Easiest approach, environment offline while it runs Best for small or single-server environments Gradual Upgrade: Upgrade Site Collections Granular control: one to many site collections at a time Run old & new versions side-by-side; can roll back to v2/2003 More complex than in-place Requires extra SQL storage, has perf impact on v2/2003 Best where there are many sites, & must limit downtime Content DB Migration: Upgrade Into Separate Farm Attach v2 content db to v3 farm & upgrade runs V2 stays available and untouched by upgrade Content only, requires new farm, has many manual steps Best if moving to new hardware

21. Gradual Upgrade Build v3/2007 farm on current HW Check disk, memory availability – this is resource intensive Run Setup, choose Gradual Upgrade on each web server For SPS, run setup & upgrade on Job then Search server(s) Create temporary URL domains V2 Config DB V2 Content DB(s) V3 Config DBs V3 Content DB(s) Search & Job Server(s) Web Server(s) V2 Web App V3 Web App For each Web Application Create new v3/2007 web app Creates matching content db for each v2/2003 content db Existing v-server moved to new domain, & site redirects created Manually re-deploy Web parts in Bin Portal site Portal site Team sites Team sites MySites MySites Portal site Portal site Team sites Team sites MySites MySites Upgrade batches of site collections Must upgrade root site first Upgrade 1 to N sites thereafter Command line available V2 Search/ User Profile DB(s) V3 SSP DB(s)

22. Gradual Upgrade URL Redirects Upgrade moves V2/2003 virtual server to new URL domain v3/2007 takes over original URL domain Redirect is created for all sites to new v2/2003 location As site is upgraded, redirect is dropped Browse access to original URL always works New URL domain is needed until upgrade is complete Pre-upgradeDuring upgradeAfter upgrade V2 at //domain Create //domain_old URL domain Key site at //domain/sites/WSS V2 at //domain_old V3 at //domain Requests for //domain/sites/WSS redirected to //domain_old/sites/wss until it is upgraded V3 at //domain Redirects not needed once upgrade completes and results are validated

23. Gradual Upgrade Steps Create v3/2007 Infrastructure On existing hardware Run standard pre-upgrade steps Prepare secondary domain for each web app Run setup, choose Gradual Upgrade on 1 Web Server Creates v3 Central Admin site, Config DB Performs local-server upgrade actions Run setup & gradual on all other farm servers Upgrades all sever-local data Review log files

24. Gradual Upgrade Steps Upgrade v2/2003 virtual server Provide domain v2/2003 will use during upgrade Recommendation: Automatically create databases May be manually configured if necessary Need one v3/2007 content db for each v2/2003 content db, plus one temporary db per SQL server. Need extra 30-50% additional SQL disk space Redirect created for all sites at this time V2/2003 IIS site reconfigured to use new domain or port V3/2007 web application created using the original domain Choose SSP for web application Re-deploy any web parts located in the v2/2003 bin

25. Gradual Upgrade Steps Upgrade Content 1.Choose if resetting files to template version Can change selection with each group of sites upgraded 2.Select first group of sites to upgrade Must include the root site of the domain in first group Note storage (number of MB) to be upgraded 3.During upgrade, redirect to v2/2003 URL is removed V3/O2 site is now live Automatic - no admin action needed 4.Review log files after each upgrade group Tip: Upgrade duration is in logs. Number of MB / duration is good approximation for subsequent upgrade durations 5.Repeat steps 1-3 for all sites 6.Command line available to automate

26. Gradual Upgrade Steps Revert to v2 When upgrade result is undesirable, revert deletes v3 & resets redirect to v2 Confirm v2 site still exists before reverting to it Make copy of v3 using stsadm Export / Import commands Revert to v2 via UI or command line UI: Select Sites for Upgrade > Revert Site Command line: stsadm –o upgrade –revert Additional considerations for Portal/MySites Fix copy of v3 using SharePoint Designer Once complete, re-upgrade original Use SharePoint designer to merge changes from fixed & re-upgraded versions

27. Gradual Upgrade Steps Shared Services Shared Services configuration For each master portal Configure search in v3/2007 Configure profile/audience sync in v3/2007 Review Managed Properties of user profiles in v3/2007 For each child portal Modify start addresses in v2/2003 master portal to prevent double-crawling

28. Available Upgrade Methods In-Place Upgrade Updates existing databases and servers Easiest approach, environment offline while it runs Best for small or single-server environments Gradual Upgrade: Upgrade Site Collections Granular control: one to many site collections at a time Run old & new versions side-by-side; rollback to v2 supported More complex & resource intensive Best where there are many sites, & must limit downtime Content DB Migration: Upgrade Into Separate Farm Attach v2 content db to v3 farm & upgrade runs V2 stays available and untouched by upgrade Content only, requires new farm, has many manual steps Best if moving to new hardware

29. Content Database Migration Create new V3 farm Initialize v3 web applications Manually copy customizations Attach databases Web Server V2 Web App Web Server V3 Web App Search + Job Server(s) Application Server(s) V2 Config DB V2 Content DB(s) V3 Config DBs V3 Content DB(s) V2 Search + User Profiles V3 SSP DBs

30. Content DB Migration Shared Services V2/2003 not affected Master continues to provide services to v2 sites Child sites retain user experience User profile/audience data not synced between v2, v3 Two profiles, two MySites, etc may confuse Applications Most search data not upgraded Re-create search settings other than custom search properties

31. Content DB Migration Steps Perform standard pre-upgrade steps Create new v3/2007 farm on clean hardware Configure farm-level settings Create a new web application for each v2/2003 virtual server Manually re-apply customizations Deploy all custom site definitions Deploy custom web parts to GAC or BIN

32. Content DB Migration Steps Back up v2/2003 content database using SQL Restore backup to copy in v3 farm Add content db to web application via GUI or command line Ensure root site is included in first database UI: Application Management > Manage Content Databases > Add Content Database Command line is stsadm –o addcontentdb Upgrade triggers automatically, runs until it completes For large databases, command line preferable Review log files for any issues Repeat for all content and search/user profile databases

33. Content DB Migration Steps Other Considerations Set v2/2003 content DBs to read-only Avoids manual merging of updates post-upgrade Note: Users will see warnings when DB is read-only Internally used ISA Server to re-map URLs As content db upgraded, remapped URLs to v3 farm Work-intensive – redirects all added manually

34. Topics Design goals Before Upgrade Upgrade Approaches In-Place Upgrade Gradual Upgrade Content DB Migration Additional Considerations SharePoint Portal Server Shared Services Post Upgrade Known Issues Summary of Alternatives and Trade-offs

35. Additional Considerations For SPS Site Structure Areas Areas are upgraded to regular sub-sites All areas under a given portal must be upgraded at once Portal URLs change after upgrade In V3/2007 URLs follow the logical navigation structure – navigation changes are now reflected in the URL E.g. http://sample_site/c16/marketing changes to http://sample_site/teams/marketing Redirects: links through IE will be redirected; Office Client apps will not

36. Additional Considerations For SPS Site Content Listings Listings in v2: Portal Listings list + Listings web part Listings in v3: Links list items + Content Query web part Recommend creating v3 summary links from upgraded listings to leverage new page features Create new Summary Link control/web part Manually copy over listing content and order Pages Area homepages (e.g. default.aspx) are upgraded to the new page template model By default, all pages will use the installed page template after upgrade

37. Additional Considerations For SPS Site Applications And SSO News Link listings become Redirect Pages Content listings become Pages Both are rolled up by Content Query Web Part Site Directory Sites List schema changes New columns added to Sites List for categories Single Sign-On (SSO) No schema changes for v3 Gradual: configure v3 to point to v2 SSO db Content DB Migration: copy, restore v2 SSO db to v3 farm

38. Additional Considerations For SPS Search And Alerts Search Indexes not upgraded – full crawl of all content required after upgrade All content sources default to a single index (v3/2007 has one index per SSP) Duplicate start addresses in content sources will be ignored Conflicting crawl rules between v2/2003 indexes will be ignored (if item included in any index, it will be preserved) Search scopes, scope groups not upgraded SPS Alerts V2 alerts preserved but not automatically upgraded

39. Additional Considerations For MySites All Upgrade Approaches My Sites are upgraded to v3/2007 look and feel, new features (Colleagues, Memberships, Blogs) Consider moving My Site to its own web application which uses the MySite host template URL simplicity; one place for my personal data (http://my) B/R, performance; dedicated content DBs Gradual Upgrade-specific Until users personal site is upgraded, entire MySite experience remains v2 Once v2 Shared Services are upgraded, changes to v2 profile will not be copied to upgraded v3 SSP

40. Additional Considerations For SPS With Shared Services Recommend Gradual Upgrade or Content DB Migration Search Two crawls running Recommend manually modifying v2/2007 start addresses to prevent double-crawling Keywords, site-level scopes only available for upgraded v3/2007 sites User Profiles/Audiences Gradual upgrade: Changes in v3/2007 pushed down to v2/2003 – does not include new properties and audience rules Review Managed Properties list for people search scope Review upgraded audiences – consider deleting those built on DLs/SGs as those groups can be used directly

41. Post-Upgrade Considerations Delete un-needed v2/2003 sites Needed for Gradual Upgrade & Content DB Migration Finalize Upgrade Required step for Gradual, In-Place Removes temporary data maintained about v2/2003 environment Post-upgrade data migration Un-install v2/2003

42. Common Upgrade Challenges Pre-scan cannot update locked or over-quota sites or database orphans Impact of redirects Office client applications Gradual upgrade hardware & disk requirements Database sizes Application pools & accounts V2 and v3 central admin account should be the same Create new v3 app pools: ASP.Net 1.1 & 2.0 conflict Avoiding content updates during upgrade

43. Common v2 Customizations Look for these elements when considering content db migration approach CSS files _layouts files Graphics Site definitions Themes (required for custom v2 site definitions) Web parts (bin and GAC) Web.config and safe controls list Non-Sharepoint Elements NT Services Web services IIS Vservers Custom DLLs

44. Topics Design goals Before Upgrade Upgrade Approaches In-Place Upgrade Gradual Upgrade Content DB Migration Additional Considerations: SharePoint Portal Server Shared Services Post Upgrade Summary of Alternatives and Trade-offs

45. Summary And Tradeoffs Upgrade Approach In-PlaceGradualDB Migration PROs SimpleUpgrade smaller batches of data V2 and V3 stay live Can revert to original Uses existing HW Upgrade and move to new farm V2/2003 is a separate farm, not affected CONs Entire farm offline during upgrade No revert ability Hardware intensive: memory and SQL storage Redirects for v2/2003 URLs during upgrade Many complex manual steps required, higher risk of error Requires new farm, double the SQL storage

46. Call To Action Try upgrade Gradual, in-place, db attach Avoid upgrading on DCs Avoid known issues Look for upgrade in README SPS gradual upgrade, multi-server farm When you send feedback Need log files from \logs Screen images of errors

47. © 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.