SharePoint 2010 Upgrade Part 2: Advanced Scenarios
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. Lots of good, detailed information here. 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. Basic upgrade process and tools information was presented in part 1. (My notes for that session are here.)
The Upgrade Team worked within a specific Upgrade Philosophy that included the following tenets:
- Detect issues early, both in O12 and at start of upgrade.
- Keep the administrators informed as to issues and next steps.
- No data loss.
- Minimize downtime
- Continue when possible (when errors are not fatal, log an error and move on)
- Be reentrant (prevent catastrophic failures that cause complete restoration)
Stage 1: Boot strap
- Config db
- Admin content db
- Pre-joined farm
- Join farm
Stage 2: Central Admin
- Local farm
- Admin web service
- Admin web application
- SPIISSite objects
- Admin content db > Web Templates, Features Upgrade, SPSites
Stage 3: User Data (performed by a Timer Job ASAP. This prevents problems if the admin’s Terminal Server session times out and logs off.)
- Local farm
- SharedResourceProvider12 Objects > Partner stuff
- ???? (didn’t type fast enough…)
- Content databases > Web templates, Features upgrade, SPSites
Within these steps come many smaller actions. Each of these are marked as successful when complete within the object schema. If the upgrade is restarted, it resumes after the last successful action in each sequence.
The further you are from the current patch level, the longer the upgrade will take, because it has to perform those actions now.
- V2V upgrade DBs set to simple recovery to maximize performance (may not happen in Beta 2)
So, don’t do any log shipping or mirroring during upgrade.
- DB growth during upgrade (2 to 3 times the normal size including the log)
- Manually shrink database after upgrade
- There will be a Health Rule that looks for DBs with large amounts of free space
- SQL timeouts are removed (if SQL server is still up)
- Version Path fallback logic (if dependencies are not in the 14 hive, look in the 12, if not there look in 60)
- Object locking has been reworked to allow multiple db upgrades to run concurrently without interfering with each other (checks for stale locks every 2 minutes)
Read-Only Content Databases allow you to upgrade a copy of the databases on the new farm while users access content.
- This is only for Content Databases
- Must be at least 2007 SP2
- SharePoint reads SQL database lock settings and proactively applies site collection locks so the users don’t see edit functionality in GUI
- If traffic is high, you may need to duplicate your SQL server for the upgrade to have enough resources
Parallel Upgrade used to be done via separate temporary farms. Now it can be done in separate command windows on the same server. Microsoft internal testing has found that a single true SQL server can handle up to about 8 concurrent upgrade threads. If you’re doing it in a limited VM environment, it’s probably more like 2 or 3.
AAM Redirection can now be used with the Content DB Attach upgrade, but it should be seen as the approach of last resort. This can only be as granular as your content databases are. It is complex and requires URL changes which means link fixup will be needed and not all clients will understand the changes.
The planning process before you attempt an upgrade should include many things:
- Gather information
- Pre-upgrade checker
- New server with same version and patch level
- Compare Web Server Extensions directory
- Compare IIS directory
- Compare GAC directory
- Determine impact (stsadm –o EnumAllWebs)
- Stale sites and webs
- Old document versions
- Templates, features, and web parts
- Repair data issues
- stsadm –o database repair
- stsadm –o deletelist
- Collect customizations
- Gather original installation media
- stsadm –o ExportIPFSAdminObjects
- Test the upgrade
- Don’t ignore warnings and errors in logs
- Use real datasets
- Similar hardware
- FBA will need to have some changes ALWAYS in your web.config files
- For the web app
- For Central Admin
- For the Security Token Service
- Make sure you test in both UI modes
Surprisingly, upgrade performance is more affected by number of sites, webs, lists… than it is by database size. Hardware limitations are also key.
When the upgrade is finished, there are some manual things you will likely need to do.
- FBA configuration
- Unghosted pages
- Over wide lists (too many columns)
- Site templates and list templates will not come forward in the upgrade
Instances built from the templates are fine, just the templates don’t upgrade. You will need to recreate the templates (best practice is to do this as user solutions instead of .stp files)
If upgrade fails (hypothetically, of course), the following sequence is recommended for troubleshooting:
- Go to status page
- Go to error log
- Go to full upgrade log (the correlation ID from the error screen is helpful to find the relevant log entries)
- stsadm –o enumallwebs
- Fix issues
- Restart your upgrade