Freigeben über

Upgrade Checker in SP2 – Behind the Scene

  • Artikel

Following the pervious post Upgrade Checker in SP2 – prepare your way to SharePoint Server 2010, here’s the detail of what upgrade checker checks.

Where are the upgrade checker rules?

The upgrade checker rules can be found at

X:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\CONFIG\PreUpgradeCheck

By default, there’re two rule files, one for WSS(WSSPreUpgradeCheck.XML) and one for MOSS(OssPreUpgradeCheck.XML). You can create your own rule files and put it into this directory. The checker will automatically load them.

How to use upgrade checker?

A simple answer is, run

"X:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN\STSADM.EXE" -o preupgradecheck

X is the drive letter you install SharePoint.

There’re a few options with this operation, for example you can use “–rulefiles rulefilename” to specify which rule file it should check, “-localonly” to only check those rules marked as localonly. This could help you in certain scenarios.

The syntax of upgrade checker can be found here:

Preupgradecheck: Stsadm operation (Windows SharePoint Services)

How does upgrade checker check my farm?

By calling object model. You can check this by opening the rule files in a XML editor yourself. Microsoft.SharePoint.Administration.Health is responsible for most of the rules. Here’s an example to check OSreqs.

<Setting Key1="Microsoft.SharePoint.Administration.Health.OSPrerequisite" Key2="LocalOnly">

If you are familiar with BestPracticeAnalyzer, you can also find these:

<ObjectProcessor Name="Group" Assembly="BPA.Common.dll" Class="Microsoft.WindowsServerSystem.BestPracticesAnalyzer.Common.GroupObjectProcessor" /> <ObjectProcessor Name="Registry" Assembly="BPA.ConfigCollector.dll" Class="Microsoft.WindowsServerSystem.BestPracticesAnalyzer.Extensions.RegistryObjectProcessor" /> <ObjectProcessor Name="SQL" Assembly="BPA.ConfigCollector.dll" Class="Microsoft.WindowsServerSystem.BestPracticesAnalyzer.Extensions.SQLObjectProcessor" /> <ObjectProcessor Name="WMI" Assembly="BPA.ConfigCollector.dll" Class="Microsoft.WindowsServerSystem.BestPracticesAnalyzer.Extensions.WMIObjectProcessor" />

These are used to help check group, registry, sql and WMI objects.

There’re two rule types, Information and Error, what’s the difference?

Information rules will check server farm for certain configurations, which would need to be considered during the upgrade process. The configurations that being checked here will not stop you from upgrade, but you might need to follow the advice to upgrade the farm. These rules also tell you the summary of the farm, to help you estimate the time needed for upgrade. For example, UpgradeType rule will check your farm for eligible upgrade methods, ServerInfo will list all the server names in the farm.

Error rules will check if there’s anything wrong which could prevent things from being upgraded. For example, your server does not meet Windows Server 2008 x64 requirement, any orphaned objects in your farm that would not be a part of upgrade process, etc.

Any explanation for the rules shipped with SP2?

You can also refer to TechNet article here for WSS rules:

Pre-upgrade scanning and reporting for future releases (Windows SharePoint Services)

