Public folders can be very useful tools in your Exchange organization. However, you just can’t create the folders and go. You must do a little planning. In this Daily Feature, I’ll show you some of the work that must go into planning for public folders in Exchange 2000.

Differences in Exchange 2000
As you might have heard, the concept of public folders has changed in Exchange 2000. Rather than having a single public folder tree like in Exchange 5.5, Exchange 2000 allows you to have multiple public folder trees on each server. Each of these individual public folder trees exists in its own database. Unfortunately, space limitations prevent me from discussing all of the ins and outs of the new public folder architecture. Since the focus of this article is on planning an Exchange organization, I’ll discuss public folder planning issues, rather than getting into the nitty gritty of how public folders work.

Public folder limitations
Before you get too deep into the planning process, there are a couple of things that you should know. I mentioned that Exchange 2000 allows you to have multiple public folder trees, each with its own individual database. I’ve seen companies try to assign a separate public folder tree to each department and let the individual departments manage their own public folder trees. While this isn’t necessarily a bad idea, there are some limitations that you should be aware of. First, Exchange 2000 permits a single server to have four storage groups, each containing a maximum of five databases. This means that you can only have a maximum of 20 databases per server, including those databases for user’s mailboxes. Therefore, don’t plan on having a dedicated public folder server with fifty public folder trees.

Another limitation is that Outlook 2000 is only capable of reading an Exchange server’s initial public folder tree. Any subsequent trees are invisible to it. To view multiple public folder trees, clients must use either Outlook Web Access or Windows Explorer. Therefore, if your clients use Outlook 2000 as their primary mail client, you’ll want to think twice about implementing multiple public folder trees until the next version of Outlook is released.

Planning the folders
The first step in planning your organization’s public folders is to understand exactly how the users will use them. Some companies use public folders as a discussion forum, while other companies use public folders to store files, such as human resources forms or software patches. Still other companies don’t use public folders at all.

Once you’ve decided who will be using public folders for what and how many public folder trees you want to use on each server, you’ll need to decide how the public folders should be distributed. For example, do you want to have a few folders on each server, or do you want one dedicated public folder server to handle everything? As you make such plans, you’ll also have to consider the issue of performance.

If a certain public folder exists on a single server and everyone in the organization uses that public folder, there’s a good chance that the server may get bogged down by traffic resulting from public folder access. In such a situation, it may be wise to replicate the public folders to other servers. By doing so, you can still maintain the public folders on a single server, but Exchange will automatically copy the public folder to other servers. User traffic is spread across multiple servers and doesn’t bog down one server.

If your Exchange organization will use multiple routing groups, you may want to consider replicating public folders across routing groups—if you’ll have users in each routing group accessing the public folders. The reason for this is that routing groups are typically separated by comparatively slow WAN connections. Having users access public folders from across a WAN connection can place unnecessary traffic on the connection, thus reducing the amount of bandwidth that’s available for other things.

However, if you replicate the public folders to a server that exists on the other side of the routing group, users in the other routing group will be able to access the public folders locally rather than having to pass through the WAN link. The users will get better performance, and the WAN link won’t be congested with as much traffic. Sure, there will be a lot of traffic flowing across the link during the initial replication, but this is a one-time process. Replication updates occur infrequently and tend to be small in size since only the items that have changed are replicated.

Once you’ve planned the basic architectural structure of your public folder stores, you need to make some plans about who will have rights to do what. If you decided to take the approach of letting each department manage their own public folder tree, this may not be as big of a job. However, if you are considering this, keep in mind that many times department heads know almost nothing about computers.

If you’re thinking of having the IT department manage the public folder trees, there are a few questions that you’ll need to answer before you actually create the public folders. Some of these questions are:

  • Who will have rights to create new top-level folders?
  • Who will have rights to create new sub folders?
  • Who will have rights to read each folder?
  • Who will have rights to post to each folder?

You’ll also have to address the issue of storage space. It’s easy for a public folder to get out of hand. Since your server only has so much hard disk space to work with, you’ll need to decide the maximum size to which the public folder database can grow and begin setting the maximum size of each folder based on the limit of this size. Remember that if your database will be limited to 10 GB of space, you don’t want to place a 10 GB limit on each individual folder. Instead, all of the folders together should have limits of no more than 10 GB total. I personally recommend setting the limits a little lower than the actual amount of space that you can spare so that you can make room for new folders as they are created.

You may be wondering what will prevent a public folder from reaching its size limit and then being too full to ever do anything else with. Exchange contains several mechanisms for keeping the size down on public folders. First, you can set age limits on the contents of public folders. This means that old items will be automatically removed. Another option is to limit the size of a post or of the attachments that a post contains. This will prevent users from posting huge files that quickly cause the server to run out of space.

Conclusion
You’re just about ready to begin creating the public folders. There’s just one more thing that you need to plan for, and that’s the folder’s naming conventions. A public folder’s name can be up to 256 characters long. Obviously, this gives you a lot of freedom when creating folder names. Just keep in mind that most clients won’t be able to display the entire folder name if you opt to go with a really long name. I’ve also heard rumors that some clients have trouble accessing public folders that use special characters in the folder name. However, I’ve been unable to confirm these rumors.