SharePoint WSP Templates and Associated Groups

The ability to save a site as a (WSP) template and reuse it on future sites have been with us for a couple of SharePoint versions by now.

There are a lot of different ways of working with templates within SharePoint. Some developers prefer site definitions, feature stapling and other quite technical apparatuses. However, from my experience a WSP template will do the job just fine. At least in most cases.

A WSP template is most often also the fastest and cheapest way of creating and managing templates. Far easier than a custom definition or feature stapling. A WSP template also has the benefit of being managed through the web interface, making it possible for a non-developer person to survive the challenge.

All the praise aside there’s, of course, also a few things to consider while working with WSP templates. Some of them, well known, are about moving templates between farms, content type hub complications and taxonomy snags. But there’s also another potential hitch that I myself unfortunately ran into a few months ago.

Property bag and Associated Groups

WSP template include parts of the template-site that you may not be aware of. By instance, the WSP template include property bag values. Applying a WSP template will overwrite the current property bag values on the site where it’s activated. This may in some cases lead to unexpected results.

The property bag is used to store all sorts of settings. Among these settings are a couple of references to SharePoint groups, the associated member, visitor and owner groups. Below is a picture of all the property bag values for a root web. If you look closely you will see three properties named vti_associatemembergroup, vti_associateownergroup and vti_associatevisitorgroup. These properties reference SharePoint groups. The value number is the id of a SharePoint group.

If the site the WSP template originate from and the site the template gets activated on has a different set of SharePoint groups (different ids) you may end up with broken references. This is because the references on the site where the template gets activated get overwritten by the references from the template, originating from the site the template was created from.

Below are the same set of property bag values after a WSP template has been activated. As you can see the property bag values has been overwritten.

This will corrupt the associated group’s properties on the web object and may cause you quite some headache. Your PowerShell script or code will throw you a simple null reference error when you try to utilize the group properties.

The simplest way to avoid this problem is to do everything in the correct order.

Apply the template.

Provision the associated groups, through code or the /_layouts/permsetup.aspx page.

Utilizing the web interface to create a site collection or web, apply the template accordingly and make sure you go through all the steps in the correct order will keep you out of trouble. The permsetup.aspx page will correct the corrupt group references in the property bag.

However, if you, like me, sometime prefer to create the site collection and provision the template through code or PowerShell and aren’t aware of this detail you may end up with corrupt references. You will probably not even see the consequences of this until much later, when it’s far more difficult to connect the dots.