Exchange and Groupware

Using public folders to share information

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 purchaserequisitions, a method to facilitate coauthoring of complex documents, or even away to let people share ideas and information. Groupware is software that helpspeople work together, and messaging software, such as Microsoft Exchange, canhelp you accomplish groupware tasks. This article explores Microsoft ExchangeServer's public folder groupware capabilities. (In the sidebar, "PublicFolder Strategy," page 124, I review the strategy behind public folderswith respect to groupware. Initially that strategy was quite simple, but recentdevelopments have changed things, so I describe how the strategy is evolving.) Iexplain what you can use public folders for, look at how you can implement themefficiently, and offer practical suggestions about deployment.

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

Customer project files and communications.
We allocate aset of public folders to each customer we work with. We store all communicationswith the customer (proposals, notes on visits to the customer, etc.) in onefolder and any project material (design documents, project plans) in another. Wealso record information about customers (contacts, mailing addresses, and phonenumbers).

Document repositories
A vast amount of information isavailable to our group from multiple sources. That information is useless unlessit is organized in a structured manner. Public folders help us with thatorganization. For example, we store white papers and articles about technologyin a set of folders. We store product documentation in another set of folders.We also use public folders to store PowerPoint presentations on the differenttopics we speak about.

Information from the Internet
A great deal of informationis available on the Internet. We use public folders to store information we getfrom the Internet, such as the messages sent to the mailing list for Exchange([email protected]). Storing this data in public folders gives us asingle point of contact for information that we find valuable. Havinginformation in one place speeds up access time. Individual consultants don'thave 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 sometimesdifficult, especially if you insert very large documents in multiple formats.Full-text retrieval engines come in handy here because they let you search theentire store in a couple of seconds rather than minutes.

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

Structure the public folder hierarchy
Users must be ableto find information within the public folders. The public folder hierarchy givesusers a map to navigate their way to information. The design of the top-levelhierarchy is important and largely depends on the structure of your company.Some companies organize the hierarchy by division, so for instance, themarketing division has its set of folders, the sales division another set, andso on. Other companies organize folders by geography so that each territory hasits folders, with organizational groupings under each territory, resulting inmarketing 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 ServerInformation and one for Exchange Services. The first is dedicated to informationabout the software, the second to consulting services that might interestcustomers. All the folders in this example have names that are easy tounderstand.

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

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

Decide between public folder replication and affinity
Youcan make public folder content available to users in remote sites viareplication or affinity. Replication means sending content to replica folders onservers in the remote sites, so data is always local. User access to data willalways be fast, and your network links won't be used to fetch information from aremote server. The more replicas, the more work Exchange has to do to pumpchanges out to all the different replicas, and that replication activity mightabsorb more valuable network bandwidth than affinity would. Reducing the numberof 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 nothold local content. Users must go over the network to a remote server to fetchinformation, so access is slower. However, affinity means that you alwaysmaintain a definitive, up-to-date source of information, and you don't havemultiple copies of documents and other items scattered in replicas across theorganization. Keep replicas to a minimum.

Plan the replication schedule
By default, Exchangereplicates public folder content every 15 minutes. If someone makes a change toa public folder, the change goes out in a special type of email message to everyserver that holds a replica of the folder. Note that all replicas are viewed asequal masters, so a change to one replica is as good as a change to another. Ifyour network is low in bandwidth, you'll want to restrict folder replicationduring the working day, perhaps replicating every hour or two hours. This tacticfrees bandwidth for interpersonal messages at the expense of having potentiallyout-of-date information on some servers. Nothing in life is free, so you have todecide whether you can afford the bandwidth to have frequent updates, scheduleless-frequent updates, or have replication messages share the network withinterpersonal mail.

Decide how to handle update conflicts
Potential for updateconflicts always exists in a network of equal master replicas. Conflicts happenwhen multiple updates occur to the same item in replicas in different sites. Theconflict won't be flagged when users update their local replica, because thelocal public information store does not know that other updates are in progresselsewhere. The conflict arises when you distribute the changes to the otherreplicas, causing Exchange to notice that it cannot apply the change because twoincompatible changes have occurred. Exchange uses a system of update numbers totrack such changes. The server flags the conflict, but human intelligence isrequired to resolve the problem. Exchange sends conflict notificationmessages 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 whatto do unless they have been trained, so make sure that you provide some simpleconflict resolution steps to anyone who might use public folders as a mechanismfor joint document authoring.

