Vesa "vesku" Juvonen

WCM enabled collaboration sites

sonofthesun — Sun, 01 Feb 2009 20:55:28 GMT

Usually collaboration sites (team sites) and WCM functionalities (publishing sites) are seen as two totally separate functionalities provided by SharePoint. However by combining these both options, we can provide even more sophisticated functionalities.

One of the challenges in the team sites is the fact that there’s no easy way to store metadata in “site level”, since all of the stored information is managed in the lists. Wouldn’t it be nice, if we could dynamically list for example all of the team or project sites of one particular company division or group team sites based on the project manager assigned to the particular project site.

Usually this kind of requirements are solved by implementing a custom web part, which is used to store the “site level metadata” to database. This is good solution, but actually we can implement the same functionality just by utilizing out of the box functionalities.

Combining best of the both

WCM provides us a way to store “site level” metadata. This can achieved by storing metadata information in the welcome page
- This way we can utilize for example CQWP to list the content dynamically within site collections
From team sites we can combine the great collaboration tools, which usually are not provided in WCM sites

Following chapters define one example usage model, which I prepared for development oriented trainings back in spring 2007. We have also used this same model successfully in multiple customer engagements.

Introduction to the solution

Following project catalog and project site functionalities are part of the more complex development methods solution, which demonstrates different possibilities of the SharePoint. Branding of the site has been done in matter of hours, so so don’t concentrate on the actual look and feel, rather to the functionalities. I didn’t want to spend too much time with CSS.

Project site

Requirement– Customer needs project sites, which should store also site level metadata. This information is used to aggregate site information in multiple places on the Intranet. Project manager, as the site owner, should be able to manipulate the site metadata to indicate progress of possible issues in the project.

Requirement– Customer wants to have project phases as the document libraries in the project site. These document libraries have different document templates.

Following steps defines the different features and functionalities developed to be able to provide the requested functionality.

1. Create a necessary site columns, which will be used to store the site specific metadata. Let’s create a feature, which defines the necessary site columns based on the requirements. Below is example of single site column required to store the organization division information.

2. Create a content type used for the welcome page of the project site. Since we are creating a publishing page content type, the content type is inherited from the out of the box Page content type and the document template is set as a specific aspx page.

3. Create necessary document content types used in the project site. Notice that we use the _cts –folder in the target definitions of the template upload (module element). Underneath this folder there will be specific content type folder created, when ever a new content type is provisioned to the site collection. This is good place to store the document templates, unless the templates are frequently updated (another story, another time…).

4. Create document libraries used in the project site, from where the document content types are provided. In the below image, we introduce a new document library template and create a new instance from it to be used to store documents in the Execute phase of the project. “Why new list template?” – If we only bind the document content types to default document library, the out of the box document template would be still available.

5. Bind the content types to the specific libraries. In the following image, we bind the specific document content types to the execute phase library. “Why aren’t we binding the content types directly in list template schema?” – this approach allows use to use the same document library template for multiple different instances and just bind the specific document templates depending on the instance.

6. Let’s not forget to bind the project welcome page content type to the pages library, so that the necessary fields will be provisioned to the list.

7. Now when the project site welcome page content type is available in the pages library, we can provision initial values for the site created. This can be done by setting the default.aspx page’s metadata appropriately as in the image below. Notice that we the the ContentType value as the content type declared earlier in the feature. We also define the initial status values to be “Green”.

8. We need to create a page layout, which is responsible of rendering the metadata information for the end users (I wont’ declared the detail steps to save some space). Now we can create the site definition used to provision the site. When the site is provisioned, we can see the initial values defined in the module above. “Why a custom site definition?” - If customer would like to utilize the oob team sites and other templates as they are, but they would also like to have this new definition available, custom definition is the only way to go. Since the WCM features are enabled, the site template option is not supported.

9. Site specific metadata can now be managed directly within the welcome page as long as the fields are rendered correctly in edit mode.

10. One advantage of this approach is also the possibility to utilize the field controls for content editing. This improves the content editing experience.

11. When the values have been updated and information is published, we have standardized site model for all of the project sites. This way the end users of the portal can easily see the key information of the specific project from the standardized place in the layout.

12. As part of the requirements we also created document libraries for each project phase and used content type binding to associate the specific document content types to the specific libraries. As an outcome we are providing different document templates from different document libraries. This way we make the document creation process more efficient and save time for the site end users.

Project catalog site

