Site Definitions Web Templates Hive Modifications etc. 2007 & 2010

SharePoint 2007 for 2010 see below…

Working with Site Templates and Definitions

Supported and Un-supported scenarios


These are Vesa Juvonen Blogs, best source of info in this subject, even free training labs.

This one is a must read

Microsoft implemented Features so that you can turn functionality on and off in a site after it was create … even if it was not in the original site definition. New to the WSSv3 Platform is a concept called Features. These enable you to package chunks of functionality and allow this functionality to be turned on or off in a WSSv3 based site. This could be things like: List templates, List instances, Menu Items, Workflows, Web Parts … Represents a modular server-side, file system-level customization that contains items that can be installed and activated in a SharePoint environment. Features are composed of at least one feature.xml file that is located in a custom subdirectory of the features directory. Features can also contain other files that make up its components, such as and most commonly an XML file that contains a list of Feature elements.

Each Feature element can be included in a Feature that has the appropriate scope. The Feature scope is defined in the feature.xml definition file for items such as List Instance, workflow, custom action etc. Each feature element XML item contains the appropriate data needed to provision that feature element.

Feature Dependencies

Features can have dependencies on other Features, and these other Features can be activated when the Feature that depends on them is activated. Whether these other Features are activated depends on whether they are hidden and whether they are at the same scope. If a Feature is dependent on another Feature that is later deactivated, the dependent feature can fail to operate correctly. You must install Features in a custom subdirectory of the features directory. Features might also require that you install certain assemblies. Each Feature GUID must be unique in the server farm or you can encounter issues in resolving the GUID to the correct Feature.

You can remove a Feature from a farm, but if it is not removed from the various locations it was activated against before it is removed, you can experience problems disassociating those Features after removal. Features can leave remnants after removal such as orphaned properties in a property bag, or files that were copied into a Web site upon activation. Whether you decide to leave those remnants depends on the design of the Feature, as it can be desirable to recover those properties if the Feature is re-added, and it can be a poor design choice to remove files that were added if they are relied upon elsewhere. A Feature that adds a file that replaces a customizable file can also permanently remove the capability to remove the customization and return the file back to its original state after the Feature is removed.

Feature Stapling

Feature stapling is implemented through a Feature that is specifically designed to staple other Features to one or more site definitions. Feature stapling allows a Feature to be stapled to any new sites created from any site definition or from specific site definitions based on the template name identified in the appropriate WEBTEMP.xml file. We want to associate a Feature with a site definition, it is not advisable to modify the out of the box site definitions. So how do you do this? This is where Feature Stapling comes in. Feature Stapling allows you to “staple” a Feature to a site definition without modifying it in any way. This means you can add your feature to all sites created using that site definition.  the feature stapling mechanism works only with the old style site definitions and not with WebTemplate definitions

To create a staple you actually create another Feature that does the staple. Below is an excerpt from a staple feature we use in the product to staple a Multilanguage feature to the STS, BDR & SPS site definitions.

Feature.xml file:

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="82E2EA42-39E2-4B27-8631-ED54C1CFC491"
<ElementManifest Location="TransMgmtFunc.xml"/>

TransMgmtFunc.xml file that contains the FeatureSiteTemplateAssociation element:

<Elements xmlns="">
<FeatureSiteTemplateAssociation Id="29D85C25-170C-4df9-A641-12DB0B9D4130" TemplateName="STS#0" />
<FeatureSiteTemplateAssociation Id="29D85C25-170C-4df9-A641-12DB0B9D4130" TemplateName="STS#1" />
<FeatureSiteTemplateAssociation Id="29D85C25-170C-4df9-A641-12DB0B9D4130" TemplateName="BDR#0" />

<FeatureSiteTemplateAssociation Id="29D85C25-170C-4df9-A641-12DB0B9D4130" TemplateName="SPS#0" />

In the above example it “staples” the Feature with the ID “29D85C25-170C-4df9-A641-12DB0B9D4130” to the STS#0, STS#1, BDR#0 & SPS#0 site definitions.

Example – Replacing ExecuteURL:

You can use Feature stapling to effectively replace your use of the ExecuteURL property in a site definition. Scenario: You want to run some custom code whenever a site is created. (a typical use of the ExecuteURL property in V2)  Solution: Build a Feature that has an Event Receiver defined on it; & have it catch the Feature activation event. Run your custom code in there. Then, use a Feature Staple to staple your Feature to the site definition e.g. FOO#0 (or whatever one you want to run your code for). Bingo! You can now run your custom code whenever a site is created 🙂

Feature Event Receiver

Specifies a server-side code routine that is called as part of four key events in the lifetime of a Feature: installation, activation, deactivation, and removal.

Site Definition

Contains a server-side collection of files that defines the structure of one or more site templates Site definitions are a powerful method of creating many sites with the same layout; however Features and feature stapling now allow you to give sites additional functionality without the development/support burden that can come with using a site definition. Site definitions consist primarily of multiple XML and ASPX files stored on a front-end Web server in folders under the \\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE. Since custom site templates are based on existing sites, at least the first site in any Windows SharePoint Services 3.0 deployment must be founded on a particular configuration within a site definition.

There are five site definitions natively installed in Windows SharePoint Services. A site definition can include more than one site definition configuration. SharePoint Web sites are based on particular site definition configurations.

  • STS includes the site definition configurations for Team Site, Blank Site, and Document Workspace.

  • MPS includes the site definition configurations for Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace.

  • CENTRALADMIN provides a site definition configuration sfor central administration Web sites.

  • WIKI provides a site definition configuration for Web sites that support community content using wiki technology.

  • BLOG provides a site definition configuration for blogs.

    List Definition

    List definitions in earlier versions of SharePoint Products and Technologies were contained directly within site definitions. In Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0, list definitions are implemented by using Features containing the required schema of the list, and are then referenced from site definitions or added later by activating a Feature within a Web site.

    Site Template

    Contains a customized site design based on an existing site definition. Site templates in this context exist outside of any site definition. Site templates are saved from within a site as an .stp file that contains a set of all modified files and lists in the source site. The file can also contain content from the source site, such as list items and documents. By default, the maximum size of an .stp file is 10 MB.

    However, in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0, you can configure the maximum size. You can use a site template to create a site within an existing site collection if the site template has been uploaded into that site collection. To use it to create the top-level site in a site collection, you must make it available for the entire Web application using stsadm. In 2010 this all changes.

    List Template

    Contains a set of customizations from a base list structure, packaged by the client as an .stp file. A list template should not be confused with a list definition, which is a server file system-based .xml file.

    Deciding Between Custom Templates and Definitions

    Are the changes you need to make simple or complex? If, for example, you need to make only minor changes in the look of certain pages and add a few fields in particular lists, you should create a custom site template. However, if you need to create new content types, add new Web Part definitions, and significantly restructure sites, you should create a custom site definition.

    How to: Create a Custom Site Definition and Configuration

    You can create a custom site definition by copying an existing site definition and then modifying the copy. In the modification stage you will change some Collaborative Application Markup Language Core Schemas markup in two schema files: one that is a copy of a WebTemp.xml file, and the other a copy of an Onet.xml file. You must not modify the originally installed WebTemp.xml file.

    MOSS 2007 Using the Central Template Gallery

    Site templates that must be globally accessible are installed in the central template gallery (this is sometimes named the global template gallery). The template title must be unique within the central template gallery. Add a template to the gallery is with the STSADM addtemplate command or with the SharePoint object model. For more information, see Custom Site Templates on MSDN.

    The following STSADM example shows how to add an incident site template to the central site template gallery:

    stsadm -o addtemplate -filename "incidentsubsite.stp" -title "SPGSubsiteTemplate" -description "SPG Sub Site Template "

    To modify the template in the central site template gallery, delete the original template and replace it with the updated version. If you want to retain the original template and also add an updated template, you must provide a unique title and file name for the updated template when you add the new version.

    The following STSADM example shows how to add a second version of the original template as a new template in the central site template gallery:

    stsadm -o addtemplate -filename "incidentsubsiteV2.stp" -title "SPGSubsiteTemplateV2" -description "SPG Sub Site Template V2"

    This example adds the updated version to the gallery as a new template. Notice that both the name and title differ from the original template. This approach leaves both the original and new template available for use.


    SharePoint 2010 (only new or different stuff talked about…)

    We have many options to make a site

  • Web Templates
  • Feature stapling
  • Site templates
  • Site definitions
  • Provisioning provides
  • Custom code (mainly for automated processes)


    Custom Web Templates from Scratch is best option to make site templates

    The WebTemplate feature element can also be used to create your own web templates, without saving a site as a template. site templates in SharePoint 2010 require an onet.xml file. instead of the webtemp.xml file you will use a feature with the WebTemplate element. In the WebTemplate element you will define a BaseTemplateName, a BaseTemplateID and a BaseConfigurationID. These 3 attributes have to be filled in for the web template to work properly. You should base your web template on an out of the box site definition that is as close to the web template you’ll be creating as possible.

    Example Elements File to define a web template in Onet file

    <Elements xmlns=""&gt;


    Example of a Team Site

    BaseConfigurationID ="0"   #This is only value usable in 2010 here

    BaseTemplateID ="1"

    BaseTemplateName ="STS"

    Description="My new site."


    Name="My Name"

    Title="My Title"



    A web template is persisted in the SharePoint database as a Microsoft SharePoint Foundation Solution, which is a file that has a .wsp extension. The .wsp file is stored in the Solutions Gallery of the site collection.  Web templates can be downloaded, edited, and redeployed as a solution to create other site collections.  A .wsp file is actually a .cab file. You can save a copy of the file from the Solutions Gallery, change the file name extension from .wsp to .cab, and open the file in Windows Explorer and can be imported into Visual Studio for repackaging and deploying. (It is easier to not do this but rather start in Visual Studio from scratch but use a copy of the oob onet file in your webtemplate file.

    Web Templates can be associated with:

    • Site scoped feature
      • Web template is available for a particular site collection
    • Farm scoped feature
      • Web template is available for the full farm

      Farm scoped web templates are available in the Central Administration Create Site page to create root site collections and also to create sub-sites from the Create New Site dialog page

      We recommend that you construct SharePoint Foundation solutions as one or more features whenever possible instead of creating a custom site definition or custom web template. However, if a custom site type makes the most sense for your solution, the next question is whether to create a web template or a site definition. To maximize the chances that your solution will be compatible with future versions of SharePoint Foundation, we recommend that you create a web template. Some other advantages of web templates are the following.

      Custom web templates are easy to create.

      Almost anything that can be done in the user interface can be preserved in the template.

      Custom web templates can be modified without affecting existing sites that have been created from the templates.

      Custom web templates are easy to deploy.

      The user context in which a web template is deployed does not have to have access to the file system of the servers.

      In the following scenarios (which are not common), you must create a custom site definition.
      The custom site type requires new document template for document libraries. (But note that the recommended way to add a new document type is to create a custom content type instead of a new document template in a site definition. For more information, see the Content Types node of this SDK.). The custom site requires a custom email footer. The custom site type requires a custom “component” of the type itemized in the Components element of an onet.xml file, such as a custom file dialog post processor or a custom external security provider.

      Web Template (Save as Site Template) Import to Visual studio and Deploy to Farm from here
      After downloading and importing an existing site we want to modify and deploy to Farm level. There are 4 default features, all 4 features are scoped to web, and all 4 are visible. In addition to renaming them, hide features 1,2, and 4 from display, and we want to scope feature 3 to the farm. Rename oob features, all of the supporting elements below are automatically renamed as well. The title is what is used when the feature is displayed in the feature list in UI, double click on the feature, and the Feature Definition box will open in the main window, modify the Title, and if desired the Description field to something meaningful to your users. Set the Is Hidden property to true for all of the features except for the Web Template feature itself (Feature 3). Open the Web Templates Folder and change the name of the Template and the feature definitions will be updated automatically. Next, we need to open the Elements.xml file, and change the Name and the Title tag to the new name using Search and replace. open the ONet.xml and change the Title attribute in the Project tag to an appropriate value. Onet file can be used to remove any feature dependencies that may not exist in the destination farm, but be careful – other elements of your template may be reliant on them. First F5 the solution and make sure to test test test. To deploy the solution to the farm, set Visual Studio to Release mode from the toolbar: Then, Right Click on the project, and select Package. Add the project to the Farm solution gallery, add-SPsolution –LiteralPath c:solutionssample1.wsp, the argument for LiteralPath is the complete path to the solution file. If there are and spaces in the path name, it needs to be encased in quotes. Now that the solution has been added, it needs to be deployed. To do so, start central admin, Go to System Settings, and select Manage farm solutions in the Farm Click on your solution name, and then click the Deploy Solution button. You can control whether or not the template is available by turning off the farm feature. You can do that from central admin by navigating to System Settings – Manage Farm Features. From here, you can turn your template on and off.

      This is from Chaks’ Corner

      Configuration ID

      The Configuration element in the onet.xml file specifies the various lists and modules used when creating SharePoint sites. In Web Templates, you can only use Configuration ID 0


      Site Scoped Feature – SiteFeatures Element in onet.xml

      The SiteFeatures element contains references to site collection features to include in the site template.

      In SharePoint 2010, if a feature listed in SiteFeatures element is not activated at the root site level, it is not activated during sub-site creation from the onet.xml.

      So, having references to site collection features in a site scoped web template is no longer required, as none of those features are activated during sub-site creation.


      Farm Scoped Feature – SiteFeatures Element in onet.xml

      For a farm scoped web template, SiteFeatures element is parsed and SharePoint will activate the features (at the site collection level)referenced in the onet.xml. They are activated in the same order as in the onet.xml.

      The difference with farm scoped feature is that you are creating a root site collection (from central administration) and thus for a new site, the SiteFeatures element is parsed. Of course, when you use the same web template to create a sub-site in that root site, the SiteFeatures element is ignored.

      Avoid Modules – Use Features

      If you are into building site definitions, then you are more inclined towards provisioning content to the site via Modules element in onet.xml.

      Though Modules are supported in web templates, it is best to provision using Features. These features will be Web scoped and referenced in the WebFeatures element in onet.xml. Using features makes it more flexible and readable.


      Also considering the upgrade paths, using features will be very beneficial.

      Same thought should be given to ListTemplates and DocumentTemplates elements.

      Upgrading Web Templates is Easy

      Since you are using a feature to deploy web templates, it is now easy to upgrade web templates. This is the reason why you must consider moving away from Modules, ListTemplates, DocumentTemplates and use features wherever you can in web templates.

      Upgrading to SharePoint vNext will be Easy

      Yes, you read it right – Using web templates will make upgrading to SharePoint vNext easy!

      The main reason being that web template is only used during the site creation and once the site is created, there is no reference that the site was created using a web template. The site does not reference the onet.xml used.

      Store the Web Template ID in the Site’s Property Bag

      Since the site created using a web template does not store any info about the web template, it is best practice to store that info so that we know which web template was used to provision the site.

      Vesa’s post (linked at the beginning of the article) explains how to do this.

      Start from a simple site template

      When building web templates, always start from a very simple site template. For example – Blank site template or Team site template

      My favourite is: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SiteTemplates\sts\xml\onet.xml

      Creating Sites Programmatically based on a Web Template

      For site definitions, you will use the Site Definition ID (STS#0, CMSPUBLISHING#0 etc.,). But we don’t specify the ID for the web template


      However, we do supply Name and Title for our web template.

      Once deployed, SharePoint identifies your web template with the following:


      FeatureGuid being the web template’s feature (site or farm scoped)

      So you can now get your Web Template:


      SPWebTemplate webTemplate 
           = spSite.GetWebTemplates(lcid)
                wt => wt.Title == "Proseware Home"


      For farm scoped web template:

      $webTemplate = Get-SPWebTemplate | where {$_.Title -eq "Proseware Home" -and $_.LocaleId -eq "1033"}

      For site scoped web template:

      $spSite = Get-SPSite "http://site-url" -ErrorVariable err -ErrorAction SilentlyContinue
      if($spSite -ne $Null)
          $webTemplate =  $spSite.GetWebTemplates("1033") | where {$_.Title -eq "Proseware Home"}
                                  "My Custom Site",
                                  "My Custom Site",

      Categories: SharePoint 2010 | Tags: web-templates | Permalink

      Most of the objects in a site are included and supported by the template. There are a number of objects and features not supported however. The following table provides a quick summary of what’s in and what’s out of a typical site template, or solution.

      Included in user solution WSP Not included in user solution WSP
      • Lists
      • Libraries
      • External Lists
      • Data source connections
      • List views and data views
      • Custom forms
      • Workflows
      • Content Types
      • Custom Actions
      • Navigation
      • Site pages
      • Master pages
      • Modules
      • WebTemplates
      • Customized permissions
      • Running workflow instances
      • List item version history
      • Workflow tasks associated with running workflows
      • People/group field values
      • Taxonomy field values
      • Publishing pages and publishing sites
      • My Sites

      SharePoint Template Code

    • GLOBAL#0 = Global template (1033)

      STS#0 = Team Site (1033)

      STS#1 = Blank Site (1033)

      STS#2 = Document Workspace (1033)

      MPS#0 = Basic Meeting Workspace (1033)

      MPS#1 = Blank Meeting Workspace (1033)

      MPS#2 = Decision Meeting Workspace (1033)

      MPS#3 = Social Meeting Workspace (1033)

      MPS#4 = Multipage Meeting Workspace (1033)

      CENTRALADMIN#0 = Central Admin Site (1033)

      WIKI#0 = Wiki Site (1033)

      BLOG#0 = Blog (1033)

      BDR#0 = Document Center (1033)

      OFFILE#0 = Records Center (1033)

      OFFILE#1 = Records Center (1033)

      OSRV#0 = Shared Services Administration Site (1033)

      SPS#0 = SharePoint Portal Server Site (1033)

      SPSPERS#0 = SharePoint Portal Server Personal Space (1033)

      SPSMSITE#0 = Personalization Site (1033)

      SPSTOC#0 = Contents area Template (1033)

      SPSTOPIC#0 = Topic area template (1033)

      SPSNEWS#0 = News Site (1033)

      CMSPUBLISHING#0 = Publishing Site (1033)

      BLANKINTERNET#0 = Publishing Site (1033)

      BLANKINTERNET#1 = Press Releases Site (1033)

      BLANKINTERNET#2 = Publishing Site with Workflow (1033)

      SPSNHOME#0 = News Site (1033)

      SPSSITES#0 = Site Directory (1033)

      SPSCOMMU#0 = Community area template (1033)

      SPSREPORTCENTER#0 = Report Center (1033)

      SPSPORTAL#0 = Collaboration Portal (1033)

      SRCHCEN#0 = Search Center with Tabs (1033)

      PROFILES#0 = Profiles (1033)

      BLANKINTERNETCONTAINER#0 = Publishing Portal (1033)

      SPSMSITEHOST#0 = My Site Host (1033)

      SRCHCENTERLITE#0 = Search Center (1033)

      SRCHCENTERLITE#1 = Search Center (1033)

      SPSBWEB#0 = SharePoint Portal Server BucketWeb Template (1033)

      Understanding Content Deployment

    • Also, if you want to change the order of templates for the Sub-Site Creation(i.e. not for top-level site creation at central admin) then, the below code does actually work and it changes the order.

      SPWebTemplateCollection clctn = web.Site.GetWebTemplates(web.Language); Collection<SPWebTemplate> templates = new Collection<SPWebTemplate>(); SPWebTemplate[] templatesArray = new SPWebTemplate[2]; foreach (SPWebTemplate template in web.Site.GetWebTemplates(web.Language)) { if (template.Title.Contains("Syed") == true) { templatesArray[0] = template; MessageBox.Show(template.Title + " " + template.ID.ToString()); } if (template.Title.Contains("Wiki") == true) { templatesArray[1] = template; MessageBox.Show(template.Title + " " + template.ID.ToString()); } } for (int i = 0; i < 2; i++) { templates.Add(templatesArray[i]); } web.SetAvailableWebTemplates(templates, web.Language); web.Update();

      In the object model, an SPWebTemplate represents a site definition (and configuration). For more information about site templates and site definitions, see Site Templates and Definitions (

      Todd Klindt says: Site collections don’t have templates, webs do. When a new site collection is created there is a template picker. That doesn’t apply a template to the site collection itself, but to the rootweb of that site collection. When the site collection is created, the rootweb is also created. That is where the template is applied. In SharePoint 2010 site (really web) templates are stored as user solutions in the site collection solution store as WSP files. Those WSP files don’t upload at the farm level (at least not that I’ve been able to find). So how does one create a new site collection with a custom template? The site collection gets created, with or without a template applied. When the site collection is created, so is its solution gallery. If we upload our WSP to that solution gallery, then it’s available to us when we create the rootweb and voila.

      Visual Studio 2010 fully supports the importing of solutions created in SharePoint Foundation 2010 and SharePoint Server 2010 but does not support importing SharePoint Services 3.0, SharePoint Server 2007, Visual Studio 2008, SharePoint Designer 2007 or Visual Studio 2010. Meaning Visual Studio 2010 does not support the importing of SharePoint solutions created in Visual Studio 2010, they have to be created in Foundation or Server 2010 out of the box only. This statement is from here Although you can often successfully import solutions created by these applications, that functionality is not tested and not supported. Developing SharePoint Solutions


      Use Powershell, this command will deploy it at Farm scope

      Install-SPWebTemplate –path "" –name "My Template" –description "TestFarm"

      I read this in a case file

      "Unfortunately a .wsp solution file that is created by saving a site as template does not work with SharePoint 2010 – It is not a supported way of creating sites based on custom site templates – we have got several cases in the past associated to this behavior. Is this true? If so the only option is to create a custom site definition.

      I got this from Mike Amerllaan – If the publishing feature is turned on, at least once, you cannot do a save as and make a site template, well you can but it will error out and not be usable. (even if you turn it off and try again it will still error and is not supported.

      But on MSDN it says this

      References for creating a Site collection template:

      How to: Create a Custom Site Definition and Configuration

      How Do I Video: Create Site Definitions for SharePoint 2010 in Visual Studio 2010?

      Deploy templates (SharePoint Server 2010)

      Great article on how to create a custom site definition

      Create a site collection

      Try this powershell to create a site collection from a wsp file

      To get list of templates and properties get-spwebtemplate | fl

      $tem = get-spwebtemplate -identity "{73A04742-5D3C-44BE-B4C4- 4CF48AD674A0}#James"

      New-spsite -url http://fs14/sites/james -owneralias contoso\administrator -name "James Site" -template $tem

      Team Site Template & saved the said site as a template "PVO-8.wsp"

      add-spsolution Then, provided the LiteralPath: C:\alx\pvo-8.wsp

      Furthermore, we did run the command : install-spsolution -identity "pvo-8.wsp" –gacdeployment

      Or Try this out

      $file = "D:\Rahul\RestoreWSPSiteTemplate.log"

      start-transcript $file

      trap { stop-transcript; break}

      Remove-SPSite -Identity "http://DEST_SERVER_NAME:PORT_NO/sites/ExampleRestore&quot;

      New-SPSite "http:// DEST_SERVER_NAME:PORT_NO/sites/ExampleRestore" -OwnerAlias domain\rahul.vartak

      Add-SPUserSolution -LiteralPath "D:\Rahul\ExampleTemplate.wsp" -Site "http:// DEST_SERVER_NAME:PORT_NO/sites/ExampleRestore"

      Install-SPUserSolution –Identity ExampleTemplate.wsp -Site "http:// DEST_SERVER_NAME:PORT_NO/sites/ExampleRestore"

      $x = Get-SPSite "http:// DEST_SERVER_NAME:PORT_NO/sites/ExampleRestore"

      $y = $x.GetWebTemplates(1033) | Where{ $_.Title -eq "ExampleTemplate" }


      $site= new-Object Microsoft.SharePoint.SPSite("http:// DEST_SERVER_NAME:PORT_NO/sites/ExampleRestore")




    • Advertisements