OFC333 Windows SharePoint Services and Microsoft Office SharePoint Portal Server: Upgrade and Migration Bill English MVP Mindsharp

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

Design goals Before upgrade Upgrade approaches Additional considerations Summary of alternatives and trade-offs Topics In-place upgrade Gradual upgrade Content DB migration Microsoft Office SharePoint Portal Server 2007 Shared services Post upgrade

Microsoft Windows SharePoint Services v2 SharePoint Portal Server 2003 Content Management Server 2002 CMS/SPS/WSS Roadmap Microsoft Office 2007 SharePoint Servers Microsoft Windows SharePoint Services ‘v3’

Design Goals Provide clean Microsoft Office SharePoint Portal Server 2003 (SPS) to Microsoft Office SharePoint Server 2007 (MOSS) upgrade No upgrade plans for SharePoint 2001 – MOSS release Minimize user impact Reduce outage duration Limit number of users impacted for any outage Support customizations to SPS Custom site definitions & web parts Pages customized using Microsoft Office 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

Before upgrade Design goals Upgrade approaches Additional considerations Summary of alternatives and trade-offs Topics In-place upgrade Gradual upgrade Content DB migration Microsoft Office SharePoint Portal Server 2007 Shared services Post upgrade

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 and new versions side-by-side; rollback to SPS supported More complex and resource intensive Content DB migration: upgrade into separate farm Attach SPS content database to MOSS farm and upgrade runs SPS stays available and untouched by upgrade Content only, requires new farm, has many manual steps

Before Upgrade to MOSS Upgrade farm to Office SharePoint SP2 – required Install pre-requisites Windows Workflow Foundation latest version ASP.Net 2.0 TIP: Test custom web parts with ASP.Net 2.0 in WSS SP2

Before Upgrade (cont’d) 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

Before Upgrade: Handling FrontPage customizations Important consideration: keep customizations or move to MOSS Custom pages kept by default during upgrade SPS 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 MOSS environment sooner Available in site settings or within SharePoint Designer Works for any page edited in SharePoint Designer or FrontPage

Maintaining Customizations Example Pre-upgrade Upgraded

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

Before Upgrade: Custom site definitions Existing sites based on custom SPS site definitions should work in MOSS MOSS site definition needed to create new sites Upgrade your custom site definitions Create new MOSS site definition Craft upgrade mapping – SPS to MOSS site definition Deploy mapping file & MOSS site definition to MOSS install directory, and run upgrade Can be done post-upgrade using command line

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

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 SPS master continues to provide services to SPS sites SPS sites retain user experience User profile, audience data pushed from MOSS->SPS by scheduled job Two search crawls active (SPS, MOSS) Maximize efficiency by removing SPS sites from SPS crawl after they are upgraded

Before upgrade Design goals Upgrade approaches Additional considerations Summary of alternatives and trade-offs Topics In-Place upgrade Gradual upgrade Content DB migration Microsoft Office SharePoint Portal Server 2007 Shared services Post upgrade

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 SPS supported More complex & resource intensive Best where there are many sites, & must limit downtime Content DB migration: Upgrade into separate farm Attach SPS content db to MOSS farm & upgrade runs SPS stays available and untouched by upgrade Content only, requires new farm, has many manual steps Best if moving to new hardware

Run setup, choose upgrade in-place Repeat setup & upgrade on each server in farm SPS no longer available after upgrade In-Place Upgrade SPS Config DB MOSS Config DBs Web Server SPS Web App Web Server MOSS Web App SPS Search + User Profiles MOSS SSP DBs SPS Content DB(s) MOSS Content DB(s) Search + User Profiles All items upgraded IIS sites Local data Config & content databases

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 (MOSS) site definition versions

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 SPS More complex than in-place Requires extra SQL storage, has perf impact on SPS Best where there are many sites, & must limit downtime Content DB migration: upgrade into separate farm Attach SPS content db to MOSS farm & upgrade runs SPS stays available and untouched by upgrade Content only, requires new farm, has many manual steps Best if moving to new hardware

