I want to show a quick example of how to use StoragePoint to externalize content to a DFS share.  Many companies use DFS to provide redundant storage space for the user community.  It’s proven itself to be a relatively solid technology for replication of data to multiple locations for redundancy and high availability.  Those qualities also make it an excellent choice for a BLOB store for StoragePoint.

Configuration

Configuration is quite easy as StoragePoint will treat a DFS Namespace just like a UNC path.  This can be used with the OOTB file system adapter.  I’ll be using four servers to illustrate this scenario.  Essentially we have two file servers that replicate data between them. This is where content BLOBs from SharePoint will be placed by StoragePoint.  Check out the diagram below for the details.

I’m not going to go into detail on configuring DFS as there are plenty of guides online that show how to do that.  You can find a few here:

·         Windows Server 2003 – http://technet.microsoft.com/en-us/library/bb727150.aspx  

·         Windows Server 2008 – http://technet.microsoft.com/en-us/library/cc732863(WS.10).aspx

·         DFS Terminology - http://technet.microsoft.com/en-us/library/cc781375(WS.10).aspx

Make sure that the DFS path where BLOBs will be stored is only accessible by the SharePoint service account.  If this share is to be backed up (and it should if it is not replicated offsite) you will need to grant access to the backup service account as well. 

Once DFS is configured we can set up a storage profile to externalize content to the DFS Namespace.  The storage profile will use the standard StoragePoint FileSystem Adapter.  In the “Connection” box input the path to the DFS Share.  In my case it is “path=\\c611.com\dev1\DFSBLOBS”.  The compression and encryption are still valid options with DFS.  Choose them based on your own requirements.

And that's pretty much it for setting up StoragePoint to work with DFS.  For a demo you can check out the YouTube video below:

Benefits

The obvious benefit here is the fault tolerance that DFS provides.  Not everyone has a fully redundant SAN or NAS to store files, but now an organization can provide a level or redundancy for SharePoint that wasn't there before.  The not so obvious benefit is potentially eliminating the need for a backup of the BLOB store.  If DFS is replicating this information to a data center that is far enough away from the primary data center to account for scenarios such as flooding, forest fires, or meteor strikes then I could see removing the need to backup the BLOB store.  SharePoint is already handling the versioning (or it should be) so you do not need to worry about recovering a specific version of a specific file.  The only concern for recovery is to ensure that the DFS Namespace is available to the recovered site.

I can see another potential use for this, but I'll save that for another post and some more testing...If you can guess it you get a gold star...