Skip Ribbon Commands
Skip to main content

Quick Launch

Todd Klindt's home page > Todd Klindt's Office 365 Admin Blog > Posts > Installing Remote Blob Store (RBS) on SharePoint 2010
December 20
Installing Remote Blob Store (RBS) on SharePoint 2010

In my daily perusing of SharePoint blogs a couple of weeks ago I saw a blog post on Jie Li's blog on how to install Remote Blob Store (RBS) on SharePoint 2010. Imagine my excitement! I was under the impression that using RBS was going to be something we were mortals would not be able to use, but here it was. Why was I so excited? Well, with SharePoint 2003 all content had to go in content databases, no exceptions. As people started putting more content, and larger content into SharePoint the question became pretty common, "Can I store my large files outside of SQL?" The answer was always no. Storing files outside of SQL became the holy grail of SharePoint content storage. It would let you take advantage of all the reasons you used SharePoint; metadata, web presentation, workflows, etc. It also let you use storage that was much cheaper than SQL storage normally is. When SharePoint 2007 came out the answer to that question remained the same, "All content must be stored in SQL, no exceptions." However, after a hotfix the support for External Blob Storage (EBS) was added to SharePoint. This was almost what we needed. The hooks were there in SharePoint, but there was no way to actually use them. It was handled much like how SharePoint handles antivirus software. There were hooks into SharePoint for it, but the functionality itself didn't exist in the product. That part had to be handled by third parties or ISVs. Not a lot of ISVs jumped on this, as the interface exposed to them wasn't great, and it wasn't clear what the upgrade path would look like. Again, storing large files outside of SQL seemed just out of reach for the average SharePoint administrator, until now…

That brings me back to Jie's post. I knew that SharePoint 2010 would ship with RBS support, but I wasn't sure what RBS products we'd be able to use. Jie's post not only showed how RBS could be used, but provided an actual RBS provider. That's was pure gold. The RBS provider Jie linked to uses SQL 2008's Filestream support. That works for me. The rest of this blog post is how I installed RBS and got it working.

Again, everything I've done here is based on Jie's blog post and the links inside. Only a couple of things are things I had to figure out myself.

I already had a VM with Windows 2008 R2, in a domain. It had SQL 2008 R2 with the November CTP on it. It also had SharePoint Beta 2 (build 14.0.4536.1000) installed on it, and I had been using it a while. There were several content databases defined with a few site collections. The first thing I had to do was enable Filestream in SQL 2008 R2. I used these instructions on MSDN. Once I had the instructions, it went very smoothly. The only snag I had was I initially ran it as the wrong user. In my VM, SQL is running as contoso\administrator. SharePoint is all running as contoso\sp_farm and that's the account I logged in as normally. That account did not have the permissions to enable Filestream. After I ran it all as Administrator it worked. Now came the fun part, RBS…

In preparation for RBS I created a new Content Database for it to use, since RBS is scoped at the content database level. I used Window PowerShell to do it, since that's what the cool kids are using.

The command I used was New-SPContentDatabase –name WSS_Content_Blob –WebApplication http://shaerpoint –MaxSiteCount 1 –WarningSiteCount 0

Next I went into SQL Management Studio, as contoso\sp_farm, and ran a few TSQL commands to configure my new database for RBS. Here are the commands I used:

Here's the text:

use [WSS_Content_Blob]

if not exists (select * from sys.symmetric_keys where name = N'##MS_DatabaseMasterKey##')create master key encryption by password = N'Admin Key Password !2#4'


use [WSS_Content_Blob]

if not exists (select groupname from sysfilegroups where groupname=N'RBSFilestreamProvider')alter database [WSS_Content_Blob]

add filegroup RBSFilestreamProvider contains filestream


use [WSS_Content_Blob]

alter database [WSS_Content_Blob] add file (name = RBSFilestreamFile, filename = 'c:\Blobstore') to filegroup RBSFilestreamProvider


I was following the directions from this MSDN post, but I had to make a couple of changes. First, I had to make sure I had the correct database name, WSS_Content_Blob, everywhere necessary. Second, I manually created c:\Blobshare before running the TSQL commands. That was a mistake. SQL needs to make it on its own when you run the third command. Deleting c:\Blobstore fixed that and the command ran successfully.

Next step was to install the RBS bits on the SharePoint servers. (Download RBS_X64.msi) In my case it was pretty simple because SQL and SharePoint were on the same machine, and I only had a single SharePoint server. Here's the command I used to install the RBS bits:


msiexec /qn /lvx* rbs_install_log.txt /i RBS_X64.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY DBNAME="WSS_Content_Blob" DBINSTANCE="sharepoint" FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FilestreamProvider_1

This install seemed to happen immediately. However it kicked off an msiexec service that ran for a couple of minutes. I had to watch it in Task Manager to see when it was finished. I was also monitoring the rbs_install_log.txt file to see when the process was finished. I was looking for the phrase "Installation completed successfully."

If I would have had more SharePoint servers I would have had to install that on all of them, or SharePoint would have been very unhappy.

You can double-check the database was changed correctly if the rbs tables appear in it. That will look like this in SQL Management Studio:

The last step, before feeling the glory that is RBS, is to go back to our old friend, Windows PowerShell and enable RBS on our content database from a SharePoint perspective. Here's what the PowerShell looked like:

