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.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: