Project planning and application lifecycle management

One of the most important and often overlooked thing to cover in planning phase of the projects is the application lifecycle management (ALM) for upcoming portal. In this context I don't mean just the lifecycle management for the customizations, rather for the full process and environments. Every single project done with SharePoint technologies (WSS/MOSS), should define the clear rules and practices to manage the process as early as possible.

By setting the ground rules immediately in the planning phase of the project, you can take them into account during the technical planning of the deployment and of course also in the operational planning. Following image and table defines one example process, which follows the continuous integration model for SharePoint development (Continuous integration in MOSS development using TFS).

Following table defines the steps and phases one-by-one.

Considerations

Following chapters defines few points to consider when the full process is planned. I also want to raise few pointers, which I have personally run into in multiple partners and customers.

Are the code and SharePoint artifacts in safe place?

It should be clear that the all of the customizations developed for SharePoint portal are stored in some source control system, like Team Foundation Server. You don't want be in situation where the customization are gone, due failure in single laptop or desktop. Also consider and ensure that the source control system is in safe hands. If there's critical issues in the production, which requires instant code level fix to be deployed, you need to ensure that the source control is up and running.

Basically this means that the source control system should be high available or at least there's a backup plan to access the source code in timely fashion, so for example possible SLA's can be achieved.

Is the process high available?

We need to go through the steps in the process to ensure that there's no single point of failure in the process. Technical failures can be fairly easily identified, but we also need to consider the steps, which require human intervention. You don't want to be dependent from single persons, which could compromise the environment for example during summer vacation. There needs to be a back up person for each critical responsibility, with sufficient knowledge concerning the possible tasks to be done.

Is there clear model to update the customizations?

Setting up the initial version of the portal is quite straight forward, but the possible updated versions have to be carefully designed. It's quite common that after the initial version, there will be additional functionalities included in the portal. At some customers, there are quarterly releases, which enhance the functionalities provided for the end users by introducing new possibilities and options. If the upgrading model is not clear before the initial customizations are deployed, life can get complicated. Can we use the in-place upgrade of the solution packages? Does the end users use SharePoint designer in production? Every decision has it's effect and there for we need to ensure the model already in the planning phase.

Personally I've seen way too many SharePoint deployments, which have been build up nicely, but when we need to update any of the customizations, the life get's over complicated.

Is the customization deployment model scalable?

The usage of the solution package in deployment of the customizations can be considered as the de-facto way of deploying ANY customizations to the portal. By using solution packages we can ensure that in case of increased load for the MOSS farm, we can scale the farm out, by adding additional servers. If the deployments are done manually, there's too huge risk for human errors and the servers won't be in-sync. Manual deployment would require also huge amounts of additional actions to be conducted when the new server is introduced to the farm.

Summary

I listed only few pointers to give you an idea of the things to cover in you project. Of course model and required processes is fully dependent on the scale of the deployment. If you only use closely out of the box SharePoint installations and the modifications are done using SharePoint Designer, you don't necessarily have to think through these kinds of things. For large scale projects, the models and processes have to be planned carefully. It's not rocket science and you should not over think the processes, but by planning a head, you can ensure the long running service, which will be definitely worth of investment.

MCM for SharePoint

Have you already completed the four MCTS certifications available for SharePoint and would like to have more challenges?

• MCTS: Windows SharePoint Services 3.0 – Configuration
• MCTS: Microsoft Windows SharePoint Services 3.0 – Application Development
• MCTS: Microsoft Office SharePoint Server 2007 – Configuration
• MCTS: Microsoft Office SharePoint Server 2007 ― Application Development

Would you like to distinct yourself as the real subject matter expert for SharePoint? Check the following links for more information concerning the upcoming Microsoft Certified Master (MCM) for SharePoint.

• Microsoft Certified Master Program
• Climbing the Ladder of Success with Microsoft Certification
• More on the Certified Master programs from me, Per, the program owner...
• So you think you qualify for the Microsoft Certified Master Program
• Live Meeting recording - https://www.livemeeting.com/cc/lmevents/view?id=MSFT073008AMlm&pw=ATT12125lm

Office SharePoint Server 2007 TechNet content released as .chm file

I just noticed that the SharePoint IT pro documentation team has released Office SharePoint Server 2007 TechNet content as a downloadable file, to be able to access the content also off-line (intercontinental flights etc.). According the announcement, the package will be updated in monthly. This is also good reference guidance, if you are in customer premises and want to verify something without access to the actual site.

