Joel Oleson's Blog - SharePoint Land

File Servers and SharePoint Doc Libraries... Tough Questions

·         Pretty much every application supports storing it’s file based data that way

FAT and NTFS File system storage has been around for a long time, so it is correct that more applications in the world support storing on windows file storage than via HTTP/S, Web Dav/Web Folders, SOAP, FP RPC,  or via Web Services all which are comparatively new and storing files which was a previously FTP function.  The usefulness of information via HTTP is the power and where we see the paradigm shift.  It’s a *Richer* experience on the web, I agree that people have lived with file system access for years, but not a good excuse not to change.

·         Everyone knows how to save files [to a file share or file server]

In my post, I believe I did mention that “Save As” and “Open” shell experience needs work.  It isn’t super easy to save to SharePoint sites, it does require training.  Partners and corporations have done work in this space, but Microsoft needs to innovate this shell experience.  Network places does not cut it.  The “explorer view” under actions on the document library does provide for drag and drop in the Windows client, for uploading or moving files and works via Web Folders/Web Dav.  The functionality has been there, but it isn’t 100% intuitive to find.  Agree we need some work and help from the Windows guys on this one.  I have met with this team and thought we’d get further along with Vista.  The truth, I’m disappointed.  There were some cuts that hurt us on this one.  There were much better plans.  The Office vs. Windows as separate technologies hurt us on this.  Innovation was impacted.  Thanks Judge Jackson.

·         Everyone knows how to navigate a file system

As far as Navigation goes…  I think would content that everyone knows how to navigate a well designed web site as well.  Corporations can make the UI as intuitive as they’d like.  I personally think that with a well designed intranet it is much easier to find and navigate than a file server.  If they are both designed well then navigation should be just as easy.  The file share navigation unfortunately is not security trimmed and is not easy to change.  With SharePoint navigation you can drastically change it from a folder structure,  tree control, to flyouts, to drop downs.  You can’t do that with a file share.

·         It’s easy to tell people where things are,  or send them a UNC path

This is simply experience with both.  It is as easy to send a URL as it is to send a UNC.  The “send to” in both XP and Vista is for client actions and can be customized to send to the mail client.  The “send to” in SharePoint is more extensible and can be to other locations outside of the client or server.  “Send to” mail recipient is there by default.  It was there in STS, and is back there in WSS 3.0 and MOSS 2007.

·         It’s easy to move stuff around, copy it, rename it

It’s just as easy on SharePoint doc libs.  This is more of a training and experience issue.  The copy simply requires using the “send to” or using “explorer view”

·         It’s easy to send files stored in a file system via email (drag and drop)

Same as previous.  Use the explorer view and drag and drop away.

·         Search tools work well on File Servers

This one surprises me.  Search on SharePoint kicks the File Shares behind.  Default search works way better than the file share search experience.  The only one that I’ve heard of was the ability to search down from a specific folder.  In SharePoint you can search from an enterprise, portal/site collection, site, doc library/list and configure scopes to create a search experience that needs to be granular.  The advanced search in SharePoint provides for more property/meta data based searching that isn’t available with the file share search.  The biggest difference is that SharePoint can index file shares, public folders, web sites, SharePoint sites, databases/structured and unstructured data sources, etc… The file share only provides search of content that it contains.

·         Performance is great

Let me break this down…

-Server Performance

Performance on file servers is well understood.  It isn’t easy to understand what’s going on if you do have a perf problem, but as the horsepower has increased file servers have continued to be low consumers of CPU and Memory.  A single SharePoint server can handle most small to medium businesses.  For larger medium to Enterprise, SharePoint farms scale to hundreds of thousands and millions.  Millions of docs and millions of users is tough to beat.  As far as server perf, I usually say 5000 on a single SharePoint box.  For a file server 5000 is ok.  In a file server cluster and SharePoint Cluster I’m ok with 25K on SharePoint per node and File Servers 25K, but I wouldn’t load it up like that if there were more than a few thousand using CSC or persistent mapped drives.  A disconnected DFSR for say product distribution should be fine with 25K.

Network Performance