SPS Config DB SPS Content DB(s) MOSS Config DBs MOSS Content DB(s) Web Server(s) SPS Web App MOSS Web App Portal site Portal site Team sites Team sites MySites MySites Portal site Portal site Team sites Team sites MySites MySites SPS Search/ User Profile DB(s) MOSS SSP DB(s) Gradual Upgrade Build MOSS 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 For each Web Application Creates matching content db for each SPS content db Create new MOSS web app Existing v-server moved to new domain, & site redirects created Manually re-deploy Web parts in Bin Upgrade batches of site collections Must upgrade root site first Upgrade 1 to N sites thereafter Command line available Search & Job Server(s)

Gradual Upgrade URL redirects After upgrade MOSS at //domain Redirects not needed once upgrade completes & results are validated Upgrade moves SPS virtual server to new URL domain Redirect is created for all sites to new SPS location As site is upgraded, redirect is dropped Browse access to original URL always works New URL domain is needed until upgrade is complete During upgrade SPS at //domain_old MOSS at //domain Requests for //domain/sites/WSS redirected to //domain_old/sites/wss until it is upgraded Pre-upgrade SPS at //domain Create //domain_old URL Key site at //domain/sites/WSS

Gradual Upgrade Steps: Create MOSS 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 MOSS 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

Gradual Upgrade Steps: Upgrade SPS “virtual server” Provide domain SPS will use during upgrade Recommendation: automatically create databases May be manually configured if necessary Need one MOSS content db for each SPS 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 SPS IIS site reconfigured to use new domain or port MOSS web application created using the original domain Choose SSP for web application Re-deploy any web parts located in the SPS bin

Gradual Upgrade Steps: Upgrade content  Choose if resetting files to template version Can change selection with each group of sites upgraded  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  During upgrade, redirect to WSS v2 URL is removed WSS v3 site is now live Automatic - no admin action needed  Review log files after each upgrade group Tip: Upgrade duration is in logs. Number of MB / duration is good approximation for subsequent upgrade durations.  Repeat steps 1-3 for all sites  Command line available to automate

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

Gradual Upgrade Steps: Shared Services Shared Services configuration For each master portal Configure search in MOSS Configure profile/audience sync in MOSS Review Managed Properties of user profiles in MOSS For each child portal Modify start addresses in SPS master portal to prevent double-crawling

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 SPS supported More complex & resource intensive Best where there are many sites, & must limit downtime Content DB migration: upgrade into separate farm Attach SPS content db to MOSS farm & upgrade runs SPS stays available and untouched by upgrade Content only, requires new farm, has many manual steps Best if moving to new hardware

Create new MOSS farm Initialize MOSS web applications MOSS Config DBs Web Server SPS Web App Web Server MOSS Web App MOSS SSP DBs MOSS Content DB(s) Search + User Profiles Manually copy customizations Custom templates All custom web parts (BIN & GAC) Content Database Migration

Content DB Migration Shared Services SPS not affected Master continues to provide services to SPS sites Child sites retain user experience User profile, audience data NOT pushed from MOSS to SPS by scheduled job Most search data not upgraded Re-create search settings other than custom search properties

Content DB Migration Steps Perform standard pre-upgrade steps Create new MOSS farm on clean hardware Configure SSP Create a new web application for each SPS virtual server Manually re-apply configuration settings Ensure all inclusions re-created in MOSS (required) Deploy all custom site definitions Deploy custom web parts to GAC or BIN Set server, special permissions Re-create quota templates

Content DB Migration Steps (cont’d) Back up SPS content database using SQL Restore backup to copy in MOSS 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

Content DB Migration Steps Other considerations Set SPS 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 MOSS farm Work-intensive – redirects all added manually Re-applying inclusions, custom web parts & custom site definitions are critical Entirely manual process for moving them Whitepaper planned to detail the process Inclusions (e.g. /teams, /mysites) commonly missed

