Share via

Troubleshoot and resume upgrade (Office SharePoint Server)

  • Article

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2017-01-25

In this article:

  • General information about troubleshooting and restarting upgrade

  • Known issues for pre-upgrade scanning

  • Known issues for in-place upgrade

  • Known issues for gradual upgrade

  • Known issues for database migration

  • Known issues for customized sites

General information about troubleshooting and restarting upgrade

If upgrade stops, you can use the following methods to troubleshoot the issues:

  • Look for the word "error" in the upgrade log files. The upgrade log files are located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\LOGS. For more information about viewing the upgrade log, see Verify upgrade (Office SharePoint Server).

    Tip

    Use the Search Files and Folders feature of Windows to find iterations of “error” quickly in these log files.

  • Review the events in Event Viewer and look for any application errors.

  • Review the readme file for known issues and workarounds. Errors are often issues that you can work around.

  • If you are running Gradual Upgrade, check to see if the site collections you were running have appeared in the new version. If so, you can perform the workaround there, or revert the new version site to the previous version, and try to upgrade the site again. For more information about reverting sites, see Revert to a previous version site (Office SharePoint Server).

  • In-place upgrade can be restarted using the command stsadm –o upgrade. Upgrade will skip those tasks that were already complete, and continue from where it left off. For more information about the upgrade operation, see Upgrade sites (Office SharePoint Server).

Known issues for pre-upgrade scanning

Upgrade is blocked if you use Localhost as your server name

Using "localhost" as your server name can cause many issues in your environment and is not recommended. If you are using "localhost" as your server name, when you run the pre-upgrade scan tool, this issue is logged and the upgrade cannot proceed. You must rename the server computer and then run an operation in prescan before you can continue with the upgrade. Follow the steps below to rename your server and fix the issue for the pre-upgrade scan tool.

  1. Back up the configuration database.

  2. From the command line, change to the following path: %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\60\bin, and then run the following command to change the server name in the configuration database:

    Stsadm.exe -o setconfigdb -databaseserver <server name> -connect

  3. From the command line, change to the following path: %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin, and then run the following command to clear the issue for the pre-upgrade scan tool:

    Prescan /fixlocalhost

  4. On the command line, run the following command to re-run the pre-upgrade scan process:

    Prescan /all

    • If it is successful, proceed with upgrade.

    • If it still fails, then there is still a service using the localhost servername. At this point, upgrade is not blocked, but some services may not upgrade successfully.

Known issues for in-place upgrade

You must use a domain account, not Network Service, for server farm upgrades

For either in-place or gradual upgrade in a server farm environment, you should use the same credentials that you used in the previous version environment in your new version environment. However, if you were using the Network Service account for your previous version environment, you must instead use a domain account in the new version. Your previous version environment can continue using Network Service, but when you install the new version and create the new farm, you must supply a domain account instead. Be sure that you grant the domain account that you use the appropriate rights to the databases in SQL Server (must be a member of the database creators, process administrators, and database owners group for all previous version databases).

Some settings are not preserved on the Web application when you perform an in-place upgrade

If you use Secure Sockets Layer (SSL) and perform an in-place upgrade, you must use the Alternate Access Mapping (AAM) feature to modify the URL within Microsoft Office SharePoint Server because some settings are not preserved on the Web application.

Before you upgrade, if you have an AAM entry that uses HTTPS, such as the following:

Incoming URL: https://<server name>

Outgoing URL: https://<server name>

After you perform an in-place upgrade of Office SharePoint Server 2007, this entry will be incorrectly set to:

Incoming URL: https://<server name>

Outgoing URL: http://<server name>

To correct the URL, on the SharePoint Central Administration Web site, on the Operations page, click Alternate Access Mappings, and then click Edit Public URLs to set the URL back to:

Incoming URL: https://<server name>

Outgoing URL: https://<server name>

For more information about alternate access mappings, see Plan alternate access mappings (Office SharePoint Server).

Upgrade finishes on the first front-end Web server but has failures

In a farm that uses multiple front-end Web servers, if the upgrade finishes on the first front-end Web server but has failures, we recommend that you solve the problem and rerun the upgrade before you move on to upgrade any additional front-end Web servers.

If, for some reason, you want to disregard the failure (for example, because the failure has to do with a rarely used site collection), you can move on to upgrade the second front-end Web server by using the Psconfig command-line tool. Use the following command-line operation:

Psconfig -cmd upgrade -inplace b2b -wait -force

Note

You cannot use the SharePoint Product and Technologies Configuration Wizard to upgrade additional front-end Web servers if you use the Psconfig command-line tool.