• Blog entry - You asked for it, you got it: .chm builds of library content
• Download - Office SharePoint Server 2007 Technical Library in Compiled Help format

Continuous integration in MOSS development using TFS

I've been delivering quite a few technical training's during past year and one of the most discussed thing is the setup of the development environments for large scale projects. Especially large ISV's are really interested on the the practicalities of utilizing the TFS as the continuous integration (CI) and/or application lifecycle management (ALM) platform. For standard .net projects this has been the way to manage large projects and it's obvious that the investment and practices are wanted to be utilized also for the SharePoint based development.

Since SharePoint development differs quite a lot from the standard asp.net development, this has not been that straight forward. Following scenario is example done using Visual Studio and TFS, but the principles and practices can be easily adapted also for other continuous integration solutions, like the CruiseControl.NET (CCNet).

Setting up the Visual Studio solution for the TFS

Before the continuous integration can be setup in the TFS side, we need to configure the Visual Studio project correctly, so that when ever build is initialized, newly compiled solution package (.wsp) is  created. There are numerous blog entries available from the Internet including the detailed steps for this.

• MSDN - Automating Solution Package Creation for Windows SharePoint Services by Using MSBuild

Basically the idea is to configure the Visual Studio solution such away that each assembly is first compiled and then the solution package is compiled using the MakeCab.exe. For the VS solution where you have multiple projects, make sure that you have defined the project dependencies such away that that the actual solution package project (the one which output is the wsp file) is dependent on the assembly projects (outputs dll's). This ensures that the assembly projects are compiled, before the wsp package is generated.

Creating the auto build project for TFS

When the auto build process of the TFS has finalized by compiling the Visual Studio solution, we have received fully package solution package(s), which are ready to be deployed to any SharePoint server. Since the TFS is not aware of these kind of file types, it does not by default copy the wsp package to the drop location. This is not an issue, since we can modify little bit the build project to be able to initiate the portal recreation.  By opening the build project file (by default TFSBuild.proj located in the TeamBuildType/[build name]/ folder in TFS source control) and adding following xml elements, we make sure that the wsp package is also copied to the drop location and additional batch file (this case the rebuild.bat) is executed.

<Target Name="AfterCompile">
  <Copy SourceFiles="$(SolutionRoot)\[TFSProjectName]\[ProjectName]
                    \SolutionFiles\Package\[SolutionPackageName].wsp" 
        DestinationFolder="$(DropLocation)" />
  <Exec Command="C:\TFS\rebuild.bat" 
        WorkingDirectory="$(DropLocation)" />
</Target>

Note. Above example of using rebuild.bat is dependent on the fact that the SharePoint is located in the same server as where the build happens, which in most of the time, is not the case. Alternative solution is declared in the following chapter.

Really nice feature concerning the auto build is also the fact that operations and actions logged by the MakeCab are automatically included in the TFS auto build report, which is generated for each executed auto build. If there's anything wrong with your solution files (manifest, ddf etc.), the errors will be automatically logged here. Each executed build has it's own detailed information, from where you can access the build log as we can see from the following image.

Build log (BuildLog.txt) has huge amounts of details concerning the actions taken in particular build. All the MakeCab logged information is also included in the log for detailed analyses on the SharePoint solution package compilation.

Adding rebuild of the portal to scenario

When the wsp package has been created, it has to be of course deployed to the portal first, before it can be tested. This can accomplished manually, but it can also be automated, so that the portal is recreated automatically as part of the auto build process.

Personally I have done this few different ways. Initially I created a console application, which was executed as a scheduled task by the Windows OS. More convenient way to do the same would be to create few new extensions to the stsadm, which are responsible of setting up the environment, so that project members can access the latest version without any manual intervention. If the build server and SharePoint server are different servers (most likely the case), you can schedule the execution of the stsadm commands to batch file located in the server of the drop location.

Following defines one approach used. The tasks are dependent on the type of development and can be customized based on your requirements.

Objectives

1. Redeploy the new solution package to the farm - remove any previous versions, if exists
2. Recreate the portal hierarchy using portal site definitions
3. Define access to the newly created hierarchy for the project managers and testers

For these objectives, I created following stsadm extensions, which are sequentially processed. These commands access the farm using object model. By default the stsadm provides already similar functionalities, but by creating my own commands, I can easily improve and/or add any actions to be deployed as part of the auto build process.

Full scenario for continuous integration

Following image defines the key steps for the continuous integration within the SharePoint development. This model can be considered as the development time process for the project.

Following table defines the steps and phases one-by-one.

Possibilities to test and verify the provided functionalities in the development integration server depend heavily on the type of the solution to build. In case declared above, complete custom site definitions with initial configuration of custom web parts are included and there for when the portal site definition is used to create the structures, new functionalities are directly visible in the portal.

On the other hand, it's quite common that you are developing functionalities, which are associated to the out-of-the-box site definitions using site stapling techniques. In these kind of projects, the new functionalities would be available, as long as you create the definitions, on which the stapling has been added.

Even though you would be developing only few custom web parts, by utilizing the deployment model as declared above, you could verify the deployment packages for your project and test the web parts in the environment. If you are only adding few new web parts to out-of-the-box portal, you might want to consider automated activation of your custom features, which deploys the .webpart files to the portal. This way the tester(s) could verify the functionalities by adding new web parts to the portal using standard web part picker.

SharePoint artifact development

One of the thing to consider when setting up the project is the storage location of the SharePoint artifacts. Even though SharePoint provides version control for artifacts it stores, it cannot be considered as a actual source control system. Especially if the development is done by ISV, which is the most common case, it's good to have the source code including the artifacts in sync in the source code system (like TFS) to be able to label the actual releases of the developed features. Consider the practicalities to update your customizations from version 1.0 to 2.0 (I'll write later practices for version handling of your SharePoint project).

