SP2010 Scalability (4 of 4): In-Place Records Management

Ok, so lets do a little math here.

In SharePoint 2007, you can define only 1 Records Center at a time for official files.  A single site collection (including a Records Center) in its own content database might contain somewhere around 1 million documents at a meager average of 55KB per document.  That keeps us under the 100GB content database recommended size limit.

1 million documents?  Seriously?  I suppose you could try to manage multiple records centers but this would get interesting if you actually needed to put something in legal hold in multiple records centers.  So for all practical purposes, we were severely limited as to the number of official records that could be supported in the SharePoint 2007 farm.

Enter In-Place Records Management.  Excellent!  With SharePoint 2010, we will soon have the ability to enable a feature on a site collection that allows us to declare a document as a record IN PLACE!

Suddenly, records center scalability isn’t such an issue anymore.  Oh yeah, and if you still want to use Records Centers… in SP2010 we will have the ability to define more than just a single Records Center.  Also, we gain the option to “Move” a document instead of just copying it to the the Records Center.

So there you have it.  Three HUGE improvements to the scalability story of SharePoint 2010!

Remote Blob Storage takes us to a whole new order of magnitude with respect to the number of documents that can be supported in a single content database.

The new SharePoint Search story just got a whole lot better with scale-out for redundancy an performance.  Plus we now have FAST for SharePoint which can support BILLIONS of documents in SharePoint.

Finally, In-Place Records Management will support Enterprise Class Records Management solutions that go far beyond the significant limitation in SP2007!

In weeks to come, I’ll be dialing in on a few of these technologies.  Particularly, I’ll be diving in to the deep end on RBS in the very near future!




  1. Andy Hopkins says:

    I agree with all of your RM value points relating to scalability, but I do think it bears noting that the recordation functionality has now been deeply embedded into the SharePoint 2010 platform. The platform will surface full fidelity records management even through the “In Place” scenario… meaning, content that has been declared as records in place will remain in location and the RM features will be surfaced there. This is true for the spectrum of content that can be stored in SharePoint such as documents, wikis, etc. For example, a wiki that has been declared as a record in place will be locked and cannot be edited nor deleted. The 2010 release of SharePoint will now have a legitimate enterprise record management feature set implemented with a very scalable architecture.


  2. rhouberg says:

    Great stuff Andy! Thanks!

  3. Eli Robillard says:

    A bit of a clarificaiton – in 2007 you can have many Records Center sites, the limitation is that you can only configure one site to be attached to the RC web service that routes incoming records into its file plan. But it’s a limit easily overcome.

    By developing a custom router to be aware of multiple RC sites (Bing: records center custom routing), you can treat that one site as your "RC Organizer".

    For sure, making RC features available in any SharePoint site is a welcome change, this is just clarify that unless you’re talking about purely out-of-box features, scalability isn’t new to records centers.

  4. rhouberg says:

    Good clarification Eli.

    I should have been more clear that I was referring to out of the box 2007 limitations.

    Your approach is certainly viable. But I’ve seen several implementations that use records center and don’t consider these consequences of using just one RC as the destination for all records. Then they bring me in because they don’t know why their stuff is slow!

    Perhaps your additional solution info will help someone understand how to work around the OOTB limitation if they’re standing up a new farm on 2007.


  5. Ritesh says:

    I have an enterprise wiki site. wherein there are folders relative to user groups(ex . if group name test exists then there is folder in pages library named test). now i want that when a page is created (which by default is saved in pages library) should be saved/moved automatically to the corresponding folder depending upon the group of which the current user is a member of.

    any suggestions,ideas..will be very helpful.
    Thanks in advance
    Ritesh Papneja

Comments have been disabled.