Bill English

Single Post

Jan 17

Published: January 17, 2010 18:01 PM by Bill English Powered by: Mindsharp and Summit 7

I was working with the crew at DePaul University this past week and we talked for a while about the danger signs that would indicate the unhealthy use of a site collection. So I thought I'd share some of our conversation with you all. Many thanks to the talented team at DePaul University for their input in thinking through this with me.

Constant Need to Move Information Out of the Site Collection to Keep it Within Prescribed Database Ranges

This is actually a constant battle for several of our clients who must keep information for X number of years, but still need to have that information available for collaboration within the site collection. Recommendation: programmatically move the oldest information to a file server or other location so that the newest information can be developed and utilized within the site collection. Use Scopes in search to group the two locations together for fast retrieval of information.

URLs longer than 256 characters

We've know about this for some time, but it seems to me that URLs that are longer than 256 characters represent either a lack of good user education or an information structure that is too deep (or both). Wide, but more shallow site collections will help prevent this problem.

Lack of good end-user education

Despite what you might have heard, SharePoint is not entirely intuitive. Users need education, not only on how to use it, but also on how to use it within your environment (think Governance training here).

Installation of untested home-grown code

Note that I'm not against home-grown code being installed and utilized in your farm. What I'm against is untested code. Site collections with untested code = high potential for disaster. This was brought home (not by DePaul), but by our theoretical (and tangential) discussion of how much code should be tested in a lab before being deployed in production.

Wrongly Secured Information

I suspect that most people don't stop to think about the site collection owners having access to every document and list item within the site collection. If information is placed in a site collection to which the site collection owners should not have access, then you have wrongly secured that information. It should be moved to a site collection whose SC owners can and should be able to see the information.

There were more items we came up with, but this is all I can remember. Perhaps I'll get the rest of the list and post it here at some point. Thanks.

Bill English
MVP, Mindsharp

Comments

Single purpose for each site collection

While I'm sure this will not apply to all cases, I have found it helpful to use separate site collections for each business solution, i.e. each site collection has its own purpose. It took us a while to implement this, but now we have it has resolved many of the governance issues we were having. Some example solutions that are implemented are: General team collaboration (where users can request a team site using only out of the box features) Specific solutions for process automation (using workflows and dashboard features) Project sites (using custom site definitions) Corporate Intranet (used for publishing news and published documents to all staff - as well as provide the navigation to other solutions) Many other small solutions where the site collection admins are specific to the solution for security reasons. Using a separate solution per site collection has helped resolve quota issues, security issues, documentation issues (we now require a brief solution governance plan per solution) and migration issues (often moving from dev>test>prod can be done easily by exporting/importing the site collection. The biggest benefit is to allocate a business sponsor to each solution (who has a budget for changes etc) who can make most decisions that impact the solution independently from the other solutions. In some cases you can justify putting the solution in a separate web app or farm. I was encouraged to see that sandbox solutions (introduced in SP2010) use this idea of one solution per site collection.

Add Comment

* Required Field

Your Name *

Your Blog Url

Message Subject *

Message Body *