How To Do SharePoint Collaboration in the Absence of Proper Governance

Written by Daniel Brunet, Senior Microsoft Premier Field Engineer.

In my previous post, I explained the goal of this series of articles is to help farm administrators make decisions when they have to maintain one or multiple SharePoint farms without governance.  One of the most challenging service offerings with SharePoint besides Content Management is Collaboration, as it usually needs both flexibility and scalability.

Whenever a portal, intranet or other specific enterprise application is built, there is usually a project associated with it. That means there’s a specific deliverable expected with specified time frames, guidelines and the participation of a development team and/or a partner. Some boundaries and rules are defined and usually the maintenance is fairly easy.

Strangely enough, in many cases Collaboration does not follow that model. For the lucky ones that did build an application with SharePoint before doing Collaboration, they usually do it the right way. But when an organization starts using SharePoint as a Collaboration platform, this is where I see many misses and improper preparation. At that point, SharePoint is used for anything and everything which creates issues in both the medium and long term. This is also where the confusion resides about SharePoint being a full application that does not require development. It may be true with basic Collaboration, but surely not in application deliveries.

So in this post, I’ll focus on what we do with Collaboration and how to properly prepare. I’ll also highlight some exceptions to the rule.

In my previous post, I talked about the SharePoint services pie graph. Collaboration usually sits in the Sites and Communities slices. It had its own slice in the 2007 version of the chart.

Another very useful graphic, shown below,  is the Intranet Pyramid Model. This comes from the Office SharePoint Server 2007 Governance Checklist Guide.

In this pyramid, Collaboration can be referenced in the Projects & Workspaces and Groups & Teams layers.

As you can see, because Collaboration sits in the middle, the rules are often mixed. Manageability may be less rigorous than a portal, life cycle will be a mix of temporary and permanent sites, ownership will vary and type of access will be a mix of read and write.

Governance on Collaboration will be focus on site creation and quotas. In term of security, this is where I will see more variants. Some organization will give real ownership of sites as others will simply lock functionalities and rights. Also, it is the area where decisions about SharePoint Designer are the most difficult.

Before we continue, here’s my latest version of the content organization decision matrix for SharePoint 2010.  Resources and details are culled from this article.

Ok, so let’s examine a “bad case” scenario that I’ve seen in some large organizations.

You’ve been ask to install SharePoint and you will be the one that maintains it. You are now the SharePoint Subject Matter Expert who has to deal with everything from the farm setup to the document library creation. At this point, the team is composed of you and maybe another person. Site and resource governance is not on the road map.

You also start to receive site creation requests on a regular basis, and depending on how you work and your organization, you will ask questions or just deliver them.

What you need here, because of the unknown, is to put some boundaries and rules in place. This way, you will keep your options open for the future and will help yourself as much as your organization.

Rule 1: Use Site Collections and Quotas

When you deliver the requested site, you should create a site collection and not a sub site. You will also apply a quotato it. Quota size will depend on your available SQL space and size of the organization. If you are unsure, give between 1 to 5 GB.

You may say that isn’t much, but I’ll explain later when and how to increase that size.

Rule 2: Apply limits on the number of versions of list items and document libraries .

By default, it is unlimited and can increase your content size significantly and/or have your organization reach their quotas too quickly.

Rule 3: Ask Questions, Use a Form

You might be surprised what a group can do with SharePoint and SharePoint Designer. I’ve seen business critical application pop out of nowhere in what was supposed to be a SharePoint trial farm.  Get ahead of this.  You will better understand what types of services your organization are expecting from SharePoint when people fill in a form or survey, .

So what type of questions should you ask?

Purpose:

• E.g.: Project, Team workspace, Rapid application creation like forms and custom lists, etc….
• Site Life cycle: Ad Hoc, Permanent
• Confidentiality level  (*Some types of site should not be hosted on a collaboration platform)
• Portal
• Large content management
• Enterprise wide applications

People and Traffic:

• How many contributors
• Target Audience (how many readers; e.g. small group, departmental, enterprise wide)
• Expected daily requests and unique users
• Security (Use the target Audience question to define your decision)
  • AD or SP Groups
  • Ownership and site collection administrators
  • Self-sustain

Size:

• Mention quota in your questionnaire
• Have a limited extension plan (Eg. 5 GB default, 10 GB max on demand)
  • Rules about larger sizes
    • Put in a different application (which I’ll detail in future posts about Content Management and large repositories)
    • Different technologies (Sometimes, a file share is still the right place for some content)
    • Cost back model

Customization

• UI customization
  • Custom pages
  • Custom libraries and lists (Boundaries should be documented here)
  • Branding
    • Out-of-the-box (OOTB), Corporate, Personalized
  • Workflows
• SharePoint Designer (SPD)
  • Permitted?
  • Un-ghosting of pages and masters (OOTB pages edited in SPD)
  • Custom workflows

Content rules (You don’t have much power here, your IM group needs to be involved)

• Information Management?
• Record Management?
• Enterprise Metadata?

So what are the benefits we gained by using these three rules?

Because of Site Collection, sites can be moved, recovered or resized more easily. Like I mentioned in my previous post, moving a sub-site can be tricky and limited to content.

Because of quotas and the form, you prevent someone from using your SharePoint application for the wrong reasons. Large departments that do not have content management are more than happy to use SharePoint with its versioning capabilities. The issue with this is that you don’t have an unlimited capacity and your infrastructure was probably not built to sustain a large amount of documents in SQL. Some proper planning is required.

Because of versioning limits, you’ll prevent your organization from quickly reaching their site collection quotas and can also dramatically reduce your storage requirements. By default, there are no limits.

