Microsoft Office SharePoint Server 2007 to Windows SharePoint Services 3.0 Site-Level Migration

I was recently asked a question regarding moving sites between Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 Web applications and whether or not there are any prerequisites associated with such a move.  While moving sites can be an arduous and on occasion, a complicated task, moving between variations in platform only adds to the complexities associated with site-level moves.  Many of the Features available to Microsoft Office SharePoint Server 2007 sites are not available to Windows SharePoint Services 3.0 and the existence of these features in the host site will cause any migration effort to fail.  Among the Features that should be deactivated on the original or host site prior to export are the Office SharePoint Server Enterprise Site and Standard Site Features; which can be deactivated through the SharePoint Products and Technologies user interface by navigating to <A href="http://%3cserver%3e/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site&quot; mce_href="http:///sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site”>/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site”>/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site”>/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site”>/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site”>/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site”>/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site”>/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site”>http://<server>/sites/site/web/_layouts/ManageFeatures.aspx?Scope=Site; however, there many Features not visible through the SharePoint Products and Technologies user interface that will cause import failures in this scenario including Features such as:

  • BaseWeb

  • AnalyticsLinks

  • DataConnectionLibrary

  • SlideLibrary

  • RelatedLinksScopeSettingsLink

To deactivate those Features not exposed through the SharePoint Products and Technologies user interface use the SharePoint Administration Tool (STSADM) deactivatefeature operation prior to the export (see example).  Some Features such as the DataConnectionLibrary are available through SharePoint 3.0 Central Administration | Operations | Manage farm features; however, in many cases it is not feasible to deactivate the Feature at that scope to support a single site-level move, in these scenarios the SharePoint Administration Tool provides a greater level of granularity in Feature management.


STSADM -o deactivatefeature -name BaseWeb -url <A href="http://%3cserver%3e/sites/site/web&quot; mce_href="http:///sites/site/web”&gt;/sites/site/web”>/sites/site/web”>/sites/site/web”>/sites/site/web”>/sites/site/web”>/sites/site/web”>/sites/site/web”>http://<server>/sites/site/web -force

Search Helper Content

Fatal Error: Could not find Feature TransMgmtLib

Fatal Error: Could not find Feature BaseWeb

Fatal Error: Could not find Feature DataConnectionLibrary

Fatal Error: Could not find Feature SlideLibrary

Fatal Error: Could not find Feature RelatedLinksScopeSettingsLink


Hybrid Upgrade Approach added to TechNet

I was reviewing the Microsoft Office SharePoint Server TechNet article Determine upgrade approach and realized an article I have been working internally over the past few weeks has been published and introduced to the three existing upgrade approaches of in-place, gradual, and database migration. The upgrade approach itself is described/labeled as a hybrid upgrade approach which combines both the gradual and database migration approaches permitting administrators to preview a subset of site collections prior to upgrading the remainder of the environment (for those who have attended my TechReady, etc. presentations, the approach is familiar). While a complex approach, it offers the ability to provide production upgrade previews without the cost of implementing additional hosting hardware. Read more…


Ghosts in the Machine?

Ghosted and unghosted pages are references not new to Microsoft Office SharePoint Server 2007, but have received increased interest as a result of their impact on upgrading from previous versions and more recently, the ability to manage pages in an unghosted state.


Ghosted is the preferred state of pages in a site collection, ghosted pages refer to site definition files cached in memory on the server at process startup of IIS.  By caching site definition files in memory performance and scalability are improved by reducing data storage and retrieval requirements.  Ghosted pages can be reused as a result across one or many site collections on the Web application.

Unghosted pages are most commonly the result of customization through Microsoft FrontPage and/or Microsoft Office SharePoint Designer and are stored in the corresponding content database.  The contents of unghosted pages are routed through safe mode parsing in ASP.NET, which prevents server-side code from executing, and which depends entirely on the Safe Controls list specified in the web.config file of the wwwroot directory to determine which controls can be rendered at run time.  When upgrading unghosted pages in SharePoint Portal Server 2003 and or Windows SharePoint Services 2.0, some functionality is lost until the page is reset to its site definition (ghosted) and can include security trimming, navigation (Site Actions), Recycle Bin, and other core Microsoft Office SharePoint Server 2007 functionality.  The performance penalty of unghosted pages in Microsoft Office SharePoint Server 2007 is less evident when compared to previous versions due to enhancements in the .NET 2.0 runtime.