Requirement – Customer wants to list dynamically all of the project sites created underneath the particular catalog site. Aggregation should list the sites based on the organization division and the phase of the project. Only those sites on which the specific user has access to should be shown.

Solution is to use Content By Query Web parts (CQWP) as part of the site provisioning process and set the web part configuration values appropriately. Since the organization division and the project phase are stored as the metadata of the project site welcome page (created with specific content type), we can simply utilize the standard out of the box functionalities.

Now since we are using CQWP to aggregate the information, all the updates are automatically updated to the lists. Out of the box Site Directory does provide similar functionalities, but the list is not dynamically updated and the information is not stored in the specific site, so that the site owner (for example project manager) could not update the information.

Requirement– Only project sites should be created underneath the project catalog site.

Define the publishing features appropriately, so that only the project site is visible in the Create Site functionality.

Requirement– Customer wants indicate possible issues in the project sites for the managers based on the status updated by the project manager.

Luckily we had three status indications stored to the the metadata of the sites, which we can utilize. Let’s also create a audience for the managers and show the web part only to those persons, whoe belongs to it. Below is the picture to show dynamically those sites, which have any of the status metadata values selected as “red”.

Putting it all together

Of course all of the functionalities are packaged to the solution package (wsp-file), which can be used to reproduce the functionalities in any MOSS deployment. This means that we need to create the manifest file, which is used to explain the SharePoint the content of the customizations, as in what features, site definitions, assemblies, web parts etc are included in the solution.

As addition to the manifest file, we need to create the ddf-file which is used when the functionalities are packaged to the solution package.

After this, we can deploy the same functionalities to any MOSS deployment and we can be sure that it works identically as in the development environment.

Independent site collections

Example design declared in this article works when the project sites are created to same site collection as the project catalog site. This has both advantages and disadvantages. One common design is the have the individual team sites created as own site collection. Also in this case, the WCM features enhance the functionality. If the site metadata information would be stored to external database, we’d have to create custom search functionality.

Since the “site metadata” is stored to welcome page based on content type, we can create managed properties of the information stored. Managed properties can then be directly utilized in the search results and we can provide same user experience as in example declared in this article.

Possible enhancements

There are multiple different ways to improve the defined functionality. Here’s few simple ideas.

1. Site approval – since we are utilizing the WCM functionalities, we could easily attach site approval process before the site would be visible for other portal users. By using minor versioning in the pages library, the site would not be visible for other persons than the site owners before the site is published as a major version. For the publishing process, we can specify any kind of workflow.

2. PKI values for the status - To indicate the project status more efficiently, we could create a custom field control, which renders the status values using traffic lights in the project site. For the catalog site, this is even more easier, since we can do conditional rendering in the xslt used by the CQWP. This way we could extremely easily create a list of all projects in organization and indicate their status using traffic light model.

WCM functionalities provides us numerous different functionalities, so you can easily invent more possibilities.

Considerations

“Why would I create standard team sites, rather than WCM enabled collaboration sites?” – good question. If the requirements can be met with more simplified solution, like feature stapling to out of the box team sites, than there’s no reason to enable WCM in team sites. If you need to provide more enhanced functionalities, enabling the WCM functionalities might just be the solution you are looking for.

“I use database to store the metadata values of the site, is this bad solution?” - No, but remember to consider he overall consequences of your architecture choice. The solution to choose always depends on the requirements and functionalities to be provided. The downside of the database based model is however the fact that the metadata is not stored within the site and therefore we need to do additional work to ensure that the values are in sync. Also the database based model requires additional work on the operational point of view in sense of disaster recovery and maintenance. The WCM based model keeps the metadata in the site and even though the site location in the hierarchy would be changed, the metadata would be intact, since it’s stored as part of the site.

Hopefully this was useful.

Internet facing MOSS sites without content deployment

sonofthesun — Thu, 29 Jan 2009 21:03:17 GMT

Lately there has been quite a lot of discussions concerning Internet facing MOSS sites and content deployment. Quite often there’s misconception that MOSS cannot be used as Internet facing platform without separate authoring farm and utilizing content deployment. Assumption is understandable, but completely wrong.

By utilizing possibility to have multiple zones for single SharePoint application, we can setup an environment, which is can be accessed by both anonymous users from Internet and content editors from corporate network using windows authentication.

Conceptual model

