Site Collection Provisioning: meta-data

For some types of sites it makes sense to have additional meta-data. If you have a project site, the presence of a project number or charge code would allow the system to fetch information from other systems and display it to the user. It’s also important to enforce this no matter how the site was created. If the site was created from a third party tool, the first time a user accesses the site, they should be prompted for filling in the required information.

Our way of solving this involves a number of components.

The first step is to create a meta-data page where users can edit whatever is relevant for their site. Different types of sites will have different types of data, so a flexible approach is needed.

With the Mystery Foundation you get a meta-data page. This is a simple application page with space for a delegate control.

The information about the owner is generic for all types of sites, whilst the project information is specific for a type of site. You can use the delegate control to add additional information to this page.

The control that you implement must implement the interface Mystery.SharePoint.ISiteMetadataControl. This will handle sending information between the page and the back-end storage.

The next step for handling meta-data is to capture it somewhere.

We have a feature, SPM.MetadataRequired, that sets the provider used to capture the data. This feature will also add a site action link under site settings that takes you to the meta-data page. The object used as the provider must inherit from Mystery.SharePoint.SiteMetadata. Your custom type will be passed to the ISiteMetadataControl methods.

Access to your meta-data can be achieved using the following method. Specify the type you want returned; it can either be your inherited type or a base type.

Now that you have wired up the meta-data handling, you  have to ensure that any required data is filled in. Remember that the site may have been created in many different ways; central admin, PowerShell, custom site collection provision UI, third party tool, etc.

The only reliable way to handle all these scenarios is when the user accesses the site for the first time. The most elegant way is to use a delegate control that redirects you to the meta-data page. Ensure that the  SPM.MetadataRedirect feature is activated as part of your web template.

When the user has filled in the required information, the feature will be deactivated, so on subsequent visits, things work as normal.  Using a delegate control only adds an overhead until information has been added. If you add some logic to the master page, the overhead will be incurred on every page visit to the site.


Site collection provisioning

When you have reached the decision to use multiple site collections, you need to think about a number of things.

  • Who should be able to provision site collections?
  • Should only a predefined set of templates be available in the web application?
  • From where will provisioning take  place? Web UI, PowerShell, third party tools?
  • How do you manage users across all these site collections?
  • Who should be the site collection administrators of the new site collection?
  • What type of approval system should be in place?
  • How does one determine when a site collection is no longer in use so that the space can be reclaimed?
  • Does the site collection require any additional meta-data?
  • What Quota should be applied to the site collection?

The Mystery foundation contains functionality that helps solve a number of these issues. I haven’t solved all of the them yet, but I’m working on it.

The current solution consists of the following components:

  • A custom application page that allows users to provision site collections
  • An object to store various configuration data:  Mystery.SharePoint.SiteProvisioningSettings.
  • A timer job that handles various site administration tasks:  Mystery.SharePoint.SiteManagementJob

Custom page:

Standard page:

Deciding what data to capture

Comparing these two pages, they are very similar in what data they capture; this is by design. The values captured here is basically the information needed to create a site no matter how you do it; Web UI, PowerShell, Object model. When you operate in a UI world, it’s easy to go overboard and ask for all sorts of additional information. It works great as long as you control the  UI, but the day you need to create 100 sites from a third party tool, you get problems. Better to plan for it from the start because you never know what is coming around the next corner.

Limiting the number of templates

One of the major difference between the standard and custom page are the number of available templates. You probably don’t want to allow everybody to create any type of site.  The standard page has no way of limiting the selection, so you will have to roll out your own or use the one we provide.

One of the values stored in the SiteProvisionSettings is a list over what templates should be made available. A custom developed web template picker uses this information to present the reduced selection.  The SiteProvisionSettings object can be retrieved and updated using the Get-SPMSiteProvisioningSettings PowerShell Cmdlet.

Limiting the user that may provision sites

One of the other settings in the SiteProvisionSettings is a list of Authentication providers and the active authentication provider. This is an extensible framework, so you can create your own. Just implement Mystery.SharePoint.ISiteProvisioningAuthenticationProvider and register it using PowerShell. The package contains two authentication providers; one that allows anybody to create site collections, the other only allows members of the root site collection to provision them.

User management

When you have a system with multiple site collections, handling users becomes an issue.  Most companies are all about sharing information. The moment you create a new site collection, you create a new security container that by default doesn’t allow everybody access. This goes against the information sharing aspect. In order to overcome this, we have included a site scoped feature SPM.SynchronizeVisitors. If this feature is activated, all the members of the visitor group at the root site collection will be copied to the visitor group of the provisioned site collection. The timer job will make sure that it’s up to date every time it runs. If you have certain types of sites that shouldn’t be available to everyone or want to turn it off, just deactivate the feature and you can control your visitor group manually.

Another area the can cause issues is the site collection administrators. These have to be added individually to a site collection; you cannot specify an active directory group. Certain people should probably have access to all site collection. Keeping this updated across 100s of site collections is a challenge. The site collection feature SPM.SynchronizeAdmin will behave in same way as the visitor synchronization. Activate it based on your needs.

When a user requests a new site collection, do you want them to become a site collection administrator? With this comes a lot of power; are they ready for it? If you want to give people this level of power, make sure that the site collection feature  SPM.OwnerRemainsAdmin remains activated. If this is not activated, the user that requested the site collection will no longer remain and administrator, but rather become a normal owner.

Quota assignment

Major corporations will require a set of different site types. i.e. Projects and Departments. In order to prevent information overflow, they may want to limit the amount of data in each site collection.  The storage needs for a project is probably very different from a department, so it’s not unlikely that they will use different quotas. How does one ensure a different quota is applied for different site collections?

One of the things to be aware of is that you can only change the quota a site collection uses if you are running as a farm administrator. This means that we cannot update our site collection immediately. We have to tell the system what quota we should be using, and then have the timer job set the actual quota. This allows the site to have a free quota for a period of time, but chances of them exceeding it before it is enforced is rather slim.

In order to leverage the quota management, make sure that you activate the SPM.QuotaAdmin feature as part of your web template.

The value specified as the default template will be assigned by the timer job. This feature will also give owners an overview over how much space their site is consuming. A notification bar will also be presented when the storage space approaches critical limits.

(in this sample I adjusted the quota after adding content, hence the 112% usage)

Additional meta-data

Some types of site collections may require additional meta-data.  I.e. a project site may need a project number so that it can use this to fetch data and display data from additional systems. SharePoint doesn’t natively support site collection meta-data, so we have to create our own system. A more detailed description on how one can create such a system will be left for a future blog post.