Designing Your Site Structure

If you start your site development by planning your site structure, the growth of your SharePoint environment will be logical to your users and administrators. A well-planned hierarchy of sites provides the following advantages:

• Security inheritance: Sites that are grouped together so that the subsites can inherit the site groups from the parent sites lessen the time spent on security administration. If you can manage the membership of the site group on one site and then use those site groups on multiple sites, the membership is more likely to be maintained accurately and consistently than if you are maintaining the groups in multiple sites.

• Autonomy for teams and divisions: Creating autonomous branches for unique teams and/or divisions allow them to work independently and add content and columns without affecting other teams and divisions.

• Logical navigation: The navigation provided with SharePoint 2007 relies to a great degree on breadcrumbs that show you the entire path from your site to the top-level of the portal. By organizing your site structure, this breadcrumb navigation will be more useful to your users.

• Aggregation of data: A common requirement for organizations is that content is published in just one location and then displayed in every location pertinent to that content or topic. For example, you can publish a team document that your team members will share, but this content should also be available to be displayed at a division and enterprise level. If your site hierarchy is well constructed, this aggregation of data is possible.

In the following sections, we walk you through the steps necessary to create a well-organized and effective site structure.

Defining site-related terms

Whether you have worked extensively with SharePoint or other portal technology before, several of the site-related terms used to describe sites and their attributes may already mean something to you. These terms are defined in this section in order to eliminate any confusion caused by different interpretations of terminology.

• Portal: A portal is a central Web site that can be used to organize and distribute company information. For SharePoint technologies, MOSS has the necessary features to aggregate company information and WSS does not (for example, audiences and user profiles and enterprise search).

• Metadata: Data used to describe content contained in a library or list. For example, you can add a metadata column to a document library that requires users to provide the document status such as draft, in review, or final when they upload a document.

• Top-level site: This site is at the root of your sites. This site has sub-sites but is not a sub-site of another site.

• Namespace: This is the name that you use to address your top-level site. This name could be a host name or a fully qualified domain name (FQDN) and should be a persistent name (changed rarely) to help avoid confusing users of the portal and sites by changing URLs too often. For example, if you have a division-level intranet portal for human resources, this name would be http://hr, or if you have an extranet portal for your company, the namespace would be http://extranet.company.com.

• Site Collection: A site collection defines a boundary between SharePoint sites. Within a site collection you can share navigation, site groups, content (using the content query Web Part or dataview Web Part), and workflows with other sites in the collection.

  Cross-Ref

  See Chapter 5 for more information on Web Parts.

  
  

• Taxonomy: The classification that you design to divide your organization (or portion of the organization) into logical sections that users will understand.

Planning your top-level sites

You can think of top-level sites as sites that require their own namespace. This could be based on your organizational structure, the scope of the namespace (intranet or extranet or Internet), or the purpose of the site (document collaboration site or records management site). Working with the key stakeholders (IT leaders, interested parties from each division, and internet/extranet publishers) in your company, you must determine which of the following items need to have their own namespace:

• Divisions: Can all divisions share the same namespace such as http://portal for intranet collaboration? If not, what division-level namespaces do you need?

• Projects: Are there any projects or initiatives within your organization that require their own namespace? You should only create portals based on projects if the projects are long term because namespace choices should be persistent.

• Central portal: If you have chosen to create smaller portals for your organization, you should create a central portal that can pull all your overall organizational content into one location.

• Extranet: If you are planning extranet collaboration with partners and customers, we recommend a separate namespace from your intranet content so that internal users are clear where they are posting content. It is less likely that users will accidentally post internal-only content to the extranet namespace.

• Team spaces: Do you want to have a namespace for self-service site creation? If you have teams that will be creating collaboration sites that are not logically related to any of your division, creating a separate namespace for self-service sites is recommended.

• Specific purpose sites: Do you need separate namespaces to support specific applications or purposes? Examples of these applications are portals for staging Web content or Excel servers or project servers.

As you make the namespace decisions, keep in mind that these sites need their own URL. If what you or your users want is a friendly name for a site that resolves to a URL that is part of a different namespace, you should use a redirect to support that friendly name. Resolving http://IT to a site that is located on http://portal/IT is not a namespace but instead a friendly name. See the section “Implementing Your Site Structure” later in this chapter for instructions on how to implement a friendly name redirect.

Defining site collections and site maintenance policies

After you have defined your top-level sites, you need to define the site collections for each top-level site and the maintenance policies that will be applied to them. Site collections isolate content into logical groupings and maintenance policies to help manage their usage and life cycle.

Defining site collections

As defined earlier, site collections are divisions of security, content, and navigation, so your decision to create multiple site collections involves creating more autonomous sites. Your top-level site is a site collection, so you must create more site collections in that namespace. To decide whether you need additional site collections, consider the following factors:

• Security: You can use site security groups across a site collection to ease administration. These are the visitors, members, and owners groups created by SharePoint, or any custom groups that you define for the site collection. If a portion of your site has unique security requirements, it is a good candidate for a new site collection.

• Portability/Administration: Site collections are easy to package up and move (between portals and other top-level sites) and backup/restore at a site level (or sites and sub-sites within the site collection). If you need these capabilities for portions of your top-level site, consider making site collections to match the portions of your site that may need to move.

• Navigation: Within a site collection, you can choose to use the global navigation from the parent site or not. However, you do not have this choice if you are in a different site collection. When creating site collections, keep in mind that navigation to other site collections will not be possible using the out-of-the-box navigation.

• Self-service site creation: Most site collections are created by the top-level site administrators. However, when you turn on self-service site creation, all sites that users of this feature create will be site collections. The idea behind this is that the self-service user should be an island that is separated from the other self-service users. Self-service sites are great for users that create their own sites for team, project, or community interaction. These sites may or may not be persistent within the organization, but because they are end user driven as opposed to information architecture driven, they should be isolated from each other in site collections.

Defining site maintenance policies

Site maintenance policies help you manage the growth and content for your site collections, especially the site collections created by end users that may not have a lot of administrator oversight or visibility. SharePoint provides two tools to manage site collections:

• Site collection quotas: You can create one or more quotas that limit the size (measured in MB) of site collections.

• Site use confirmation and deletion: To help eliminate sites that might be forgotten or abandoned, SharePoint monitors sites and notifies the site owner when the sites are not used; if this option is selected, SharePoint can also delete the site if no action is taken after notification. Site use and confirmation parameters are defined for each Web application.

Although both tools help you manage SharePoint space utilization, they have different roles in the SharePoint life cycle. The site collection quotas help more with planning the growth of your SharePoint storage, whereas the use confirmation and deletion policy helps you reclaim unused space.

Creating site collection quotas

When created, site collection quotas are applied to site collections. However, you can change the template applied to site collections after the site collections are created by using the central administration console. To start, you define the site quotas for your organization:

1.

List the site quotas that you need. Site collections vary on uses and content and therefore most likely require different quotas.

2.

For each of the site quotas, determine the warning size and maximum size for the site collection. The difference between the warning size and the maximum size should be a reasonable number so that the site collection owner has time to react to the warning before the maximum is reached. For example, if your warning size is 80MB and the maximum size is 81MB, the 1MB difference will probably be met and exceeded before the site collection owner has time to take an action from the warning.

To create a site quota:

1.	Open SharePoint Central Administration and select the Application Management tab.
2.	Click Quota templates in the SharePoint Site Management section.
3.	Select Create a new quota template and provide a new template name.
4.	Enter your maximum size in MB and size for when an e-mail warning is sent in MB.
5.	Click OK.
6.	Repeat Steps 1 to 5 for all templates that you have defined.

To apply a site quota to a site collection after it has been created:

1.	Open SharePoint Central Administration and select the Application Management tab.
2.	Click Site collection quotas and locks in the SharePoint Site Management section.
3.	Select the site collection to which you would like to apply or modify the quota template from the Site Collection pull-down menu.
4.	Select the desired quota template in the Current quota template pull-down menu.
5.	Click OK.

Defining site use confirmation and deletion parameters

Of course, if you are an IT administrator, you hope that users delete their collaboration sites when the sites are no longer necessary. However, this does not always happen because users often think they might need the information later or that others are still possibly accessing the data.

To manage unused sites, SharePoint allows you to create site use confirmation and deletion policies at the Web application level. These policies allow you to define:

• How often to ask users to confirm that their site is still in use: This parameter lets you set the number of days after the site is created or confirmed to still be in use to contact the site owner for confirmation. This number should reflect the duration of a typical project life cycle in your organization. The default is 90 days but that probably is low for most organizations. Setting this to 180 days is a pretty reasonable interval so that users get prompted for a use confirmation two times a year.

• How often to check for unused sites and send e-mails: You can set the interval (daily, weekly, or monthly) and hour for when usage processing should take place.

• Whether to automatically delete sites if use is not confirmed: You can select whether you want SharePoint to delete sites if they are not confirmed to be in use (site collections are presented with a URL to click if the site owners want to confirm that the site is in use). If you do automatically delete, you tell SharePoint how many notices to send before the deletion. So, if you select to delete after four notices and the notices are processed weekly, the user will have four weeks to confirm that the site is in use. Make sure that the users have plenty of time, otherwise someone could come back from vacation to find his or her inbox filled with site notices and a deleted SharePoint site.

After you have determined the appropriate parameters for your organization, you can configure the site use confirmation and deletion policies by following these steps:

1.	Open SharePoint Central Administration and select the Application Management tab.
2.	Click Site Use Confirmation and Deletion in the SharePoint Site Management section.
3.	From the Web Application pull-down menu, select the Web application to which you would like to apply or modify the site use confirmation and deletion settings.
4.	Select the Send e-mail notifications to owners of unused site collections check box and enter the number of days after creation or confirmation that you want notifications sent.
5.	Select the period (daily, weekly, monthly) and hour that you want notifications to be processed and sent.
6.	If appropriate for your organization, select the Automatically delete the site collection if use is not confirmed check box and enter the number of notices that you want to be sent.
7.	Click OK.