New Medical Condition: SharePointea Sitecollectionfearophobia

You may not have heard of this serious medical condition, but it exists in most people. It is the irrational fear of SharePoint Site Collections (and particularly Self Service Site Creation). The primary driver for this fear is that allowing people to create site collections will “prevent my ability to manage the environment effectively.”  This is pretty ironic, all things considered. Lets compare:

So… from a manageability standpoint, the Site Collection wins. Granted, the Plan for Software Boundaries TechNet article clearly documents the “limit” of 50,000 site collections per content database vs. 250,000 webs per site collection… but if you’re also following the recommendation on content database size, you’re never going to hit either of these “limits” anyway.

In a strange twist of irony, many people seem much more comfortable providing users with the “Full Control” that comes with being either Site Collection Administrator or in the default Owner group. This is ironic because in the process of trying to maintain some sense of control, they’re allowing their users to do things like create unlimited subsites (that they can’t separate or move between databases) on virtually any number of nested paths, allowing permissions to inherit throughout the site collection (occasionally leading to permissions that weren’t planned), and allowing users to activate various features, use SharePoint Designer, and any number of things that are good features implemented badly.

Rather than let everyone create everything everywhere in ways that can’t be reported on, managed, backed up, or migrated, go ahead and turn on Self Service Site Creation and let the Site Directory be your guide!

There are some recommendations that go along with this though:

• Create some managed paths that these sites can be created in. The default “/sites/” path is fine for smaller organizations, but can create some difficulty once a lot of sites have been created with people wanting to use URLs that are already taken. I prefer the following structure: (this is somewhat repeated from this post)
  • The “Root” site collection (“/”): This is the intranet homepage, or at least the entry point into SharePoint. It exposes at least search and the site directory, and is the primary means of navigating to all of the site collections in the application. Preferably, the Collaboration Portal template is used for this site.
  • a Teams managed path (“/teams/”): In this universe, subsites aren’t created. This also means that the org structure does NOT match the URL path for teams. This is a pretty big change for most environments… but realize that just because I’m on my managers team does not necessarily mean I’m a direct member of my manager’s manager’s team (if that were true, we’d all have access to the CEO’s team site… which we don’t). You’re on your manager’s team, and your manager is on their manager’s team, and all teams are created at the same level… /teams/MyManager and /teams/TheirManager, for example. This also means that if reporting structures change, the sites and URLs stay exactly where they are! You’re insulated from organizational changes!
  • a “Projects” managed path (“/projects/”): Only projects… that is, something with a begin date, start date, deliverable, and generally a schedule, will be created in this path. This also means that after a project is completed, it is easy to backup the site collection and either delete it, move it to less expensive storage, or archive it. This also means that if the project owner/sponsor changes, the site and URL stay exactly where it is! You’re again insulated from organizational changes!
  • a “Programs” managed path (“/programs/”): The programs managed path is designed to support long running service-type offerings. For example, a company’s Education Assistance program offers a service rather than a specific deliverable. This path allows for the creation of site collections that are a group of people that work together to make this service or program work, ignoring organizational hierarchy, and without a specific end-date in mind.
• Use or create a governance tool/feature for cross-site-collection compliance and default configuration. A great example of this is here from Microsoft IT. In particular, pay attention to:
  • Master Pages
  • Site Collection Content Types/Columns/Values
  • Permission Levels (FULL CONTROL IS EVIL! Create a new “Manager” level that matches Contributor, but grants basic items like Override Check-Out instead of Full Control)
  • Group membership/creation (a “Site Manager” instead of Owner is a great idea, granted the “Manager” permission level above)
  • Version/Audit/Policy settings
  • (optional) Revoke “Create Sub-Site” in the permission levels or permissions mask for the web application. This can have the unintentional side effect of preventing meeting workspaces from being created, but a workaround is listed in the first comment.
• Use the Site Directory, enforcing listing, attributes, and activate nightly link validation. It is particularly important to ensure the attributes/columns used in the Site Directory reflect how your users might want to locate sites they’re interested in.
• Use Search web parts, custom scopes, and managed properties to allow content to appear from various site collections. Remember that search results are automatically security trimmed… so if I display a search web part that only shows sites (a bit of extra work) I have access to, and place that on the homepage, I’ve made my own personal site directory!

Yes, this is more initial work… but it is a LOT easier than what I usually hear: “Our site collection is too large, unwieldy, and we need to split it up and we’re not sure how that’s going to work!”.

Go ahead… enable SSSC… done right, it’s much easier to manage than you might think.