Our Great Posts

In previous posts in this series, we considered a customer requirement for surfacing documents stored in file shares through SharePoint and various third-party tools that are available as possible solutions. What makes this particular requirement tricky is that the file shares are not in the same location as the SharePoint farm, and bandwidth between the two is limited.

Having considered offerings from AvePoint, Bamboo, and Metalogix, we will now close out the discussion by considering how SharePoint 2013’s out-of-the-box Enterprise search features can be brought to bear on the problem.

Search in SharePoint 2013 is extremely robust. In fact, improvements in enterprise search are one of the nicest improvements of the new version. Applying the capabilities of SharePoint search to this particular problem requires two steps: 1) defining the file share as an external content source so SharePoint’s search service application can crawl it, and 2) defining the means by which the crawled data should be made available to users.

Within SharePoint, external content sources can be crawled by the Search Service Application. The I/O requirements for these crawls can be very light, as the only data captured is basic metadata that exists in the file share, such as document name and creation and modification information. In situations such as the customer requirement under discussion in this series where documents may be large (up to hundreds of MB) and bandwidth is constrained (T1),  minimizing data captured can be a means of providing the best performance.

Within SharePoint, items crawled by the Search Service Application are surfaced when search results are delivered to a user as a part of the Search process. These items can also be browsed, however, by preparing dedicated, pre-configured results pages and by leveraging out-of-the-box SharePoint web parts that are configured to rollup search results on the basis of a predefined query. Furthermore, these items, whether presented in predefined browseable views or in search results, are automatically security trimmed by SharePoint on the basis of user access rights on the source file share. No separate permissions management is required.

The advantages of this approach for the customer use-case here are the low bandwidth required to make the file share objects available in SharePoint, the ability to customize predefined browseable views for specific groups of users, and the ability to present the documents to the user without requiring them to be either stored in the SQL content databases or passed through the WFE to reach the client browser.

The disadvantages of this approach are the limitations it places on document management functionality. With SharePoint search results from external content sources, no additional metadata can be added to documents beyond what is already present in the source file share, no document versioning or co-authoring is possible, and the documents cannot be presented in the browser via Office Web Apps without streaming them both up from the file share to the SharePoint farm and then down from the SharePoint WFE to the remote client.

These are serious limitations from our customer’s point of view, who was hoping to maximize SharePoint’s DMS features..

However, given the constraints imposed by the requirement, it is probably the best option, and certainly the only one that is supported out of the box without recourse to costly third-party tools.

The bottom line is that SharePoint document management features such as metadata and versioning depend on the SharePoint technology stack: the SQL DB server that stores the data and the web server that sends it to the client. Any time a SharePoint solution requires bypassing the core parts of that stack (as when document are stored in file shares instead of in the SQL DB), compromises in functionality are almost inevitable. It’s up to the client to determine what set of tradeoffs are most palatable given their business needs.


Leave a Reply