“I'm Not Dead, Yet!"

Although I've proclaimed that the traditional collaborative file share is dead, don't throw your file servers out the window just yet! You likely have file shares that don't fit into the shared folder scenarios I just mentioned, which you'll need to retain. So before we look at how to implement document libraries, let's quickly explore why some file-sharing scenarios are best suited to traditional file shares.

Large files and archives. SharePoint imposes a fixed maximum size of 2GB per document, as well as quota settings (defined at the site-collection level) that are generally recommended to be set at 50MB to 100MB per file but can be increased up to the 2GB ceiling. Storage of large files in a traditional file share is a bit "cheaper" from a total cost of ownership perspective than storage of documents in SharePoint's SQL Server–based content databases and becomes even cheaper given the interesting storage enhancements that will be introduced in the next release of the Windows Server OS (Longhorn Server). Access to large files also can become problematic over a WAN, which can stretch the capabilities of the HTTP-based access to documents in SharePoint. For the same reasons, historical archives can be maintained at somewhat lower cost in file shares.

Distributed scenarios. DFS and DFS Replication (DFSR) can be used to abstract and localize access to distributed resources, such as software distribution points, if those resources are stored in server message block (SMB) shares. So distribution scenarios, such as Microsoft Systems Management Server (SMS) packages, will be better supported in file shares because no comparable distributed-resource access method exists for document libraries.

Personal-data storage. Although you could theoretically encourage users to store their personal data in their Microsoft Office SharePoint Server 2007 MySite or in another SharePoint document library instead of My Documents, it's generally recommended that you continue using shell-folder redirection to a traditional file share for user data. Too many applications and "hooks" in the Windows shell point to My Documents, and users are accustomed to the My Documents metaphor.

Relational databases and executables. Most flat databases can benefit from migration to SharePoint, but complex, relational databases will best remain in Microsoft Access, SQL Server, or other database platforms. Scripts and executables are blocked from SharePoint document libraries, so files of these types should be stored in file shares.

Source-control systems. Developer source control, through which developers track and maintain changes over time, is better supported by using applications targeted to that task instead of a system of document libraries.

Even in these scenarios, SharePoint can still play a valuable role. For example, you might choose to store large archives or streaming media files in a shared folder but provide links to those files in a SharePoint links list to make those files easier for users to find. If your developers are storing code in a source-control application, they still might use a SharePoint team site to collaborate. Or, if you have SharePoint Server 2007, you can configure it to index the contents of shares, so that their contents are included in search result lists.

The trick is to balance the needs of your organization, your network's capabilities, and the types of resources you're managing in a way that maximizes value and agility. Although the file server isn't dead, close analysis of your information-access and collaboration needs will likely suggest that most traditional file shares in your organization will benefit from migration to SharePoint document libraries, and those file shares that remain can be supported by SharePoint.

End of Article