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?