May, 2009

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.

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

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 = http://iws1:2000, internal Url = http://iws1:2000 name = [SharePoint - 80], zone = [Default], public Url = http://iws1, internal Url = http://iws1 name = [SharePoint - 80], zone = [Internet], public Url = http://www.mssearch.cn, internal Url = http://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 “http://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.

The upgrade checker in MOSS/WSS SP2 stsadm operation is very useful. It checks server farm for system requirements, database health and a list of rules. The rules can also be extended.

To use upgrade checker, first open a command line prompt, and run

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

(X is the drive letter where you install SharePoint)

Make sure you are in administrator mode. Otherwise it would be denied.

You can see there’re a list of rules checked by the operation. I will have a seperate post talk about the detail of each rule.

SearchContentSourcesInfo
SearchInfo
ServerInfo
FarmInfo
UpgradeTypes
SiteDefinitionInfo
LanguagePackInfo
FeatureInfo
AamUrls
LargeList
CustomListViewInfo
CustomFieldTypeInfo
CustomWorkflowActionsFileInfo
ModifiedWebConfigWorkflowAuthorizedTypesInfo
ModifiedWorkflowActionsFileInfo
DisabledWorkFlowsInfo
OSPrerequisite
WindowsInternalDatabaseMigration
WindowsInternalDatabaseSite
MissingWebConfig
ReadOnlyDatabase
InvalidDatabaseSchema
ContentOrphan
SiteOrphan
PendingUpgrade
InvalidServiceAccount
InvalidHostName

A successful run could show the following:

Hey, we got a “OSPrerequisite… Failed” here. So let’s take a look at the report.

The report will give you the following information:

Search content sources and start addresses 

Office Server Search topology information 

Servers in the current farm 

The components from this farm 

Supported upgrade types 

Site Definition Information 

Language pack information 

Feature Information 

Alternate Access Mapping Url(s) within the current environment that should be considered when upgrading. 

Lists and Libraries 

Customized field types that will not be upgraded

Windows SharePoint Services Search topology information 

And also the failed items it checked.

In my case, because this machine is still on Windows Server 2003 32bit, so it does not meet the requirement of SharePoint Server 2010, which needs to be install on Windows Server 2008 x64.

Failed : This server machine in the farm does not have Windows Server 2008 or higher 64 bit edition installed.

Upgrading to Windows SharePoint Services 4.0 requires Windows Server 2008 or higher 64 bit edition.
Please upgrade the server machines in your farm to Windows Server 2008 64 bit edition, or create a new farm and attach the content from this farm. For more information about this rule, see KB article 954770 in the rule article list at http://go.microsoft.com/fwlink/?LinkID=120257.

I will explain the detail of the checker in another post later.

Update: the post is here: http://blogs.msdn.com/opal/archive/2009/05/12/upgrade-checker-in-sp2-behind-the-scene.aspx

Windows Server 2008 R2 RC is avaliable several days ago. You may ask questions: What if I want to install WSS/MOSS on Windows Server 2008 R2? Is that supported?

The answer: WSS/MOSS RTM & SP1 is not supported on WS2008R2. But with SP2, it is supported. If you try to run the installer without SP2 slipstreamed, it would be blocked and you cannot continue. Meanwhile, if you want to use SQL Server 2008, you will also need to apply SQL Server 2008 SP1 on it after installation.

So slipstream build of WSS and MOSS SP2 is required. WSS SP2 slipstream build can be found here: x86 x64. There’s no slipstream build for MOSS so you need to create your own one. Here’s a quick guide:

Remove all stuff inside the Updates folder of your MOSS installation directory. Download both wss and moss SP2 packages, extract them in command line using /extract:drive\path option,  and then put all into the Updates folder. Delete Wsssetup.dll, this is important. Otherwise only WSS SP2 will be installed.

More details can be found on TechNet.

With SP2 slipstreamed, you can run the installer without any problem now. After installation, site version will be 12.0.0.6421.

Windows Server 2008 SP2 is also supported by MOSS/WSS SP2.