Thursday, April 10, 2008

Simplifying SharePoint Structure with Site Collections

Site Collections in SharePoint 2007 are the "pieces" of a web application. Personal sites (my site), for instance, are each a site collection. There are a couple of real benefits, too, for using many site collections--instead of multiple web applications--to form the bulk of your SharePoint implementation. SharePoint Maintenance On the whole, it's simpler to have few IIS web sites (and few web applications) and many site collections. This provides for fewer urls (and thus fewer IIS sites) and fewer ACLs (permissions) to maintain. The permissions piece, in particular, can become a real bear in a large SharePoint installation, as each piece of a web application and all of the pieces of all of its site collections can all have different permissions assigned to them. Using site collections as the primary content-delivery piece can simplify the permissions considerably. Backups/Restore Backups in SharePoint are a tricky business, partly because Microsoft gives you many ways to perform backups and recovery. The simplest solution for backing up your SharePoint installation is to do a farm-level backup, which gives you the option of restoring individual web applications. The downside to using lots of web applications, as most SharePoint administrators quickly discover, is that you end up with a multitude of IIS web sites. To create subdirectories within these sites, administrators create site collections within them, giving a pretty complex structure. Moreover, when you perform a web application backup, you have to restore the web application, which includes all of the site collections contained within it. That complicates the restore process quite a bit. Some implementations (particularly very large SharePoint sites) will benefit from the above scenario, but most people can get all the functionality and simpler administration by using site collections as the primary structural unit. Because you can backup and restore individual site collections, it allows you a lot more flexibility and granularity in your backup and restore strategy. Moreover, it happens from time to time that a web application configuration become corrupt, such that, for instance, the my sites functionality no longer works. If you have backed up the individual site collections from that web application, it is a trivial task to create a new web application and import the component site collections into it. Backing up site collections, however, does bring up a problem: because stsadm (the admin tool used to backup site collections) requires a site collection url as a command line parameter, there's not an out-of-the-box way to backup all site collections in one fell swoop. Happily, this problem has been recognized by many competent scripting folks. The script we use is a modified version of the one posted by Mauro Cardarelli on his blog. It runs through all of the site collections in a given url and backs them all up individually. Note that, should you use this script, it was written for SharePoint 2003, and as a result, the path to the stsadm executable needs to be updated from C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN\stsadm to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.

No comments:

Post a Comment

Thanks for leaving a comment!