Verify upgrade and review upgraded sites (SharePoint Foundation 2010)

Article
07/22/2014

Applies to: SharePoint Foundation 2010

After you have performed either an in-place upgrade or a database attach upgrade to Microsoft SharePoint Foundation 2010, you must verify that the content was successfully upgraded to the new version. You can verify the status of the upgrade (is it still in progress, or has it been completed successfully or with errors or failures?) and then also review the upgraded sites to see whether any issues remain for you to address. When you follow these steps as part of a trial upgrade, you can use them to identify customizations that have to be reworked before you attempt to upgrade your production environment. When you upgrade your production environment, it is even more critical that you know when the upgrade was completed, which sites have been upgraded successfully, and which sites require additional work before you allow users access to them again.

In some cases, you might have to restart upgrade to finish upgrading your sites. For more information about how to restart upgrade, see Resume upgrade (SharePoint Foundation 2010).

In this article:

Verify upgrade status
Review upgraded sites

Verify upgrade status

The upgrade process has several phases. For in-place upgrade, you run Setup.exe to install the new software, and then run the SharePoint Products Configuration Wizard to upgrade the configuration database and the admin content database, and then the SharePoint Central Administration Web site opens. At this point, the content upgrade process starts. There are different ways to check the status of the upgrade process during each of these phases: You can review log files for Setup.exe, for the SharePoint Products Configuration Wizard, and for the content upgrade. In SharePoint Central Administration, you can view the version number to make sure that it is correct for the version that you upgraded to. Also, you can use the Upgrade Status page in SharePoint Central Administration or the localupgradestatus operation in Stsadm to find out which sites have been — or are currently being — upgraded. If upgrade was not successfully completed, you can view the log files to find the issues, address them, and then restart the upgrade process.

Review the log files

To verify that upgrade has succeeded, you can review the following log and error files:

The Setup.exe log file for SharePoint Foundation 2010.

The Setup log file is stored in the temp directory for the user account that is running Setup (%USERTEMP% or %WINDIR%\Users\user account\AppData\Local\Temp). It is named SharePoint Foundation Setup(YYYYMMDD-HHMMSS-SSS).log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds).
The SharePoint Products Configuration Wizard (Psconfig.exe) log file.

The Psconfig.exe log files are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. The logs are named in the following format: PSCDiagnostics_MM_DD_YYYY_HH_MM_SS_SSS_randomnumber.log, where MM_DD_YY is the date and HH_MM_SS_SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds), and the random number is used to differentiate between possible simultaneous attempts to run the Psconfig.exe program.
The upgrade log file and the upgrade error log file.

The upgrade log file and the upgrade error log file are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). The upgrade error log file combines all errors and warnings into a shorter file and is named Upgrade-YYYYMMDD-HHMMSS-SSS-error.log.

To review the log files to find and troubleshoot issues, start at the top of the files. Errors or warnings may be repeated if they occur for several site collections in the environment, or if they block the upgrade process completely. For example, if you cannot connect to the configuration database, the upgrade process will try (and fail) several times and these attempts will be listed in the log file.

To review the log files

Verify that you have the following administrative credentials:
- To view the log files, you must be a member of the local Administrators group on the server.
In Windows Explorer, change to the directory that contains the log file that you want to view.
Use a text editor to open the log file.
In the upgrade log file, search, or visually scan, for the following entry:

Upgrade session finished successfully!

If you find this entry, the installation was successful.
If you do not find the entries from the previous step in the upgrade log file, or if you are reviewing one of the other log files, you can identify specific issues that may have contributed to a failure by searching, or visually scanning, through the file for the following terms:
- Search for ERROR in the log files to find any failures (such as failing components and faulty database connections).
- Search for WARNING to find issues such as missing features or components.

To find issues, you may find it useful to use a log parser to run queries against the log files.

If you find blocking issues in the log file, you can resolve the issues and then restart upgrade to continue with the process.

Verify the version number

In addition to viewing the upgrade log file, you can verify that the upgrade was successful by using the SharePoint Central Administration Web site to view the version number on the Servers in Farm page.

To verify the version number on the Servers in Farm page

