Exchange and Groupware

How can you use groupware? The answer depends on the problems you are trying to solve in your company. You might need a workflow application to speed up purchase requisitions, a method to facilitate coauthoring of complex documents, or even a way to let people share ideas and information. Groupware is software that helps people work together, and messaging software, such as Microsoft Exchange, can help you accomplish groupware tasks. This article explores Microsoft Exchange Server's public folder groupware capabilities. (In the sidebar, "Public Folder Strategy," page 124, I review the strategy behind public folders with respect to groupware. Initially that strategy was quite simple, but recent developments have changed things, so I describe how the strategy is evolving.) I explain what you can use public folders for, look at how you can implement them efficiently, and offer practical suggestions about deployment.

Uses for Public Folders
I work with a group of consultants, most of whom spend considerable time working outside the office. Easy access to information and the ability to share documents with colleagues are the major advantages we gain from public folders. We use public folders for customer project files, as document repositories, and to store information we get from the Internet.

Customer project files and communications.
We allocate a set of public folders to each customer we work with. We store all communications with the customer (proposals, notes on visits to the customer, etc.) in one folder and any project material (design documents, project plans) in another. We also record information about customers (contacts, mailing addresses, and phone numbers).

Document repositories
A vast amount of information is available to our group from multiple sources. That information is useless unless it is organized in a structured manner. Public folders help us with that organization. For example, we store white papers and articles about technology in a set of folders. We store product documentation in another set of folders. We also use public folders to store PowerPoint presentations on the different topics we speak about.

Information from the Internet
A great deal of information is available on the Internet. We use public folders to store information we get from the Internet, such as the messages sent to the mailing list for Exchange (ms-exchange@insite.co.uk). Storing this data in public folders gives us a single point of contact for information that we find valuable. Having information in one place speeds up access time. Individual consultants don't have to search through many different sources to find what they are looking for, unless our public folders don't include the specific information they need.

Putting data into public folders is easy; retrieving it is sometimes difficult, especially if you insert very large documents in multiple formats. Full-text retrieval engines come in handy here because they let you search the entire store in a couple of seconds rather than minutes.

Implementing Public Folders
As you can see, we hold a reasonable amount of commercially sensitive information in our public folders. We deal with a lot of customers and have a lot of information to store. For these reasons, we carefully structure the public folder hierarchy and set the permissions on each folder. Let's look at these and other important points to bear in mind when implementing public folders.

Structure the public folder hierarchy
Users must be able to find information within the public folders. The public folder hierarchy gives users a map to navigate their way to information. The design of the top-level hierarchy is important and largely depends on the structure of your company. Some companies organize the hierarchy by division, so for instance, the marketing division has its set of folders, the sales division another set, and so on. Other companies organize folders by geography so that each territory has its folders, with organizational groupings under each territory, resulting in marketing and sales folders for each territory.

Screen 1 illustrates a reasonably well-structured public folder hierarchy. In this example, you see two top-level folders, one for Exchange Server Information and one for Exchange Services. The first is dedicated to information about the software, the second to consulting services that might interest customers. All the folders in this example have names that are easy to understand.

Screen 2 shows how a well-structured hierarchy can easily descend into confusion. What function do the folders named frank, jrw.copsi1, jrw.copsi2, Malmoe, and Kees serve? Some duplication is also obvious (MS Exchange Mailing List and MSA-Exchange Mail-List, and maybe even MSXNews). Duplicate folders probably result from multiple sites creating public folders for the same purpose, so you need to coordinate folder creation in distributed environments.

Control top-level folder creation
You can achieve a structured public folder hierarchy only if you restrict top-level folder creation. If people are allowed to create folders at the top level of the hierarchy, the potential is greater for individuals to affect the overall structure of the hierarchy. Restrict this ability to a nominated set of individuals, and carefully monitor the structure as it evolves. The existence of folders such as frank in the hierarchy in Screen 2 shows that some people have set up public folders without paying attention to naming standards. Screen 3, shows how to fix the problem by restricting top-level folder creation to a nominated set of users. You can use distribution lists to select users who have permission to create folders, and omit the other users. This permission is sitewide and has no effect outside the site. You need to coordinate folder creation policy across all sites.

