These are some notes from a great session today at the SharePoint Conference 2009 in Las Vegas delivered by Sean Livingston, the Upgrade Program Manager at Microsoft.  The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be.  I’ve decided to err on the side of more information – less polish.  There will be another session immediately following about advanced upgrade scenarios – so stay tuned.

Let’s start with some quick reference information:

Supported Scenarios

• In-Place
• Database Attach – Probably the most common to be used
• Single Click Install (Basic install w/ WID to SQL Express 2008)

Unsupported Scenarios

• Upgrade from earlier than WSS v2 SP2 / MOSS 2007 SP2
• Direct upgrade from WSS v2 / SPS 2003 or earlier
• Side by side installation
• Gradual upgrade (although AAM redirection is still possible, see next session)

There are several preparation tools that come bundled with 2007 SP2 (enhanced in October 2009 CU) to get you ready to upgrade:

• stsadm –o preupgradecheck (-localonly if you want to run against individual servers)
• stsadm –o EnumAllWebs (10/09 version includes features, event receivers, and web parts activated per web)
• SPDiag V2 (in the Admin Toolkit)
• stsadm –o ExportIPFSAdminObjects (for customizations like admin-approved InfoPath Form templates)

The preupgrade check looks for many things and reports on them.  This is done without editing the databases, and the operation is not required before upgrade – both of which are changes from the 2003 > 2007 prescan operation.

• Informational
• Farm servers and databases
• AAM Configuration
• Lists, Site Definitions (with instance counts), Features, Web Parts, Event Receivers to match up GUIDs and find missing elements
• FBA configuration (FBA will have to be reconfigured in 2010, think web.configs…)
• Installed Language Packs
• CAML views/CAML content types
• Issues
• Missing Site Definitions, Features, Assemblies
• Data orphans
• Modified content databases

There are also some new tools available in 2010 to help from the new server:

Test-SPContentDatabase

• Complements the pre-upgrade check
• Compares against a specific web application to look for missing dependencies
• Scans both 12 and 14 databases

Upgrade-SPContentDatabase

• Will resume an upgrade process (B2B or V2V) already in progress
• This DOES NOT attach a database (contrary to the Beta review document distributed in hard-copy at the conference)
• Attaching is done by stsadm –o addcontentdb, or
• Mount-SPContentDatabase (NOTE: Until RTM, this one will force the UI upgrade to 14)
• Upgrade-SPEnterpriseSearchServiceApplication

The new Visual Upgrade Capability by default upgrades using the old Office 12 UI.  It does this by including all of the old master pages and CSS sheets in the new version.  Admins / Owners are then able to do a temporary preview of the new UI, and / or do a final UI upgrade to the new look and feel.

• Farm admin or site collection admin controlled
• Web level setting
• Preview mode is not meant for extensive changes
• Web parts can now be UI version aware to make them automatically render differently per instance
• Some items are not O12 compatible
• MySite host
• Project Web Access site collection
• Report Server web parts

Patch Management has been overhauled, basically because it stunk in many ways in 2007.  2010 now has:

• A new UI
• A new PowerShell cmdlet
• New Health Rules
• Backwards compatibility mode
• Binaries can be ahead of the database(s)
• Defer upgrade for short period of time
• Not intended for long delay (maybe weeks or days)

There are multiple downtime mitigation techniques that can be used to minimize the effect of the upgrade process on end users.  Some of these are valid for both 2007 and 2010, and others are only in 2010:

Both

• Read-only databases (kind of, the UI just trims all of the edit functionality)
• Parallel upgrade farms
• Gradual Upgrade

2010 only

• Single server, multiple db upgrade sessions (works consistently well up to 2 sessions on the same disk spindle, for more you will need to test)
• Content database with AAM redirection

Upgrade logging has also been improved to help us trouble-shoot potential errors and warnings.

• One upgrade log per session
• Errors only log
• Predictable structure for log
• Improved status page
• New history page
• Command line progress indication

Shared Service Providers each get upgraded into separate service applications, and new databases are created as needed.