Verify that you have the following administrative credentials:
- To use SharePoint Central Administration, you must be a member of the Farm Administrators group.
On the Central Administration Home page, under System Settings, click Manage servers in this farm.
Under Farm Information, next to Configuration database version, verify that the number starts with "14".

Check upgrade status for sites

To find out which sites have been upgraded or are currently being upgraded, you can use either the Upgrade Status page in SharePoint Central Administration or the localupgradestatus operation in Stsadm.exe.

The Upgrade Status page lists the upgrade sessions and gives details about the state of each session — whether it succeeded or failed, and how many errors or warnings occurred for each server. The Upgrade Status page also includes information about the log and error files for the upgrade process and suggests remedies for issues that might have occurred.

To see which sites were missed or skipped during upgrade, you can use the localupgradestatus operation in Stsadm.exe. You must run the command on every front-end Web server in a server farm.

To view upgrade status in SharePoint Central Administration

Verify that you have the following administrative credentials:
- To use SharePoint Central Administration, you must be a member of the Farm Administrators group.
On the Central Administration Home page, under Upgrade and Migration, click Check upgrade status.

To view upgrade status from the command line

Verify that you have the following administrative credentials:
- To use Stsadm, you must be a member of the local Administrators group on the server.
Click Start, right-click Command Prompt, and then click Run as administrator.
In the Command Prompt window, navigate to the following directory:

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\bin
Type the following command and press ENTER:

Stsadm -o localupgradestatus

For more information about the localupgradestatus operation, see Localupgradestatus: Stsadm operation (Windows SharePoint Services).

Review upgraded sites

Review your upgraded sites to identify any issues that must be addressed before you run the upgrade process on your production environment. If you performed an in-place upgrade and chose to use Visual Upgrade, you can use the Visual Upgrade feature to preview the sites in the new user interface. For more information about previewing sites using Visual Upgrade, see Manage visual upgrade (SharePoint Foundation 2010).

If you want to verify basic functionality, you can create a new site collection by using a representative set of lists, libraries, Web Parts, and so on. Review the new site to make sure that the common, basic elements of your sites are working.

