In this blog post, we will discuss some tips and techniques around the B2B upgrade process.

Detaching and attaching the Content Database:

Many times during the upgrade process, we may see errors that are specific to one or two content databases especially when you have several content databases and of large size in the farm. In these scenarios, we can detach the specific content database, do the upgrade by running configuration wizard on the farm and then attach the database back. When we attach it back, the content database will be upgraded. Of course, we can encounter the same error, but it will be easier to troubleshoot and also the entire farm will not be down while we are finishing the upgrade of that content database.

Below is the command for detaching the content database:

stsadm -o deletecontentdb -url <url> -databasename <name of the database>

The command for attaching back the content database:

stsadm -o addcontentdb -url <url> -databasename <name of the database>

Orphan entries:

If you encounter any error in upgrade log that indicates orphan entries, for example, "Cannot insert the value NULL into column 'ScopeId'", "The system cannot find the path specified" at the Microsoft.SharePoint.Library.SPRequestInternalClass.GetSiteQuota() method etc, we can check for the existence of orphan entries.

To check for Orphans, use the below command:

stsadm -o databaserepair -url <url> -databasename <name of content database>

To remove/delete the orphan entries, we can run the following command:

stsadm -o databaserepair -url <url> -databasename <name of content database> -deletecorruption

The upgrade process seems to be hung:

Sometimes, depending on the size and the state of the content database, it may take quite a long time for the upgrade process to complete. We should NOT assume it is hung and we should NOT cancel the upgrade process. We need to verify if there is any CPU utilization on the WFE or the SQL box. We can also use SQL Profiler to monitor and check if there is any activity going on the SQL server for the SharePoint databases. We can also keep monitoring the upgrade.log to see if we are progressing or it is really hung/blocked.

Cancelling the upgrade process explicitly in between could leave the farm in a corrupted state. If you are running the upgrade process on the production environment, and if it seems like hung, you can contact Microsoft support line to open a support case for assistance.

While concluding, I want to stress on the point, always test the upgrade on a test environment before doing it on the production environment. Take a Full farm backup from SharePoint level and also take SQL level backup of all the SharePoint databases before doing anything on the production farm. Take the backup of any customizations you have done. Also, make sure that you plan some maintenance window as it may take quite a long time for the upgrade to finish depending on the size and state of the databases and just in case if we encounter any problem, we have enough time to troubleshoot it.

Hope it helps :)