Zone in the SharePoint basically means different access points to access the same content. Each of these access points can have their individual configuration for the network and for the authentication. When we create a new zone, we actually create new IIS application, which is pointing to the same SharePoint application.

This model is often used in extranet scenarios, where the external users are authenticated using forms based authentication (FBA) and internal users are authenticated using windows authentication (NTLM). Same model can of course be used to provide content editing functionality for Internet facing site.

Following picture defines the elements more detailed.

#	Element
1	External users are seeing only the www.[sitename].com address. This is physically one IIS application, which accesses the MOSS application. Anonymous access is configured to the zone and the ViewFormPagesLockDown feature is activated for site collection to enhance security.
2	Internal users will have access to http://internet , which is exposed only to the internal network. This secondary IIS application is used for creating the content in windows authentication mode to same MOSS application
3	Actual SharePoint application is in the database and both zones access the same content.

Infrastructure architecture

Following picture defines the model in infrastructure level. There are multiple different variations of this kind of setup depending on the network policies and possibilities. Each of the elements and few possibilities are declared also in detail.

#	Element
1	Internet facing network zone for external people to access the service. Anonymous zone(s) are accessed from this direction.
2	Internet facing firewall and network load balancer, which permits only necessary ports to be used when accessing the portal.
3	Web front end servers actually serving the content for the external url, which is configured to the NLB and to the alternate access mapping. Depending on the networks and the security setup, these can actually also be in the corporate network. Since all of the zones created to the MOSS applications are synchronized between the servers, the IIS application for NTLM zone exists in these servers, but there’s no way to external people access this IIS application.
4	Optional firewall depending on the network, if the web front ends are in DMZ zone and the farm is divided between network segments. This is so called split-back-to-back farm.
5	Optional internal servers, which can be used to access the internal zone configured to use Windows authentication. Zone is only available for corporate network using internal DNS entries. Depending on the requirements and network, the NTLM zone could actually also exists in the WFE servers as declared partly already in step 3. This is not usually seen as a valid option, but actually the model is justified with security considerations and with cost saving since we would not need separate authoring farm.
6	Internal access point to the portal using NTLM. From here the content editors can access the portal and make necessary changes.
7	Database cluster for the MOSS farm.
8	Index server crawling the sites. Depending on the content and load, the index server can actually also be acting as the WFE server and there for it can access the content directly from itself, rather than causing load to the other WFE servers. There are however multiple different options on this one, so it’s a different discussion.

Considerations

Customization development and deployment

When separate staging or authoring farm is used, there’s more detailed processes to follow to keep the farms in sync, so that the content publishing work properly. In this option, there’s only one farm, so the deployment practices are more simplified (separate QA farm of course though recommended).

Other advance on the single farm setup is more simplified possibilities for custom solutions. Let’s have an example concerning simple feedback functionality.

Objective – Collect feedback from end users by providing a simple form for information entry. Store the sent feedback to secure list in SharePoint, which can only access the web masters.
Single farm with Zones – Create feedback list to the root web and setup the access control appropriately to it. Use elevated privileges in the custom form to write the feedback to the list. Web masters can access the list directly using the NTLM zone.
Separate authoring farm – Since the content in the internet facing farm should not be updated for proper content publishing to work, we need to implement the write back to the authoring farm using web services. Writing entries for single list is natively supported, but especially little bit more complicated solutions increase the costs of the customizations.

Management

Since there’s only one farm to manage and monitor, the overall costs of the MOSS deployment are considerable smaller than having two farms. Also keeping the separate farms in sync is more complex than having single farm to configure. Model also decreases the storage requirements, since there’s no duplications concerning the databases of the individual MOSS farms.

Security

All the concepts declared in this article are dependent on the network configurations and security settings. Especially when we are exposing the services to the Internet, we really need to ensure that the network and farm is properly configured.

Also all the customizations developed have to follow the security recommendations so that any sensitive information is not exposed.

Content editing

Since publishing of the content is instant when the Publish –button is clicked, the content can be easily modified and managed. There’s no delays of getting the information released to the internet, except the possible caching configurations.

It’s of course important to notice the model in prepared training mater, like instructing the content editors to use relative addresses for resources, like images and for the links within the portal.

Real life experiences

We have used this model in multiple Internet facing sites during past few years successfully. Administrators have been pleased on the fact that there’s only one farm to manage and monitor, content editors have been pleased on the simplified model of authoring the content and generally customer directors have been pleased on the fact that the model saves investments done to hardware and to the possible customization.