SPConfigurationDatabase2 sequence error in the upgrade log

If you perform an in-place upgrade and it fails, check Upgrade.log, which is located in the COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS folder. If you receive the following error message: “[SPConfigurationDatabaseSequence2] [ERROR] [date]: The role 'WSS_Content_Application_Pools' already exists in the current database,” you can use any of the following workarounds to solve the problem:

  • Run the following SQL queries on the configuration database.

    delete from dependencies

    delete from objects

    delete from classes

    delete from sitemap

    exec sp_droprole N'WSS_Content_Application_Pools'

    Note

    If the drop role has any members when the action failed, the sp_droprole call returns the names of those members. You must then run the following command for each member.
    exec sp_droprolemember N'WSS_Content_Application_Pools',
    N'usernameReturnedFromSP_DropRole'

    Then you must run the following query again.

    exec sp_droprole N'WSS_Content_Application_Pools'

  • Create a new V3 farm, and then attach the existing content database. This option will retain all the user data, but will lose configuration information that was stored in the V2 configuration database, such as Web Part packages and virtual server settings.

  • If the original failure was addressed (for example, the failure was due to lost network connectivity or insufficient SQL Server computer disk space and then corrected), you can restore the V2 farm and then restart the upgrade.

Note

Remember to restart the upgrade after you have performed the workarounds.

You cannot use site definitions from Microsoft Office SharePoint Portal Server 2003 for Office SharePoint Server 2007 Web sites

If you use the same custom site definition templates for both SharePoint Portal Server 2003 and Office SharePoint Server 2007, you will encounter page errors when you access your Web site. You cannot use custom site definition templates that you created for SharePoint Portal Server 2003. You must create new custom site definition templates for Office SharePoint Server 2007. You must also create a site definition upgrade file that maps the custom elements from your old custom site definition to the new custom site definition, so that each element in your site (for example, a custom page) can upgrade to the appropriate new element. For more information about creating new site definitions for Office SharePoint Server 2007, see Develop new custom site definitions and create upgrade definition files (Office SharePoint Server) and Deploy upgrade definition files and new site definitions (Office SharePoint Server). For information about supported and unsupported scenarios for working with custom site definitions, see article 898631, Supported and unsupported scenarios for working with custom site definitions and custom area definitions in Windows SharePoint Services, in SharePoint Portal Server 2003, and in Office SharePoint Server 2007 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=140380).

Broken link to the Help file when you attach an existing content database to a new farm

When you create a new farm and then attach an existing content database, the original Listings Web Part contains a URL to the Help file for the previous version of the product. The Help file for the previous version of the product is not available on the server. As a result, the link Microsoft SharePoint Products and Technologies Help Resources, which points to the following URL:
http://< server:port_number>/_vti_bin/help/1033/sps/html/HelpResources.htm
displays an error message that states that the page cannot be found (HTTP Error 404). Delete the link to resolve the problem.

In-place upgrade may fail for medium or large farms with non-front end Web servers when using the Default Web Site in IIS

If your medium or large server farm contains one or more servers that are not front-end Web servers, and you have used the Default Web Site in Internet Information Services to host a SharePoint site, upgrade may fail with a message that the Default Web Site cannot be upgraded. To work around this issue, before running upgrade, on all non-front end Web servers (such as the Index server), rename the Default Web Site in IIS to something else, then run upgrade, and then restore the name to Default Web Site. You do not need to rename the Web site on any front-end Web servers in the server farm.

If you don't rename the Default Web Site in IIS before running upgrade, upgrade will fail. If this happens, you can rename the Default Web Site on the non-front-end Web servers, and then resume upgrade. You can use the following command-line operation to resume upgrade:

psconfig -cmd upgrade -inplace previous versionv -wait -force

In-place upgrade may fail if there are multiple portal sites with the same URL in your environment

If your environment contains multiple portal sites at the same URL, the SharePoint Products and Technologies Configuration Wizard will fail with the following error in the log file: An item with the same key has already been added. This error results if you have any orphaned portal sites - sites that exist in IIS or on the file system, but not in the configuration database. Your environment may have gotten into this state by any of the following ways:

  • You had accidentally deleted and then recreated the IIS Web site that hosts a portal site

  • You had unextended an existing virtual server, then reextended the same virtual server to host a new portal site.

  • You have more than one IIS Web site for the same port number.

To determine whether you have any sites with duplicate URLs, in your SharePoint Portal Server 2003 environment, go to the List and Manage Portal Sites page in SharePoint Central Administration and look for any portal sites with the same URL. Determine which site is in use and which is the orphaned site, and then delete the orphaned site before running upgrade.