Decide between public folder replication and affinity
You can make public folder content available to users in remote sites via replication or affinity. Replication means sending content to replica folders on servers in the remote sites, so data is always local. User access to data will always be fast, and your network links won't be used to fetch information from a remote server. The more replicas, the more work Exchange has to do to pump changes out to all the different replicas, and that replication activity might absorb more valuable network bandwidth than affinity would. Reducing the number of replicas also reduces the chance that document update conflicts will occur. Affinity means that you establish paths to servers that hold the data and do not hold local content. Users must go over the network to a remote server to fetch information, so access is slower. However, affinity means that you always maintain a definitive, up-to-date source of information, and you don't have multiple copies of documents and other items scattered in replicas across the organization. Keep replicas to a minimum.

Plan the replication schedule
By default, Exchange replicates public folder content every 15 minutes. If someone makes a change to a public folder, the change goes out in a special type of email message to every server that holds a replica of the folder. Note that all replicas are viewed as equal masters, so a change to one replica is as good as a change to another. If your network is low in bandwidth, you'll want to restrict folder replication during the working day, perhaps replicating every hour or two hours. This tactic frees bandwidth for interpersonal messages at the expense of having potentially out-of-date information on some servers. Nothing in life is free, so you have to decide whether you can afford the bandwidth to have frequent updates, schedule less-frequent updates, or have replication messages share the network with interpersonal mail.

Decide how to handle update conflicts
Potential for update conflicts always exists in a network of equal master replicas. Conflicts happen when multiple updates occur to the same item in replicas in different sites. The conflict won't be flagged when users update their local replica, because the local public information store does not know that other updates are in progress elsewhere. The conflict arises when you distribute the changes to the other replicas, causing Exchange to notice that it cannot apply the change because two incompatible changes have occurred. Exchange uses a system of update numbers to track such changes. The server flags the conflict, but human intelligence is required to resolve the problem. Exchange sends conflict notification messages to the users who have caused the conflict (and to the folder owners) and expects the users to resolve the conflict. Of course, users won't know what to do unless they have been trained, so make sure that you provide some simple conflict resolution steps to anyone who might use public folders as a mechanism for joint document authoring.

Set permissions carefully
Exchange controls access to public folders with a set of permissions held in an access control list (ACL). Permissions determine exactly what a user can do with a folder. You don't want to be too restrictive, but you have to understand what the permissions do. For example, for public folders that you want to make available to non-authenticated Web clients, you must grant access to the special anonymous user. But the delete permission is all-powerful in public folders because the public information store has no Deleted Items folder. Thus, if a user deletes an item from a public folder, that item is immediately removed from the store (and will be removed from all other replicas after the replication process finishes). Recovering an item deleted in error from a public folder requires a complete restore of PUB.EDB.

Watch offline replicas
Traveling users will be delighted to find that they can copy public folders and take them on their travels. You simply mark a public folder as a favorite and set the synchronization property so that the folder is available both online and offline, as Screen 4 shows. Thereafter, when you synchronize all folders, Exchange will move the contents of the selected public folders into the offline store (.ost file). Screen 4 shows that my offline copy of the MS Exchange Mailing List public folder holds 3113items. Problems arise when people delete items from the offline folders. An offline folder is a slave replica of the server-based folder in the offline store, complete with the ACL. If the ACL says that you can delete items, the slave replica lets the deletes happen, and then sends the delete commands to the server the next time you synchronize the folder. Imagine what would happen if a careless user took a copy of a folder containing very important information and then made a lot of offline deletes just to free up some space on a PC?

Plan Ahead
Exchange Server is a great base platform for groupware. The enabling technology is certainly present in the messaging engine and public information store. And what needs to happen now is for Microsoft, other software vendors, and system integrators to take advantage of the technology and build the groupware applications on top of Exchange. I expect that this area will see a lot of development over the next couple of years. Make sure that you get a solid messaging infrastructure in place, and don't let anarchy rule in public folders. You'll be in great shape to take advantage of new developments as they arise.

Exchange is relatively new, and most deployments focus on email. So far, few installations are considering the implementation of other groupware applications, such as making travel authorization requests via email based on Exchange. The market has not really seen a mass of groupware products appearing to complement Exchange, either (remember, the product is only a year old).

