File Shares and SharePoint. Still a Hot Topic.

I'm sometimes reminded that there is still a lot of debate over how to position file shares and SharePoint in an organization. There are still many people drinking the file share Kool-Aid and that's fine. I blogged about this a little over a year ago and it generated more than 5000 views and 8 comments/trackbacks which is about 8 more than usual. Apparently, Joel has to talk about this a lot as he posted about this again recently. (I would link you there, but his new blog is down again. Somebody please fix this! Joel's blog is too important to be down. I joked with him when he was putting together his new site that he needed a hot standby failover solution.)

 Anyways, after I posted my latest entry on geo-redundancy in SharePoint I've been enjoying some great debate through comments with TBA. I thought that conversation would be interesting for the rest of you. Here's it is:

# re: More Clarification Needed? Geographic Separation of SharePoint Farm Components.

What strikes me is that due to these limitations, SharePoint cannot be easily configured to replace DFS for file storage ! SharePoint is marketed as the "file server of the future" yet it lacks the DFS's feature of maintaining local copies of files in environments that span continents/remote locations.

If I am to store all my files in SharePoint I have to store them all in one primary data center. Obviously users from different continents are better off having the data locally.... I would think this will be the major upgrade to the next SharePoint...

Monday, April 07, 2008 12:41 PM by TBA


# re: More Clarification Needed? Geographic Separation of SharePoint Farm Components.

SharePoint and file shares co-exist, not replace one another. Each have their own merits. SharePoint makes traditional file share data usable. DFS is one of the few technologies that allow multi-master replication. You are right that users prefer data to be local for performance reasons. However, http traffic is much better than CIFS over the WAN and SharePoint supports numerous acceleration vendors to make consolidated deployments seem local.

Monday, April 07, 2008 12:52 PM by Michael Watson


# re: More Clarification Needed? Geographic Separation of SharePoint Farm Components.

You say "SharePoint makes traditional share data usable". Ok, I have 250 Gigs of project "Delta" files located on a file share that is DFS replicated for fault-toleration and localization. I have people using that data from all-over the world. Due to SharePoint’s architectural limitation ( lack of file replication support ) I can't migrate out of DFS.

Right, I have created a team-space in SharePoint called "Delta" - great - the team members now can use discussions / calendars / etc. However  the 250 Gigs of related-files are still in DFS and people cannot use Sharepoint't s doc management features due to this. The only way around this would be to ask people move files between SharePoint ans DFS which is silly and is up to them really - leaving you out of control.

So how  exactly is SharePoint making my data usable , again ?

Tuesday, April 08, 2008 4:46 AM by TBA


# re: More Clarification Needed? Geographic Separation of SharePoint Farm Components.

Thanks for the great debate. It brings the blog to life.

Your file share data in SharePoint becomes "usable" because of the rich metadata definition, context, and most importantly, search. File Share data exists in its raw form without much context. It becomes an island, unknown outside of its most ardent users. It will most likely be duplicated by others since they are unaware it exists.

To improve upon the file share experience while still enjoying its benefits, you could link to the existing data in DFS from SharePoint or simply index the content for search. However, most organizations will prefer to simply migrate the collaboration-ready data to SharePoint. Since data usually has a preferred location it should be moved to the nearest regional SharePoint farm. This ensures the primary users of that data enjoy great performance while still providing access to users outside of the region. If the scenarios truly require it, consider using network acceleration technologies for remote collaborators or one of the SharePoint data replication solutions. We have a lot of great partners in this space and the solutions are probably much cheaper than most realize.

The bottom-line is SharePoint is part of a robust information architecture that improves upon the traditional file share experience with rich metadata, better context, and consolidated and scoped search. While there are certain scenarios were file shares are still the a great solution I'm confident that an organization will be best served by moving the majority of its collaboration to SharePoint.

Tuesday, April 08, 2008 1:43 PM by Michael Watson

Comments (2)

  1. Brad Saide says:

    Hi guys.

    Why not get the best of both worlds? Files stored on DFS with rich user interface and metadata linked to them through SharePoint… by using the External BLOB storage feature that became officially supported in WSS / MOSS SP1?

    More info here

    and some sample code here

    Wouldn’t that answer TBA’s concerns?

  2. Brad Saide says:

    Actually, after having a think thru the issues, it may not – the benefits TBA seems to be focussed on (local instances of files) would probably relate to bandwidth access between sites (both speed and cost/gig) – External BLOB Storage will give SP the ability to use a DFS drive to store data, but from the perspective of the site, the DFS location would always be the same, no matter where the site was geographically (unless you set up some site-specific DNS rules that pointed to the "local" DFS folder to retrieve the document from)… so the file (BLOB) data would always have to be streamed across the WAN. The only benefit that DFS provides in this scenario is a replicated copy of the files being used by SP (which could easily be batched using robocopy or managed via SAN replication, etc).

    The solution would be to use something like Syntergy’s replicator to replicate data / file changes between geographic sites… but then you have additional infrastructure and Licence cost per site.

    TBA, could you please list your requirements so we can see if a solution can be built (say using wss) that meets the requirements and is cost effective?

    A start of the list might be:

    Multiple copies of each file, geographically dspersed

    Minimisation of bandwidth utilisation between sites

    Company has an EA, so SQL licencing is not an issue

    The ability to associate file objects with Projects, news items, metadata etc

    Try and focus on the requirements, not the benefits you get from each technology… so "What is it that IT, Finance and the Business users are demanding?" instead of "What benefits do I get from DFS" and just listing those.


Skip to main content