Managing Resources in SharePoint Online (Office365) Site Collections – "You are approaching the maximum storage limit"

Recently, I ran into a problem on my Office365-based SharePoint site. I’ve got an E1 account so that I can test how things work in the cloud. When I went to add a new Site Collection, I saw the message below in yellow.


This message itself didn’t make sense to me, since I have only uploaded a few tens of megabytes of content to the account so far across the three Site Collections that I had set up at the time. There’s no way I’d even started to get close to my storage limits. Note that the screen is also telling me that I have 0 resources and 0 MB available.

The thing that stopped me in my tracks was that the New button on the ribbon was greyed out, so I couldn’t create a new Site Collection. I checked the online help, and I should have been able to create up to 300 Site Collections (see below), and I only had three so far. Something wasn’t right.

I filed a service request online with Office365 to try to get things sorted out. Since I did this through the Web site, I assumed, and preferred, that we could work it out through email. I always believe that the way a customer initiates a service request ought to be the default follow up method. The first reply back said that we needed to schedule a phone call to figure this out. This became a theme in the eight emails I received from Microsoft support on this issue.

I say Microsoft support, but it became very clear that this is probably an outsourced function. The answers were only tangentially related to my issue and seemed fairly pat in nature. I tried to point out that I am a SharePoint MVP (I don’t often haul that into a conversation, but they seemed to think I had no idea what I was doing), but that didn’t make any difference. The most frustrating part of this was that, even after repeated suggestions from my end, they didn’t seem to be looking at my account at all. They just sent me standard information about how SharePoint Online works, like the information at the bottom of this post. It wasn’t that the information wasn’t interesting to read through. It simply didn’t address my specific issue, and made it clear that they probably weren’t looking at my account at all.

Finally, after more suggestions that we had to solve this via phone, we got to the bottom of the issue. It wasn’t that I was nearing my storage usage limit, but that the storage quota was used up. Here is the message from Microsoft support that finally got me there.

Issue Resolution:-

-> You need to reduce the storage Quota for [MySiteURL] (9450MB) . You need to select that site from “Site Collection” and click on “Storage Quota” on ribbon and reduce the “Limit storage quota for each selected site collection to a maximum of: ” .

-> Or you need to add some test users and provide them Licenses so that you would get 500 megabytes (MB) per enterprise user.

This will help you to Increase your MB available and then you would be able to create new site.

That answer still didn’t tell me that they had looked at my account (I certainly don’t need another 500Mb of storage for another user when I’m only using maybe 20Mb so far). But by reducing the Storage Quota for the existing Site Collections, I got rid of the initial issue. It turned out that I also had to reduce the Resource Usage Quota for the Site Collections so that I wasn’t bumping up against that total limit as well.



Once I knew the solution, it seemed obvious, of course, but this is certainly something that could be spelled out more clearly on the screen. If I couldn’t figure it out, so it’s bound to be confusing to many others. The other weird thing is that I’m pretty sure that both the Storage Quota and the Resource Usage Quota were set to the maximum available when I created the Demos Site Collection. I’m sure that there was a message of some sort, but it must not have been clear enough to help me set the values more intelligently.

Hopefully, the messages for these two issues will be improved in the future, In case they aren’t, I figured I’d post what I went through in case someone Bingles the “You are approaching the maximum storage limit” message.

Here’s the useful info I mentioned above about the E1 plan.

Key Features and Specifications

Table 7 provides a quick look at some of the key features and specifications of SharePoint Online.

Table 7: SharePoint Online key features and specifications



Storage (pooled)

10 gigabytes (GB) base customer storage plus 500 megabytes (MB) per enterprise user

Storage per Kiosk Worker

Zero (0). Licensed Kiosk Workers do not bring additional storage allocation.

Storage per external user

Zero (0). Licensed external users do not bring additional storage allocation.

Additional storage (per GB per month); no minimum purchase.


Site collection storage quotas

Up to 100 gigabytes (GB) per site collection

My Site storage allocation (does not count against tenant’s overall storage pool)

500 megabytes (MB) of personal storage per My Site (once provisioned)
*Note: the storage amount on individual’s My Site storage cannot be adjusted.

