This is the next in a series of articles addressing core SharePoint implementation topics. I hope that this is valuable to both groups looking to implement SharePoint for the first time as well as groups planning planning for an upgrade or migration to SharePoint 2010.
A Series of Containers
I tend to think about SharePoint from a container perspective. Each of the containers has a set of settings and features that can be configured and administered for all of the containers within. It is important to understand the boundaries of each level so that you can create a site topology that meets all of your objectives. I’ll cover a sub-set of these I typically consider while planning the site topology. The containers I’m going to address include:
Farm – In the context of this article, all of the Applications, Site Collections, and Sites hosted by one or more connected SharePoint servers. I say “connected” because it is possible, and fairly likely that most organizations will have more than one Farm (Dev, Staging, Production for things like Intranet, Extranet, Internet, etc). A farm has one or more content Applications plus additional applications for things like Central Administration.
Application – An application would be the top level address which maps to an application in IIS. For example http://sharepoint. An application has one or more Site Collections. The application level is also the level where you have the opportunity to identify one or more content databases for storing the content on the SQL server.
Site Collection – A site collection has one or more Sites also referred to as Webs or Sub-Sites.
Sub-Sites or Webs – This is the smallest container which resides under and can be managed by the Site Collection.
Types of Content
The first step is identify what types of content or site(s) you expect to host.
- Company or Divisional Portal(s)
- Web Content Management (Publishing)
- Electronic Content Management (Document Management)
- Business Intelligence
- Project Management
- Team Collaboration
- Application Hosting
Not all of those types of content apply to every organization, but it should be pretty clear that the content, the update frequency and the manner in which it is used and managed can vary quite a bit from type to type.
Considerations of Multiple Applications
Very small companies or workgroups may be able to get by with all of the types of content hosted in a single Application, but for anything larger there should be plans to segment it to multiple Applications in the farm.
Here are some considerations when using multiple Applications:
Authentication Model – What type of authorization model will be used?
Options include Anonymous, Windows Integration (NTLM or Kerberos), and Forms Based Authentication (FBA). Since an Application can only support a single authorization mode, that can dictate additional applications.
Edit: Anders Rask was kind enough to point out some changes to the authorization model in 2010 that make the previous statements incorrect.
In 2007: Options include Anonymous, Windows Integration (NTLM or Kerberos), and Forms Based Authentication (FBA). Since an Application can only support a single authorization mode, that can dictate additional applications.
In 2010: There are two high level options; Classic which supports Windows Authentication only and Claims Based which supports one or more different providers. Additional information can be found on TechNet’s article Plan Authentication Methods.
Sessions – When a user visits an application a session is created. It is important to understand that their session is for a specific IIS Application so if they visit the main company portal and then click to see the MySite they may be asked to authenticate again. With Anonymous this should not be an issue. With Windows Integrated this should not be an issue if 1) users are using Internet Explorer 2) they access the site(s) with the same account they use to access their computer and 3) their browser is properly configured to pass logged on user information.
Application Scoped Solutions – Solutions can be scoped to specific Applications which can provide some flexibility in deploying new features. In a large environment it is important to only show features to the areas where they apply.
Considerations for Site Collections
The site collection has some important boundaries to consider when deciding to use one versus multiple site collections. They include:
Amount of Data – It is important to keep your site collections at a maintainable level. There is no hard limit, but as Site Collections grow over 40GB they can get more difficult to maintain and will take longer to restore. SQL Server tuning becomes more critical with larger databases. It is a good idea to segment your content across multiple site collections (and across multiple content databases) in a manner that makes sense.
SharePoint Groups – SharePoint Groups can be a good way to organize users, especially when they do not map to functional areas or groups otherwise managed in Active Directory. These groups are defined and contained within a given Site Collection which means if you want to use them in multiple site collections they have to be duplicated and maintained separately which can be problematic.
Site Collection Administrator – A site collection administrator has great power and control within the site collection container. A Site Collection administrator can choose themes, manage all security within the site collection, manage activated solutions and potentially deploy other customizations if policy permits. Enabling content owners should be a top priority, and the Site Collection provides a good container for that.
Quota Management – Quotas are set at the Site Collection level so if granular quota management is required for billing or charge back purposes it may have some impact on how site collections are segmented.
Navigation – The default SharePoint navigation provider does not span site collections (and therefore applications) which can make a standardized or unified navigation scheme difficult to maintain. This tends to work fine for team collaboration sites, but can be cumbersome when you need to link many site collections.
Content Types – I think Content Types were one of the most important changes introduced with WSS 3.0 and MOSS. An entire overview of content types is outside the scope of this article, but keep in mind that within the current release Content Types are created and maintained within a Site Collection. If a Content Type applies to multiple site collections then it needs to be duplicated. SharePoint 2010 will support farm level content types which will remove the need to duplicate them.
Profiles (WSS Only) – If you are using WSS it is important to understand that the profiles are stored at the Site Collection level. If you add custom attributes they will need to be added to all site collections they apply to.
Implications on Backup and Recovery
There are a few different methods to backup and recover SharePoint content. Within the context of this article it is important to understand the difference between the commands that stsadm provides.
Site Collection Backup and Restore – Considering the boundaries previously discussed, there is a lot of extra content stored in the top level site of a site collection. Doing an stsadm backup will provide a high fidelity snapshot of the content, configuration, workflows, and other customizations. It is important to note that if you are moving the site collection between applications or farms that you will need to install any solutions or dependencies referenced in the current location.
Sub-Site or Web Export and Import – The Export process offered for Sub-Sites is great for archiving, but it does not provide the fidelity needed to move sites around. It will not save workflow, features, solutions or alerts. I’ve also had inconsistent results with DataViews on sites being migrated in this manner.
If you think you will need to migrate the content or want flexibility, it would be in your best interest to consider using more Site Collections rather than deeply nested Sub-Sites.
Upgrade and Migration Considerations
The purpose and content within a site collection or site can evolve over time. Some sites that started very narrow in purpose may change and now warrant their own Site Collection or Application. When preparing for a migration or upgrade it is a good time to run through this exercise again to validate the assumptions and decisions that were previously made or overlooked. While it may make the move more difficult the changes will pay dividends over the coming years offering a system better tuned to the user’s needs and more maintainable by the site owners and farm administrators.