Troubleshoot upgrade issues (SharePoint Server 2010)
Applies to: SharePoint Server 2010
Even after you test the upgrade process to identify potential issues, you might experience unexpected issues during an upgrade from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 2010. If you experience issues after upgrade, the sooner you detect and fix them, the better the end-user experience will be.
This article describes general principles for identifying and addressing upgrade issues, and includes a list of common issues. After you have identified and addressed the issues, you can resume upgrade. For more information about how to resume upgrade, see Resume upgrade (SharePoint Server 2010).
In this article:
General principles for identifying issues
Common issues
Missing or deprecated server-side files or customizations
Incorrectly configured or missing settings for server farm, Web application, or services
Inconsistent or incorrect update levels
Missing global navigation for blogs
Data issues
UI changes
Lack of space
Forms-based authentication
Security and permissions
.Stp files are not working after upgrade
Cannot find new versions of the Fabulous 40 application templates
Upgrading data from SharePoint Portal Server 2003: pre-upgrade checker reports corrupted databases
General principles for identifying issues
Start by checking the upgrade status to see where upgrade stopped (if it did stop), and check log files to find any errors or warnings. Next, address the issues that you find before you resume the upgrade.
First, check upgrade status and log files
Upgrade status indicators and log files should give you an indication of what went wrong during the upgrade process. We recommend that you carefully review all the errors that were logged in the upgrade log files. Warnings might not always indicate an issue, but you should review them all to determine whether any of them are likely to cause even more issues.
Check upgrade status by doing one or both of the following:
Review the Upgrade Status page in the SharePoint Central Administration Web site.
Use the Stsadm.exe operation localupgradestatus to check upgrade status.
For more information about how to check upgrade status, see Verify upgrade and review upgraded sites (SharePoint Server 2010).
Review the following log files:
The Setup.exe log file.
The SharePoint Products Configuration Wizard (Psconfig.exe) log file.
The upgrade error log file and the upgrade log file (which contains more detailed information than the upgrade error log file).
ULS or trace log files.
These files are stored in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS folder and are named Servername_YYYYMMDD-MMSS.log.
The application event log file.
This file can be viewed by using the Event Viewer.
For more information about the Setup.exe, PSconfig.exe, and upgrade log files, see Verify upgrade and review upgraded sites (SharePoint Server 2010). For more information about the trace log file, see Trace Logs (https://go.microsoft.com/fwlink/p/?LinkId=182380) on MSDN.
Then, address issues in order
Some issues have more effect than others. For example, a missing server-side file can cause many seemingly unrelated errors at the site level.
Address issues in the following order:
Missing server-side files or customizations, such as features or Web Parts.
Configuration issues in the server farm, Web application, or services, such as managed paths or services that are not started.
Additional issues that you discover on a site-by-site basis, starting with high-impact, high-profile sites.
As you identify and fix the top-level issues, you can try running upgrade again to see whether any issues further along in the upgrade process have also been fixed.
Common issues
Check to see whether any of the following issues are causing an upgrade error or warning.
Missing or deprecated server-side files or customizations
One common error during upgrade is missing server-side files — either files that were installed with Office SharePoint Server 2007 or customized files. When you prepared for upgrade, you should have created an inventory of the server-side customizations (such as site definitions, templates, features, Web Parts, assemblies) that your sites required. (The pre-upgrade checker can help identify these items.) Check this inventory to make sure that all the files that are needed for your customizations are installed in your upgrade environment.
If you are performing a database attach upgrade, you can use the test-spcontentdatabase Windows PowerShell cmdlet before you upgrade the database to identify any missing files. You can also use the enumallwebs operation in Stsadm.exe to identify server-side customizations that are being used.
In the upgrade log files, you may see errors such as the following:
ERROR Found Reference Count web(s) using missing web template Site Template Identifier (lcid: Site Template Language Code) in ContentDatabase Content Database Name.
ERROR Found a missing feature Id = [Feature Identifier]
ERROR File [Relative File Path] is referenced [Reference Count] times in the database, but is not installed on the current farm.
WARNING WebPart class [Web Part Identifier] is referenced [Reference Count] times in the database, but is not installed on the current farm.
WARNING Assembly [Assembly Path] is referenced in the database, but is not installed on the current farm.
WARNING Feature could not be upgraded. Exception: Feature definition id 'Feature Identifier' could not be found.
If you can obtain a missing server-side file or dependency, install it and then run upgrade again for the affected sites. If the file or dependency (such as a Web Part) has been deprecated, you have to investigate whether you want to rebuild the site, page, or Web Part to use a different template, feature, or Web Part. If you can redo the customization by using dependencies that have not been deprecated, you can run upgrade again for the affected sites. If you cannot remove the dependency, you cannot upgrade the site.
After you install the missing file or dependency, use the test-SPContentDatabase Windows PowerShell cmdlet on a test server to determine whether any other files for that database are missing. If you only run the pre-upgrade checker or run upgrade again, the error might not appear in the log files, even though it might still be occurring.
Incorrectly configured or missing settings for server farm, Web application, or services
Verify your farm and Web application settings, and create and start any missing services.
Verify that any managed paths (included or excluded paths) are configured correctly for each Web application.
In the upgrade log files, you may see errors such as the following:
ERROR Template Template Id: SPSite Id=Site Id could not be accessed due to exception. Skipping SPWeb Id=Web Id for template upgrade. Exception: System.IO.FileNotFoundException: The site with the id Site Id could not be found.
This error indicates that a managed path is missing. Add the managed path for the site collection into the Web application and restart upgrade for the content database that contains this site collection.
Inconsistent or incorrect update levels
You must be running Office SharePoint Server 2007 with Service Pack 2 to run upgrade. If you do not meet this minimum requirement, you will see an error and upgrade will not run.
In addition, your servers must be updated correctly. For example, if you have applied the Windows SharePoint Services 3.0 version of an update, but not the Office SharePoint Server 2007 version of the update, upgrade will not run. The version number for Windows SharePoint Services 3.0 is displayed on the Servers in Farm page in SharePoint Central Administration. The version number for Office SharePoint Server 2007 is the version number of the file Microsoft.SharePoint.portal.dll in the %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\ISAPI folder. The version numbers on the Servers in Farm page and for the Microsoft.SharePoint.portal.dll files must match, and must be at 12.0.6420.1000 or higher to upgrade. For more information, see Deploy software updates for Office SharePoint Server 2007.
Missing global navigation for blogs
Another common error is the global navigation is missing for upgraded blogs. This occurs because the MySiteNavigation (6adff05c-d581-4c05-a6b9-920f15ec6fd9) feature is not enabled during the upgrade. To enable this feature, run the Enable-SPFeature Windows PowerShell 2.0 cmdlet.
For more information, see Enable-SPFeature.
Data issues
The following data issues can cause errors or warnings during upgrade:
Connectivity to data sources. If your servers cannot connect to the databases, they cannot be upgraded.
Orphaned sites or lists, or other database corruptions. For more information, see Clean up an environment before upgrade (SharePoint Server 2010).
Hidden column data. If the upgrade process adds a column to a list, and a custom column that has that same name already exists in the list, the custom column is renamed. After upgrade, you might have to readjust your views to include the renamed column.
In the upgrade log files, you may see errors such as the following:
WARNING The orphaned sites could cause upgrade failures.
ERROR Database [Content Database Name] contains a site (Id = [Site Collection Identifier], Url = [Site Collection URL]) that is not found in the site map.
Fix any orphaned items or database corruptions, and then run upgrade again.
UI changes
Changes to the user interface (UI), such as the addition of the Fluent UI (also known as the ribbon) or adherence to XHTML standards, can cause problems in sites. Occasionally, custom elements (such as a content type) may have a name that conflicts with a name in the new version. You may also have pages that must be reverted to the standard site definition, or large lists for which you have to create new views.
For more information about how to review UI issues in sites, see Verify upgrade and review upgraded sites (SharePoint Server 2010).
In the upgrade log files, you may see errors such as the following:
Failed to activate site collection features on site Site Url. Exception: A duplicate content type name "name" was found.
This error indicates that a 3rd party "Summary Info" content type was added to the specified site in o12 and during upgrade to o14 it name conflicts with our out of the box "Summary Info" content type. Delete or rename the 3rd party content type in the specified site to something other than "Summary Info" and re-run upgrade.
Lack of space
If you run out of space (for example, for transaction log files on your database servers), upgrade cannot continue. Free some space, or increase the size of the transaction log file before you resume upgrade. For more information, see Managing the Size of the Transaction Log File (https://go.microsoft.com/fwlink/p/?LinkID=124882).
Forms-based authentication
Additional steps are necessary if you are upgrading an environment that uses forms-based authentication. Follow the steps in Configure forms-based authentication for a claims-based Web application (SharePoint Server 2010) to upgrade forms-based authentication providers.
Security and permissions
If you receive an error about an unknown account, or if a database is not upgraded, verify the following:
For an in-place upgrade, make sure that the account that you use to run the SharePoint Products Configuration Wizard is a member of the db_owner fixed database role for all the databases that you want to upgrade. If it is not a member of this role, you might see an error about an unknown user account when the wizard starts to upgrade the databases.
For a database attach upgrade, if you are moving databases between instances of SQL Server, make sure that you verify that security is configured correctly. Check that the accounts that you are using have the appropriate fixed roles and permissions on the databases, and that they will still be valid accounts if you are upgrading across domains.
.Stp files are not working after upgrade
Site templates (.stp files) are deprecated in SharePoint Server 2010 and cannot be used to create new sites. Existing sites that are based on .stp files will continue to function as usual. Solution packages (.wsp files) are the supported method for creating sites that are based on a template in SharePoint Server 2010. You can convert an .stp file to a .wsp file to continue to use the template after upgrade.
To convert an .stp file to a .wsp file
In Office SharePoint Server 2007, create a site that is based on the template, and then upgrade the site to SharePoint Server 2010.
In SharePoint Server 2010, on the Site Actions menu in the upgraded site, click Site Settings.
On the Site Settings page, under Site Actions, click Save site as template.
On the Save as Template page, enter a File name and Template name, and then click OK.
The site template is saved as a .wsp file to the Solutions Gallery for that site collection and you can create new sites that are based on that solution.
Cannot find new versions of the Fabulous 40 application templates
Many people have used the "Fabulous 40" templates that were created for Windows SharePoint Services 3.0. Some of these templates were created as site admin templates (.stp files) and some were created as server admin templates (.wsp files). Microsoft is not releasing new versions of these templates for SharePoint 2010 Products. Also, .stp files are deprecated and cannot be used to create new sites when you upgrade to SharePoint Server 2010.
You can upgrade sites that are based on these templates. However, you should try to upgrade these sites in a test environment before you upgrade the production environment so that you can discover any potential issues. Use the pre-upgrade checker to discover any issues. (Some people have seen problems with custom workflows or CAML-based views in the templates.) Note that after upgrade, you will be unable to use .stp files to create new templates.
The following table describes how the templates can be used.
| Type of template | Can I upgrade sites that are based on this template? | Can I use the template after upgrade? |
|---|---|---|
Site admin (.stp file or site template) |
Yes |
No |
Server admin (.wsp file or solution package) |
Yes* |
Yes* |
*There are issues with some .wsp files after upgrade. In particular, after upgrade, some customers cannot create new sites that are based on the following templates: Absence Request and Vacation Schedule Management, Call Center, Help Desk, IT Team Workspace, Knowledge Base, and Physical Asset Tracking and Management. If you have problems using any of these templates, you can post an issue to the SharePoint 2010 – Setup, Upgrade, Administration and Operation TechNet Forum (https://go.microsoft.com/fwlink/p/?LinkId=201600), or contact Microsoft Customer Support.
If you want to continue to create sites that are based on the site admin templates (.stp files) in SharePoint Server 2010, you must convert them to solution packages (.wsp files). For more information, see the section .Stp files are not working after upgrade earlier in this article.
Upgrading data from SharePoint Portal Server 2003: pre-upgrade checker reports corrupted databases
When a content database in an Office SharePoint Server 2007 farm was upgraded from a Microsoft Office SharePoint Portal Server 2003 content database, you might see the following error when you run the pre-upgrade checker:
Failed : Content database with modified database schemas
If you did not make any manual schema changes to the database, you can ignore this error and continue with the ugprade. This is a residual error from the upgrade process from SharePoint Portal Server 2003 to Office SharePoint Server 2007. For more information, see the Microsoft Knowledge Base article 954772.
See Also
Concepts
Use a trial upgrade to find potential issues (SharePoint Server 2010)
Verify upgrade and review upgraded sites (SharePoint Server 2010)
Resume upgrade (SharePoint Server 2010)
Other Resources
Downloadable book: Upgrading to SharePoint Server 2010
Resource Center: Upgrade and Migration for SharePoint Server 2010