In-place upgrade might display the wrong URLs for sites in Central Administration if you create the Central Administration site on a non front-end Web server

If you are performing an in-place upgrade on a large farm and you ran upgrade on an index server before running it on a front-end Web server, then Central Administration is created on the index server instead of the front-end Web server. This can make Central Administration display incorrect host names for the URLs to the Web sites being upgraded on the Site Content Upgrade Status page. To work around this issue, you can add an alternate access mapping for the Central Administration site to point to the correct URL for the front-end Web server.

  1. In Internet Information Services Manager on the front-end Web server, verify the hostname and port number for Central Administration.

  2. Open Central Administration on the Index server, and on the Operations tab, under Global Configuration, click Alternate access mappings.

  3. On the Alternate Access Mappings page, click Edit Public URLs.

  4. On the Edit Public Zone URLs page, click the Alternate Access Mapping Collection down arrow, and select Change Alternate Access Mapping Collection.

  5. In the Select an Alternate Access Mapping Collection box, click Central Administration.

  6. In the Public URLs section, in the Intranet box, type the correct URL for Central Administration on the front-end Web server, and then click Save.

  7. On the front-end Web server, open Central Administration, and on the Operations tab, under Upgrade and Migration, click Site content upgrade status.

    The URLs should display correctly.

Search start address and file types upgrade might fail if an unusual start address is configured in Microsoft Office SharePoint Portal Server 2003

If you have an unusual start address, such as http://server_name/server_name.com, as a start address for indexing, the search upgrade might fail to upgrade the start addresses and file types, and you must enter these configuration settings manually in your Office SharePoint Server 2007 environment.

Known issues for gradual upgrade

You must use a domain account, not Network Service, for server farm upgrades

For either in-place or gradual upgrade in a server farm environment, you should use the same credentials that you used in the previous version environment in your new version environment. However, if you were using the Network Service account for your previous version environment, you must instead use a domain account in the new version. Your previous version environment can continue using Network Service, but when you install the new version and create the new farm, you must supply a domain account instead. Be sure that you grant the domain account that you use the appropriate rights to the databases in SQL Server (must be a member of the database creators, process administrators, and database owners group for all previous version databases).

Additional steps are required to gradually upgrade an SSL-only servers

The gradual upgrade process uses a paired set of IIS Web sites to host the original (un-upgraded) site and new (upgraded) site. By default, the new site that is created does not use SSL. If you need this Web site to use SSL, you must perform additional steps during the gradual upgrade process to set the IIS settings and port number to be correct for SSL.

Perform the following steps after you have created the target Web application for your sites, but before you upgrade any sites.

For more information about creating the target Web application, see Create a new Web application to host upgraded sites in Upgrade sites (Office SharePoint Server)).

Change the port numbers and SSL settings in Internet Information Services (IIS) Manager

  1. In Internet Information Services (IIS) Manager, click the plus sign (+) next to the server name that contains the Web application you want to change.

  2. Click the plus sign (+) next to Web sites.

  3. Right-click Default Web Site, and then click Properties.

  4. On the Web Site tab, in the SSL port box, type 444, and then click OK.

  5. Right-click Default Web Site_Pair, and then click Properties.

  6. On the Web Site tab, in the SSL port box, type 443, and then click Apply.

  7. On the Directory Security tab, in the Secure communications section, click Server Certificate.

    Follow the steps in the wizard to assign a new certificate.

  8. On the Directory Security tab, in the Secure communications section, click Edit.

  9. In the Secure Communications dialog box, select the Require secure channel (SSL) check box, and then click OK.

  10. Click OK to close the Default Web Site_Pair Properties box.

Update alternate access mapping settings and reset IIS

  1. Open a command prompt window and change to the following directory: %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin.

  2. Run the following command to change the alternate access mapping for the original Default Web Site to point to port 444:

    Stsadm -o addzoneurl -url https://server_name:port -urlzone default -zonemappedurl https://server_name:444

    Where server_name:port is the location for the Default Web site.

  3. Change to the following directory: %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\60\bin.

  4. Run the following command to change the alternate access mapping for the redirected Web site:

    Stsadm -o addzoneurl -url http://server_name:port -urlzone default -zonemappedurl https://server_name:443

    Where server_name:port is the location for the new site that was created when you created the target Web application.

  5. Run the following command to reset IIS:

    iisreset /noforce

I finalized the upgrade, but some sites were not upgraded yet, what can I do?

