Jie Li's GeekWorld : Upgrade

October 2009 Cumulative Update Packages for SharePoint Server 2007 and Windows SharePoint Services 3.0 are published

Jie Li — Thu, 29 Oct 2009 03:07:00 GMT

The server-packages of October 2009 Cumulative Update for Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 are ready for download. October 2009 Cumulative Updates introduce more rules on Pre-Upgrade Checker, which can help customers to prepare the upgrade of their SharePoint farm to SharePoint 2010.

Download Information

Windows SharePoint Services 3.0 October 2009 cumulative update package
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=974989

Office SharePoint Server 2007 October 2009 cumulative update package
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=974988

Detail Description

Description of the Windows SharePoint Services 3.0 October 2009 cumulative update package
http://support.microsoft.com/kb/974989 (link may not be live yet)

Description of the Office SharePoint Server 2007 October 2009 cumulative update package
http://support.microsoft.com/kb/974988 (link may not be live yet)

Installation Recommendation for a fresh SharePoint Server

To keep all files in a SharePoint installation up-to-date, the following sequence is recommended.

Please note: Start from April 2009 Cumulative Update, the packages will no longer install on a farm without a service pack installed. You must have installed either Service Pack 1 (SP1) or SP2 prior to the installation of the cumulative updates.

After applying the preceding updates, run the SharePoint Products and Technologies Configuration Wizard or “psconfig -cmd upgrade -inplace b2b -wait” in command line. This needs to be done on every server in the farm with SharePoint installed.

The version of content databases should be 12.0.6520.5000 after successfully applying these updates.

You can also refer to April Cumulative Update post for deployment guides, slipstream how-to links and FAQs.

Jie Li

Technical Product Manager, SharePoint

Upgrade Checker in SP2 – Behind the Scene

Jie Li — Tue, 12 May 2009 00:11:00 GMT

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.

Upgrade Checker in SP2 – prepare your way to SharePoint Server 2010

Jie Li — Fri, 08 May 2009 22:55:00 GMT

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