Do you really need SharePoint Site Collection Quotas?

Setting some context

Like on almost everything in life, there are different opinions on using site collection quota.

In his blog post “Controlling Sites Sizes with QuotasMichal Pisarek proposes to use Site Collection Quotas and they should be one of the first things to be considered in your SharePoint Governance plan.
I do agree with him, but I also firmly disagree.

Why don’t I agree with the obsessive (IT) need to implement Site Collection Quota?

During a workshop I was delivering to the business key stakeholders for a SharePoint project (it was a workshop to gather business requirement for a SharePoint implementation) the topic of quotas presented itself. Without telling or asking anything about quota, the business representatives came up with this question. Technically it is not a question because the is no question mark in the sentence, it was more like a proposal or even a requirement.

“If our Enterprise IT strategy directs us to use SharePoint and use this tool to share files between countries and continents then we don’t need (read want) quotas.”
(They were at this moment not able to share information on file shares easily between different countries since file share servers are hosted in the office or country where the files were primarily stored)

Now, from an IT perspective this is a NO-GO because IT wants to (draconic) keep control on disk space consumption and storage capacity planning.

So my response to that was (I was also surprised of this statement, but understood exactly what they meant) asking them on how they can assure that only relevant information will be stored in their sites.
That old, outdated content will be removed. You know, people tend to start cleaning up disk space when they run out of it. And how can we make sure they will not have (too much) duplicates in their sites. And that’s for me the part where governance enters the discussion.

So what is a possible solution?

My solution is not just 1 solution. It is a combination of different solutions that can fulfill the business requirement (the need for “unlimited” disk space and freedom just like they now have on their file share) is not to use Site Collection Quota (or use a very big quota) and define content types (something you should always do on your SharePoint sites)

After defining the content types, you can configure retention policies on these content type. Just to make sure that legal documents don’t get deleted, after 2 years. And you probably don’t need to have your minutes of meetings available for 7 years in the production environment.

An extra step (and maybe a highly recommended one, although  I’m lacking real life experience with this as we speak (Jan 2012)) is that this retention policy actually moves files out of the SharePoint SQL database into another system. Like a tape or a BLOB. There are tools available on the market where you can do storage optimization and create rules that will move documents (or versions of documents) to a BLOB. So you offload these document from the underlying SQL database to alternate tiers of storage like a SAN. This will benefit the sizes and numbers of content database, but it is also a good thing for search and indexing. If you can keep the relevant content in your content databases lower, by off loading these files to BLOB, the overall performance of your database will not decrease (or decrease less) compared to when you keep all these files in the database.

Delivering Business value or loosing control over disk space capacity?

My point of view is that these solutions provide value to business users. Even though IT people will most probably freak out on the thought about not defining a quota, when you define the technical governance correctly and have the proper tools (like Docave Storage Manager from AvePoint  and Storagepoint from Metalogix) you’ll be able to provide a trustworthy solution.
Defining and configuring site collection quota requires less effort then defining  enterprise wide content types, retention policies combined with offloading the SQL server.
But I think it is worth it.

About Patrick Sledz

Patrick works as a consultant. He assists organizations to deliver SharePoint business value and create the awareness in these organizations that only a strong technical team is not sufficient to deliver this added value.
Tagged , . Bookmark the permalink.
  • Hans Pierre

    Nice Post Patrick.I also suffered multiple times from short sighded IT departments. It is true that many IT departments are only interested in managing their disk storage. They only want to get rid of information to free up disk space, without taking into account what can and cannot be removed. They want to treat every piece of information the same way. “Let’s delete it when it hasn’t been modified in the last 6 months”

    Content analysis is paramount in delivering value solutions in SharePoint, regretfully much companies don’t want to invest in this and use SharePoint only as a file server and treat it as such. And thus do not create any added value for their organization.

    IT should be an enabler and not an obstacle for people wanting to collaborate. IT does not own the content!

  • Koen Vosters

    Nice post, In a perfect world that would be a good approach to solve the site collection quota, as it isn’t a foolproof system. Business will find a way, and you can either enable them or they will find, a usual less optimal approach, to achieve what they want (request new site collections, place it on some project site where they still have space, mysite, skydrive…). The solutions you propose are good solutions, but in my opinion it isn’t that black and white at all. In my opinion a good approach would be to also know what your solutions mean on the IT architectural POV. It’s nice to be conceptual, but what does it actually mean for our SharePoint farm, the maintenance team, the SQL setup…

    Don’t agree at all on the short-sighted / draconic view on the IT departments. They are the ones that have to make sure that your environment stays in the air, they are the ones that get yelled at when the system goes down and isn’t up and running soon (guess that this huge content database actually needs a long time to restore, and yes the backup only happens once in a week as your database is so big that the backup isn’t able to finish during the night…oh yes, and then there is also the SLA). They are also the ones managing the thirdparty solutions you add to the environment. Not to mention that the money for this maintenance usually comes from another budget than the project itself. Personally I prefer the approach where you check with IT what is currently possible and what the roadmap is for the future. You then talk to the business what it is that they want and then provide a roadmap to get there. Which might mean that business will have their limitations due to the current IT limitations. It’s then up to them to tackle those challenges, either through providing additional budget/resources or by using the environment in a different way.

  • gat3k33pr

    I enjoyed reading this post and sparked my interest in some challenges I’ve discovered in designing information solutions on SharePoint. The statement in this post that got my interest is this: “configure retention policies on these content types”

    The requirement is honorable but the solution presents a myriad of challenges, let me summarise.

    Defining a retention policy means, the information has an expiry date. An expiry date means that information can be ‘removed’ after that date. The remove part is where the complexity enters. I’ve experienced where companies implemented this approach and very soon discovered that information were deleted because of the content type it belonged to that should never have been deleted in the first place. In the real world very few companies have zero information on a server where new fresh rules can be applied to newly uploaded content with well defined content types.

    When companies already have a lot of information and retention policies are applied the variance within that becomes unmanageable. Then the next solution/idea would be to add ‘intelligence’ to removing the data from the live environment i.e. by generating tasks using workflows in which users are notified that a document must be archived.

    Initially, this sounded like a wonderful idea, but what happens if you apply those rules to document libraries across the whole site from the get go? Thousands of documents on that environment belonging to the same content type will require archival on the same day.

    This creates the same mess that the company were stuck with initially – how do wet get to everything to clean-up.

    I’m interested in hearing other people’s thoughts on this.

    Thank you for the intelligent post!

  • Lisa Atarian

    Nice post, and I mostly agree. Mostly.

    Your very last sentence is the real challenge: “Defining and configuring site collection quota requires less effort then defining enterprise wide content types, retention policies combined with offloading the SQL server.”

    Content management (content types, metadata, information management policies) is completely foreign to some (most) users. Giving them a shiny new SharePoint site, then throwing all the features at them at once, would certainly present an adoption challenge. As such, I think the SharePoint maturity of the organization factors heavily on the answer to the problem.