Transcript Windows SharePoint Services and Microsoft Office

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
Topics
Design goals
Before upgrade
Upgrade approaches
In-place upgrade
Gradual upgrade
Content DB migration
Additional considerations
Microsoft Office SharePoint Portal Server 2007
Shared services
Post upgrade
Summary of alternatives and trade-offs
CMS/SPS/WSS Roadmap
Content
Management
Server 2002
Microsoft Office 2007
SharePoint Servers
SharePoint Portal
Server 2003
Microsoft
Windows SharePoint
Services v2
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
Topics
Design goals
Before upgrade
Upgrade approaches
In-place upgrade
Gradual upgrade
Content DB migration
Additional considerations
Microsoft Office SharePoint Portal Server 2007
Shared services
Post upgrade
Summary of alternatives and trade-offs
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
Maintaining Customizations Example
Does not match rest of site
Lacks new features:
Navigation
Site actions menu
Security trimmed UI
Recycle bin
Etc…
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
Topics
Design goals
Before upgrade
Upgrade approaches
In-Place upgrade
Gradual upgrade
Content DB migration
Additional considerations
Microsoft Office SharePoint Portal Server 2007
Shared services
Post upgrade
Summary of alternatives and trade-offs
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
In-Place Upgrade
Run setup, choose
upgrade in-place
Search +
User
Profiles
Search +
User
Profiles
Web Server
Web Server
All items upgraded
SPS Web App
MOSS Web App
IIS sites
SPS Web App
MOSS Web App
Local data
Config & content databases
Repeat setup & upgrade
on each server in farm
SPS no longer available
after upgrade
SPS Config
DB
MOSS
Config DBs
SPS Content
DB(s)
MOSS
Content DB(s)
SPS Search +
User Profiles
MOSS SSP
DBs
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
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
Search & Job Server(s)
Web Server(s)
SPS Web App
Portal site
Team
sites
MySites
MOSS Web
App site
Portal
Team
sites
MySites
Create new MOSS web app
Creates matching content db
for each SPS content db
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
SPS Config
DB
MOSS Config
DBs
SPS Content
DB(s)
MOSS
Content DB(s)
SPS Search/
User Profile
DB(s)
MOSS SSP
DB(s)
Gradual Upgrade
URL redirects
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
Pre-upgrade
During upgrade
SPS at //domain
SPS at //domain_old
MOSS at //domain
Create //domain_old
URL
Requests for
//domain/sites/WSS
Key site at
//domain/sites/WSS
redirected to
//domain_old/sites/wss
until it is upgraded
After upgrade
MOSS at //domain
Redirects not needed
once upgrade
completes & results
are validated
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
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 WSS v2 URL is removed
WSS v3 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.
6.
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
Content Database Migration
Search +
User
Profiles
Search +
User
Profiles
Create new MOSS farm
Web Server
Web Server
Initialize MOSS web applications SPS Web App
MOSS Web App
SPS Web App
MOSS Web App
Manually copy customizations
Custom templates
MOSS
Config DBs
All custom web parts
(BIN & GAC)
MOSS
Content DB(s)
MOSS SSP
DBs
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 e-mail 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
Topics
Design goals
Before upgrade
Upgrade approaches
In-place upgrade
Gradual upgrade
Content DB migration
Additional considerations
Microsoft Office SharePoint Portal Server 2007
Shared services
Post upgrade
Summary of alternatives and trade-offs
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. http://sample_site/c16/marketing changes to
http://sample_site/marketing
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
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
Topics
Design goals
Before upgrade
Upgrade approaches
In-place upgrade
Gradual upgrade
Content DB migration
Additional considerations
Microsoft Office SharePoint Portal Server 2007
Shared services
Post upgrade
Summary of alternatives and trade-offs
Summary and Trade-offs
Upgrade
Approach
PROs
CONs
In-Place:
Simple
Entire farm
offline during
upgrade
No revert ability
Gradual
DB Migration
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
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
URLs, Farms and Admin Effort
In Place
Same URL
Same Farm
Least Admin Effort
Gradual
New URL’s
Same Farm
Moderate Admin Effort
DB Migration
New URL’s
New Farm
Extensive Admin Effort
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 <WSS install dir>\logs
Screen images of errors
Portal Server Upgrade
Resources
Technical Chats and Webcasts
http://www.microsoft.com/communities/chats/default.mspx
http://www.microsoft.com/usa/webcasts/default.asp
Microsoft Learning and Certification
http://www.microsoft.com/learning/default.mspx
MSDN & TechNet
http://microsoft.com/msdn
http://microsoft.com/technet
Virtual Labs
http://www.microsoft.com/technet/traincert/virtuallab/rms.mspx
Newsgroups
http://communities2.microsoft.com/
communities/newsgroups/en-us/default.aspx
Technical Community Sites
http://www.microsoft.com/communities/default.mspx
User Groups
http://www.microsoft.com/communities/usergroups/default.mspx
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.