Make the most of a limited feature
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:
- Top-level folders—Which folders are immediately under the root, and who has the ability to create new top-level folders?
- Folder organization and naming—Do you want to organize folders on a geographic, business unit, or other basis? A public folder hierarchy is difficult to change once it's in place, so getting it right the first time is a good idea. You should establish a taxonomy for folder organization and communicate it to everyone responsible for creating or managing public folders. If your company also uses other repositories (e.g., file shares, SharePoint Portal Server), lay down rules for which content is stored where and how it's organized and named. Be sure to name folders so that people immediately understand what the folders contain. Figure 1 shows a public folder hierarchy that's easy to navigate because it's based on business units (i.e., company divisions) and geographical areas, and the folder names reinforce the organizational structure.
- Folder administration—Who's responsible for creating new folders? What logic drives folder creation? You don't want to force users to complete 14 forms before an administrator will create a new folder, but you also don't want to give everyone the freedom to create folders unchecked. Some large companies have allowed such freedom and the resulting chaos has taken months to sort out.
- Folder control—What are the default values for deleted item retention, storage quotas, age limits, and so on? Will you impose these values on a server-by-server basis, or will you use a system policy? Unfortunately, the mailbox manager doesn't process public folders, so age limits and quotas are the only ways to restrict what people can keep in public folders.
One idea for managing public folders is to move the default public folder container into a separate administrative group and assign a restricted set of users the permissions to manage the administrative group. Don't let this set of users or any other individuals create new top-level folders; keep the ability to create these folders separate (if possible) from day-to-day management tasks. Every time you introduce a new Exchange 2000 server into the organization, the installation procedure grants everyone the ability to create new top-level public folders. This bug is fixed in Exchange Server 2003 (formerly code-named Titanium), but when you deploy Exchange 2000 servers, you should check that the correct permissions remain in place and that folder creation remains restricted. Install all public folder servers during the early part of the deployment so that you can sort out permissions, replication schedules, ownership, and so on.
What clients will access the public folders? If you exclusively use MAPI clients, you're restricted to one top-level hierarchy (i.e., one root folder from which all other folders must branch). If you use IMAP4 or Web clients, you can create and use other hierarchies, but you need to have a good reason for doing so. For example, you might create a set of folders that a specific application uses and that only IMAP4 or Web clients need to access. The fact that public folders are free after you install Exchange might tip the balance in their favor. However, in most cases, a better answer, such as SharePoint Portal Server, probably exists.
In Exchange 2003, you can create new public folders from Exchange System Manager (ESM), so you can perform all management operations in one place. However, if you want to use a public folder to host a shared calendar, you should use Outlook to create the folder and select the appointment item option from the Create New Folder dialog box.
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.