The File Share Is Dead: Long Live SharePoint Document Libraries

The traditional collaborative file share has lived its 15-odd–year life well. From its roots in other network OSs, through its proliferation during the explosive growth of Windows NT, Windows 2000, and Windows Server 2003 file servers, to today, the file share served our needs. But it's fading into the sunset, and a new day is dawning: the era of collaborative document sharing using Windows SharePoint Services document libraries. To grasp the implications of the shift to document libraries, you'll need to understand first why they're destined to replace file shares in most common filesharing scenarios. (Sometimes, file shares still serve the purpose better than document libraries. For a look at these scenarios, see the sidebar "I'm Not Dead Yet!".) From there, you'll need to get a handle on the fundamentals of document library implementation: creating, configuring, and securing libraries and viewing, editing, and monitoring documents in those libraries.

By document libraries, I mean primarily typical information-worker shared folder scenarios, in which groups of users—a team, a department, or even an entire organization—share access to files for day-to-day reference and collaboration. SharePoint document libraries will very likely replace file shares in these scenarios. Document libraries enable capabilities that are crucial to an agile, collaborative enterprise—including checkout and monitoring, which I'll discuss here—as well as version history, content approval, workflow, and remote and offline access, which I'll cover in upcoming articles.

Creating a Document Library
Let's start with how to implement document libraries in Windows SharePoint Services 3.0 (the process is virtually identical in Microsoft Office SharePoint Server 2007). To create a document library from a standard SharePoint team site, or most other templates, either click View All Site Content in the Quick Launch bar and click Create, or click the Site Actions button and choose Create.

In the Libraries section, you can see what libraries are available, and your first task will be to determine what type of library you require. Document libraries are the closest equivalent to traditional, collaborative file shares. Picture libraries are specialized for graphics and include a useful thumbnails view and a well-implemented slide-show view. There are also form libraries, wiki page libraries, and (in SharePoint Server 2007) several other types of document libraries.

When you choose to create a document library, you're asked to enter a name and description, and you can configure the document library to appear in the left panel, Quick Launch navigation, and whether versioning is enabled. In the Document Template section of the page, which Figure 1 shows, you can also specify the type of document that's created when users click the New button in the document library.

If a document library will generally or exclusively contain one type of document, such as generic Microsoft Office Word, Excel, or PowerPoint, and if that type is in the Document Template drop-down list, select it. However, in certain situations you should choose None as the template:

• The template for the type of document you want to create when clicking the New button in the document library isn't listed.
• The library will contain a custom document type (e.g., Contracts, Expense Reports).
• The library will be used to create multiple document types.
• A document library will be populated only by uploading documents, not by clicking the New button.

After you've created the document library, you can modify each of these configurations in the document library settings by clicking the Settings button and choosing Document Library Settings. In fact, I urge you to go to the document library's settings immediately after creating the library, so that you can configure it to fully support the capabilities you require, such as forced check-out and version history.

Finally, if you expect to provide search for your document library, you might need to add IFilters, which are plug-ins that enable SharePoint to index specific document types, such as PDFs. The Microsoft article "No Adobe PDF documents are returned in the search results when you search a Windows SharePoint Services 3.0 Web Site" (http://support.microsoft.com/?kbid=927675) explains how to install the Adobe PDF IFilter and modify the registry to enable SharePoint search to crawl and index PDF documents. Be sure to install the IFilter early, before adding documents of that type to the library. SharePoint includes a number of IFilters for common document types, including Microsoft's own document types. Contact application vendors, such as Adobe Systems, for IFilters that support their document types.

Managing Security
You'll probably want to configure permissions, which can be assigned to any securable object in the SharePoint model—that is, a top-level site, subsite, library or list, folder, document, or item. By default, permissions are inherited from the parent object, so that permissions applied to the top-level site are inherited by all sites, libraries, and documents. But you can "break" the inheritance at any object in the hierarchy, then configure permissions on that object, which will then be inherited from that point downward.

To set permissions on a document library, open the library. Click Settings, Document Library Settings, then click Permissions for this document library. Current permissions are displayed, and the description bar shows the text This library inherits permissions from its parent web site. Click the Actions menu button, then click Edit Permissions, and confirm by clicking OK. Permissions previously inherited from the parent object will be copied as the default new explicit permissions for this library, and you can then add, remove, or modify permissions to meet your requirements. To change the permissions of users or groups, you can select groups or users and use commands in the Actions button menu (Remove User Permissions and Edit User Permissions). To add a new user or group and configure its permissions, click New, as Figure 2 shows.

Although the UI suggests that these are "user permissions," in actuality you can configure permissions for any user or group. Accounts can be SharePoint groups (created by clicking Site Actions, finding the Site Settings command, then navigating to People and Groups) or users or groups from the site's authentication provider(s) such as Active Directory (AD). As with Windows folder permissions, it's a best practice to manage permissions by using groups, not individual users, but there are always exceptions to that rule. I also recommend that you use SharePoint, rather than AD, groups because of the ease with which site administrators who are nontechnical users can manage SharePoint group memberships. Using SharePoint groups also makes it possible to configure SharePoint groups to enable access requests—a powerful permissions-management provisioning capability.

Be aware that once an object no longer inherits permissions from its parent, any changes to the parent won't "drill down" to the object. To revert an object to inheriting permissions from its parent, click the Actions button on the Permissions Settings page and choose Inherit Permissions. Doing so removes all explicit permissions. Unlike Windows NTFS permissions, a SharePoint object can't have a mixture of both inherited and explicit permissions: only one or the other.

   Previous  [1]  2  Next