Collaboration Feature Article: Transitioning from File Shares to SharePoint

While currently most files are designed to be stored on standard file systems, the move to a web based system – SharePoint – is happening because of the added benefits for users. These include check-in/out, workflow, auditing and records management. SharePoint can perform the same functions as a file share: there is item level security, and a recycle bin, and SharePoint Explorer view can be used to perform file share like actions. SharePoint Explorer's interface contains many of the same characteristics and functionality as Windows Explorer. These are still however many types of file not designed for storage in SharePoint. The standard kinds of documents to put into SharePoint are MS Office documents, but also PDFs and ZIP files. For SharePoint to crawl the content of these, additional ifilters must be installed and configured.

Other Considerations

Offline access is also a consideration. Tools like Outlook 2007 and Groove can be used to sync with SharePoint, but this is not as simple as using the local hard drive on a laptop. File Shares are also easier to replicate and backup. SharePoint is a complex mix of IIS, file shares and SQL Server data. SharePoint does not always integrate with some 3rd Party applications either. It is difficult to copy attachments to and from Lotus Notes clients for example. Lots of applications can see UNC paths but not HTTP. SQL Storage is also more expensive than file storage, so must be definite productivity benefit in moving to SharePoint and a clear ROI.

Using SharePoint requires training. Most users know how to upload a file to a share, and use Save As... and Open. But SharePoint is not as simple. There is an additional cost involved here, as well as the time taken to transition and train users with the new system. There is also training users how to move content around within SharePoint and how to navigate the system, as well as use new functionality like versioning and Check-in/out.

Linked Files and Documents
Linked documents and files cannot be run from a SharePoint site, as the dependency on an external sources isn’t captured in SharePoint. For example, the URL references created in a linked Excel file when it is uploaded to a SharePoint site are not translated by Excel, and the links will not work. The creator of an AutoCad file would be responsible for ensuring the file was either not linked to other files or are consistently created in the appropriate file format (*.dwf). In all situations, SharePoint is unable to resolve embedded links in documents/files.

Database, Configuration, and Log Files
In order to properly use database files, configuration files and log files, they need to be open and in a locked (writable) state. For example, in a normal file server scenario, shared MS Access databases need have several instances of the database open and locked to allow for users to update it. Similarly, log files and configuration files must be locked and in a writable state. Outlook *.pst files are designed to be used locally, as they have a one to one relationship with the *.pst file owner. SharePoint is not designed to manage locked files (.llck) and therefore it would not be a best use of the platform to run these types of files from a SharePoint site. They can, however, be stored in SharePoint, but would need to be downloaded to the local machine to work effectively. Common examples include: Access database files, Windows configuration files, application log files, Outlook personal stores and archive stores (.pst) and offline stores (.ost).

Large files

Large Audio/Video and Streaming Media and other large archive read only media such as DVDs, CDs storage (.iso, .wmv, .ram, .vhd) are too big and costly to store and share via SharePoint. Linking to these from SharePoint is the best option.

Application Developer Resources (i.e. Visual Studio)

Visual Studio and similar application development suites are designed so that developers can build applications and deploy them to others. This application work is often broken up into project files during development, with the goal of compiling the project files into a final executable file.

While the project files can be uploaded to SharePoint to be shared with other developers, the best practice is to use a file compression utility (i.e. WinZip) to collect and upload the *.zip file to SharePoint.

Source Control

While SharePoint is an excellent document control/document versioning tool, it is not designed to be replacement for a Source Code Control solution like to Visual Source Safe.

Application Distribution: Batch, Command Scripts, Executables (.exe, .vbs, .cmd, .bat)
SharePoint is not designed to be a host for Product or Application distribution similar to the functionality provided in Microsoft Systems Management Server (SMS), or as a replacement for a network server that is used to distribute application packages. The recommended application here would be to create a SharePoint site and provide hyperlinks to the server location where the application packages are stored.

Conclusion

Simply for storage, file servers are a better option, but for standard user generated content, SharePoint adds additional functionality that will make most users jobs easier. There will continue to be a need for some file storage however in most organizations.

Stephen Cummins, SharePoint MVP, runs the popular SharePoint blog www.spsfaq.com . He is a Microsoft Technologies Consultant who has specialised in SharePoint for the past seven years. He has managed in excess of thirty SharePoint Implementations to clients including: The Disney Corporation, Hewlett-Packard, Deloitte & Touche, Kraft Foods International, McAfee, BP, The International Criminal Court, European Patent Office and Intel.

Stephen is going to be heading up the Irish SharePoint User Group, which is due to launch in the second half of November. See https://www.sugie.org/ for details of the inaugural meeting!