Community

• Blogs
  • Expert Blogs
  • Community Blogs
  • Create a Blog Entry
• Discussions
  • Start a Discussion
• Job Center
• Chapters

External Blob Storage (EBS) and SharePoint Records Management

• 
• 
• 
• 

What have we learned in our SharePoint projects where we made use of External Blob Storage, or EBS?  A great deal.  This is the technology that Microsoft introduced with SQL Server to take the storage of large objects out of SQL Server.  Since many users store large documents in SharePoint, which is built on SQL Server, the relationship is a natural.  Here are several observations and conclusions:

EBS works really well in some circumstances

The advertisements for EBS are true.  The resulting SharePoint sites are smaller and faster, and the performance gains have led Gimmal clients to develop the confidence that they needed to take their SharePoint solutions forward to replace legacy ECM solutions for their enterprises. 

It is important to architect and backup the SharePoint environment carefully

Dividing the content and the content metadata makes it harder to recreate the state of a SharePoint environment if this becomes important.  These functions need to be synchronized and integrated. 

EBS support for SharePoint comes in many flavors

Tools from StoragePoint and AvePoint take objects from SharePoint and hand them back to SharePoint on command.  The competition at this end of the market is fierce, and AvePoint has recently made its EBS solution available at no cost.  At the other end of the spectrum, the EDRSS connectors for EMC|Documentum send the entire SharePoint Property Bag over for Documentum to resynchronize with the object and support the classification and retention of the object in Documentum. 

EBS has enabled some sophisticated Records Management solutions to be integrated with SharePoint

I originally thought that using EBS behind the MOSS 2007 Records Center would be a valuable use case.  However, in the one large customer where we evaluated this solution, the alternative of EBS integration for all SharePoint sites was preferred because it established better control over all content, it simplified the user interface, since the Records Center was uninvolved, and the performance boost from EBS integration was seen in every SharePoint site.  We used metadata from the SharePoint Property Bag to establish appropriate folders in EMC|Documentum’s Retention Policy Services, so an enterprise scalable records management solution was built for users who saw our solution as SharePoint-pure.  HP has announced a similar solution for the product formerly known as Tower Trim.  I reviewed this solution in my AIIM Show review last week. 

SharePoint 2010 adds new Records Management capabilities

The new capabilities of the hierarchical file plan and content organizer (among others) make the SharePoint 2010 platform much more strategic to organizations that are considering their records management options.  However, since EBS capabilities integrate with SharePoint through its SQL Server infrastructure, there is no fundamental change in the nature of the EBS support from MOSS 2007 solutions.  The improved performance of SharePoint 2010 may make the threshold to justify an EBS investment higher, but the use of EBS in high-end SharePoint solutions is likely to continue. 

EBS is a requirement for the DoD 5015 certification of SharePoint 2010 as a records management tool

My company has done work for the Microsoft SharePoint Marketing and Product teams on requirements for DoD 5015 and MoREQ2 certification.  Our conclusion is that the deletion requirements of DoD 5015 cannot be supported within a SQL Server database and therefore, externalizing that storage is the best method to enable the digital shredding requirement of DoD 5015 standard in a SharePoint-pure DoD 5015 solution. 

What about Remote Blob Storage (RBS)?

RBS has been touted as the successor technology to EBS for some time.  Since it integrates with SharePoint via SQL Server, there aren’t huge differences in approach, but there are some low level differences.  EBS has been in the field and proven for some time.  Some of the features of EBS have not been implemented in RBS in the same way, so vendors and end-users who have built EBS solutions are not assured of a smooth port to RBS.  But, we expect that Microsoft support will enable the migration to RBS to be achieved somewhat seamlessly for implementers. 

Summary

External Blob Storage requires careful planning, but the improvements that can be achieved in performance, control and compliance make it a tool that enterprises should consider in the architecting of their SharePoint ECM and RM Solutions.  The eventual migration to Remote Blob Storage will enable additional capabilities in the future. 

Comments

Submitted by Martin Spriggs May 05, 2010 - 8:17 AM

I'm just trying to get smarter on EBS and SharePoint. So SharePoint 2010 supports EBS, but only through third party tools? We have DocAve and recently learned that DocAve Extender is now available to us, which I believe would be the tool we would use for EBS, but does SharePoint 2010 have any native tools to make this happen? Thanks.

Report

Was this helpful? Yes No

Reply

Subject  

Comment  

Submitted by Mike Alsup May 06, 2010 - 11:12 PM

Martin - External Blob Storage (EBS) and Remote Blob Storage (RBS) are not SharePoint tools. It is a capability of SQL Server to enable the storage of binary large objects (blobs) outside of SQL Server. Many SharePoint sites have large numbers of large documents, so they are a natural user of this capability. AvePoint has made their EBS tool free of charge, and I believe that they make excellent SharePoint add-ins. Microsoft does not provide native EBS or RBS tools, but they provide the API's to enable these specifications to work. I believe that Microsoft sees EBS and RBS tools as extensions to storage and archival and not in their primary domain. Mike Alsup

Report

Was this helpful? Yes No

Reply

Subject  

Comment  

Submitted by Rob D'Oria May 19, 2010 - 1:23 AM

A couple things I'd like to correct and expand on:

1. EBS is not a SQL capability. It is a SharePoint capability delivered with WSS 3.0 SP1. It has nothing inherently to do with SQL Server.

2. StoragePoint is not an EBS-only solution. We were one of the 1st, if not the 1st, to develop an RBS provider.

3. Martin, Microsoft does provide a RBS FILESTREAM Provider for SharePoint 2010 free of charge. It was developed to provide an upgrade path for existing WSS3/WIDE (Windows Internal Database Engine) customers to SharePoint Foundation Server using SQL Express R2 2008, which has a 10GB per instance size limitation. It may be suitable for other usage scenarios, but you will find that it doesn't provide much OOB. It's biggest shortcoming is probably the requirement that the BLOB store be local to the SQL Server, so there is no opportunity to save on storage costs. You're also not going to be able to compress or encrypt the content or securely delete (shred) it.

4. I don't know that I would characterize the competition as fierce. Giving your product away for free is hardly competing, at least not in my opinion. And if one took the time to look at our 3.0 offering you would see that there is no comparison between AvePoint's freeware and StoragePoint. There's also that big difference in how the administration experience is surfaced. Ours is surfaced within SharePoint Central Admin, which is where SharePoint admins expect it to be. The DocAve suite is a Java client running on IBM WebSphere Application Server Community Edition. They do a super job hiding it.

5. Our 3.0 release contains a shallow copy migration between EBS and RBS OOB, so upgrades for our customers won't be an issue, assuming EBS remains deprecated.

6. While it may seem like a best practice to have integrated or synchronized backups of your content databases and BLOB stores, the nature of remoted BLOBs do not make this a requirement. Remoted BLOBs are static, meaning they are never updated, so the requirement to have an absolutely 100% federated backup set does not exist. You can simply backup your content database and then the corresponding BLOB stores can follow. Worst case you will end up with some orphaned BLOBs (...BLOBs that exist in the BLOB store but are not represented in the content db backup), but those are trivial in nature and will be garbage collected. Our offering has some additional capabilities that completely eliminate the need to have synchronized backups while significantly improving recovery times...whitepaper coming on this topic in a couple weeks.

Report

Was this helpful? Yes No

Reply

Subject  

Comment  

This post and comment(s) reflect the personal perspectives of community members, and not necessarily those of their employers or of AIIM International