Our Great Posts

Recently, a customer came seeking advice on how best to incorporate documents in remote file shares into their SharePoint 2013 portal. Their scenario was this:

  • Centralized office with SP 2013 Farm
  • Multiple remote locations with separate file shares at each site
  • Some large files at each site (including  >100 MB)
  • Low bandwidth (T1) connections to some remote sites
  • Limited resources with which to implement a file migration process

“How,” they asked, “can we present these documents through SharePoint without actually moving them into SharePoint? Can we do that?”

The answer is: Sort Of.

What the customer really wanted was to leverage the full range of SP document management features (centralized point of access, metadata, versioning, workflow, etc.) while avoiding the both the cost of actually migrating the documents into SharePoint and the resulting performance risks. (The customer was concerned that moving all of the local documents into the central SharePoint farm would introduce unacceptable performance costs when accessing the documents due to the low bandwidth between the central office and the remote locations.)

The customer requirement is difficult because  it runs counter to how SharePoint works.

SharePoint at its core is a web server sitting on top of a database server—documents and data are stored in the database and served by the web server to a user’s browser. This file share requirement is attempting to use SharePoint to surface documents to the user’s browser while bypassing both the database server for document storage (by leaving documents in their current file share repositories) and the web server for document delivery (by routing documents directly to the client from the local repositories and not through the central office where the SharePoint servers are located).

Given these constraints, any solution is going to involve compromises in functionality. You can’t expect to bypass both halves of SharePoint’s core technology stacks without paying a price in terms of available features.

In particular:

  • Access to SharePoint document management functionality will be limited, including versioning, alerts, and metadata. Versioning and alerts are configured as part of the SharePoint document library, and metadata is applied to the document as part of the database entry associated with the document.
  • Access to Office Web Apps functionality will be limited. The WAC server’s in-the-browser viewing and editing capabilities require routing the document to the WAC server for handling, which actually doubles bandwidth requirements from a remote location (when compared to serving the document form a SP database), as the document must be sent not just downstream, but both upstream and downstream.

In a later post, we’ll review the out-of-the-box and 3rd-party options that are available to meet this requirement, what kind of feature set you’d have left given the constraints, and whether or not it would be worth it to use SP as the central portal for the remote documents  in this situation.


Leave a Reply