If you have finalized the upgrade process, you can no longer use the gradual upgrade method to upgrade any remaining sites. You can, however, use the database migration approach to upgrade the sites. For more information about using database migration to upgrade sites after having finalized a gradual upgrade, see article 926718 in the Microsoft Knowledge Base (https://support.microsoft.com/kb/926718).

Running search from a child portal may not find new documents after performing a gradual upgrade with shared services

If you have upgraded a child portal that consumed shared services from a parent farm, you must update the alternate portal site URL mappings to point to the upgraded URL. Otherwise, when users search from the child portal, they may not see content added to the child portal.

Important

These steps must be performed in the SharePoint Portal Server 2003 environment.

Update the alternate portal site URL mappings

  1. Click Start, point to All Programs, point to SharePoint Portal Server, and then click SharePoint Central Administration.

  2. Under Portal Site and Virtual Server Configuration, click Configure alternate portal site URLs for intranet, extranet, and custom access.

  3. On the dropdown menu for the upgraded site on the child portal, click Edit.

  4. On the Change Alternate Access Setting page, in the Intranet URL box, enter the original site's URL, and then click OK.

    You should now have a Default URL pointing to the upgraded site and an Intranet URL pointing to the original site.

  5. Perform a crawl for the SharePoint Portal Server 2003 environment.

Search start address and file types upgrade might fail if an unusual start address is configured in SharePoint Portal Server 2003

If you have an unusual start address, such as http://server_name/server_name.com, as a start address for indexing, the search upgrade might fail to upgrade the start addresses and file types, and you must enter these configuration settings manually in your Office SharePoint Server 2007 environment.

My parent portal site wasn't crawled after upgrade

No crawl is performed on a parent portal if the following conditions are met:

  • You are using shared services

  • You have a large server farm with more than one index server

  • There is an exclusion rule for the parent portal on one of those index servers.

  • To generate the indexes, you can either delete the rule, or change the rule from exclude to include, and then perform the crawl again.

My query failed on the parent portal after upgrade with separate query servers

If you are using query index propagation between farms, it takes a while to initialize the query servers. On each of you query servers, run the following operation on the command line to be sure that they are initialized:

stsadm.exe -o osearch -propagationlocation <applications directory>

Where <applications directory> is the location above the index data for all SSPs, such as:

applications
   SSP1 (as a GUID)
   SSP2 (as a GUID)
   SSP3 (as a GUID)

My upgraded parent portal doesn't have the converted start addresses, only the original start addresses, for content still in SharePoint Portal Server 2003 sites

After a gradual upgrade, the parent portal site might not have the correct temporary URLs listed for start addresses, only the original start addresses. To work around this issue, use the following process:

  1. In SharePoint Portal Server 2003, in the Search administration pages, add an exclusion rule to delete any content now stored in the Office SharePoint Server 2007 environment.

  2. Add a new content source to crawl the new URL for sites still in the SharePoint Portal Server 2003 environment.

  3. Perform a crawl in the SharePoint Portal Server 2003 environment.

Failed to start the Office SharePoint Server Search service

If the Office SharePoint Server Search service does not automatically start during the update, the following message in the SharePoint Products and Technologies Configuration Wizard appears:

Failed to start service SearchServiceInstance on this server after completing upgrade. Please start it manually.

The SharePoint Products and Technologies Configuration Wizard finishes successfully but the Office SharePoint Server Search service remains stopped. To start the Office SharePoint Server Search service:

  1. Open a Command Prompt window and change to the following folder:

    %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\BIN

  2. Run the following command

    stsadm –o osearch –action start

I have selected the “Do not upgrade” option in the Setup screen, but I have now changed my mind and want to upgrade

If you have selected the Do not upgrade option during Setup and change your mind after you run the SharePoint Products and Technologies Configuration Wizard, you must run the SharePoint Products and Technologies Configuration Wizard again to change to a gradual upgrade.

Use the SharePoint Products and Technologies Configuration Wizard to change from the “Do not upgrade” option to a gradual upgrade

  1. Run the SharePoint Products and Technologies Configuration Wizard to disconnect from the farm.

  2. Go to %COMMOMPROGRAMFILES%\Microsoft shared\Web Server Extensions\12.0\WSS\ and change the registry key to V2V_GRADUAL_UPGRADE for SetupType and SetupTypeBackup.

  3. Rerun the SharePoint Products and Technologies Configuration Wizard to perform the upgrade.

Failed to upgrade SharePoint Products and Technologies

If you add a new Web server to an existing server farm that does not have any Web applications, and you update the Web server and then run the SharePoint Products and Technologies Configuration Wizard, you might receive the following error message:

An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information: Failed to upgrade SharePoint Products and Technologies.

This error occurs when the SharePoint Products and Technologies Configuration Wizard cannot locate or modify the Web.config file. To resolve the issue, you must manually copy the Web.config file from %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\Config to %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\Template\Layouts. After the Web.config file is in the Layouts folder, you can run the SharePoint Products and Technologies Configuration Wizard again.

Upgrade fails and, in the upgrade log, an error message appears that states that there is no Web

If you perform a gradual upgrade and the upgrade fails, you should check the upgrade log, which is located in the %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS folder. If the error message in the upgrade log states that there is no Web, the Web site has been deleted. The result is that no Web site can be found at the location in question. To solve this problem, stop and restart the Windows SharePoint Services Timer service, and then rerun the upgrade.

Known issues for database migration

You cannot add the same content database more than once to a farm, even on different Web applications

Each site collection in a content database (including each portal site) has a globally-unique identifier (GUID) associated with it, registered in the configuration database. So, adding the same site collection (or portal) twice to the farm, even in separate Web applications, is not possible. Although the database attach succeeds in this situation, the site collection cannot be started. If you need a duplicate copy of a site collection (or portal) in the same farm, first attach the database that contains the site collection to a separate farm, and then use the Stsadm.exe backup and restore operations to copy the site collection over to the other farm. The backup and restore process creates a new GUID for the site collection.

For shared services environments, you must run an extra command before detaching a database

When you perform a database migration in a shared services environment, before you detach (or backup) the databases, you must run the following operation on the command line:

Stsadm.exe -o preparetomove -contentDB <database_server:database_name>

This operation ensures that the content database will be included in the membership and profile synchronization after you reattach them. If you do not run this operation before you detach the content database, then the membership and profile information in the content database is static and will not be synchronized after upgrade.

If you did not perform this operation before detaching the database, you can run the following operation after attaching instead to fix the synchronization issue:

Stsadm.exe -o preparetomove -oldcontentDB <GUID> -newcontentDB <Database_name>

Note that you will have to determine the GUID for the database before you can run the preparetomove operation for an already-detached database. To find the GUID, use the following operation:

stsadm -o sync -listolddatabases <days>

For information on how to detach a database, see Detaching and Attaching Databases.

Do not attach the component settings (_SERV) database or the user profile (_PROF) database during a database migration

When you perform a database migration, you do not need to migrate and attach the SharePoint Portal Server 2003 component settings database (the search database, usually named "ID_SERV" where ID is an ID such as the server name) or the user profile (_PROF) database. Rather, you must recreate the search database and reconfigure your search settings when you perform a database migration. This is because Search settings from SharePoint Portal Server 2003 were stored both in the registry on the server and in the database, and a database migration does not contain all of the settings.

If you attach the component settings (search) database during database migration, the upgrade process will fail when upgrading the shared services and you may see the following message: Could not find stored procedure 'dbo.proc_MSS_PropagationGetQueryServers'.

Perform the database migration again, and do not attach the component settings (_SERV) database or the user profile (_PROF) database.

My upgraded Web site page is missing the My Site link after I attach the content database

In a shared services environment that includes My Sites, after you upgrade by way of database migration, the upgraded Web site pages do not include the My Sites link. When you perform a database migration, you perform an in-place upgrade on the databases, but you do not upgrade the server farm configuration data. Consequently, the URL for your My Site host is not configured in your upgraded server farm.

After migrating the content database that contains the personal sites to the new server farm, set the URL to use as the My Site host location. On the Shared Services Administration home page, in the User Profiles and My Sites section, click My Site settings. In the Personal Site Services section, type /MySite as the URL of the Web application for the My Site host location on your upgraded server farm. /MySite is the path of the My Site host location that is created by default in the Web application for the SharePoint site. For more information, see Configure settings for My Sites.

Known issues for customized sites

An application error can result when disallowed customizations are made to Web.config files

Certain customizations are not allowed in Web.config files for subfolders within a virtual server. For example, the AUTHENTICATION and SESSIONSTATE nodes are not allowed within the Web.config file at this level. Modifying the Web.config file in ways that are not recommended can result in unexpected upgrade results. Be sure to follow the recommended practices for customizations, including customizations to the Web.config file. For more information, see Best Practices for Ensuring Application Reusability and Upgrade in Windows SharePoint Services on the MSDN Web site (https://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc\_SP2003\_ta/html/WSSSharePointCodeReuse.asp).

Download this book

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable content for Office SharePoint Server 2007.