Artifact development on the ISV side can of course utilize the standard SharePoint tools, like SharePoint Designer, which increase the productivity during the initial creation of the functionalities. There's however no easily way to sync the artifacts from SharePoint to the Visual Studio package responsible of the encapsulating the solution packages. Whenever the development for particular artifact is finalized, it can be however copied to the package manually. This way for example the master page developer, can first finalize and verify the functionalities in her/his own virtualized environment and provide versions to the official solution package when appropriate.

Real life experiences

I initially created this process and the necessary configurations for one enterprise project, which started July 2007, where I was acting as the technical lead for the infrastructure architecture and for the customized development (at the time project started developers from ISV didn't have that much experience on the customization models). Overall amount of developers in the project was up to seven persons and since the development happened at customer premises, the daily builds provided easy way for the customer representatives to follow the progress and give instant feedback whenever required.

Similar setup would be however extremely useful for also any ISV, which does SharePoint development. Since the recommended deployment method for any customizations in the SharePoint landscape is to use solution packages, this process would be useful to any development project, no matter the amount of the customizations (from one web part to enterprise projects with tens of developers).

One additional advantages from automation came as a surprise during the project - or initially it was not foreseen. One of the guidelines we kept in the project was to utilize immediately fresh copy of the virtualized environments, if unexplained errors were encountered during development, that could not be solved in timely fashion. By utilizing the same process as for the auto build, we could recreate the full portal for the development environment from scratch (huge WCM portal) just by running the predefined batch files. This decreased the time required for setting up the development environments with latest build and there for saved project resources for actual activities to be completed.

Summary & more information

Utilization of continuous integration practices within the SharePoint development projects provides fairly easy way to increase the quality of the delivered functionalities. The process might first seem difficult, but when the initial configurations and actions have been completed, process can be reproduced easily to any number of projects.

Links to the concepts defined in this blog post

• Overview of Team Foundation Build
• How to: Extend the STSADM Utility
• SharePoint Solutions Overview
• Automating Solution Package Creation for Windows SharePoint Services by Using MSBuild

I'll write more guidelines concerning the ALM (Application Lifecycle Management) and other project practices for SharePoint development in upcoming posts.

Define Central Administration database to use in MOSS installation

By default when you install new MOSS/WSS farm to your environment, the content database for Central Administration application is renamed automatically using standard prefix (SharePoint_AdminContent_) and randomly generated GUID to avoid any problems if there's multiple MOSS farms installed using the same SQL Server.

If there's only one MOSS farm installed using the same SQL Server, you can quite easily identity the content database for the Central Administration web application, but especially if you have multiple MOSS farms utilizing the same SQL Server cluster, you might have difficulties to identity for example the Internet MOSS farm admin database, if the extranet farm is installed on the same server.

Usually also the companies hosting the databases would like to know the exact name of all the databases created as part of the installation process before hand, so that they can establish the necessary operational activities (backups etc.).

Solution for the naming issue is quite simple, but it has to be done before the actual MOSS farm installation is finalized, meaning before the actual MOSS farm databases are created using configuration wizard. After running the setup.exe, close the configuration wizard and move to the folder where the psconfig tool exists. This is the same folder where stsadm tool is located and by default the path is c:\program files\common files\microsoft shared\web server extensions\12\bin.

Execute the following from the command line (change the values to the correct ones to use in your environment...especially the farm account details)

Note. Make sure that the account you are using has the sufficient access rights to the database server as declared in Technet.

When the configuration is ended, the configuration database (this case the MOSS_Config) has been created to SQL Server (in this case to server servername) and you can restart the configuration wizard. From the wizard you can notice that the initial values have been already set and the server has already been attached to the newly created MOSS farm.

At this stage you can do the traditional next-next-next installation, since all the required information already has been configured. When the configuration is completed, the admin database you defined in the psconfig command has been created to the SQL Server and the Central Administration is automatically started.

Interesting governance and training material for SharePoint

I'm currently working in two large MOSS project (Global Intranet & Internet facing site) where there are requirements to define the governance models and organize training for the end users. It's quote common that companies do not realize the requirements in this area in time and when the projects are already in finalization phase, this causes huge fuzz... Even though the issue was raised immediately when the projects start... well nevertheless... Here's few extremely important links to material which are useful for every single MOSS project out there.

I'm not anymore even counting the times on when the customer have been amazed that Microsoft is providing this kind of guidance and training material... Yes... we actually do also something else rather than only install the products / servers... especially with MOSS.

Governance and general guidance

• SharePoint Gear Up
  • http://sharepoint.microsoft.com/gearup
  • Huge amount of good materials concerning how to plan the overall project based on the SharePoint technologies.
• SharePoint Governance site at Technet
  • http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx
  • Excellent site including numerous links to relevant documents, guidance and information
• SharePoint Governance Checklist Guide
  • http://technet.microsoft.com/en-us/library/cc261826.aspx
  • Excellent checklist, which points what to be plan and decide as part of the governance planning
• SharePoint Governance and Manageability (Codeplex)
  • http://www.codeplex.com/governance
  • Code examples and tools to manage sites more easily
• Example governance plan
  • http://go.microsoft.com/fwlink/?LinkID=92333&clcid=0x409
  • Sample by Mark Wagner and Joel Oleson

Training material

Following downloads were also extremely interesting, especially the Training Portal Edition, since it can be customized based on the customer case. In large global projects it's extremely important to provide consistent and well planned training materials for the administrators and end users... especially if they don't have necessarily any previous experience on the SharePoint.

Microsoft Office SharePoint Server 2007 Training Standalone Edition

http://www.microsoft.com/downloads/details.aspx?FamilyId=7BB3A2A3-6A9F-49F4-84E8-FF3FB71046DF&displaylang=en

• Step-by-step through beginning to advanced features, including Collaboration, Business Processes and Forms, Portals and Personalization, Search, Business Intelligence and Enterprise Content Management.
• Includes videos, interactive tutorials, and articles.
• Accessed through your browser after you install the application on your personal computer.

Microsoft Office SharePoint Server 2007 Training Portal Edition

http://www.microsoft.com/downloads/details.aspx?FamilyId=673DC932-626A-4E59-9DCA-16D685600A51&displaylang=en

• Built on the Microsoft SharePoint Learning Kit,
• Designed for server administrators who want to help their end-users learn how to use the features of Microsoft Office SharePoint Server 2007.
• Step-by-step through beginning to advanced features, including Collaboration, Business Processes and Forms, Portals and Personalization, Search, Business Intelligence and Enterprise Content Management.
• Includes videos, interactive tutorials, and articles.
• The material is SCORM compliant.
• Easily add or remove training topics to fit your business needs.
• Includes a reporting function that allows an administrator/trainer to track learners’ completed training topics.
• You can customize the Training to fit the look and feel of your own Office SharePoint Server site.

Dev Days 2008 - Example solution package

I'm speaking in the MOSS development track for the whole day in Finland Dev Days on upcoming Thursday (13.3.2008). As part of the delivery I prepared Visual Studio Solution package, which is demonstrated in each of the sessions with a little bit different twist. If you are interested, the used solution package can be downloaded from my public folder  in SkyDrive. Below is direct link to the folder...

I'll write more information concerning the functionalities demonstrated on the VS solution on upcoming blog posts including instructions and guidelines to extend / modify the solution based on requirements in projects.

If you have any questions concerning the structures, feel free to add comments on this blog entry...

Create a WebCreated event of your own in onet.xml

I just delivered an internal MOSS IW Ramp course in Münich and we have some discussions concerning the onet.xml and how to modify the content of the sites, which have been created using custom code directly after site has been created. You are most likely aware that during site provisioning, there's no such event available as the WebCreated, which would be raised when the web creation based on onet.xml has been done. This is quite a huge limitation, but then again, there are quite good workarounds for this.

Possible workarounds

1. Create your own custom site definitions using browser and export that using WSS 3.0 Extensions for VS 2005. As part of the export process, the tools generate the necessary code and associations to be used. Unfortunately the extensions do not support WCM enabled sites, so it cannot be used in publishing sites.
2. Use ExecuteUrl element to redirect the user to custom aspx page after the site has been created to be able to customize the site. Your custom aspx page might be located under the _layouts folder and there for we can easily point to that one using the xml elements within the onet.xml.
3. Create the WebCreated event using the powerfull feature framework. I'll declare the steps below for more detailed information.

Steps for WebCreated event using feature receiver

Step-by-Step guide for manual creating of WebCreated event are the following:

1. Create feature to deploy the default.aspx to root of the site using Module events
2. Create feature with feature receiver class – This is used for the Site Created event
3. Create site definition, which does not have directly default.aspx, rather use the feature developed above
4. Set the order of the features so that the default.aspx feature is activated before the receiver feature
5. In feature receiver feature, access the default aspx page, for example access the web part manager of the welcome page using following code

Final words

This was extremely quick sample, but hopefully it's useful to you. I'll try to find some time to make more comprehensive example of this.

Controlling publishing features from onet.xml

In the previous post, I promised to try to find time to share additional information concerning the onet.xml and how it can be modified to control other properties of the MOSS site. It took a while, but here we go. Starting from this blog entry, I promise to be more active with writing new stuff to the blog.

This blog entry explains the different options when you configure the standard publishing features in onet.xml. If you are interested concerning the navigation options for the MOSS sites, check the previous post with details concerning the different options on configuring the navigation settings within the site.

Introduction

If you have created your own site definitions based on the out-of-the-box reference implementations, you have most likely noticed following feature and it's configuration options.

The feature ID defined in the onet.xml refers to the Publishing feature stored by default in the folder C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\Publishing. Feature.xml file for the feature looks like following.

<Feature Id="22A9EF51-737B-4ff2-9346-694633FE4416"
         Title="Publishing"
         Description="Enable Publishing in a web."
         Version="12.0.0.0"
         Scope="Web"
         Hidden="TRUE"
         DefaultResourceFile="core"
         ReceiverAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0,
                                              Culture=neutral, PublicKeyToken=71e9bce111e9429c"
         ReceiverClass="Microsoft.SharePoint.Publishing.PublishingFeatureHandler"
         xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    ...
  </ElementManifests>
</Feature>

So when the site is created based on this site definition, the Microsoft.SharePoint.Publishing.PublishingFeatureHandler class is executed, which manipulates the sites settings using object model, based on the properties defined in the onet.xml. Unfortunately the class used in here is dotfuscated, so we can not check all the possibilities using Reflector. I'll cover the known properties and their meaning one-by-one with corresponding images from the UI, so you can easily figure out the different meaning and possibilities of each of the properties.

Master page setting

<Property Key="ChromeMasterUrl" 
   Value="~SiteCollection/_catalogs/masterpage/MBaseMaster.master"/>

This is the most commonly used property in the feature receiver. You can use it to change choose the master page to be applied to the newly created site. This property configures the WCM master page to be used for the aspx pages, which are based on some page layout and stored in the pages list of the particular site. In this example we set the MBaseMaster.master master page to be used in this particular site.

It's important to notice, that this setting is actually the same setting as the Site Master Page in the master page settings page. This does not have any affect for example for the list aspx pages, since those pages use the system master page by default. I'll write separate post concerning the system master page and how it can be changed from the onet.xml easily.

Welcome Page Url

<Property Key="WelcomePageUrl" 
    Value="$Resources:cmscore,List_Pages_UrlName;/default.aspx"/>

This property defines the welcome page to be used for the site. Welcome page means the page, where the user is redirected when the site's url is requested. By default when the sites url is requested (for example http://portal/site1/) we redirect the user to the default.aspx page, as in this example. Good example of the welcome page usage, it the Wiki sites. The Wiki site uses the welcome page setting to redirect the user directly to the wiki list stored in the site.

In user interface, the welcome page can be set using the Welcome page link, which can be found under the Look and feel section in the site settings page.

On the welcome page setting page, you can browse to the file you want using standard asset picker.

Page List Url

<Property Key="PagesListUrl" Value=""/>

You can use this property to define some other list to be used as the pages library. By default the WCM pages are stored under pages list (http://portal/site1/pages), but if you like, you can change the setting by adding the list name in to this property.

Available Web Templates

<Property Key="AvailableWebTemplates" 
     Value="*-Microsoft.Intranet.POC.Project#1"/>

This setting can be used to filter the site definitions to be shown in the Create Site page. So using this property, you can limit the different options to be shown to the site hierarchy manipulators. If you have multiple different site definitions used in your portal, the portal managers might have difficulties of understanding the different templates available. It's also important to realize that if there's multiple appications installed on the same MOSS farm, all of the installed site definitions are shown by default in the Create Site page, regardless of the application used..

So if property is left empty, all of the installed site definitions are available. Multiple templates can be configured to the property using following syntax. In this example there would be two different site definitions available.

<Property Key="AvailableWebTemplates" 
     Value="*-Microsoft.Intranet.POC.Generic#1;
            *-Microsoft.Intranet.POC.News#1;"/>

From user interface, you can configure the same setting from the Page layouts and site templates functionality found under the Look & Feel section of the Site Settings page.

Using this functionality, you can manually select the shown site definitions. In this case also, all of the site definitions installed on the MOSS farm are shown, regardless of the particular application.

Following image is from the Create Site page, when only one site definition is configured to be shown. In this case, we are under the Projects Catalog site, and based on the portal design, it's decided that you should only create Project sites under it.

Available Page Layouts

<Property Key="AvailablePageLayouts" 
   Value="~SiteCollection/_catalogs/masterpage/MGenericBodyOnly.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageLeft.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageRight.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageTop.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericLinks.aspx:
          ~SiteCollection/_catalogs/masterpage/MSectionPage.aspx"/>

This property is similar as the AvailableWebTemplates, but it applies on the page layout level. Using this property, you can filter the page layouts to be shown in the Create Page functionality. Since there might be tens of different page layouts created on on portal, it's convenient to filter the options to be shown for the portal editors. If you have multiple page layouts available for the particular site, the different layouts are lsited in the same property, but separated using colon.

From the user interface, the similar would be configured using the the Page layouts and site templates functionality found under the Look & Feel section of the Site Settings page.

So when the configuration has been done for the site and you select Create Page from the Site Actions menu, we can see only the configured page layouts to be shown.

Simple Publishing

<Property Key="SimplePublishing" Value="true" />

Possible values for this property are True / False. This actually affects on the approval functionality concerning the sites pages list... If property is set as false, the pages list has require approval setting activated and there for all of the changes done to the pages in the sites, have to be approved using separate process. If the property is set as true, the content is instantly published to the portal.

Final words

Using these settings and properties, you can fairly easily control the different publishing settings for the particular site. On the upcoming post, I'll declare the detailed steps to write a custom feature receiver to be able to configure also those properties, which are not by default available.

Hopefully this helps.

Controlling navigation options from the onet.xml

During past weeks I have been creating few customer POCs to demostrate the excellent WCM features of the MOSS 2007. Since the MOSS publishing features are deployed over the WSS using standard feature framework, we can configure the provisioning of the sites directly from the onet.xml. In this blog entry, I'll declare the concepts behind this possibility and the possible properties, which can be set.

Introduction

If you have played around the onet.xml files included as out-of-the-box in the MOSS (Publishing template etc.), you have most likely noticed the publishing navigation feature dependencies in the WebFeatures element as in xml block below.

<WebFeatures>
     ...
     <Feature ID="541F5F57-C847-4e16-B59A-B31E90E6F9EA">
          <Properties xmlns="http://schemas.microsoft.com/sharepoint/">
          <Property Key="InheritGlobalNavigation" Value="true"/>
          <Property Key="ShowSiblings" Value="true"/>
          <Property Key="IncludeSubSites" Value="true"/>
          </Properties>
     </Feature>
     ...
</WebFeatures>

So what does this really mean? Basically we are making a binding to publishing navigation feature and configuring it by using properties, which the handler is capable to handle. So the ID given in the onet.xml is a reference to NavigationProperties feature, which can be found from the following folder (by default):

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\NavigationProperties

And the feature.xml file from here contains following information:

<Feature Id="541F5F57-C847-4e16-B59A-B31E90E6F9EA"
               Title="Portal Navigation Properties"
               Description="Set per-site navigation properties."
               Version="12.0.0.0"
               Scope="Web"
               Hidden="TRUE"
               ReceiverAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
               ReceiverClass="Microsoft.SharePoint.Publishing.NavigationFeatureHandler"
               xmlns="http://schemas.microsoft.com/sharepoint/">
               <ElementManifests>
                    <ElementManifest Location="NavigationSiteSettings.xml"/>
               </ElementManifests>
</Feature>

As you can see, ReceiveAssebly and ReceiverClass attributes are set and there for when the actions are performed for the feature, "custom code" is executed. As declared already above, the custom code is aware of some parameters which can be set for the feature and based on these parameters, the receiver handler modifies the SPPublishingWeb object's properties.

Supported parameters

So what are the parameters supported by the NavigationFeatureHandler class and how do they affect compared to settings done from the user interface. I'll declare the supported parameters one-by-one and compare the settings to modifications done from the user interface (Site Actions -> Site Settings -> Navigation).

IncludeInGlobalNavigation, IncludeInCurrentNavigation 

Controls the IncludeInGlobalNavigation and IncludeInCurrentNavigation properties of the SPPublishingWeb. In user interface this functionality is controlled by using following options.

InheritGlobalNavigation

This paremeters controls the global navigation options. If set the true, we will get the same outcome by selecting "Display the same navigation items as the parent site".

InheritCurrentNavigation

This controls the inheritance of the current navigation. If set the true, we would get the same results as by selecting the "Display the same navigation items as the parent site" from the user interface (the first option from the picture below)

ShowSiblings

If set the TRUE, the outcome is the same options as the “Display the current site, the navigation items below the current site, and the current site's siblings” option in the user interface (second option from the picture below). Note that the IncludeSubSites and IncludePages parameters also affects to outcome.

IncludeSubSites

This is same as the "Show subsites" option in the user interface. Note that if the current navigation has been set to show the same navigation items as the parent site, this option has no meaning.

IncludePages

This is same as the "Show subsites" option in the user interface. Note that if the current navigation has been set to show the same navigation items as the parent site, this option has no meaning.

OrderingMethod

This option affects to ordering of the navigation items. Note that the final outcome depends also from the AutomaticSortingMathod and the SortAscending properties.

Possible values

Automatic - Sort all node types automatically, and group pages after other types. 

Manual - Sort all types manually. 

ManualWithAutomaticPageSorting - Sort all types except pages manually. If pages are included, sort them automatically and group them after all other types. 

AutomaticSortingMathod and  SortAscending

These controls the sorting of the navigation items. Possible outcome depends on numerous other properties, since for example the AutomaticSortingMathod property has only meaning, if the OrderingMethod has been set to ManualWithAutomaticPageSorting.

Note. It's not a typo... it's really AutomaticSortingMathod...

Possible values for the AutomaticSortingMathod property

CreatedDate - Sort items by time of creation. 

LastModifiedDate - Sort items by time of last modification. 

Title - Sort items alphabetically by title. 

Final words

As you can see, you can configure all the same options directly from the onet.xml, as you can do from the user interface. Other thing to notice is the possibilities provided by the Feature Receiver concept, which gives flexible way to execute custom code during the site provisioning (or anytime the feature is otherwise activated).

More information concerning the functionalities declared here can be found from the SDK.

• Feature.xml schema
• Onet.xml schema
• SPFeatureReceiver class - All the FeatureReceiver's are inherited from this class

PS. I'll try to find some time to write similar article concerning the other possibilities of the WCM features (how to limit the page layouts, how to limit the web templates shown in UI, how to configure master page etc.). Stay tuned...

[Update] - The following post with information concerning the other publishing feature configurations has been released. Check the details from here.