Plan process for creating sites (SharePoint Foundation 2010)
Published: May 29, 2010
Some organizations need to maintain tight control over who can create sites, or when sites are created. Other organizations can allow users more access and freedom to create sites when needed. This article helps you determine which type of site creation process will fit your organization, and which method to use to implement that process.
In this article:
Determine who can create sites and a method for site creation
By default, new site collections (and therefore new top-level Web sites) can only be created by using Central Administration, which means that they can only be created by members of the Farm Administrators group. This behavior might suit your organization if you want your environment to be tightly controlled and managed, with only a few people allowed to add top-level sites. However, the default top-level site creation method might not suit your organization if you have any of the following requirements:
You want users to be able to easily create informal, perhaps even disposable, top-level sites, such as for short-term projects.
You want to create an informal space for team, group, or community interaction.
You are hosting top-level sites (either internally or externally) and want the process for requesting and receiving a top-level site to be as quick and low cost as possible.
There are several ways to allow users to create their own sites, while still maintaining some control over your environment. Consider which of the following methods will work best for your organization.
Self-Service Site Management In Central Administration, you can turn on Self-Service Site Management to allow users to create site collections under the /sites path (or other path you specify) within a particular Web application. This method is best used when you want to allow groups or communities to create sites. This method also works well if you are hosting sites and want to allow users to create sites without waiting for a complicated process. The sign-up page for Self-Service Site Management can be customized or replaced with a page that includes all of the information you might need to integrate with a billing system or to track custom metadata about the site at creation time. This method does not work well when large numbers of users need access to multiple sites. Because Self-Service Site Management creates site collections, which have separate permissions, users need to be added uniquely to different site collections. If you use subsites instead, the users can be inherited from the parent site in the site collection. Search works within a specific site collection. Therefore, if you want users to be able to find content across multiple sites, make the sites into subsites within a site collection.
Subsites of existing sites Limit users to creating subsites of existing sites, rather than new site collections and top-level sites. Any user who has the Full Control or Manage Hierarchy permission level on an existing site can create a subsite. This method is the most limited, because you still control how many site collections there are. Because the sites are always subsites of other sites, they can either be easy to organize (if there are just a few) or very difficult to organize and browse (for example, if everyone in your organization wants a subsite and they create them at different levels in the site collection's hierarchy, the site collection can soon become very difficult to navigate).
If you do not want users to have this capability, you can remove the Create Subsites right from the Full Control and Manage Hierarchy permission levels, either at the site collection or Web application level.
Keep in mind that none of these methods can control how much space each site takes up in your content databases. To control site sizes, you should use quotas and set a size limit for site collections. You cannot set individual size limits for subsites. For more information, see Plan site maintenance and management (SharePoint Foundation 2010).
Plan for Self-Service Site Management
Self-Service Site Management allows users to create and manage their own top-level Web sites automatically. When you turn on Self-Service Site Management for a Web application, users can create their own top-level Web sites under a specific path (by default, the /sites path). When turned on, this capability advertises itself with an announcement added to the top-level site at the root path of the Web application, so any users who have permission to view that announcement can follow the link.
If you want to use a path other than /sites for Self-Service Site Management, you must add the path as a wildcard inclusion. For more information, see Plan for collaboration sites (SharePoint Foundation 2010).
This capability can obviously affect the security for your Web server. Self-Service Site Management is disabled by default — you must turn on the feature to use it. You enable Self-Service Site Management for a single Web application at a time. If you want to use it on all Web applications in your server farm, you must enable it for every Web application individually.
If you enable Self-Service Site Management, you should consider the following:
Generally, you should require a secondary site collection administrator. Administrative alerts, such as those for when quotas are exceeded, or checking for unused Web sites, go to the primary and secondary administrators. Having more than one contact reduces administrator involvement with these sites because the secondary contact can perform required tasks even if the primary contact is not available.
Define a storage quota and set it as the default quota for the Web application.
Review the number of sites allowed per content database. Combined with quotas, this will help you limit the size of the databases in your system.
Enable unused Web site notifications, so that sites that are forgotten or no longer of value can be identified.
Because Self-Service Site Management creates new top-level Web sites on an existing Web application, any new sites automatically conform to the Web application's default quota settings, unused Web site notification settings, and other administrative policies.
Plan for custom site creation processes
You can, of course, create your own process for site creation by using a custom form to request a site that integrates with a back-end billing system to charge a customer's credit card or a corporate cost center. If you have a complicated system or process that you want to include as part of site creation, you should create a custom application to call the site creation interface and perform any other tasks you require. However, if you simply want to add a few custom fields to the site creation page (for example, to track which department in your company is requesting a particular site), you should consider using Self-Service Site Management and customize the sign-up page to include the information that you need. You can customize the scsignup.aspx page in the site definition to include the metadata that you need without having to develop an entire application.
For more information about building custom applications or editing pages in a site definition, see the SharePoint 2010 developer portal on MSDN (http://go.microsoft.com/fwlink/p/?LinkId=178818).
Use the following worksheet to plan the process for creating sites:
Site Creation and Maintenance Worksheet (http://go.microsoft.com/fwlink/?LinkId=193521)