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:
<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:
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
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 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
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 220.127.116.1121.
Windows Server 2008 SP2 is also supported by MOSS/WSS SP2.