Go to page: 1 2 3  Printer Friendly Version

Site Collections and Security

Security is substantially more flexible in V3 than it was in V2. However, with that being said it's not infinitely more flexible and not every configuration is supported within a site collection or site. For instance, the site collection administrator has access to everything in the site collection and there is no way to turn that off. Similarly turning Anonymous access or auditing on or off is done at a site collection level. Little issues like this may push you into splitting content into two or more site collections.

Search Settings

The site collection is also a substantial boundary when it comes to setting up search. Search keywords, best bets, and search scopes are all set at the site collection level. If you're customizing search for a set of users it may be necessary to set best bets, keywords or scopes. If you want to limit the scope of the best bets, or have a different set of search scopes you'll need to break things into their own site collection.

Site Collection Quotas

Another reason why you might need to split into multiple site collections is the need to manage storage quotas at a more granular level. Storage quotas are implemented at a site collection level within SharePoint. So you can say that a single sight collection can't grow to more than 10GB -- but you can't specify a quota for a single sub-site, document library, or folder. That means that if you need to control individual storage quotas you're going to have to break apart into smaller site collections.

The Contrary View

The contrary view is a good one -- everything in its own site collection. This is a valid way to approach the problem. It does, however, create some extra work for the business trying to use SharePoint in two specific areas: navigation and rollup.

One of the hidden benefits of a one site collection approach is that SharePoint will manage all of the navigation for you. As you nest sites, SharePoint provides navigation between them. In fact, SharePoint will maintain breadcrumbs all the way down the site hierarchy. When you're using separate site collections, navigation can't be built for you automatically. You'll have to stitch the sites together by yourself.

The other problem, is that the "rollup" web parts in SharePoint, perhaps most notably the content query web part, works only within a site collection boundary. That means that you'll have to find or develop your own solution if your users want to roll up content from across site collection boundaries -- or you'll have to keep everything that they want to query in one site collection.

Since rarely do you know exactly how users will use their site collections it's often hard to know if you should allocate a single site collection -- or several site collections.

Merging and Breaking-up Site Collections

The good news is that if you make a mistake and have things in one site collection that should be split or items from multiple site collections to be merged it is possible to move sites around. The bad news is that it's based off of the content migration API -- a.k.a. PRIME. PRIME is a brand new API so it has more than its fair share of quirks. PRIME also doesn't move workflows (not even workflow template associations), alerts, or the recycle bin. In addition, PRIME takes non-trivial resources from the server on which it's run. The packaging process for PRIME isn't trivial as evidenced by the fact that exporting a site generates at least 50 lines of status messages and a log file.

Ultimately the out of box solution is workable if you need to make a small set of changes and can do extensive testing after the migration.

Go to page: 1 2 3  Printer Friendly Version