If pages are not rendered, you can check the Site Settings page by going directly to the URL (http:// siteurl/_layouts/settings.aspx). If the Site Settings page works and the upgrade has succeeded, there might be issues with the master page or home page. If the Site Settings page does not work, go to the log file to see whether you can get more information about the problem.

Begin by validating high-impact or high-profile sites, and then move on to lower-priority sites. As part of the planning process, you should have identified which sites are high-impact and high-profile and require immediate attention, and which can wait a bit longer.

Use the following checklists to review your upgraded sites and look for issues.

Web Parts

The following table lists issues with Web Parts that can occur after upgrade and how to address them.

Tip

To test your Web Parts quickly, you can build a new Web Part page that contains all of your custom Web Parts before you test your upgrade, and then review the page for any missing or broken Web Parts after the trial upgrade.

What to check	What to do if there is a problem
Do all the Web Parts from your original site appear in your upgraded site?	If a Web Part zone exists in a customized (unghosted) page, but not in the site definition, the Web Parts from that Web Part zone may have been moved into the bottom zone on the page during the upgrade. Either in Edit Mode for the page in the browser or in Microsoft SharePoint Designer 2010, look for missing Web Parts in the bottom zone or other zones, or check to see whether the Web Parts have been closed. For more information about how to work with Web Parts and Web Part zones in SharePoint Designer 2010, see the SharePoint Designer Help system.
Are the Web Parts displayed correctly (in the correct zone, location, and size)?	Either in Edit Mode for the page in the browser or in SharePoint Designer 2010, drag the Web Part into the correct zone or modify the Web Part properties to correct any sizing or positioning problems.
Are there any extra or missing Web Parts?	Open the page either in Edit Mode for the page in the browser or in SharePoint Designer 2010. If you see extra Web Parts on your page, look for closed or inactive Web Parts on the original version of the page. Were the closed or inactive Web Parts opened by the upgrade process? If so, you can modify the Web Part properties to close these Web Parts. If Web Parts are missing, look for errors in SharePoint Designer 2010 such as "Error Rendering Control" or "Missing Assembly." These errors indicate that the Web Part was not installed or was configured incorrectly for the new environment and must be reinstalled or reconfigured.
Do the Web Parts work correctly?	Open the page either in Edit Mode for the page in the browser or in SharePoint Designer 2010, and look for errors that indicate that a component or service is missing. Make sure that any components or services that the Web Parts rely on exist in the upgraded site. Particularly for the database attach upgrade approach, you must make sure that you have installed all the components or services that you must have for your Web Parts, and that you have configured them correctly (for example, you have configured the Web.config Safe Controls list). Update and redeploy any Web Parts that exist but no longer function correctly.

Tip

If you have problems with a Web Part, append contents=1 to the end of the URL syntax (http:// siteurl/default.aspx?contents=1), and then press ENTER. This opens the Web Part Maintenance page where you can remove and repair the broken Web Part.

Large lists

By default, large list query throttling is applied after an upgrade to SharePoint Foundation 2010. If a list is very large, and users use a view or perform a query that exceeds the limit or throttling threshold, the view or query will not be permitted. Check any large lists in your environment and have the site owner or list owner address the issue. For example, they can create indexed columns with filtered views, organize items into folders, set an item limit on the page for a large view, or use an external list.

Styles and appearance

The following table lists common issues with the style and appearance of your Web site after upgrade and how to address them.

Tip

Most of the issues in this section can be solved by correcting the links to an item.

What to check	What to do if there is a problem
Are all the images on your pages displayed correctly?	Verify or fix the links to the images.
Are the appropriate cascading style sheet colors and styles used in the appropriate locations?	Verify or fix the links to the cascading style sheet file. Verify the link on the master page.
Does the theme that you applied to your site still look the same?	Your site's home page, or other pages on your site, may look different after the site is upgraded. You may have to re-create or revise a theme and reapply it.
Do you have any scripted controls that are not working?	Verify or fix the links to the controls.
Are your pages displayed correctly in Windows Internet Explorer 8?	Verify that any HTML on the page is in strict XHTML mode.
Are any script errors displayed on any pages?	Verify the scripts and links, and verify that any HTML is in strict XHTML mode.

Permissions

Do the appropriate people and groups still have the correct level of permissions to sites, pages, lists, and items?

You can use the Check Permissions button in the Permission Tools section of the ribbon to see who has permissions to which items in a site or subsite.

Customized (unghosted) pages

Customized (unghosted) pages are pages that have been edited and are now unique versions of the pages, instead of the default template pages. The following table lists issues with customized pages that can occur after upgrade and how to address them.

What to check	What to do if there is a problem
Are your customizations still in the correct locations?	Determine whether you have only one issue or a larger problem with the whole page. If you added a brand new page to your original site (for example, if you replaced Default.aspx with a different file instad of changing the existing Default.aspx file), the new page has no association with the site definition. Therefore, it might not resemble the other pages on the upgraded site — nor can it be reset to resemble them. If you want your customized page to have the same look and feel as the other pages on your site, consider creating a brand-new page that is based on the site definition and then transferring your customizations to that new page.
Can you still access the editing controls on the pages?	If you customized the editing controls (for example, the Site Actions link or the Edit Page link), check whether they still appear. If they don't appear, you can replace them with the editing controls of the new version by resetting the page to the default version. Use the Reset to Template command in SharePoint Designer to reset the page to the default version (also known as reghosting). After you have restored the default page, you can then reapply your customizations in the browser by applying a different master page, or by reapplying the customizations in SharePoint Designer.
Are your customizations still appropriate in the new environment, or do you want to update to the new functionality and look?	If you want the new functionality and features, you must reset any customized pages to use the template. Resetting the page basically discards the customizations and attaches your page to the appropriate master page. Any customizations you want can then be transferred to the master page instead of being stored in individual pages. Use the Reset to Template command in SharePoint Designer to reset the page to the default version (that is, reghost it). After you have restored the default page, you can then reapply your customizations in the browser by applying a different master page, or by reapplying the customizations in SharePoint Designer.
Are any pages still checked out?	If you check out a page to make changes, make sure that you check in the page again.

Share via