RBS external provider invalid reference

Joel Plaut

December 22, 2011

All Post

Inside every Content Database is a key table called AllDocs; when configured for RBS there is a field called DocFlags that can provide insights into the configuration.  If the value is 65868, it indicates to the RBS Provider to leverage the deprecated Farm ExternalBinaryStoreClassId, which was used as part of EBS in SP2007.  You can see whether this is set for your farm by running these two PowerShell commands. For my farm, it gives a zeroed out GUID:

PS C:\Users\SP2013Farm> $farm = Get-SPFarm
PS C:\Users\SP2013Farm> $farm.ExternalBinaryStoreClassId
Guid
----
00000000-0000-0000-0000-000000000000

The following SQL run in the context of your content database provides a count of this DocFlag:

selectCOUNT(*)
from AllDocs where DocFlags = 65868

The following SQL run in the context of your content database provides a count of this DocFlag:

selectCOUNT(*)
from AllDocs where DocFlags = 65868 

This situation prevents the PowerShell Migrate() cmdlet from running. As a refresher, here’s the full PowerShell set of commands to set the minBlobSize and call Migrate():

$cdb=Get-SPContentDatabase -identity "[replace with your content db]"
$blobstoragesettings=$cdb.remoteblobstoragesettings
$rbs = $cdb.RemoteBlobStorageSettings
$rbs.MinimumBlobStorageSize
$rbs.GetProviderNames()
$rbs.Installed()
$rbs.Enable()
$rbs.MinimumBlobStorageSize =1mb
$rbs.update
$cdb.update()
$rbs.Migrate()

For me, I get a hideous “Object Variable Not Set” for the migrate() command. Oddly, the underlying AllDocs records with this one 65868 flag all predate my installation of SP1 with June CU, hinting that this Service Pack may have fixed a condition going forward…

What occurs for DocFlags is the highest order bit (0x10000, or 65536) is set to indicate an external provider (EBS) is utilized; this value should be zero for the typical SharePoint 2010 out-of-box RBS configuration.

The simple solution is to fix the offending bit. However this violates Microsoft’s rules telling us users not to muck in their database internals. We would never do that of course, but “hypothetically” here is how you can fix it. Take your hypothetical backup before hypothetically running this SQL:

update AllDocs
set DocFlags = DocFlags & 0xFFFEFFFF
where
( DocFlags & 0x10000 ) = 0x10000

What this does it clear the 65536 (0x10000) bit. This SQL would run (hypothetically speaking) in a fraction of a second.

We can then (again, of course hypothetically) enable RBS and do a Migrate() of content back into FILESTREAM.

Ciao, and happy Blobbing!