Site collections (#) per tenant

Up to 300 (non-My Site site collections)

Total storage per tenant

Up to 5 terabyte (TB) per tenant

File upload limit

250 megabytes (MB) per file

External Users (PALs)

50 PALs are included per tenant. Current “Feature Preview” allows for usage rights of up to 1000 external users without requiring additional PALs. Microsoft reserves the right to charge for additional PALs beyond 50 at the time the next major Office 365 update.

Microsoft Office support

Microsoft Access 2010

Microsoft Excel® 2007 and 2010

Microsoft InfoPath® 2010

Outlook 2007 and 2010

Microsoft OneNote 2010

PowerPoint 2007 and 2010

Microsoft SharePoint Designer 2010

Word 2007 and 2010

SharePoint Workspace 2010

Project Professional 2010

Browser support

Internet Explorer 7

Internet Explorer 8

Internet Explorer 9

Firefox 3 and higher

Safari 3.1.2 on Macintosh OS X 10.5


Mobile device support

Windows Phone 7.5 codenamed “Mango” or later

Windows Mobile® 6.1 or later

Nokia S60 3.0 or later

Apple iPhone 3.0 or later

Blackberry 4.2 or later

Android 1.5 or later


SharePoint Online allocates an initial 10 GB of storage plus 500 MB for each user. This storage is pooled and available for allocation across multiple site collections. For example, an organization of 1,000 users by default would have a base of 510,000 MB (510 GB) of storage.

In addition, users can purchase more SharePoint Online storage in GB increments charged monthly, currently $2.50USD/GB/month.

Site Storage Quotas

The SharePoint Online service administrator can set the storage limits for site collections and sites created by users. The minimum storage allocated to a new site collection is 24 megabytes (MB). The maximum storage available for any site collection is up to 100 gigabytes (GB).

The maximum SharePoint Online storage available to a single company’s tenancy is up to 5 terabytes (TB).


For more information about storage quotas, review SharePoint Online: software boundaries and limits at the site.

Site Collections

A site collection consists of a top-level site and its subsites. SharePoint Online lets users allocate their available storage space across up to 300 site collections. Site collections are often based on departmental boundaries. My Sites (personal site collections) do not count against this overall number of team site oriented site collections, nor do My Sites pull from the pool of storage; each My Site, once provisioned, is allocated 500 megabytes (MB) of personal storage.

Sites within a site collection share common features, such as galleries for templates, content types, Web Parts, and custom solutions uploaded to the site collection solution gallery. A subsite can inherit permissions and navigation structure from its parent site, or these can be specified and managed independently. See the TechNet article Determine permission levels and groups (SharePoint Server 2010) for details.

Base Your SharePoint Database Architecture on Business Requirements First, Database Concerns Second

Sometimes when I’m speaking at SharePoint events, I’ll mention something about the fact that “the geeks” make decisions about Site Collections and database boundaries that are a detriment to the users. I got a question about this the other day:

…you mentioned something that I wanted to follow up on: basically it was a warning to avoid setting up the information architecture (site collections and thus ability to shuffle between databases) based on “the geeks”.  I would love to find out what the issues you’ve seen or experienced that were caused by breaking up data across site collections.  I image it might be the cross site query web parts and such.

The main thing I am referring to is the promise of being able to promote content from private or local contexts into wider contexts, therefore maintaining the single version of the truththat Microsoft sometimes talks about. This single version of the truth ought to apply not just to content when considered from a database perspective, but also from a Content Management perspective. A particular version of a document ought to exist in exactly one place. Of course, that’s far more easily said than done, but it’s a Content Management goal.

Note that when I talk about “the geeks”, I mean those of us (yes, I sometimes belong in this group, too) who view the technology for technology’s sake over what its function for the users should be. If you’re an admin who never talks to end users about what they need, then you probably are in this group, though you might not be because you are able to extrapolate their needs well.

Take the example where an Intranet has a root Site Collection and then a Site Collection per Department. (A simplified example, sure, but not that uncommon.) If there is a document in the HR site that we want to promote to the root site, there are no good mechanisms to do it. Site Collection boundaries are primarily security boundaries from the end user standpoint, so we can run into permission issues. We also don’t have a good way to keep a pointer on the root site to the actual document in synch. That means there can’t easily be one version of the truth.

CQWPs and DVWPs in CrossList mode are also out of the question for doing things like rolling up Announcements, for example, which is an extremely common use case. Again, Site Collections are permission boundaries, so those Web Parts don’t work across them. We have to resort to all sorts of tomfoolery using the Web Services or third party tools.

Of course, to the geeks, it makes total sense to make the Departments individual Site Collections. They want to be able to manage the content that way so that they can go to one Department if that Department’s content is getting out of hand to make them clean it up. But it often doesn’t work from a user perspective.

A more complex example would be a smaller organization (as a larger one is unlikely to find the idea palatable) which wants to use SharePoint for its Intranet, Extranet, and Internet sites. Ideally one could create work output in a Team Site in the Intranet somewhere and upon completion, promote it to expose it more widely on the Intranet. That itself if often a problem. But what if we then want to expose that piece of content in multiple Extranet sites? Or we want to expose it as part of the content corpus on the Intranet? Now, one can easily respond with all sorts of enterprise-class concerns about security, but that’s up to the customer. These scenarios come up with my clients all the time, and if they want to make them happen, it’s their choice.  The geeks will usually set things up to preclude any of this because of the content database concerns they have.

The business sometimes simply can’t do what it wants to do because of decisions based on database concerns, and SharePoint is blamed for a shortcoming which it doesn’t actually have. That’s not a good thing for any of us.

When to Use Separate Site Collections

I had some questions today from a respected colleague about when to use separate Site Collections, and I sorta liked my response, so I’m going to foist it off on you, too.

The gist of the questions was this:

They are fighting the battle of site collections here (IT wants several) which of course will make it impossible to share lists, site columns, content types.  Will separate site collections also effect “send to” and document routing for individual content items?

and my response:

Think of Site Collections as separate gated communities.  Just because you can get into one doesn’t mean that you can get into others (you probably can’t).  To me, Site Collections are all about security.  The walls between the communities have broken glass on the top and guards roaming around.  Now, if you can get a guest pass, you’re all set…

At one of my clients, everyone got a separate Site Collection (over a thousand of them) and NOTHING could cross those boundaries.  Sort of what they wanted, but not really always.

which of course generated the clarifying question (my cool metaphor didn’t really work in the send to behavior of the USPS or anything):

So to be clear, “send to” and document routing would be inhibited by separate site collections?  Passing documents between site collections?

with the answer: