Imagine buying a first-class seat on an airplane, then standing up for the entire flight. You might unknowingly be echoing such pointless behavior if you aren't using Exchange Server's powerful public-folder features. Public folders can help you manage group communications, mailing-list and newsgroup traffic, application development—even resource (e.g., conference room, VCR) allocation.
What's a Public Folder?
The first step to effectively using public folders is to understand their purpose. Exchange Server stores all mail in folders. Your Inbox is a folder; so are the Sent Items and Deleted Items containers. Public folders are different from these folders in that many users can share a public folder's content. Exchange Server can automatically replicate public folders' contents between servers; all you need to do is create replicas where you want them and set the replication schedule. (For information about how to replicate public folders, see Tony Redmond, "Managing Public Folder Replication," June 1998.)
You can index public folders, too, so that they're searchable from Microsoft Outlook or the Web. With Exchange Server 5.5, you must use Microsoft Site Server to index the folders. Exchange 2000 Server integrates indexing functionality; you simply set the folder properties to indicate that you want to index the folder, then Outlook 2000 clients can search the folders to their hearts' content. Better still, you can use these folders as a base for applications that create, modify, or act on messages sent to the folder. Let's look at some of the ways you can use public folders.
Because public folders are public, you can use them to share information among groups in your organization. This usage seems painfully obvious, but plenty of administrators never think about the potential that shared-information resources have for users. For example, you can create public folders that help project teams share documents and discuss issues related to projects; this solution is often more efficient—for both the team members and your Exchange Server machines—than using distribution lists (DLs). You can assign permissions to public folders so that you can determine which users see the folders you've created and what those users can do with the folders.
Another handy use for public folders is as a collection point for messages that multiple people might want to view. For example, consider your customer service organization. You could configure the email address email@example.com to point to a public folder so that everyone on the customer service team can see messages from your customers. No doubt you can think of several other applications for this function—I know our company's Water Cooler public folder is popular.
Get a Grip on Mailing Lists
Internet mailing lists are a terrific source of information and peer support. My favorites include swynk.com's Microsoft Exchange Discussions mailing list (http://ls.swynk.com/scripts/lyris.pl) and Martin Tuip's eGroups Exchange2000 list (http://www.egroups.com/community/exchange2000). These lists, however, can generate a lot of messages—I get about 450 mailing-list messages per day. I don't want all that email flooding my Inbox, and I certainly don't want more than one copy of each message entering my network because several people subscribe to the list. The solution is to create a public folder for each list, then let my users access that folder whenever they want. This scenario lets me maintain one point of access for each list. Users can choose whether to read the list. And I never need to worry about the mess that ensues when a user leaves the organization and the user's incoming mailing-list messages start bouncing.
How do you make this setup work? Each public folder has an associated SMTP address. (If you're using Exchange 2000, you'll need to mail-enable the folder.) So, begin by creating a folder for each desired mailing list, giving each folder an SMTP address. Next, you can use Outlook to assign permissions for the folder as appropriate. (For example, you probably won't want to let users arbitrarily remove messages and—depending on the mailing list—you might want to restrict who can send or read messages from particular lists. You might want to let anonymous users read or send messages too.) Also, you might want to set a default view for the folder, although your users will probably override the default.
In Outlook, open a new message. Select the View From Field command to reveal the From field. Manually enter the public folder's SMTP address, or click From and select the address from the Global Address List (GAL). Send the message to the mailing list's subscription address. Wait a few minutes for the message to reach the list server; a confirmation message from the mailing-list processor will soon appear in the public folder. (Some list servers require you to answer the confirmation message.) When you notice list messages beginning to appear in the folder, you'll know you're in good shape. Don't forget to configure suitable public-folder aging settings so that the folder doesn't grow without limit, and don't forget to unsubscribe the folder from the mailing list before you delete the folder.
Spread the News
Like mailing lists, Internet newsgroups can be valuable sources of information about topics ranging from systems administration to bonsai gardening. Microsoft maintains an extensive set of support newsgroups in the microsoft.public news hierarchy, and other vendors provide similar groups. Newsgroup-message transfers generally use the Network News Transfer Protocol (NNTP). In Exchange Server 5.5, the Internet News Server (INS) provides NNTP; in Exchange 2000, the NNTP service provides the protocol. You can configure either the INS or NNTP service to request articles from a remote server (aka a pull feed) or to let a remote server send articles on a schedule that the remote server sets (aka a push feed). As the articles arrive on your server, Exchange Server stores them in folders under the Internet Newsgroups public folder. (For example, messages in the microsoft.public.access.macros newsgroup reside in a public folder named macros, which resides in Internet Newsgroups/Microsoft/public/access.) Thanks to this arrangement, public-folder clients can easily locate the folders that they're interested in.
After you specify the newsgroups that you want to receive and whether your server will use a pull or push feed, you'll notice that your public-folder hierarchy updates to reflect the newsgroup structure. Now is a good time to establish replicas of the folders so that you can begin replicating the contents while the folders are still fairly small. Bear in mind that a full feed of all active newsgroups exceeds 2GB of data per day, so even a small subset of groups might generate many more messages than you intend to keep. Be sure to set age limits on the folders; these limits should reflect how long you want to keep content. Managing the INS or NNTP service is fairly straightforward, with one Exchange 2000-specific note: Because Exchange 2000 permits multiple storage groups (SGs), you can put your newsgroup feeds into a separate SG that has circular logging turned on. Circular logging is rarely appropriate but makes sense in this case because newsgroup traffic can quickly generate a large volume of transaction-log data that you don't need to keep. As a bonus, you won't need to back up the newsgroup SG as often, or at all, because you can always request a content refresh from your upstream NNTP provider.
Public folders make a good platform for developing applications too. You can replicate the folders and write code that uses Collaboration Data Objects (CDO) to create, manipulate, or modify items in the folders; therefore, public folders are a natural way to store items such as trouble tickets and Help desk requests. (Microsoft offers several online sample applications, including a sample Help desk management application that you can easily customize.)
In Exchange Server 5.5, you can also use the Microsoft Exchange Event Service to write scripts that certain events, including the arrival of new messages, trigger. This service gives you the flexibility to write applications that carry out certain actions when email arrives. By combining your own scripts with a public folder, you can easily build applications that automate manual processes. With a bit more work, you can write sophisticated workflow and routing applications.
Exchange 2000 ups the ante by letting you maintain multiple public-folder hierarchies (i.e., trees); you can dedicate individual trees to particular applications. Future releases of other Microsoft products will undoubtedly leverage this capability to give you a way to deploy applications throughout your network. Outlook Web Access (OWA) 2000 already lets you use multiple public-folder hierarchies, but more power will come from promising tools such as the Office Designer tool in the next version of Microsoft Office (code-named Office 10). This tool will let you quickly build applications that run from, and store data in, a public-folder hierarchy. By creating multiple hierarchies, you can control who has access and how your data replicates.
Besides implementing the strategies I've presented, stay on the lookout for third-party tools that can help you find even more uses for public folders. (See the sidebar "Book 'Em, Dano," for an example of such a tool.) Any purchase is an investment, and Exchange Server is no different. Why not get your money's worth and take advantage of everything Exchange Server has to offer—including the humble public folder?