SharePoint Terminologies and Hierarchy
Following diagram illustrates the SharePoint hierarchy:
Web Application, Site Collection and Sub-Site
The following points are to be considered when deciding on an extranet site structure and usage of SharePoint Components.
· Administration Overhead
· Scalability
· Upgrade Scope
· Backup/Restore
· Security
· Search Settings
· Audit/IRM Settings
· Feature Scope
· Recycle Bin
· Usage Reporting
· Branding
· Navigation
· Content Rollup and Aggregation
· Content Type / Site Column Scope
Backup and Restore
· Full fidelity backups are only possible at the site collection level
· If a sub-site needs to be restored then the entire site collection must be restored
· 3rd party solutions offer full fidelity recovery at more granular levels
Security
· Site Collections allow security groups and permissions to be isolated from other site collections
· Management is more complex with site collections
· Difficult to see what access a user has across site collections
· No OOTB way to synchronize settings across site collections
· Usage of Site collections can reduce the need to break security inheritance
· Site Collections can be used to overcome SharePoint group limitations (Cannot go over 2000 users or AD groups in a single ACL)
Feature Scope
· Features can be scoped to a Site Collection or Web (or Farm or Web Application)
· You can prevent access to certain functionality by using site collections
o Some Features must be scoped to a site collection
o You might have to activate a Feature thereby (potentially) making functionality available to all users/contributors/designers of a site
Search
· Search Scopes are defined at the site collection level (You can create shared scopes via the SSP but they must be “activated” at each site collection)
· Best bets and keywords are site collection scoped (Use a single search centre)
· Settings must be manually (or programmatically) synchronized across site collections
Scalability
The single most critical reason for using multiple site collections is scalability
· Limit content databases to 100GB (50GB recommended, 100GB maximum)
· If you must go over 100GB then use only 1 site collection in the content database
· You will encounter performance issues and possibly deadlock conditions (if over 100GB)
· Split content approaching 100GB in a site collection into a new site collection in a separate content database (STSADM)
· Site collections cannot live across content databases
· Web applications can have multiple content databases attached to them
Reporting
· Usage reports are scoped at the site collection
· There is no out of the box mechanism to get cross site collection usage reports
o SSP administrators can get search query reports which span site collections
· Many 3rd party products produce much more useful/sophisticated reports for cross site collection reporting
Branding
· Master pages and CSS can be used to enforce a consistent branding experience
· Use Themes for as much as possible so that the application/system pages will be branded
· Use Feature Stapling to automatically apply the branding. This provides a seamless experience for the end-user
Content Types / Site Columns
- Features could be used to deploy to consistent Content Type and Site Columns across multiple Site Collections
- It is important that the Content Type ID remains the same – creation via the browser does not allow setting the ID across site collections
Cross Site Configuration
- Solution Accelerator from MSFT (http://www.codeplex.com/SPConfigurator)
- The tool automates the process of deploying site settings in all or selected sites in a server farm:
- Applying Master Pages across a SharePoint server farm
- Setting up Web Titles for all or selected site collections across the farm
- Applying audit control settings to all or selected sites
- Adding advanced settings such as “Allow content type management” to all types of lists
- Adding a new Expiration Policy at the site collection level
- Adding a new Expiration Policy to content types, lists, and documents