Pre-upgrade scanning and reporting for future releases (Office SharePoint Server)
Updated: April 28, 2009
Applies To: Office SharePoint Server 2007
Topic Last Modified: 2009-04-23
The Stsadm command provides a rule-based scanning operation to determine whether servers in an existing SharePoint environment meet the core requirements for upgrading from Windows SharePoint Services 3.0 and related products to future releases of SharePoint Products and Technologies.
The pre-upgrade scanning and reporting operation is implemented as Stsadm –o preupgradecheck, and can be run with or without parameters. For more information, see Preupgradecheck: Stsadm operation (Office SharePoint Server).
You can use this Stsadm operation to scan farm servers before starting an upgrade to ensure that some upgrade prerequisites are met and to detect known issues that can prevent the upgrade from completing successfully. The results of the scan enable you to address any issues that are identified.
The upgrade checker does not do the following:
Supersede the Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office system.
Automatically fix issues that are identified.
Each server that you want to scan must have Service Pack 2 for Windows SharePoint Services 3.0 installed in order to initiate a scanning session and generate a report about the upgrade readiness of the server.
In order to run a scan with the upgrade checker you must be a member of the Farm Administrators SharePoint Group and have administrator permissions on the server that you scan.
The pre-upgrade Stsadm operation comprises a set of routines that load one or more XML rule files as input that is evaluated against the current SharePoint farm and server configuration. During the scanning process, each rule passes the results to a routine that writes the results to log files. Thus, the focus is on rules and output:
The upgrade checker rule collection consists of rule files and the rules that these files contain. A list of the existing default rules appears later in this topic.
Rule files are not processed in any specific order unless the person running the scan specifies a rule file or set of rule files as parameters that are passed to the preupgradecheck operation. In this case, the rule files are processed in the in the specified order in which they are passed in. The rule files are located in the %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\CONFIG\PREUPGRADECHECK directory.
The rules in a rule file specify the checks to be performed during a scan. The rules contained in a rule file are processed in the order in which they are listed. There are two types of rules: informational rules and error rules.
This category of rules provides upgrade-related statistics for the farm that can be used for planning an upgrade. An example is the FarmInfo rule, which provides information about the version of SharePoint that is installed, the number of servers in the farm, and other information. The FarmInfo informational rule provides the following information:
The components from this farm
The software based on SharePoint Products and Technologies currently running on this farm is <binary build version number>. The farm contains the following components:
<Component>[Number of Servers] Servers</Component>
<Component>[Number of Web Applications] Web applications</Component>
<Component>[Number of Content Databases] Content databases, approximate total size = [Total Size of Databases] bytes</Component>
<Component>[Number of Site Collections] Site collections</Component>
See http://www.microsoft.com/sharepoint/upgrade to estimate how long it will take to upgrade your farm compared to a similar farm on Microsoft's benchmark hardware. For more information about this rule, see KB article 954759 in the rule article list in the Windows SharePoint Services Solution Center (http://go.microsoft.com/fwlink/?LinkId=149394&clcid=0x409).
This category of the rules provides information about the local server or farm configuration that the administrator needs to fix before starting an upgrade. An example is the DatabaseSchema rule, which lists the names of content databases that have different schema than the standard Windows SharePoint Services 3.0 content database. The DatabaseSchema error rule provides the following information:
Content database has database schemas modified by user
User modifications to the SharePoint content database, including but not limited to table schemas, an index, and stored procedures, are not supported and will cause attempts to upgrade to future versions of SharePoint to fail.
The databases in the following list seem to have been modified from the original schema: [ForEach Database]<Database>[Database Name]</Database>
Additional information and remedy if result is an error:
For more information about this rule, see KB article 954772 in the rule article list in the Windows SharePoint Services Solution Center (http://go.microsoft.com/fwlink/?LinkID=120257).
The rules described in the following table are provided with this release of the pre-upgrade requirements operation.
Upgrade checker rules
|Name||Description||Local server or farm||Severity|
All servers that are running SharePoint bits in the farm.
The components of this farm.
The upgrade types supported by the farm.
This farm uses the following site definitions.
The features installed on the farm.
The language packs required for the farm.
AAM URLs within the current environment to be considered when upgrading.
This server machine in the farm does not have the 64-bit edition of Windows Server 2008 or later installed.
Content databases are modified by user, and cannot be upgraded.
Content databases contain orphans.
Some sites cannot be referenced properly.
This farm is currently being upgraded by using the gradual upgrade process.
This Web site does not have a web.config file.
Invalid host names found.
The application pool account must be fixed.
Databases in this farm are configured as read-only and the upgrade will fail unless they are configured as read-write.
Database in this farm are hosted on the Windows Internal Database and are larger than 4 gigabytes. Windows Internal Database uses SQL Server technology as a relational data store for Windows roles and features only, such as Windows SharePoint Services, Active Directory Rights Management Services, UDDI Services, Windows Server Update Services, and Windows System Resources Manager.
Site collections in this farm are hosted on the Windows Internal Database and are larger than 4 gigabytes.
A list of the content sources and start addresses for each shared service provider in the farm.
A list of the components of the search topology for the farm.
As rules are processed during the pre-upgrade scanning, the results from each rule are written to an XML log file and a text log file. These log files are written to the %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\LOGS directory and use the following naming convention, where a random number is used to differentiate between possible simultaneous attempts to run the pre-upgrade command:
Both of the preceding log files contain the following information:
The checks that were run.
The issues that were found.
A description of how to fix the detected issue or a link to a KB article that pertains to the issue.
After the scan is finished, the XML results are transformed to HTML format that is displayed as a page in the default Web browser. The file-naming convention for the transformed XML is PreUpgradeCheck_YYYYMMDD-hhmmss-millisecond-random-number.HTM.