So how do pages become unghosted?

In most cases an unghosted page is the result of customization through Microsoft FrontPage and/or Microsoft Office SharePoint Designer 2007 – browser based modifications such as the manipulation of Web Parts will not cause the page to be unghosted.  In a change over Microsoft FrontPage, Microsoft Office SharePoint Designer users are presented with a prompt to indicate the page they are working with will no longer be associated with its specified site definition (see illustration).


In many cases users can resolve minor customizations through resetting the page to its site definition through both the Windows SharePoint Services 3.0 user interface and Microsoft Office SharePoint Designer; however, changes made within Web Part Zones will be retained after synchronizing the page with its site definition.  [Site Settings | Look and Feel | Reset to site definition]. 

In some circumstances a page cannot be reghosted, for example if the page was not based on an existing page, was created from a blank page, imported from another application or editor or (most commonly) was associated with a site definition no longer available to the server farm – this can occur if a site definition was retired or a database migration approach was implemented and the upgrade definition not made available to the target server farm.  In many cases you can simply copy a known good <page>.aspx from an alternate location and retrofit it to restore functionality.


Reghosting can be also accomplished through by a server farm administration calling the RevertAllDocumentContentStreams method of the Microsoft.SharePoint namespace on each SPWeb object.

Sample Code

        static void Main(string[] args)
string siteUrl = “”;
SPSite Site = new SPSite(siteUrl);
foreach (SPWeb Web in Site.AllWebs)

This code snippet is provided under the Microsoft Permissive License.

Microsoft Office SharePoint Designer 2007

  1. In Office SharePoint Designer 2007, open the Web site where the customized page resides.
  2. Right-click the page that you want to reset to the site definition, and then click Reset to Site Definition on the shortcut menu.

NOTE A copy of the customized page is placed in the same directory where the reset page resides and is named file name_copy(1), where file name is the original file name – when reghosting a page through the Windows SharePoint Services 3.0 user interface a backup copy of the page is not created.


If the customization was implemented on a MasterPage, the MasterPage and attached pages can be reset to their site definition through Microsoft Office SharePoint Designer 2007:

In Office SharePoint Designer 2007, open the Web site where the customized master page resides.

  1. Right-click the master page that you want to reset, such as default.master, and then click Reset to Site Definition on the shortcut menu.

    Note   By default, in the Folder List, master pages are located in the masterpages folder, which is in the _catalogs folder in the site.

    A warning message informs you that the master page’s contents will be overwritten, but that a backup copy of the current page will be created.

  2. Click Yes.

Ghosted Pages and Upgrade

Ghosted pages, though, in many cases can be upgraded safely depending on the extent of their customization (see introduction for caveats) should be considered for reghosting at the time they are upgraded.  The gradual upgrade approach allows administrators to reghost (reset to site definition) pages during the upgrade process and enables the reghosting of pages at a more granular level.  Reghosting in a gradual approach can be applied through the Upgrade user interface or optionally using the STSADM -o command line argument -Reghost in the upgrade operation, for example STSADM -o upgrade -sidebyside -url http://www.contoso.com -sitelistpath <pathtoxml> -reghost.  This granularity allows you to decide where you would like to reghost and what customizations should be retained during the upgrade.  The database migration approach and inplace approaches both permit the upgrade of unghosted pages preserving the customizations; however, these pages will be upgraded in their existing state and will need to be reghosted post-upgrade to enable Microsoft Office SharePoint Server 2007 functionality.

Locating Unghosted Pages

Now that we understand ghosted vs. unghosted pages and their implication on upgrade, how do we determine where unghosted pages exist?