Upgrade approaches Before upgrade Design goals Additional considerations Summary of alternatives and trade-offs Topics In-place upgrade Gradual upgrade Content DB migration Microsoft Office SharePoint Portal Server 2007 Shared services Post upgrade

Additional SPS Considerations: Site structure Areas Areas are upgraded to regular sub-sites All areas under a given portal must be upgraded at once URLs Portal URLs change after upgrade In MOSS URLs follow the logical navigation structure – navigation changes are now reflected in the URL E.g. changes to Redirects: links through Internet Explorer will be redirected; Office Client apps will not

Additional SPS Considerations: Site content Listings Listings in SPS: “Portal Listings” list + Listings web part Listings in MOSS: “Links” list items + Content By Query web part Consider creating MOSS 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

Additional SPS Considerations: Site applications News News listings are upgraded to Links list items and pages List items/pages are rolled up Content by Query Web Part Site directory Site is upgraded to new UI Sites List schema changes New columns added to Sites List for categories Single sign-on (SSO) No schema changes for MOSS Gradual: configure MOSS to point to SPS SSO db Content DB Migration: backup, restore SPS SSO db to MOSS farm

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 (MOSS has one index per SSP) Duplicate start addresses in content sources will be ignored Conflicting crawl rules between SPS indexes will be ignored (if item included in any index, it will be preserved) Search scopes, scope groups not upgraded SPS Alerts SPS alerts preserved but not automatically upgraded

Additional Considerations for MySites All upgrade approaches My Sites are upgraded to MOSS look and feel, new features (Colleagues, Memberships, Blogs) Consider moving My Site to its own web application which uses the MySite host template Gradual Upgrade-specific Until user’s personal site is upgraded, entire MySite experience remains SPS Once SPS Shared Services are upgraded, changes to SPS profile will not be copied to upgraded MOSS SSP

Additional Considerations for SPS with Shared Services Search Two crawls running Recommend manually modifying SPS/O12 start addresses to prevent double-crawling Keywords, site-level scopes only available for upgraded MOSS sites User profiles/Audiences Gradual upgrade: Changes in MOSS pushed down to SPS - 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

Post-Upgrade Considerations Delete un-needed SPS sites Needed for Gradual Upgrade & Content DB Migration Finalize upgrade Required step Removes temporary data maintained about SPS environment Post-upgrade data migration Un-install SPS

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

Common SPS Customizations CSS files _layouts files Graphics Site definitions Themes (SPS site def’n won’t render without it) Web parts (bin and GAC) Web.config and safe controls list Non-SharePoint Elements NT Services Web services IIS Vservers Custom DLLs

Additional considerations Upgrade approaches Before upgrade Design goals Summary of alternatives and trade-offs Topics In-place upgrade Gradual upgrade Content DB migration Microsoft Office SharePoint Portal Server 2007 Shared services Post upgrade

Upgrade Approach In-Place:Gradual DB Migration PROsSimple Upgrade smaller sets of data at a time SPS & MOSS stay live Can revert to original Uses existing HW Upgrade & move to new farm SPS is a separate farm, not affected CONs Entire farm offline during upgrade No revert ability Hardware intensive: memory & SQL storage Redirects for SPS URLs during upgrade Many complex manual steps required, higher risk of error Requires new farm, double the SQL storage Summary and Trade-offs

URLs, Farms and Admin Effort In Place Gradual DB Migration Same Farm Least Admin Effort Same Farm Moderate Admin Effort New Farm Extensive Admin Effort Same URL New URL’s

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

Portal Server Upgrade

Resources Technical Chats and Webcasts Microsoft Learning and Certification MSDN & TechNet Virtual Labs Newsgroups communities/newsgroups/en-us/default.aspx Technical Community Sites User Groups

Fill out a session evaluation on CommNet for a chance to Win an XBOX 360!

© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.