Connections can be an issue, but with x64 windows a server can easily handle TB.  File servers and WANs don’t mesh if you’re trying to have your users use them.  HTTP and WANs work a lot better.  On the LAN the file server wins, on the WAN SharePoint wins, but don’t let that make you shut down all your file servers in your local offices.  Simple page loads and file transfers are faster on the WAN and SharePoint (really HTTP) has better tolerance for latency.  I do think there are some great opportunities to do consolidation of home and public shares and mapped drives in small offices and consolidate this type of collaborative data to SharePoint My Sites and team sites.  The backup piece is a tough one.  It’s not a full 1 to 1 mapping to say that the 5GB dump share where users backup their data to a 500MB or even 1-5 GB SharePoint My site.  You don’t want your users “dumping” their local drives onto their shared documents or private documents on their my sites or team sites.

·         Solutions are available for working  off-line

With Groove 2007, Outlook 2007 the Offline solution is pretty decent.  Sure it’s not two way, but with collisions and the infrequency of updates I think it works for most.  Otherwise, those that need to update they can update the docs that they changed when they get back to the Office.  The Groove workspaces are really the riches disconnected experience I’ve come across, but it doesn’t fit my scenario.  I’m usually connected at home or connected at work.  Otherwise, even on the go with the new Exchange 2007 experience with link fixup and ISA Web Publishing access to SharePoint I can get at my SharePoint files anywhere I’ve got an internet connection.  The new mobile views of pages and lists are great.  I find it very easy to navigate and use SharePoint “on the go.”  I have reservations with CSC and even with the new Vista Offline stuff.  It isn’t intuitive for the end user and I don’t like the idea that the client is master.  It is very confusing in file sharing environments where multiple users are working off the same content.  The merge messages need some work too.  The on the go File Sharing scenarios need work.  Publishing a file server to the internet with Web Dav is pretty slick, but not easy to use for most end users.  Sure you can grab whatever doc, but not a rich experience.

·         Fairly easy to replicate

Easy?  Not too bad.  The DFSR stuff wasn’t as intuitive to setup as I thought it should be.  I prefer stand alone DFS clusters, and I think DFSR as a solution was more designed for the AD DC folks.  I do think SMS team should be more attached to product distribution and running what's left of File Services.  The site costing stuff is pretty cool, but it really has a dependency on how well you managed your AD Domains and AD Sites.  Don’t get over zealous with your file server replication… if you are having people use this for collaboration, you’ll find that collisions are a problem, no merging, last one wins.  The SharePoint mapped paths and content deployment jobs make content deployment pretty easy.  It’s not two way, but it fits the need for what people need for staged environments and publishing scenarios.

·         Well integrated with backup

I think it’s a stronger argument to say, is easier to backup.  File shares are files on the file system.  They’ve been around longer than Windows has.  SharePoint backups are a combination of file system and SQL backup which can be accomplished via the command line and scripted or accomplished via a scheduled task.  So yes, it is more challenging, but with all the additional meta data, calendars, discussion threads, etc… This type of data needs a db.  Having the content and configuration stored in the same place ensures better consistency.

·         Integrated with all sorts of applications

Integration is a poor one.  You can do integration with SharePoint with just as many or more apps than with a file server.  The rich APIs in the Object model expose more than you could get with a file share.  There are a lot more layers to be able to provide around the files.  If you’re referring to simple access of the files from another app, I would agree that apps understand UNC more often than HTTP.  New apps can work with web services, object models,

·         File Servers are Cheap

Great argument and why I recommend file servers when you are looking for dump space or product distribution and large file storage and read only archive scenarios that have lower business value.  Storage on file servers is as cheap as the disks you buy + formatting (RAID 5), + Shadow Copy Diff Area storage (20%?),  + Replicas 1X+.  SharePoint Tech is as cheap as the disks you buy (RAID 5 & RAID 0+1), + transaction logs (~10%), + backup solution disk space (1X), FTS Index/Logs Temp db (~10%) and storage for indexes on Index Server (varies up to 50%).   It’s a real science to figure out what disk space you need because there are so many factors.  If I were to simplify this as 2X-3X then it sounds like a lot, but most of this is directly to provide the rich experience and can be ratcheted to take up less of that disk if it isn’t needed.

<update>

A great post follow up by spsdreamjob has a decent list of what doesn't work on SharePoint.

</update>