PRESCAN.EXE has two primary purposes:

  1. It parses and saves List definitions with the associated Lists.  SharePoint Portal Server 2003 Service Pack 2 already incorporates this feature whenever a list is modified; however, this process should be completed for all Lists, so prescan calls the SharePoint Portal Server 2003 Service Pack 2 method to persist that data.
  2. PRESCAN.EXE will report on common issues that will result in a failed upgrade; therefore, running PRESCAN.EXE, addressing reported issues, and resolving those issues, and re-running PRESCAN.EXE to verify those fixes is a best practice when planning a Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0 upgrade.  The most commonly detected issues are:

    • Database Orphans This is a class of issue where an object exists, but the pointer with the parent object is broken and/or corrupt.   Classic examples include situations where a site exists in the content database; however, does not exist in the configuration database and a web that points to a site collection that no longer exists. 
    • Missing Site Definitions This issue is rare at best ad exists when a site collection has been removed/deleted – sites under this classification will not be upgraded and in addition those sites will not render in SharePoint Portal Server 2003/Windows SharePoint Services 2.0.

PRESCAN can be used to identify custom Site Definitions, FrontPage customizations, Web Parts, etc.

PRESCAN.EXE will report and summarize any unghosted pages occurring in your environment (see illustrations).

The example above illustrates unghosted pages discovered by PRESCAN.EXE and reported in the application log file.

The example above illustrates a summary of unghosted pages.


Alternatively SQL can be leveraged (not recommended on production databases) to generate a report of unghosted pages in your content databases (see example).





     (Docs.Type = 0)


     (Docs.SetupPath IS NOT NULL) AND

     (dbo.Docs.DocFlags & 64 = 64)

Microsoft Office SharePoint Designer 2007

You can also run a report in Office SharePoint Designer 2007 to list all of the customized pages in your site.

  1. In Office SharePoint Designer 2007, open the Web site for which you want to run the report.
  2. On the Site menu, point to Reports, point to Shared Content, and then click Customized Pages.

    The report opens with all pages in the site listed, and the Customized column indicates whether content has been customized for that page.

  3. To display only pages that have been customized, click the down arrow to the right of the Customized column, and then click Yes.

    The report now displays only pages that have been customized.

Additional Resources

Joel Oleson’s To Ghost or Not to Ghost, That is the Question

MSDN – Custom Site Defintiions

Microsoft.com – SharePoint Application Templates

This Blog – PRESCAN

Microsoft.com – Upgrade Considerations for Customized Sites

Technet – Determine How to Handle Customizations


Understanding PRESCAN.EXE Errors (UPDATED – May 2007)

I’ve updated my post Understanding PRESCAN.EXE Errors to include new errors and solutions. Read more here: http://blogs.technet.com/wbaer/archive/2006/12/22/prescan-errors-what-they-mean.aspx.

Excerpt:  ““An outbound zone URL is configured for something other than the default zone on virtual server http://fabrikam/, and no default zone outbound URL is defined.  This is not supported, and must be corrected before upgrading.””


Code Snippet – How to Locate Host Header-based Site Collections in Windows SharePoint Services 3.0

One of the great features in Windows SharePoint Services 3.0 is the ability to co-host both path-based and host header-based site collections within the same server farm and content databases. Now that you’ve introduced host header-based site collections to your server farm, how do you quickly identify those site collections within a server farm or content database that also hosts your path-based site collections? In this scenario the object model is extremely useful in reporting on those site collections, the Web application, and content database where they reside.

The following code example provides a basic object model approach to locating and returning those site collection via a Command Line application.

Before using the code example add references to the following in your Microsoft Visual Studio project:

  • Microsoft.SharePoint

In the code example each SPSite object (site collection), is represented within an SPSiteCollection object that consists of the collection of all site collections in the Web application, by exposing the HostHeaderIsSiteName member, host header-based site collections can be enumerated through the object model.

            //Let’s get the set of Web applications installed with this service
SPWebApplicationCollection WebApps = SPWebService.ContentService.WebApplications;
//SPWebApplication Class represents an IIS load-balanced Web application installed on the farm
//Step through the Web applications
foreach (SPWebApplication WebApp in WebApps)
//Let’s check the Web application status before we begin and write each available Web application to the console
if (WebApp.Status.ToString() == “Online”)
SPSiteCollection SiteCollections = WebApp.Sites;
//Step through the site collectons
foreach (SPSite SiteCollection in SiteCollections)
//Let’s check the site collection and determine whether a host header URL is the site name,
//if TRUE we’ll write the output to the console
if (SiteCollection.HostHeaderIsSiteName.Equals(true))
Console.WriteLine(“Site Url=” + “”” + SiteCollection.Url.ToString() + “”” + ” ContentDatabase=” + “”” + SiteCollection.ContentDatabase.Name.ToString() + “””);

