May, 2009

  • Jie Li's GeekWorld

    Upgrade Checker in SP2 – Behind the Scene


    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 = 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 =, internal Url =

    • 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.

  • Jie Li's GeekWorld

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


    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.


    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


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

    Update: the post is here:

  • Jie Li's GeekWorld

    Install MOSS 2007 & WSS 3.0 on Windows Server 2008 R2 – you will need SP2 slipstream


    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


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

Page 1 of 1 (3 items)