What is the difference between a file server and SharePoint?
A major topic of discussion within most beginner workshops is “Why should I use SharePoint when I already have access to a file server for sharing and storing documents?” This is part of an extended discussion on End User buy-in. The topic deserves consideration because anyone who is satisfied with their current file server will give push back on using SharePoint.
Let’s start with our friendly neighborhood Wikipedia for a definition of file server: “A form of disk storage that hosts files within a network… In many cases, the directory service spans many file servers, potentially hundreds for large organizations.”
In a simplistic sense, a file server can be thought of as a storage area, accessible by a select group of people for exchange of documents. So what does SharePoint add to the mix? Check out the diagram below and you’ll see there are components within SharePoint for communication and collaboration. Notice the overlap in the categories. Using SharePoint adds information around the documents being stored, such as automated workflow, historical archive management through blogs and wikis, tracking list, document workspaces and a myriad of other capabilities.
My suggestion for initial users of SharePoint who have lots of legacy data on a file server is to keep the file server as an archive, but use SharePoint for the creation and management of new documents. The advantage to using SharePoint is the ability to talk about the documents as a team, collaborate on the creation of the documents and, most importantly, attach metadata to the documents so they carry their identification around with them.
Within the next day or two, I’m going to post a description of metadata and why it is so important, but in the meantime, take time in your planning process to see which documents currently residing on your file server are critical and need maintenance on a regular basis. These are the ones that should be considered for movement into the SharePoint environment. The rest can stay on the file server, using the Business Data Catalog to act as an interfacing archive mechanism.
Mark,
Thank you for this timely post. It will be a good resource for those beginning implementations of SharePoint, perhaps for the first time. By focusing on getting relevant information into SharePoint (versus archiving years of unused documents), you don’t recreate the storage problem that already exists!
This is something that Bill English (SharePoint MVP) explained to the DFW SharePoint Users Group. If we don’t focus on relevancy, we just recreate the problem in a new place!
Thanks again!
Totally agree! We have 1.2 million documents in 16,000 folders – some up to nine folders deep. We decided the only realistic way of handling that mix of 10% important historical material and 90% superfluous drafts and stuff, was to set the archive server drives to ‘Read-only’. That way we have found new material has to be created in SharePoint. When important historical material is accessed, that too can be moved onto SharePoint.
Nick – Thanks for the validation. This issue will come up in EVERY major installation that has massive amounts of legacy data. It’s almost as if we are establishing a “best practices” by continuing to enforce the separation of file server and SharePoint.
Mark
The hallmark of good software is ‘everything you had before and more’. SharePoint should be able to provide OLD traditional (mapped drive) directory tree views and access to the same document folders for which SharePoint enables NEW interfaces for sharing, collaboration, presentation, and workflow. Then the issue becomes ‘how do I add new capabilities’, not ‘what am I giving up’. The interface should not be tightly coupled to the storage, instead multiple interfaces should be enabled.
Lets not forget the all important search capabilities within sharepoint. If your getting challenged on deployment, consider mentioning the capabilities of the Sharepoint search features and how “historical, archived” information can become a goldmine of customer information!! Whether it stays on the fileserver or moved to the sharepoint database.
One word of caution, without proper governance a lean 500mb installation can turn into a bloated 3 gig copy of your fileserver.
Regards,
Brian
I understand how valuable Sharepoint is for seraching and organsising files but I need some clarification. If you use SQL server to store the Sharepoint database do your new documents also get stored on your fileserver in some form or other? Or is everything in the SQL db?
I’m asking because another organisation is going to host our SQL server so will that mean no Sharepoint documents will be on our servers (unless users save them there of course). This will have implications on how much storage area we will need on our new servers.
TIA
Lisa – The new files will be in the SharePoint SQL db.
Mark
hello friends,
actually i wanna know wht is the biggest feature of share point when i am getting the same security and features in my file server???
If I migrate our document storage archive into sharepoint, are the files still accesible as separate entities without using sharepoint?
Piyush,
Search, Creation of metadata to classify and organize documents, Simple web applications empowered by a business user, offloading work from IT, there are many benefits.
Simon,
You can access the files using the UNC share, but the documents reside within a SQL database which is accessed either through SharePoint or through the UNC path which is translated by the SharePoint server. It won’t be in a simple fileserver form, but can be accessed similarly and can be flagged as read only.
Hope that helps.
Having about 1TB of data in Sharepoint, I regularly curse a number of issues with Sharepoint:
1. Restoring files from a monolithic database is painful. Gigabytes of restore in order to get back a 100kb file? Not good. The other option Sharepoint makes available involves crawling the whole site to do item by item backups. Again quite painful compared to backing up/restoring from a file system.
2. Performance is noticably slower than a file system – people access documents via internet explorer. On the LAN they wait while Internet Explorer and the Office DLLs communicate, before the file opens in the appropriate application. It was instant from the file system.
3. We keep hitting up against this issue where an install of Office 2003 will only allow opening documents in Read Only format, no matter how you open it. Even reinstalling Office doesn’t fix it – the only fix we have so far is to rebuild the PC from scratch.
4. When opening a http:// link to a sharepoint document in an email for example, it opens in Read Only mode.
Sure Sharepoint is great for Workflows and metadata and other document management processes. However, unless you know what and why you want to do these things, a file system is a far easier place to maintain documents. The model I am starting to feel my way to is to allow users to work on documents in a file system. Once they are complete, upload them to sharepoint.
Sharepoint can index documents in file systems. So far this is about the only benefit we have had from Sharepoint for 95% of the documents stored in it. And the docs don’t need to be stored in Sharepoint to benefit from that.
Duncan,
I published your response as an article on the main site. Thanks for your input.
Mark
http://www.endusersharepoint.com/2009/12/01/point-counterpoint-what-is-the-difference-between-a-file-server-and-sharepoint/
Duncan,
I hit some of those challenges with integration myself. It sounds like the pendelum swung and too much was pushed into sharepoint (at least in your described environment). With regards to:
1. If a file is deleted, then you should be able to restore from the sharepoint recyclye bin logged in as the Sharepoint administrator. This has saved me a couple times from having to restore loads of data. If it was edited, turning on versioning for groups should facilitate the same behavior for specific document libraries.
2 and 3 may be related. There seems to be some issue with with Office Web integration tools and a lingering dll thats a registerd addon for Internet Explorer. If I get a moment I will try to dig up the link for you that should alleviate and minimize some of your challenges. I have seen some new checkout/read only issues associated with the introduction of Office 2007 in an previously established Offices 2003 environment. We are are still working through some of those challenges.
4. Search is nice, until it breaks, then its a PIA.
As pointed out – any file system be it in a file server or SharePoint SQL database will become a nightmare if not governed properly in the first place.
Having said that, the Key benefits of placing files within SharePoint over a standard folder file system is:
In SharePoint
1. Documents are searchable without having to open them. That is very important also in legal matters.
2. Versioning of the document is possible.
3. Check-in, Check-out capability is possible
4. Adding metadata, and attachments is possible.
5. Workflows is possible. And because of that autoarchiving can be achieved.
6. Permission levels are more diverse, and grandular.
7. setting up a maped drive is no longer needed in most cases. With over 20TB of data, in our case, in a file sysetm – maping is also a huge nightmare. This is virtually eliminated using a SharePoint file system.
8. Finally, it’s easier for us to SEE what’s in a Sharepoint library if created properly without too much emphisis on using folders except when you absolutley have to.
9. You can set policies on how a SharePoint library is to be manipulated in a more granular way than with a standard file system.
10 – and the best part is you don’t need IT to do all the above, except maybe to collaborate with them on policies that govern the SharePoint server itself.
Having said all the above, I’d keep things of less legal importance in a file server, and move active, and important archive files into Sharepoint.
Hi Duncan,
Im a novice to Sharepoint, my new boss would like to get Sharepoint , and wants to sell it to our clients as this would help re file share for specific projects.
Unfortunately I’ve not be able to find anyone to break it down for an IT novice like me. My question is do we need a different server for the example below or is Sharepoint capable of file classification.
What we want is to be able to send an mail and sharepoint automatically files this mail in the right file carbinet for easy access by anyone working on the same project. I hope this makes sense
Stella,
Please see:
http://technet.microsoft.com/en-us/library/cc288433.aspx
You don’t necessarily need MOSS 2007 to do what you want to do.
Regards,
Brian