Set permissions carefully
Exchange controls access topublic 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 wantto be too restrictive, but you have to understand what the permissions do. Forexample, for public folders that you want to make available to non-authenticatedWeb clients, you must grant access to the special anonymous user. But the deletepermission is all-powerful in public folders because the public informationstore has no Deleted Items folder. Thus, if a user deletes an item from a publicfolder, that item is immediately removed from the store (and will be removedfrom all other replicas after the replication process finishes). Recovering anitem deleted in error from a public folder requires a complete restore ofPUB.EDB.

Watch offline replicas
Traveling users will be delightedto find that they can copy public folders and take them on their travels. Yousimply mark a public folder as a favorite and set the synchronization propertyso that the folder is available both online and offline, asScreen 4 shows.Thereafter, when you synchronize all folders, Exchange will move the contents ofthe selected public folders into the offline store (.ost file). Screen 4 shows that my offline copy of the MS Exchange Mailing List public folder holds3113items. Problems arise when people delete items from the offline folders. Anoffline folder is a slave replica of the server-based folder in the offlinestore, complete with the ACL. If the ACL says that you can delete items, theslave replica lets the deletes happen, and then sends the delete commands to theserver the next time you synchronize the folder. Imagine what would happen if acareless user took a copy of a folder containing very important information andthen 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 enablingtechnology is certainly present in the messaging engine and public informationstore. And what needs to happen now is for Microsoft, other software vendors,and system integrators to take advantage of the technology and build thegroupware applications on top of Exchange. I expect that this area will see alot of development over the next couple of years. Make sure that you get a solidmessaging 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. Sofar, few installations are considering the implementation of other groupwareapplications, such as making travel authorization requests via email based onExchange. The market has not really seen a mass of groupware products appearingto complement Exchange, either (remember, the product is only a year old).

That situation is changing as third-party vendors come to gripswith Microsoft's Messaging API (MAPI) and realize how best to integrate theirproducts with Exchange. For example, both Fulcrum FIND! and Verity SEARCH'97 areexcellent full-text search and retrieval engines, and both are available in anice integration for Exchange. Full-text retrieval engines help you retrieveinformation very fast, in most situations, in a couple of seconds. Fast accessto data is important, and from experience I can tell you that this point becomesmore important as users begin to use public folders in their work. Publicfolders let users put items (a message is an item, as is a Word document, anExcel 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, Microsoftenhanced Exchange's document publishing capabilities in 5.0, with theintroduction of anonymous Web-based access to public folders. You can now makepublic folder content available to anyone who has a Web browser.

Even before Exchange had officially been released, public folderswere sometimes proposed as the universal groupware panacea. Suitably furnishedwith 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 workflowdocuments. The range of applications that public folders could handle was(apparently) enormous, and the only limitation was the skill of the programmerwho created the e-forms. Microsoft used public folder capabilities as anoffensive weapon in its ongoing battle against Lotus Notes. The situation issomewhat different now, and public folders are perhaps less of a focus asExchange moves to fight new battles, most recently embracing Internet protocolsand standards in Exchange 5.0. Instead of expanding the existing e-formscapability, Exchange 5.0 permits access to public folders via Web browsers, thefirst indication of how HTML e-forms might be deployed in the future. I expectMicrosoft to re-emphasize the e-forms capability of public folders in thefuture, as outlined below.

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

Exchange e-forms are built with a dialect of Visual Basic (VB), so they areeasy to construct and bring into production. However, the e-forms are 16-bitapplications, and you can execute them only on platforms that support VB (forexample, UNIX and Macintosh users cannot use these forms), a gap that has becomeapparent as Exchange begins to support more and more client platforms. Groupwareapplications aren't much good if they eliminate large potential user populationsbecause of software incompatibilities. Although the Outlook WebView client andActive Messaging have introduced Web-based forms, we're still not at the stagewhere all clients can use the same forms.

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

JetForm's software is still proprietary technology, albeit somethingthat you can use now to develop workflow applications. If you can wait,developments in the wider Internet world might provide a set of protocols thatworkflow applications can use. The continuing development of Security MIME(S/MIME) is important because it will let you encrypt information enclosed indocuments exchanged between business partners. Extensions to Simple MailTransfer Protocol (SMTP) to incorporate some workflow commands are alsoimportant because they will let SMTP-capable systems, such as Exchange,participate in platform-independent workflow applications. We don't know whenall 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 anExchange-specific workflow engine in a future version of the server. Certainlysome rumblings coming out of Microsoft indicate that some workflow developmentsmight 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 existstoday rather than waiting for the future to arrive.