With the form, you can see how content should be categorized. Also, you can see if you need a different web application or not. Let’s say that in Collaboration you do not permit video or audio files but you need to enable it on one site, you already need two web applications as this setting is at that level. Another example would be the maximum file upload size that you would permit.

Other considerations that we’ll now look at:

• Managed Paths.
• Self-creation of site collection
• SharePoint Online with Microsoft’s O365 (awareness of the benefits and overview of service. Great value for Collaboration).

Managed Paths

When you create a web application, you define at least one root URL. For this example, we’ll use https://collaboration.  The web application now needs to service one or more site collections. Of course, at the root, you will want https://collaboration to be a site and answer to a request. This is the root Managed Path.

Out of the box, when you create a second site collection, you do not have the option to put it on the root as there is already a collection there. Instead you see a dropdown with the option to add it to sites. This is the second managed path available out of the box. When you create a third collection, you still have the option to create it under sites.

There are two types of managed paths: Exclusive and Wildcard. Exclusive can only have one site collection while a wildcard supports many. You will understand that the root site collection of the Web Application is an exclusive type while sites is a wildcard.  You can create more managed path in the web application but you are limited to 20 per web application.

Why would you create more managed paths? I’ll give you two examples here that can be used in a content management scenario.

Let say that you need to create site collections for departments in your organization. Also, let’s say that you put a quota of 25GB per site collection in your content management.  The IT department needs to store 200GB content while HR will be fine with 25GB. This means that IT requires 4 site collections while HR needs only one.  If you only have a single wildcard managed path like sites you would have something like this.

• https://collaboration/sites/HR
• https://collboration/sites/IT
• https://collaboration/sites/IT2
• etc.

Not very pretty. Here’s how you can do it with custom Managed Path

• Managed path HR: Exclusive
• Managed Path IT: Wildcard

Here’s the new look

• https://collaboration/HR
• https://collaboration/IT/training
• https://collaboration/IT/support
• etc.

You’ll understand that the training and support sites are in fact site collections with 25GB each. The only caveat is that if you hit https://collaboration/IT or https://collaboration/sites, no one answers.

Self-Site Creation

SharePoint offers self-site creation of site collections. That means that you can give permission to people to create their own site collection without the need of a SharePoint administrator.

When someone creates a site collection, that person gets automatically site collection administrator rights. That means they can control almost every parameter that belongs to the collection. Some organizations restrict that and do not give site collection administration rights to owners. This is where a good definition of rules is required for self-created sites. It’s okay to let people within your organization to self-create site collections as long as the conditions are well defined.

A good example of self-created site collections is “My Site”. Everybody that creates a “My site” gets a site collection but with some rights limitation, a quota and properly isolated security.

Here are some things that need to be managed with self-site creation.

Mandatory Secondary site collection administrator

• If the owner who created leaves the organization and was the only administrator, nobody with the exception of farm or support team can change that. That can leave the site unattended.

Topics that only site administrators can handle

• Access requests to the site
• Email alerts when collection quota is almost reach
• Email alerts on inactive site collection to be deleted

Site expiration

• When a site is not updated for a long period, it may not be used anymore. There is a mechanism that permits you to delete that site collection after a certain period. This feature also alerts the site collection administrators so that they change the status of their site to show that it is still active.

Site quota

• Like in centralized created site collection, a quota must be applied.

Type of sites that fits well in the self-service model

• Ad-hoc sites, project and small team sites where people can create their own little workspace without administration overhead.  More important sites if customization is used to handle items that the OOTB solution does not offer.

Planning

• Self-created sites should be in their own web application. This setting is done at that level. Centralized created sites can be on another one without the capability of self-creation.

Improved creation process

• SharePoint out-of-the-box only offers a simple page to create a site. It does not require any information from the user, does not have that person commit to anything and does not provide much information. In the reality of enterprises, a custom form should be used where data about the site must be filled in by the future owner, and special code should be run to apply any customization like branding or custom security. Also, confidentiality levels could be requested there, as well as requesting a signature from the owner saying that they read and agreed to the organization rules.

SharePoint Online – Office 365 (O365)

Since we are talking about operations, I want to bring awareness on what this solution offers and an operational perspective on it.

Since server side customizations (I’ll talk more about these later on) are used minimally in collaboration, these type of sites are usually very easy to migrate to SharePoint Online. O365 supports Sandbox solutions and Designer customization.

Advantages of SharePoint Online is the complete abstraction of infrastructure management. Microsoft takes care of the servers, SQL, required space, load balancing and fail over. All you have to manage is site collection creation. Depending on your security model, you or the owner will manage the security of the collection. You do not need to do any farm operations.

Microsoft even supports extranet scenarios where you can invite partners to work on sites with Live Accounts.  And like all the other O365 offerings, single sign on with your current AD accounts is supported and centrally managed in your organization.

Next in this series…

Since this post is already lengthy, please check out my subsequent articles that will cover the following topics:

• Security
  • AD or SharePoint groups
  • Site Collection administration
  • Custom permission level
  • Sub site creation
• Customization
  • Composite applications and rapid development
  • SharePoint Designer
  • Change Management
  • Visual Studio and solutions
  • Lists boundaries and common mistakes
• Capacity Management for Collaboration
  • Boundaries
  • Content databases
  • Shared and isolated site collection in content databases
  • RBS
  • Archiving
• Backup and restore
  • Minimum requirements
  • Different levels
  • Space required
  • Limitation and boundaries
  • Site Collection Orphans
  • Staging