That situation is changing as third-party vendors come to grips with Microsoft's Messaging API (MAPI) and realize how best to integrate their products with Exchange. For example, both Fulcrum FIND! and Verity SEARCH'97 are excellent full-text search and retrieval engines, and both are available in a nice integration for Exchange. Full-text retrieval engines help you retrieve information very fast, in most situations, in a couple of seconds. Fast access to data is important, and from experience I can tell you that this point becomes more important as users begin to use public folders in their work. Public folders let users put items (a message is an item, as is a Word document, an Excel spreadsheet, and an electronic form­e-form) into

containers to share with other users throughout an Exchange organization. Microsoft is also adding functionality to Exchange. For example, Microsoft enhanced Exchange's document publishing capabilities in 5.0, with the introduction of anonymous Web-based access to public folders. You can now make public folder content available to anyone who has a Web browser.

Even before Exchange had officially been released, public folders were sometimes proposed as the universal groupware panacea. Suitably furnished with an appropriate e-form, a public folder could host a discussion forum.

With a different e-form, a public folder could be a repository for workflow documents. The range of applications that public folders could handle was (apparently) enormous, and the only limitation was the skill of the programmer who created the e-forms. Microsoft used public folder capabilities as an offensive weapon in its ongoing battle against Lotus Notes. The situation is somewhat different now, and public folders are perhaps less of a focus as Exchange moves to fight new battles, most recently embracing Internet protocols and standards in Exchange 5.0. Instead of expanding the existing e-forms capability, Exchange 5.0 permits access to public folders via Web browsers, the first indication of how HTML e-forms might be deployed in the future. I expect Microsoft to re-emphasize the e-forms capability of public folders in the future, as outlined below.

The strategy of using e-forms and public folders for custom groupware applications has faded as Exchange matures, for two reasons: First, because of platform dependency, the current implementation of e-forms inside Exchange is flawed, perhaps fatally so; and second, Internet-based technologies are set to take over at least some of the role that had been envisioned for public folders.

Exchange e-forms are built with a dialect of Visual Basic (VB), so they are easy to construct and bring into production. However, the e-forms are 16-bit applications, and you can execute them only on platforms that support VB (for example, UNIX and Macintosh users cannot use these forms), a gap that has become apparent as Exchange begins to support more and more client platforms. Groupware applications aren't much good if they eliminate large potential user populations because of software incompatibilities. Although the Outlook WebView client and Active Messaging have introduced Web-based forms, we're still not at the stage where all clients can use the same forms.

Microsoft has incorporated support for all the important Internet protocols in Exchange 5.0 and promises to keep up to date with new developments as messaging protocols mature in the Internet community. We can, for instance, expect the next release of Exchange to support the IMAP4 messaging protocol. The Internet has not embraced groupware applications to date. But, applications that let you build discussion forums using Web technology (Digital's AltaVista Forum is a good example) and early versions of workflow applications are appearing. JetForm's recent announcement of support for Microsoft's Active Messaging component is a good pointer for the future. Active Messaging is, of course, the part of Exchange that supports Web client access to the functionality Exchange servers offer. JetForm is building software to let Web clients participate in workflow applications, so you can now have workflow documents circulating around a much wider user community than before.

JetForm's software is still proprietary technology, albeit something that you can use now to develop workflow applications. If you can wait, developments in the wider Internet world might provide a set of protocols that workflow applications can use. The continuing development of Security MIME (S/MIME) is important because it will let you encrypt information enclosed in documents exchanged between business partners. Extensions to Simple Mail Transfer Protocol (SMTP) to incorporate some workflow commands are also important because they will let SMTP-capable systems, such as Exchange, participate in platform-independent workflow applications. We don't know when all these protocols will settle down and be incorporated in mail servers. Several years might pass before true platform-independent workflow is viable. Microsoft might decide not to wait and go ahead and introduce an Exchange-specific workflow engine in a future version of the server. Certainly some rumblings coming out of Microsoft indicate that some workflow developments might happen sooner rather than later. No one can wait for the future to arrive, so if workflow is important to you now, consider using technology that exists today rather than waiting for the future to arrive.