This code snippet is provided under the Microsoft Permissive License.


Jingmei Li has put together a great post…

Jingmei Li has put together a great post detailing partner solutions supporting SharePoint Portal Server 2003 to Microsoft Office SharePoint Server 2007 migrations; these solutions are useful in situations where any of the three supported approaches do not fit within the scope of a business’ plans for migration and upgrade.  Read the entire post here http://blogs.msdn.com/jingmeili/archive/2007/03/13/evaluate-partner-solutions-that-support-migration-from-sps-2003-to-moss-2007.aspx.


Upgrading Windows SharePoint Services 2.0 Scalable Hosting Mode Server Farms

In Windows SharePoint Services 3.0 host header-based Site Collections can coexist with path-based site collections within a Web Application or optionally reside on multiple Web Applications.  Gradual, in-place, and database migration upgrade approaches can be applied to Windows SharePoint Services 2.0 server farms in scalable hosting mode.  This differs from Windows SharePoint Services 2.0 where a server farm was configured to run in scalable hosting mode preventing the introduction of path-based Site Collections to the server farm.

Step 1
Install Windows SharePoint Services 3.0 and run the SharePoint Products and Technologies Configuration Wizard.  See the Windows SharePoint Services 3.0 Technical Library article Install Windows SharePoint Services 3.0 and run the SharePoint Products and Technologies configuration wizard at http://technet2.microsoft.com/windowsserver/WSS/en/library/b9490b1a-45de-45fd-9f4c-754dab1383e61033.mspx?mfr=true for detailed installation and deployement instructions.

NOTE If introducting the Windows SharePoint Services 2.0 scalable hosting mode content databases to an existing server farm, proceed to Step 3.

Step 2
Create a Web Application to host Windows SharePoint Services 2.0 content.

Step 3
Set the host header property on the Windows SharePoint Services 3.0 server farm by running:

STSADM -o setproperty -pn v2usedhostheadermode -pv true

Errors in the upgrade log such as the example below are indicative of the property not being set on the upgrade server farm.

[RemoveFullUrlFromSitesTable] [] [DEBUG] [3/30/2007 4:52:46 PM]: The v2 host header mode property could not be found.  This suggests that a v2 backup is being added to a newly-created v3 farm.  Since we cannot conclusively tell if this is from a v2 host header configuration, we assume that it was not.If this assumption is incorrect, run “stsadm -o setproperty -pn V2UsedHostHeaderMode -pv true”, detach this database, and reattach the v2 backup. 

Step 4
Add the Windows SharePoint Services 2.0 content database to the Web Application using the addcontentdb operation.  See the Windows SharePoint Services 3.0 Technical Library chapter Deploy a new farm, the migrate database (Windows SharePoint Services) at http://technet2.microsoft.com/windowsserver/WSS/en/library/b9490b1a-45de-45fd-9f4c-754dab1383e61033.mspx?mfr=true for detailed instructions.

STSADM -o addcontentdb -url http://webapplication/ -databaseserver databaseserver -databasename databasename

Step 5
Reset the host header property on the Windows SharePoint Services 3.0 server farm.

STSADM -o setproperty -pn v2usedhostheadermode -pv false

Host header mode in Windows SharePoint Services 3.0 provides administrators a number of options when working with existing Site Collections on a Web Application, to backup, restore, and/or create a site collection as a host header-based site collection use the STSADM samples below:

Backup a path-based Windows SharePoint Services 3.0 site collection using the command-line

STSADM –o backup –url http://server/sites/sitecollection -filename E:backupfile.bak

Backup a host header-based Windows SharePoint Services 3.0 site collection using the command-line

STSADM –o backup –url http://hostheadersitecollection/ -filename E:backupfile.bak

Restore a path-based site collection as host header-based site collection using the command-line

STSADM -o restore -url http://hostheadersitecollection/ -filename E:backupfile.bak –
hostheaderwebapplicationurl http://webapplication/ –overwrite

Create a Windows SharePoint Services 3.0 host header-based site collection using the command-line

STSADM -o createsite -url http://hostheadersitecollection/ -ownerlogin <domain><username> –
owneremail <email address> -hhurl http://webapplication/