Cet article est disponible en francais.

I upgraded recently a WSS 3.0 Farm to Sharepoint Foundation 2010, I tought I’d share some of notes and pitfalls I found during the upgrade.

My setup is built around two Windows Server 2008 R2 64 Bits VMs hosted on Hyper-V Server R2, one VM for the frontend, one for the Database (SQL Server 2008 SP1 64 Bits) and the Search Server Express.


Hyper-V Assisted Upgrade

Having the setup built on Hyper-V saved me a great deal of time, primarily by the use of snapshots taken at the same time on both machines. This helped a lot to be able to experiment directly on the production system during an expected downtime for the users.

The snapshots allow a trial and error process that lead to a somehow “perfect” environment where mistakes can be reversed pretty easily. Ugrading using this snapshot technique is however pratical only with enough disk space and a reasonable content database size depending on the physical hardware.



Here are the steps I followed to perform the upgrade :

  • Made clones of both machines in a VM library, just to be safe in case the Hyper-V messed up the VMs because of the snapshots (you never know)
  • Upgraded WSS 3.0 with latest Cumulative Updates (KB978396)
  • Downloaded Sharepoint Foundation and Search Server Express packages
  • Installed the prerequisites of Sharepoint Foundation on both VMs (not Search Servers prerequisistes, which do not install properly, and are seemingly the same as the SPF package)
  • Installed SQL Server 2008 SP1 Cumulative Updates KB970315 and KB976761 (in this order)

That’s the easy part, where updates do not impact the running farm.

I took a snapshot of both VMs at this point.


Upgrading SharePoint and Search Server

You may want to read information on this on technet, which is very extensive.

Now, the Sharepoint upgrade :

  • Put a site lock in place (just in case a user might try to update stuff he’d probably lose)
    • stsadm -o setsitelock -url http://site -lock readonly
  • Detached the content databases using : (See later for the explanation of this step)  :
    • stsadm.exe -o deletecontentdb -url http://site –databasename WSS_Content
  • Backup the content DB so they can be upgraded on an freshly installed SPF2010 setup.
  • Executed the Search Server Express setup on both machines, without configuring it
  • Upgraded Sharepoint Foundation setup, without configuring it
  • On the frontend VM (so the admin site can track the update jobs), ran the Sharepoint Configuration wizard to perform the upgrade. I selected the Visual Upgrade so the site collections templates would use the new visual style (Ribbon powered !)
  • After the configuration ended on the frontend machine, ran the same wizard on the database VM.
  • Let the jobs run and finish properly.
  • On a temporary empty SPF 2010 setup on a spare VM, mounted the backed up content DB and ran this powershell command :
    • Mount-SPContentDatabase -Name WSS_Content -DatabaseServer db.server.com -WebApplication http://site –Updateuserexperience
    • You may require to install the templates used on your production environment to perform the upgrade properly.
  • After the content db upgrade ended, detached the content database using the admin site (beware of the dependencies between content DBs if you have more than one)
  • Backuped up the content DB.
  • On the production Farm, dropped and recreated the appropriate Web Application without any site collection. I did this step to make sure the AppPools and sites were configured properly.
  • Restored and attached the content DB on the production server using the SPF admin site.

Now, I did perform the “Attach/detach” procedure because it can be performed in parallel on multiple farms if the content databases are huge, and on my production setup, the in-place upgrade did not work properly. The images libraries where not upgraded properly (images where not displayed), and the default pages did not render properly for some obscure reason.


A few additional gotchas

  • I had a few other issues with the search SSP, where I needed to remove completely the Search SSP and recreate it to avoid this error :
    • CoreResultsWebPart::OnInit: Exception initializing: System.NullReferenceException
  • The search SSP needs uses of the Security Token Service Application, which by default does use the “Extended Security” setting, which needs to be turned off in IIS.
  • Since I use Search Server Express, Content Databases must not select the search provider named “Sharepoint Foundation Search Server” for the search to work properly.


Upgraded Wikis

You’ll find the the wiki editor has been greatly enhanced, and you’ll find it even more powerful when you select the “Convert to XHTML” option in the html menu of the ribbon. The original pages were using the very loose HTML 4.0, which does not seem to work very well.

Other than that, everything else works very fine in this area.


Upgraded Discussion Boards

I had a few discussion boards that had issues with the view of individual conversations using the threaded view. The conversation were defaulted to the default “subject” view, which is not applicable to view single threads. To fix this, make a new “subject” view and delete the previous one the normal behavior will come back.


Happy SharePointing ! Now I can go back to my Immutability and F# stuff :)