Here's one place I had to deviate from the MSDN article. It says the first line should be $cdb = Get-SPContentDatabase –WebApplication http://sitename That didn't work for me. I suspect the person writing that article had a web application with a single content database, so that command would only return one SPContentDatabase. The web application I was testing this on had three content databases, so $cdb had a collection of SPContentDatabases, which doesn't work for the next line. Reading through the PowerShell it looks pretty clear that $cdb should contain a single SPContentDatabase object. I went through the RBS install three times and had the same behavior each time.

The last step was to test RBS and upload a file and see where it ends up. The rbs_install_log.txt was 1.2 MB and a good candidate for the test. I created a site collection (with PowerShell of course) and uploaded that text file. To see if RBS worked, I navigated the c:\blobstore directory to see if my file was there. Here's what I found:

Looks like it was successful. I went through this three times and it worked every time. I tried various sizes of files and various operations on those files. I added versions, deleted them, added metadata, indexed and searched for them. It all worked just fine.

I hope this blog post inspires some of you to install RBS and play with it yourself. I do have another blog post planned where I go a little more in depth with what I found in RBS.

Have fun,



Edit: 3/19/11

This blog post explains how to enable Filestream RBS on multiple databases. I haven't tried it myself yet, but I've talked to others that have.


Question about deletion (maintainer with RBS)


Great article, thanks. I have been trying to find information on how the maintainer and SharePoint delete operations work. In EBS it was full responsibility of the provider developer to find BLOBs no longer referenced in SharePoint and delete them from the storage. However the RBS documents and blogs refer to the maintainer doing the actual garbage collection work. Up to what point it will be internal to SharePoint/SQL to find deleted objects and when is that list passed to the provider? Does the provider have to go and find it or it might be a new RBS method or API, or something that will request delete of a list of BLOBs to the provider? IT was partially mentioned in the SharePoint conference, but I was expecting to find more concrete info in it. I have even found some blog references about a provider VETOING a delete operation or supporting updates.
Do you have any idea where I can find information about this?  
Please if you have some reference or info send me an e-mail to
 on 1/11/2010 12:52 PM

EBS for now RBS later

Hi Todd,

Right now our environments have MOSS 2007 and SQL 2005 back end so I'll need to either find an EBS method now.  or

This gives me more reason to look forward to SharePoint 2010 and helps make the case for SQL2008 as we get ready to make that move.

Thank you for the post.  Insightful and helpful as always.

 on 2/25/2010 2:04 PM


I like how this will be available for Foundation.  It opens the door to split a web app we have off of our Sharepoint farm that's hosting some large files in the DB and utilize the blob functions someplace else. 


 on 2/25/2010 2:19 PM

Filesystem Structure

Very useful post.  I'm going to be testing this right away.

In the meantime, could you possibly post some screenshots of what the content of the blobstore looks like when you upload files into it?  Is it GUID gobbledygook or is there some readability to it?

 on 3/5/2010 12:01 PM

Re: Filesystem Structure

The last screenshot shows the structure. It's all GUIDs.

Todd O. KlindtNo presence information on 3/6/2010 5:15 PM

Great installation guide!

I'm one of the developers of RBS and wanted to drop in and thank you for putting together a great setup guide and to answer a couple of questions in the comments.

1. The RBS Maintainer process runs as a seperate process via a scheduled task and handles all the garbage collection algorithms. The provider simply needs to implement a delete blob and delete pool method. We also have an optional callback that can be used for provider specific maintenance tasks if that particular provider needs something custom done.

2. There's no plans to allow providers to support updates. Even though the underlying blob store might physically be able to support updates RBS has a requirement that blobs are immutable to ensure our consistency guarantees and to support metadata restores within the SLA time limit. There's more info on GC and the various settings at our blog,

3. The GUIDs used by the blobstore are the SQL Filestream implementation. This is wholly a provider specific path and unrelated to the general RBS architecture, although the Filestream provider is the default provider supported by Microsoft.

Once again, thanks for a great post and please let us know if you need any assistance or clarification in the future.

- Michael
 on 3/16/2010 11:45 AM

Awesome guide ...but I have an issue

Hi Todd
Thanks for a wonderfull post. I followed your post exactly and was able to install the RBS bits on SharePoint 2010 server.
I verfied the log file and it did had the line
"MSI (s) (6C:B8) [22:11:46:374]: Product: SQL Remote Blob Storage -- Installation completed successfully."
But when I double checked the content database no tables were found for rbs?
Even after running the command $rbss.Installed() I got a False result

Any body faced similar issue?
- Steve

 on 4/1/2010 12:56 AM

Re: Awesome guide ...but I have an issue

I guess I'd read through the whole rbs_install_log.txt file and verify everything went well and that you didn't specify the wrong database name or something.

Todd O. KlindtNo presence information on 4/1/2010 10:14 AM

Awesome guide ...but I have an issue

Thanks Todd

Finaly figured out the issue. While enabling FILESTREAM support for MS SQL Server in SQL Config. Manager, Windows share name for enabling I/O streaming was accidently misspeled. I had to reanable it and make it same as SQL instance name.
 on 4/5/2010 2:38 AM

Re: Awesome guide ...but I have an issue

Thanks for the followup. I would have never guessed "did you mispell your share name?" :)

Todd O. KlindtNo presence information on 4/5/2010 3:35 PM
1 - 10Next

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.


Body *

Today's date *

Select a date from the calendar.
Please enter today's date so I know you are a real person


Want a message when I reply to your comment? Put your Twitter handle here.