Using Exchange Public Folders

On the surface, Exchange Server public folders seem to add a lot of functionality to the product. Having a place to hold shared information that all users or selected groups of users can access through Messaging API (MAPI), IMAP4, Network News Transfer Protocol (NNTP) or Web clients is great. The ability to associate electronic forms with public folders to build applications is even better, even if those forms are limited to MAPI and Web clients. The challenge is figuring out how and when to use public folders in an Exchange deployment.

Here are some questions that you might consider when drawing up a public folder design. When is it best to use public folders, and when are network file shares more appropriate? Should I avoid public folders and deploy Microsoft SharePoint Portal Server or a straightforward Web server instead? What training must I provide to help users create and use public folders? What impact will public folder replication have on the network, and what steps can I take to manage the traffic? A look at the key questions surrounding public folder deployment and management will help you lay out a public folder design.

Public Folder Goals
To some degree, systems designers and administrators don't know what to do with public folders. Perhaps the fault is Microsoft's because the company has never been able to state just what public folders are good for. Before Microsoft launched Exchange in 1996, public folders seemed to offer an exciting platform for electronic forms and collaboration. You could use the Visual Basic (VB)­like Exchange Forms Designer to build all manner of electronic forms to serve many purposes such as travel requests, expense tracking, and sales calls reporting. You could set up public folders to be the base for online discussion forums, something that was in line with the name Microsoft used for public folders during their development: public fora.

However, the result wasn't good. Exchange Forms Designer was reasonably easy to work with, but it produced 16-bit code that ran slowly, especially when a folder contained more than a few items. You couldn't question Microsoft's earnest intent regarding public folders, but slow performance and the inability to support all platforms marked Exchange Forms Designer's quick end. Remember that in those days, Exchange supported a DOS client, so the 16-bit platform was important. The electronic forms situation has certainly improved over the years, and you can now use Outlook to generate sophisticated and powerful forms. Folder performance is better too, but don't expect instant access to a folder that contains several thousand items, especially if the replica you use isn't colocated on your mailbox server.

The other major use of public folders is as a replacement for network file shares*the logic being that it's much easier for users to navigate public folders than a fragmented set of network shares. Public folders can successfully take the place of network shares, but only if you take care to create an appropriate folder hierarchy and maintain the folders, which many administrators don't do. Using public folders to hold documents that change frequently (e.g., project updates) isn't wise because of the replication load that changes generate. Exchange performs public folder replication on an item level (i.e., at the message or document level) and doesn't support delta changes, so if you change one word in a large Microsoft PowerPoint presentation or Microsoft Word document, Exchange must replicate the complete item instead of just the changed data to all the servers that hold folder replicas. Public folders make good repositories for static data such as policy and procedure information because replication doesn't occur unless someone changes an item in a folder.

Few administrators are eager to store more than a couple hundred files in a network share, whereas they seem quite happy to accumulate many more items in a public folder. Just like mailbox folders, public folders can hold thousands of items. For example, any public folder that acts as an archive for a busy email distribution list (DL) can quickly capture large numbers of items.

Fortunately, public folder administration is easier today than ever before. Some early disaster areas, such as the need for the infamous Directory Service/Information Store (DS/IS) consistency adjuster, have been eliminated, and replication typically flows smoothly. For instance, on an Exchange 2000 Server server, you don't have to guard against some other administrator rehoming all the public folders from their original site into his or her site or removing a complete set of folders from the hierarchy in a well-intentioned attempt to clean things up. As usual, however, the success of public folders depends on a solid design, so let's begin there.

Public Folder Design Principles
As you would for any repository intended as a source of information for users, you need to put in some work to design a good structure for public folders. A well-designed hierarchy is easy for users to navigate and easy for administrators to manage. The design should address the following points:

Whatever design you use, make sure that top-level folder creation is restricted to a very small number of users and, preferably, secured through one universal security group. If you let users create a folder anywhere in the hierarchy, they will, and you can end up with a horrible mess.