How To Do SharePoint Operations in the absence of Proper Governance

Written by Daniel Brunet, Senior Microsoft Premier Field Engineer.

If you found this article, chances are that you searched for some combination of “SharePoint” and “Governance”.This is the first of a series of articles that will be mainly focused on operational procedures for Microsoft SharePoint admins in the absence of governance. It is not meant to help build a governance process, rather to help my typical customers understand some dos and don’ts. If you are a developer, business analyst, architect or customer, it will give you an insight on SharePoint operations and help you understand the challenges and reasons behind some decisions. If you are a farm admin, I hope these articles will help you in your day to day work.

What to do if you don’t have a SharePoint Governance Process

A popular request for SharePoint consultants is to help their customers build a SharePoint governance document for the organization. There are also references on TechNet, and some consulting organizations and independent software vendors have tools and/or offerings to help build one.

In my role, I mainly work with SharePoint farm administrators that are responsible for maintaining one or many SharePoint farms. At most of my engagements, I see the same challenges that these people face every day when no governance is present.

I also want to point out that many factors can be affected by the addition of other tools to manage SharePoint. I’ll focus on what SharePoint offers out-of-the-box. Feel free to share your personal point of view, but I am trying to help organizations that work exclusively with SharePoint and no additional tools.

You’ll also notice that my views in these articles are primarily based on infrastructure-related concerns. Consultants and developers need to look at SharePoint from a business requirements and application perspective and sometimes are not involved in the infrastructure portion. The farm admins need to insure that the infrastructure can sustain the current and future services offerings.

In many cases, the SharePoint platform was delivered to address a specific service or application. At that point, it is usually easy to maintain. Risks or issues arise when SharePoint is used to address scenarios that were not planned. Because SharePoint continues to have a very rapid rate of adoption, this becomes a somewhat common scenario. The other typical scenario is where SharePoint is let loose in the enterprise and people see its potential and start to use it for many services without proper preparation. Many farm admins are caught by surprise by the volume increase in both traffic and size. I have seen many “pilot” farms become production environments with all the associated issues that arise from such “organic” or ungoverned growth.

SharePoint viewed as Service Offerings

The first thing I tell my customers is to think of SharePoint as multiple service offerings instead of an application or platform. It is in the context of these different offerings that I will write my articles.

Like me, I am sure you have seen this SharePoint capabilities pie graph many times and may think of it as a “pre-sale” thing. For me, it’s the base on how I help people manage their farm(s). When you know what services you are offering with SharePoint, you can start defining some elementary rules to help you.

What’s important to understand is that each of the pieces of this pie can require different approaches and governance. These differences will help you build the definitions and rules of your services.  So what are the factors that can impact your choice of approaches?

From an infrastructure stand point, your challenges will be:

• Security Manageability
• Scalability Management
• Capacity
• Performances
• Business continuity (SLA, Backup/Restore, DR)

From an application stand point:

• Security requirements
• Ease of navigation
• Complexity of development in a multi-service environment

And what will be mainly impacted based on the services and associated requirements?  The following:

• Number of farms, servers
• Number of Web Applications
• Number of Content Databases
• Number of Site Collections
• Site Structure
• Lists and libraries structure

Typical questions or comments I receive that are related to this:

• What are the benefits of using multiple web applications?
• What is the difference between an application pool and the web application?
• Managed Path? What’s that?
• How many Site Collections? Oh, we have one for now. Yes we do have an intranet and departmental document storage!
• Should I permit the use of SharePoint Designer?
• We are small and I might break security inheritance to do this.
• The organization doesn’t want development in SharePoint.
• Active Directory or SharePoint groups?
• When do I create a site collection instead of a sub site?

With all this said, where and when do I draw the line? This is what I’ll attempt to articulate here.

The Mistake of Mixing SharePoint Service Offerings

One of common mistakes I see is the mixing of services. A common example I still see is building an intranet and creating collaborative departmental sub-sites to do collaboration or, even worse, document management.

So what are the issues here?

• Intranets:
  • Are large and primarily geared for read access across the organization
  • Are Geared towards limited authoring and write access
  • Contain a small to medium volume of documents, forms, web pages
• Document Management Systems:
  • Are largely geared towards Read-Write access
  • Are secured by department or business units
  • Contain a large volume of office documents

So what are the challenges caused by the mixing intranet and document management requirements?  The following:

• Limited scalability
• Cannot fully restore a sub-site *
• Cannot apply quotas to sub site
• Shared Recycle bin
• Database too large, cannot be split
• Too many security exceptions
• File upload size limit cannot be different
• Intranet restored time affected by database size

* Be aware that SharePoint, out of the box, is limited when it comes to backing up a sub-site. The smallest container that can be restored with full fidelity is a site collection. When you backup a sub-site, you are in fact exporting and importing content. This works well for content, but if you have functionality like columns lookups, workflows, recurring meetings etc., your restored sub-site may not work as the customer expected. Also, a site collection cannot be span on multiple databases.

To implement such a scenario with minimal governance:

• The Intranet should have its own web application
  • Departmental sub-sites are still intranet content
• The Departmental document management storage should have its own web application
  • At least one content database
• Use a minimum of one site collection per departmental document storage
  • You typically don’t want and/or need to see the other departments site collections in your navigation
• You should apply a site collection quota. We will talk more later on this topic.

Now even with this minimal approach to governance, you can still hit scalability limits:

• The departmental site collection becomes too large
• The failure to backup one collection from the content database

In the case of collaboration, usually the site collection sizes are easily managed, but if we are talking content management with thousands of departmental documents, proper preparation and analysis is mandatory.

When and Why To Use a Particular Container

Another big challenge is to decide when and why you need a particular container. I designed a graphic a couple of years ago that I’ve used many times since to try show the configuration and limitations of each container. This one is for SharePoint 2007:

The numbers are much higher in SharePoint 2010 and other factors like site collection isolation in a database can affect these numbers. We will cover that in more details in subsequent articles.

In upcoming articles, I’ll also dig deeper on how you can govern and maintain the different services, such as:

• Collaboration
  • Service agreement
  • Site Collection quotas
  • Self-creation of site collection
  • Ownership and rights
  • Backup and restore
  • My site, not so bad after all
• Search
  • Capacity management
  • Refreshment requirements
• Composite applications
  • SharePoint Designer, don’t be scared.
  • Workflows
  • List limits
  • Change management and versioning
  • Limitation and when to move out of SharePoint
  • 3^rd party tools
• Custom and 3^rd party components and solutions
  • Documentation
  • Multi-server environment
  • Deployment
  • Project management
  • Collaboration with application team or vendor
  • Supportability

I hope this introduction got you interested. Your feedback is appreciated and will help define the focus of this series of articles.