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] [3.0.38.0] [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/

Understanding Solution Packages in Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0

Understanding Solution Packages


Solution packages are designed to provide the ability to develop and deploy reusable  site and feature definitions, web part files, templates, assemblies, and code access security policies across one or more server farms.  A solution package is a cabinet file that can contain, site and feature definitions, web part files, templates, assemblies, and code access security policies.  A solution package contains a web manifest that that defines the list of features, site definitions, resource files, Web Part files, and assemblies to process when the solution is deployed.  The directory structure within the cabinet file dictates the resulting structure on the web front-end computer when the solution is deployed.  If solution files are not indicated in the web manifest; however, they will not be processed with the solution. 


Solutions can range from simple to highly complex incorporating features, new site definitions, code deployments, etc.  The benefit of a solution package is the ability to deploy the solution to multiple servers and server farms rapidly, on a desired schedule, and uniformly across servers and server farms from one location.  The solution sample in this post details the simplest of solutions, deployment of a new default content page replacing an existing default content page.


Sample Solution Package


The sample web manifest shown indicates a solution package directory structure of SiteTemplatessts and the file to be deployed as default.aspx.


Web Manifest (manifest.xml)



<Solution SolutionId=”6F2A9959-E7C3-471b-9AB8-030D7DFFEA64″ xmlns=”http://schemas.microsoft.com/sharepoint/“>
  <TemplateFiles>
    <TemplateFile Location=”SiteTemplatesstsdefault.aspx”/>
  </TemplateFiles>
</Solution>


The <Solution> element is the web manifests root element and can contain <TemplateFiles>, and <TemplateFile> child elements in addition to <FeatureManifests>, <FeatureManifests>, <RootFiles>, <RootFile>, <Assemblies>, and <Assembly> child elements depending on the application.  In the sample web manifest, the <TemplateFile> child element contains a Location attribute that specifies the relative path to the site template directory on a web front-end computer.  In this sample default.aspx will be replaced on the STS site template with the file packaged in the solution.  In order to ensure the file is correctly placed, the solution package should host default.aspx in the following directory structure/substructure:  SiteTemplatessts complementing the relative path on the web front-end computer. 


The <Solution> root element has attributes of SolutionID and xmlns; the SolutionID attribute specifies the unique GUID assigned to the solution and the xmlns element is used to declare namespace bindings.  For additional information on namespaces in XML visit:  http://www.w3.org/TR/REC-xml-names/#sec-namespaces.


Building the Solution Package


A solution package in essence is a cabinet file using the wsp file extension.  To build a solution package, you can use the Microsoft MakeCAB tool supplying an optional file containing the MakeCAB directives.  The Microsoft MakeCAB user’s guide is available at http://msdn2.microsoft.com/en-us/library/bb267310.aspx#microsoftmakecabusersguide.


Adding the Solution Package to the Server Farm


A solution package can be deployed through STSADM.


To add a solution to the server farm you can use the STSADM operation AddSolution. 



stsadm.exe -o addsolution
            -filename <Solution filename>
            [-lcid <language>]


Deploying the Solution Package


A solution package can be deployed either through the Central Administration user interface or optionally through STSADM.



Central Administration


To add a solution to the server farm using the Central Administration user interface, open Central Administration, select Operations, and then select Solution management under the Global Configuration options.


The Solution Management user interface lists the solutions in the server farm, their individual status, and the Web Application they have been deployed to, when deployed.


To deploy a solution to the server farm, select the solution name from the list of available solutions, and then select Deploy Solution from the Solution Properties user interface.  The Solution Properties user interface can also be used to check the status of deployed solutions and includes information about the deployment status, deployment location, and results of the deployment operation.  Alternatively you can use STSADM to view a list of solutions deployed to the server farm using the enumsolutions operation (stsadm.exe -o enumsolutions).


STSADM 


To deploy the solution to the server farm you can also use the STSADM operation deploysolution.



stsadm.exe -o deploysolution
            -name <Solution name>
           [-url <virtual server url>]
           [-allcontenturls]
           [-time <time to deploy at>]
           [-immediate]
           [-local]
           [-allowgacdeployment]
           [-allowcaspolicies]
           [-lcid <language>]
           [-force]


In the sample syntax above you will see we opted to retain the .cab extension as opposed to providing the .wsp extension to the solution package.


These deployment operations allow you to add a solution to a server farm and deploy the solution at a later time or optionally deploy the solution immediately.  To deploy a solution or redeploy a solution to a single web front-end computer, you can optionally use the -local parameter in the operation above or the -global parameter to deploy the solution to all web applications in the current server farm.


Retracting a Solution Package


Solution packages can be retracted as easily as they are deployed.  A solution package can be retracted either through the Central Administration user interface or optionally through STSADM.



Central Administration


To retract a solution from the server farm using the Central Administration user interface, open Central Administration, select Operations, and then select Solution management under the Global Configuration options. Select the solution to be retracted, and then select Retract Solution from the Solution Management user interface. As with deployment, retracting a solution is dependent on a Windows SharePoint Services Timer Job.  Once the solution has been retracted from the server farm, any dependencies on that solution will be affected.  When retracting a solution, ensure that any dependencies are properly remediated prior to retracting the solution from the server farm.



STSADM


To deploy the solution to the server farm you can also use the STSADM operation retractsolution.



stsadm.exe -o retractsolution
            -name <Solution name>
           [-url <virtual server url>]
           [-allcontenturls]
           [-time <time to remove at>]
           [-immediate]
           [-local]
           [-lcid <language>]

Understanding webtemp*.xml

In Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0 webtemp*.xml contains a set of <Template> elements within a <Template> element that contain a set of site definitions available in the Template Selection user interface and define how to instantiate a Web site.  <Template> elements where the <Configuration> element does not contain a <ProvisionAssembly> (Example 3) attribute indicate the <Template> element applies to a single site definition and not a portal site definition.  The <ProvisionAssembly> attribute is equal to the Microsoft.SharePoint.Publishing namespace which provides the fundamental publishing infrastructure in Microsoft Office SharePoint Server 2007.  webtemp*.xml is provisioned on each web front-end computer and installed to each locale available in the server farm configuration and available in six (6) unique instances:


WEBTEMP.xml



Products:  Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0



Includes:  Team Site, Blank Site, Document Workspace, Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, Multipage Meeting Workspace, Central Admin Site, Wiki Site, and Blog templates.


webtempsrch.xml



Products:  Microsoft Office SharePoint Server 2007



Includes:  Search Center template.


webtempsps.xml



Products:  Microsoft Office SharePoint Server 2007


Includes:  SharePoint Portal Server Site, SharePoint Portal Server Personal Space, Personalization Site, Contents area Template, Topic area Template, News Site, Publishing Site, Press Releases Site, Publishing Site with Workflow, Site Directory, Community area Template, Report Center, Collaboration Portal, Search Center with Tabs, Profiles, Publishing Portal, My Site Host templates.


webtempoffile.xml



Products:  Microsoft Office SharePoint Server 2007


Includes:  Records Center template.


webtempbdr.<local>.xml



Products:  Microsoft Office SharePoint Server 2007


Includes:  Document Center template.


webtemposrv.xml



Products:  Microsoft Office SharePoint Server 2007


Includes:  Shared Services Administration Site template.


In the example 1 below, the Name attribute specifies the directory name equivelant to the directory hosting ONET.xml which contains the definition configuration under %commonprogramfiles%Microsoft SharedWeb Server Extensions12TEMPLATE<localeid><Name>XML.  The <ID> attribute is a unique ID corresponding to the ID of a configuration in an ONET.xml file that specifies the lists and modules of a site definition.  The <Configuration> element contains attributes that define the template, these attributes indicate what configuration should be appiled to the template when the Web site is instantiated.


Configuration Attributes:



  • <Title> Template title text displayed in the Template Selection user interface.

  • <Description> Description of the purpose and features of the requested template displayed in the Template Selection user interface.

  • <ImageUrl> Provides the virtual path to the preview image displayed in the Template Selection user interface. 

  • <DisplayCategory> Defines the category where the template should be made available for selection in the Template Selection user interface.

  • <RootWebOnly> Defines the usage scenario in which this template can be applied.

  • <ProvisionAssembly> Provides the fundamental publishing infrastructure in Microsoft Office SharePoint Server 2007.

  • <ProvisionClass> Defines the class associated with the <ProvisionAssembly> attribute.

  • <ProvisionData> Provides the virtual path to the associated Web manifest (%commonprogramfiles%Microsoft SharedWeb Server Extensions12TEMPLATESiteTemplatesWebManifestportalwebmanifest.xml)

  • <VisibilityFeatureDependency> Feature dependency associated with the template that provides its visibility.

Example 1:



<Template Name=”SPSMSITEHOST” ID=”54″>
   <Configuration ID=”0″ Title=”My Site Host” Type=”0″ RootWebOnly=”TRUE” Hidden=”FALSE” DisplayCategory=”Enterprise” ImageUrl=”../images/perstemp.gif” Description=”A site used for hosting personal sites (My Sites) and the public People Profile page. This template needs to be provisioned only once per Shared Service Provider, please consult the documentation for details.”>   
    </Configuration>
</Template>


Example 2 (Single Site Definition):



<Template Name=”STS” ID=”1″>
    <Configuration ID=”0″ Title=”Team Site” Hidden=”FALSE” ImageUrl=”/_layouts/images/stsprev.png” Description=”A site for teams to quickly organize, author, and share information. It provides a document library, and lists for managing announcements, calendar items, tasks, and discussions.” DisplayCategory=”Collaboration” >  
</Configuration>
</Template>


Example 3 (Portal Site Definition)



<Template Name=”SPSPORTAL” ID=”47″>
    <Configuration ID=”0″ Title=”Collaboration Portal” Type=”0″ Hidden=”FALSE” ImageUrl=”/_layouts/1033/images/template_corp_intranet.png” Description=”A starter site hierarchy for an intranet divisional portal. It includes a home page, a News site, a Site Directory, a Document Center, and a Search Center with Tabs. Typically, this site has nearly as many contributors as  readers and is used to host team sites.”
      ProvisionAssembly=”Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”  ProvisionClass=”Microsoft.SharePoint.Publishing.PortalProvisioningProvider”  ProvisionData=”SiteTemplates\WebManifest\PortalWebManifest.xml”
      RootWebOnly=”TRUE” DisplayCategory=”Publishing” VisibilityFeatureDependency=”97A2485F-EF4B-401f-9167-FA4FE177C6F6″>
    </Configuration>
 </Template>


On occassion you will want to hide a template from end-users in the Template Selection user interface, by setting the <Hidden> attribute to TRUE the configuration will be hidden from the user interface.  In Microsoft Office SharePoint Server 2007 you may want to hide the SPSMSITEHOST template from the Template Selection user interface to prevent end-users from creating new Site Collections using the My Site Host template.  (See illustration).


 

Other templates to consider removing from the Template Selection user interface include:  Site Directory, Search Center with Tabs, Search Center.


Development Best Practices


When developing custom site definitions, it is recommended to use an existing site definition as a baseline and copy that to a directory that will host your custom site definition.  Customizing the existing site definitions is generally not recommended as service packs and hotfixes can reset custom configurations. 


Use an existing WEBTEMP.xml as a base for your new site definition renaming the file to associate it with your new directory.  For example, if your new site definition directory is CONTOSO, rename the copied WEBTEMP.xml, WEBTEMP.contoso.xml.


Specify unique names in the <Template> <Name> and <ID> attributes; it is recommended the ID be an integer greater than 10000 to avoid any conflict.



<Template Name=”ContosoBase” ID=”10001″>
    <Configuration ID=”0″ Title=”Contoso Basic Site” Hidden=”FALSE”
ImageUrl=”/_layouts/images/contosoprev.png” Description=”This template provides a standard site configuration
for basic Contoso sites.” DisplayCategory=”Collaboration”>
    </Configuration>
</Template>


The above example indicates a template name of Contoso that will be displayed in the Collaboration category of the Template Selection user interface as Contoso Basic Site with an associated preview image.


Once the site definition has been created, the site definition can be customized leveraging ONET.xml which serves as a repository for all available resources within the site definition.

Backup – Microsoft Office SharePoint Server 2007 Search

One of the most critical components of Microsoft Office SharePoint Server 2007 to many businesses is search and often is a key component of business processes.  To ensure consistent and recoverable content is available to end-users, it becomes necessary to periodically backup the search components in the event of a catastrophic failure or issues requiring the rebuilding of the search component. Since re-crawling all content sources may not be practical or efficient in many cases, Microsoft Office SharePoint Server 2007 has streamlined the search component backup and restore process. Some key notes follow:


The ability to query an index relies on two key search components:



  1. The index file propagated to the front-end web servers from the designated query server machine

  2. The Shared Services Provider Search database


NOTE Backing up only the index file requires the SSP in addition to be searchable by users.How do I backup my index file and SSP Search database?


Microsoft Office SharePoint Server 2007 has made the index backup and restore process heterogeneous, meaning a server farm’s index file and SSP search database can be backed up and restored from one central location, in this case, Central Administration.


Step 1


Open Central Administration and select the Operations tab.


Under the Backup and Restore options, select Perform a backup.


From the Perform a Backup – Step 1 of 2: Select Component to Backup window, select the Shared Services Provider component, this component includes the sub-components of the SSP content database, Shared Services database, User Profile Application, Session State Shared Application and the index component on the file system.


Click Continue to Backup Options


Step 2


From the Start Backup – Step of 2: Select Backup Options window, specify the type of backup as either Full or Differential and the backup file location. A Full backup will backup all of the components selected in step 1 including all history, a Differential backup can be run periodically to backup any and all changes to the component selected in step 1 since the previous Full backup.


Click OK to commit the changes.


Step 3


The backup status will be displayed once the Timer Job is scheduled and committed in the Backup and Restore Status window. This page also supplies options to view the history of previous backup and restore operations. History logs are stored in the directory specified to host the backup files and can also be reviewed by selecting the Backup and Restore | Backup and restore history option under the Operations tab in Central Administration.  Alternatively STSADM can be used to display a history of backup and restore operations that have been run using -o backuphistory; use STSADM -help backuphistory to generate a list of available commands.


Step 4


If the backup process is not indicated in the Backup and Restore Status window, verify the SharePoint Timer Service is running – additionally you can inspect the Timer Job Definitions under the Operations tab in Central Administration by checking the status of the Backup/Restore job.