Hopefully this provides more insight on the flexibility of the SharePoint and for the different possibilities it provides. Each enterprise architecture is independent and they all have their own environmental characters. Therefore the guidance provided from TechNet or from numerous blogs should be always adapt to specific engagement.

Office 14 for Web

sonofthesun — Fri, 31 Oct 2008 07:20:46 GMT

This was so cool video, that I had to publish the link. Pretty interesting functionalities are coming up.

http://channel9.msdn.com/posts/PDCNews/First-Look-Office-14-for-Web/

Caribbean English and SharePoint - localization techniques for WCM sites

sonofthesun — Thu, 23 Oct 2008 13:20:39 GMT

This was so interesting, that I had to share it more widely... I'm working with one global customer concerning Internet facing MOSS site, which will eventually have more than 50 local sites within their own languages (including the corporate sites in multiple languages). Translation of the labels used in the sites are based on standard RESX handling, without any custom resource providers.

So basically as part of the solution deployment, the resx files are distributed to app_GlobalResources folder of IIS application in each WFE (requires some extra effort to be automated during deployment, but that's a separate story). The RESX files are not included in to the assemblies to provide more flexible way of updating just the translations without any other changes.

As part of the following releases, there was a requirement to generate the translations for the Caribbean English. You might wonder the business case, but there are certain phrases, which should be translated differently as for the US... similar way as there's different translations for UK. For initial testing, the RESX file with the correct culture information (en-CB) was created. When the file was introduced to the application, whole application came down with following error message.

Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0101: The namespace 'Resources' already contains a definition for 'CUSTOMER'

Well... that's interesting, since based on the .NET 2.0 documentation, the en-CB is officially supported locale. I did little bit more digging on the case and found out that there's actually a KB article released concerning issues with few locale codes, if certain security fix has been installed. KB article defines that for example in this case, the locale should be actually en-029. After changing the RESX file name correctly, everything started working again and translations were successful.

Improving the translation logic

Obviously the situation declared above was extremely scary. You can pull down the whole farm just by providing wrongly named RESX files. That's not good at all. Actually there's similar implications when the RESX file contains duplicate keys etc. It's of course clear mistake in the RESX, but the fact that the farm will be dropped to it's knees, is simply extremely scary. In our case, we luckily had strict process of getting the new files published in the farm (similar as declared here), so this didn't cause any catastrophic issues to production.

What can you do? - ASP.net provider model to rescue... since we can extend or change the default asp.net functionalities, we can write our own resource provider to manage the different translations. Of course the requirement of having custom provider to be written depends on the requirements for the project - especially on the high availability sense. Depending on the requirements and implementation, you can also define your own logic concerning fall back mechanisms and duplicate keys etc. etc. etc. More information on the resource provider can be found from the following MSDN article.

MSDN - Extending the ASP.NET 2.0 Resource-Provider Model

This approach also provides more flexible ways to provide the translations. By creating a custom resource provider, we could also fairly easily provide UI to update the translations directly for example from the site settings page of the particular country sites. This way the maintenance of the labels can be more easily delegated and managed by the web masters of the particular country sites.

Hopefully this was useful.

Project planning and application lifecycle management

sonofthesun — Tue, 16 Sep 2008 18:00:01 GMT

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.

#	Phase / Element
1	Developers develop individual features and functionalities based on of the technical specification using their independent virtualized environments, which have access to the TFS server for work items, source control etc. Virtualized environment have to be in-sync with the production environment concerning the licensing and patching. Customizations developed with enterprise license; don't necessarily work in standard environment. Patches and service packs should be also keep in sync. Ensure that it's somebody’s responsibility to keep the virtualized environment up to date.
2	TFS Server used to store source code and other project related information. Developers can also sync their environment using the artifacts stored in TFS. It's obvious, that developers have to have ensured connection to the source control repository.
3	SQL Server instance of the TFS, used for actual storage of the different artifacts and document. Ensure that this database is fully managed, monitored and operational; otherwise the development cannot be conducted.
4	Development integration server, which is used to verify the builds from the TFS, preferable using automated build process. Server should be kept in sync with the production environment. Integration server is used for integration and deployment testing. Also the initial functional testing for full package should be conducted in this environment.
5	Project members (for example project manager, testers and even customers representatives in some cases) can follow the progress of the project and give feedback based on the builds deployed. Define the ground rules for accepting the deployments to quality assurance environment from the integration environment. If the development happens in ISV premises, this server is most likely located also there. It's not however good practice to have similar server in these cases also at the customer premises, so that it can be used to deploy pilot or draft versions of the solution. This way we can establish communication channels concerning the upcoming features as soon as there's something to deploy. This approach minimizes surprises at the end of the project and the customer representatives can use the environment for training purposes as early as possible There has to be clear rules to follow for accepting the deployment for following phases.
6	Quality assurance environment used for functionality testing and acceptance testing. In ideal world this environment is identical as the production environment, so that it can also be used for load testing. Quite often though, the environment is virtualized for more convenient maintenance. Load testing can be nevertheless conducted also in virtualized environment, if project performs the initial load testing (base line testing) during the first version of the portal. This way the future load testing results can be compared to these base testing values. In sense of licensing and configuration, the environment should be completely identical to production. This ensures that if the deployment is successful in this environment, it will work also in production.
7	SQL Server of the quality assurance environment. Obviously the configuration should be identical as for the production. Operational setup should also follow the production, so that full portal behavior can be observed also in this environment.
8	MOSS environment used for production purposes. There should be clear responsibilities and operational guidance for this environment to ensure that possible issues caused for example customizations can be solved in timely fashion. One of the key things to document and to follow is the version handling model of the customizations (how things are updated). As written earlier, there has to be crystal clear model for deployment of new versions and guidance to follow in case of any issues encountered.
9	SQL Server for the production, which is fully managed and monitored 24/7. In case of any issues, there should be clear guidance on how to proceed. Backup and restore process should be verified in quality assurance environment and if possible also in production environment, before going live with the portal.

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

sonofthesun — Fri, 01 Aug 2008 07:12:05 GMT

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

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.

Office SharePoint Server 2007 TechNet content released as .chm file

sonofthesun — Fri, 01 Aug 2008 06:34:20 GMT

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

sonofthesun — Tue, 29 Jul 2008 16:58:09 GMT

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

Redeploy the new solution package to the farm - remove any previous versions, if exists
Recreate the portal hierarchy using portal site definitions
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.

Command	Description
deploysolutionadv	Responsible of deploying the new solution package to the farm. Retracts and removes any previous versions from the farm, if exits. Command is used to redeploy the solution package as part of the daily builds.
recreatesitecollection	Command recreates site collection using specific template defined as parameter. If site collection already exists in the farm, it's deleted. Command is used to recreate the site collection for the daily builds. Portal site definitions are great way of providing immediately full hierarchies for the newly created site collection.
assignuserstogroup	Grant access to defined site collection for the users defined as parameter. Command is used to define access to the newly created site for the persons responsible of verification tasks.

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.

#	Phase / Element
1	Developers develop individual features and functionalities based on module plan (part of the technical specification) using their independent virtualized environments, which have access to the TFS server for work items, source control etc.
2	TFS Server used to store source code and other project related information. TFS is scheduled to build the integrated version of the package using build automation functionalities. Developers can also sync their environment using the artifacts stored in TFS.
3	Development integration server, which is used to setup the outputs from the TFS. If required, this server environment can be utilized by multiple projects as long as they have separate application on which the solution is automatically deployed (often the case in ISV environments).
4	Project members (for example project manager, testers and even customers representatives in some cases) can follow the progress of the project and give feedback based on the builds deployed. By providing instance access to daily builds, project will get instant feedback for the developed functionalities Daily builds provide flexibility to follow the progress and to discover any required changes in the design as early as possible

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

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

sonofthesun — Thu, 24 Apr 2008 10:56:15 GMT

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)

psconfig -cmd configdb -create -server servername -database MOSS_Config -user domain\farmaccount -password accountpwd -admincontentdatabase MOSS_Content_Admin

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

sonofthesun — Fri, 11 Apr 2008 06:22:48 GMT

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

sonofthesun — Tue, 11 Mar 2008 17:34:16 GMT

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

sonofthesun — Sun, 11 Nov 2007 17:33:14 GMT

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

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

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

//look for the default page so we can mess with the web parts
SPFile thePage = curWeb.RootFolder.Files["default.aspx"];

//get the web part manager
SPLimitedWebPartManager theMan = thePage.GetLimitedWebPartManager(System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared);

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

sonofthesun — Sun, 14 Oct 2007 18:31:40 GMT

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.

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

sonofthesun — Fri, 23 Mar 2007 08:28:00 GMT

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.