There’s not enough detail in the document, so I borrowed their nice table and added my own comments here:

  • ServerInfo
    Description: All servers that are running SharePoint bits in the farm. Basically this is just a list of servers.
  • FarmInfo
    Description: The components of this farm. For “components” it means how many servers, web apps, content dbs, and site collections in your farm. A sample report is here:
    1 servers 3 web applications 3 content databases, approximately total size = 108199936 bytes 4 Site collections
  • UpgradeType
    Description: The upgrade types supported by the farm. For most of the server farms, there will be two method available, Inplace Upgrade and Content Database Attach. Content Database Attach (also called DB Attach in some materials) is a recommended way to upgrade.
  • SiteTemplates
    Description: This farm uses the following site definitions. This rule will list all the site defs in the farm, sample here (WSS+Search Server):

    name = STS, language = 1033, template id = 1, count = 1, status = Internal name = MPS, language = 1033, template id = 2, count = 0, status = Internal name = CENTRALADMIN, language = 1033, template id = 3, count = 1, status = Internal name = WIKI, language = 1033, template id = 4, count = 0, status = Internal name = BLOG, language = 1033, template id = 9, count = 0, status = Internal name = OSRV, language = 1033, template id = 40, count = 1, status = Installed name = SRCHCENTERLITE, language = 1033, template id = 90, count = 1, status = Installed
  • Features
    Description: The features installed on the farm. This would be a big list for every feature you installed on the farm. Sample:
    Name = [S2SearchAdmin], Feature id = [2b1e4cbf-b5ba-48a4-926a-37100ad77dee], Reference count = [1], Scope = [Site], Status = [Installed]
  • LanguagePacks
    Description: The language packs required for the farm. If you have any other language packs installed on your farm, you will need to install new SharePoint 2010 language pack after the upgrade process.
  • AAMURLs
    Description: AAM URLs within the current environment to be considered when upgrading. It will list all AAMs, sample:
    name = [Central Administration], zone = [Default], public Url = https://iws1:2000, internal Url = https://iws1:2000 name = [SharePoint - 80], zone = [Default], public Url = https://iws1, internal Url = https://iws1 name = [SharePoint - 80], zone = [Internet], public Url = https://www.mssearch.cn, internal Url = https://www.mssearch.cn
  • OSType
    Description: This server machine in the farm does not have the 64-bit edition of Windows Server 2008 or later installed.  I would assume that you already know the system requirements of SharePoint Server 2010, if you don’t, please refer to Richard’s post here:Announcing SharePoint Server 2010 Preliminary System Requirements
  • DatabaseSchema
    Description: Content databases are modified by user, and cannot be upgraded.
    Sometimes this things do happen, especially with wrong patch process. For example, I know an admin patched the farm database, and didn’t patch other servers in the farm so they are not working. What he did was, directly modify the database schema version to older ones! You should NEVER do this. Direct modification to SharePoint Content DB should always be avoided.
  • DataOrphan
    Description: Content databases contain orphans. This will be reported when the items has no relationship with the parent. For example, a corruption happened in content DB so a site has no web, a list with no parent list. STSADM operation databaserepair will be suggested to find and fix the errors.
  • SiteOrphan
    Description: Some sites cannot be referenced properly. Sometimes site collections are not in the sitemap, which cannot be upgraded. This could happen when you have duplicated URLs/hostheaders. You could detach the content DB or delete the site collection to fix this.
  • UnfinishedGradualUpgrade
    Description: This farm is currently being upgraded by using the gradual upgrade process.
    If there’re still some V2 sites (WSS v2 and SPS2003) inside the content DB which are not upgraded properly, you need to first finish this process.
  • MissingWebConfig
    Description: This Web site does not have a web.config file. This definitely is a problem, so you may need to copy a web.config there.
  • InvalidHostNames
    Description: Invalid host names found. This actually checks if there’re any reference with “https://localhost”. You need to change this to something that make sense.
  • InvalidServiceAccount
    Description: The application pool account must be fixed. “NT AUTHORITY\LOCAL SYSTEM” and “NT AUTHORITY\LOCAL SERVICE” should not be used as app pool account.
  • DatabaseReadOnly
    Description: Databases in this farm are configured as read-only and the upgrade will fail unless they are configured as read-write. Of course.
  • WYukonLargeDatabase
    Description: Databases in this farm are hosted on the 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. and are larger than 4 gigabytes. 
  • WYukonLargeSiteCollection
    Description: Site collections in this farm are hosted on the Windows Internal Database and are larger than 4 gigabytes.

There’re two additional rules for MOSS to check search related stuff. They check for server names, content sources, indexed file numbers, index size and search DB size, etc. You can figure them out by yourself.

Comments