Improve Document Management with Sharepoint Portal Server

Microsoft moved one step closer to releasing its document-management server with last week's announcement that the server formerly code-named "Tahoe" would be known as the SharePoint Portal Server, and that Release Candidate 1 (RC1) for SharePoint is now available.

You may be thinking that Microsoft already has a document-management server—Exchange Server. You can store documents in Exchange Server Public Folders, can't you?

Think again. Exchange Server has distinct advantages as a document-storage server but offers little in the way of actual document management.

Here's a situation in which Exchange works well: Suppose you use Exchange Public Folders to store documents such as human-resources policies. Saving Microsoft Office documents to Public Folders is easy with the File, Send To, Exchange Folder command in most Office programs. Users can keep the latest versions of such company documents offline by putting a folder in Favorites and synchronizing regularly.

When more than one or two people need to update the documents, however, I don't recommend using Public Folders because Exchange Server provides no check-in/check-out function or version management. Two people trying to update the same document results in a conflict message, and then they must try to merge the two documents or sort out which copy to keep.

Exchange works this way because of how it stores documents and how Outlook opens them. Look at a document in an Exchange or Outlook folder using either the mdbvu32.exe tool on the Exchange CD, or use the new Outlook Spy tool that exposes Outlook, Collaboration Data Objects (CDO), and Extended Messaging API (MAPI) properties. Such a document item has its own application-related message class (e.g., IPM.Document.Word.Document.8), but the document data is stored as an attachment that functions the same as all other Outlook file attachments.

When you open an attachment from an Outlook item, Outlook saves the attachment to a temporary file on the local hard disk and then opens that saved file in the appropriate application. So if April and Miguel open the same Word document from a public folder, they're not working on the same file. April uses the temporary file that Outlook saved locally on her hard disk, while Miguel modifies his local copy. When they save their changes and close Word, Outlook tries to copy the updated file back into the original item. If Exchange Server gets two different updates for that item, it issues a conflict notice.

Documents stored in Exchange folders work the same way, with one difference: Opening an IPM.Document.* item automatically opens the attached file. You'd never want this to happen with ordinary attachments in email messages, of course, since it could spread viruses in file attachments.

A true document-management application should use a different approach. One method is check-in/check-out. For example, when April needs to work on a document, she checks it out. No one else can work on that document until she checks it in. Some document-management programs also support merging changes from multiple users into a single document rather than enforcing sequential access through check-in/check-out.

Document-management servers—including SharePoint—also typically provide full-text indexing. Exchange 5.5 and earlier versions require a separate program for indexing the contents of documents in Public Folders. Exchange 2000 has its own indexing engine and displays results to Outlook users through the Advanced Find dialog box. Read the white paper on Exchange 2000 best indexing practices to find out more about this feature. You will find tips on how to tell Outlook users what to expect.

If you want to use Exchange Server as a document-management server, investigate third-party add-ins from 80-20, Eastman Software, Hummingbird and other companies.