Russ' SharePoint Blog

Over the holiday break I spent quite a bit of time trying to get a real good handle on exactly how SharePoint 2010 and RBS interact in order to externalize content to a BLOB store.  As part of that effort, I implemented the CodePlex RBS Provider as an exercise to learn more about the roles of SQL Server 2008, the RBS Framework, and SharePoint 2010.

So why would you want to try out this exercise?  Well, there are some limitations to the FILESTREAM provider.  First, it only works with local volumes on the SQL Server.  So if you want to store your binaries out on a file share that consists of cheap storage, you’re out of luck.  Also, by default, FILESTREAM provider seems to put all binaries in a single folder.  NTFS used to have problems when you had too many files in a single folder.  That may have been mitigated in newer platforms, so I can’t testify to this specifically.  But in general, I’m not a big fan hundreds of thousands of files in single folder.

I will be doing an RBS Deep Dive session at the SharePoint 2010 Evolution conference on April 21st and there are going to be some real juicy tidbits in that session.  But in the meantime, I thought I would provide a guide to installing the CodePlex RBS Provider in SharePoint 2010 (beta).  Note that some of these steps may be subject to change as I am currently working with the beta bits.

In order for the CodePlex provider to work, it has to be tweaked a bit because SharePoint 2010 requires the provider to properly dispose the BlobStore object in the framework.  So I’ve recompiled the provider appropriately.  You’ll find the link in the steps below.

Also, before we get started, the steps below assume you have a single WFE in your farm.  If you have more than one WFE, steps 2 - 9 will need to be executed on each WFE.

So here we go:

1. Prepare your content database.  This script must be executed in SQL Management Studio in the context of the content database that will have RBS installed:
   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'
   
2. Download rbs_x64.msi from here and save it to your WFE.
   
3. Execute rbs_x64.msi on your WFE to begin installation of the RBS Framework.
   • Buzz through the standard agreement and registration forms.
     
   • All features should be installed except FILESTREAM Provider is not necessary.  So your feature options should look like this:
     
     
   • Configure the connection to your content database.  Use “default” for the Filegroup name.  Test the connection to ensure your good before proceeding. Should look something like this:
     
     
   • On the database configuration form, no need to check the “Request connecting clients…” box.
     
   • On the Maintainer Task form, scheduling the Maintainer is optional.  I typically do because it’s easier to let the installer help you set up the task.  It’s important to configure the “Run As” account as well as the task schedule which is disabled by default.
     
     
   • On the Client Configuration form, I typically set all log settings to “Warning”.
     
     
   • You should be ready to “Install” at this point.  Once you kick it off, the installer will go to town setting up the framework binaries and running RBS SQL scripts on your content database.  If you told the installer to configure a scheduled task for the Maintainer, the Schedule Task configuration box will pop up for you.
     
   • Once the installer has completed, your content database should have some new tables in it that look like this:
     
4. Download the updated CodePlex RBS Provider that I updated here. 
   
5. For the sake of this guide, create a directory to permanently contain the RBS Provider binaries at c:\CodePlex_RBS_Provider
   
6. Copy the contents of the “Binaries” directory in the rbs.zip file to c:\CodePlex_RBS_Provider
   
7. Now you need to use Notepad to edit c:\CodePlex_RBS_Provider\InstallProvider.cmd
   • The “RootDir” parameter needs to be c:\CodePlex_RBS_Provider
     • If you choose a different RBS Provider location for the RBS binaries, this value needs to reflect that location
       
   • The “ProviderName” parameter needs to be FileStoreProvider_1 for the purposes of this example.
     
   • The “DataLocation” parameter contains the location of your BLOB store.  This will typically be a network share somewhere but it could be a local directory.
     • Note that the RBS provider will be invoked in the context of the SharePoint content access (Application Pool) account specified for the Web Application that the content database is associated with.  So that service account needs to have FULL Permissions to this folder.
     • I typically create a subdirectory in the file share for each BLOB Store which I create 1 to 1 for each Content Database that I enable for RBS.
       
   • The “ServerName” parameter contains the name of your SQL Server instance.
     
   • The “DatabaseName” parameter contains the name of the content database that has had the RBS resources already installed (new RBS tables, etc).
     
   • Save the InstallProvider.cmd which should now looks something like this:
     
     
     NOTE!!! The application pool account for the SharePoint web application that contains the content database that will have RBS enabled, must have full permission to the final BLOB store folder as well as read access to the location of the RBS provider DLL (if it's not installed to the GAC).
     
8. Launch a command prompt with Run As Administrator:
   
9. Run the InstallProvider command:
   
             C:\CodePlex_RBS_Provider\InstallProvider.cmd
   • When it runs correctly, the result looks like this:
     
10. Run the SharePoint 2010 Management Shell as Administrator.
11. Execute the following commands to enable the CodePlex RBS Provider for the content database:
    
    $site = get-spsite http://siteurl 
    $rbss = $site.ContentDatabase.RemoteBlobStorageSettings
    $rbss.Enable()
    $rbss.SetActiveProviderName($rbss.GetProviderNames()[0])
    $rbss
    • When you execute “$rbss” you should see a result that looks like this:
      
      
    • Congratulations, you just enabled RBS!  If all goes well, all future binaries added to your content database will be sent to the BLOB Store.
      
    • In order to externalize existing BLOB content, you need to run one more PowerShell command.
      
      $rbss.Migrate()
      • This command will send all binaries currently in the database to the active RBS Provider BLOB Store.
        
    • What if I want to pull all my BLOBS back into the database?  Simple.  Just execute:
      
      $rbss.SetActiveProviderName("")
      $rbss.Migrate()
      • This will pull all the BLOBs back in-line in the content database.  This is handy when you need to move your BLOB store or if you need to change your RBS Provider all together.

Ok, so that was all pretty cool, so how do I know that it worked?  Well, before you enable the RBS Provider, the AllDocStreams table in your content database will show values in the “Content” varbinary(max) column like this:

After you enable the RBS Provider, the AllDocStreams table in your content database will show NULL values in the “Content” varbinary(max) column and instead show values in the “RbsId” varbinary(64) column like this:

Also, if all goes well, then the BLOB Store directory that you specified in the InstallProvider.cmd configuration file will have BLOB files showing up like this:

Finally, I’ll say that while this is a great exercise to show you what’s possible with an RBS Provider other than FILESTREAM, the CodePlex provider should probably be used at your own risk in production.  In my mind, this is an extremely useful but elaborate teaching example.  It should be thoroughly tested before being deployed in mission critical systems.

It's also important to know that Microsoft ISV Partners are working on several different RBS Providers that will provide feature support for file shares, BLOB encryption, BLOB compression, REST, and Cloud Storage as well as support for specific storage platforms such as Fujitsu Eternus, EMC Centera, and Hitatchi HCAP.

I’m convinced the flexible RBS Provider options in the works will squash any remaining FUD out there regarding SharePoint storing binaries in the database.  The scalability story was already great, and it is so much better for SP2010 that it makes my job as a SharePoint evangelist that much easier!

Cheers.