Introduction to Public Folders

In the chapters prior to this, we've mentioned the term public folder several times and we've even examined how to configure policies for them, but we've not really introduced public folders or their purpose in the Exchange infrastructure. If you've used Usenet newsgroups, you've got a basic idea of one type of data that can be stored in public folders but Exchange provides much more than just newsgroups in its public folders!

Public folders are basically a storage location that can be used to store various types of information, such as email, documents, multimedia files, and so on, for sharing with many users. Users can access Exchange public folders natively within the organization using the Outlook client. In addition, public folders can be accessed via Hypertext Transfer Protocol (HTTP) and the venerable Network News Transfer Protocol (NNTP) by users who might be located outside of your organization's network.

As you might well suspect by now, public folders are created and located in public folder stores on Exchange servers. Public folders are mail-enabled and exist as objects within Active Directory. Public folders are arranged hierarchically in a tree structure known appropriately enough as the public folder tree. Parent folders contain child folders, and the folders that exist directly under the root of the public folder tree are called top-level folders. One of the more unique, and potentially troublesome, things about public folders is that they can actually be created and configured from within Outlook. We examine this more later in this chapter.

As mentioned previously, public folders can be accessed by both internal and external clients assuming that you've configured the public folder permissions for such. Internal clients connect to the public folders using Messaging Application Programming Interface (MAPI) compliant Outlook, HTTP, or NNTP, as previously discussed. Now that you have a basic idea of what a public folder is, you might be wondering what the need for public folders is. Public folders have virtually endless possible uses and are only limited by your imagination. Perhaps the most common uses for public folders are hosting Usenet newsgroups for internal clients, hosting Usenet newsgroups for external clients (such as microsoft.public.cert.mcse), providing a storage location for Outlook forms, and providing a discussion area for internal users similar to a newsgroup.

Public folders in Exchange Server 2003 have some nice features of which you should be aware:

• Users can post email messages directly to public folders, such as to participate in an ongoing discussion.

• Users can send email messages to the email address of the public folder, thus allowing the message to be posted in the folder.

• Public folders can be stored in multiple public folder trees via replication to increase their availability and reduce wide area network (WAN) link usage.

• Public folders can be accessed using a uniform resource locator (URL).

• Like mailbox stores, public folders can also be full-text indexed to make searches against them more efficient for the user.

Public Folder Trees

As mentioned previously, public folders are located in public folder trees, which are located on Exchange servers. When the Exchange installation is performed on a server, one default public folder store and public folder tree are created. The default public folder tree is thus replicated to all public folder servers by default. You can, however, create additional public folder trees as your organization might require. In the next paragraphs, we examine the specifics of default public folder trees and general-purpose public folder trees.

The Default Public Folder Tree

As mentioned previously, the default public folder tree is created automatically with the Exchange installation and is configured to automatically replicate to all public folder servers by default. This is the public folder tree that you will see listed in the Exchange System Manager as "Public Folders" and in Outlook as "All Public Folders."

Clients can access the default public folder tree using MAPI, HTTP, or NNTP. There can be only one public folder tree that can be accessed via MAPI, and that is the default public folder tree. As we discuss in the next section, all general-purpose public folder trees are accessed by using HTTP or NNTP. The default public folder tree contains the listing of all public folders located within that tree but does not contain the content of these folders. The content remains in its original location and is only referenced by the default public folder tree an important distinction to remember.

General-Purpose Public Folder Trees

General-purpose public folder trees are typically created to house custom applications and data that might be pertinent to only one department within your organization. As an example, you might create one public folder tree to store various information that will be used by the Accounting department for research and other data. You could then create another public folder tree for your Engineering department to provide a centralized location to store research and development information for ongoing projects.

General-purpose public folder trees can be configured to replicate to any selected Exchange 2000 Server or Exchange Server 2003 public folder server, thus allowing you granular control over where they are stored. Access to these public folder trees is via HTTP or NNTP only, thus you need to configure your Outlook clients to access them using the Folder Home Page feature. In addition, to allow users to access the general-purpose public folder trees, you need to create and configure an HTTP virtual server or virtual directory. We discuss both of these items later in this chapter.

Public Folder Permissions

You can configure permissions on most every object within Active Directory (with a few notable exceptions), and public folders are no exception. Like other directory objects, a public folder inherits its permissions from its parent object. A top-level public folder gets its default permissions from the administrative group to which it belongs, whereas a child folder inherits its permissions from the parent folder under which it is located in the public folder tree.

Like NTFS permissions, public folder permissions are assigned by administrators (and public folder creators) to specify which users or security groups are allowed to perform specified actions in that public folder. Public folder permissions vary from NTFS permissions, however, in that you can assign both client access permissions and administrative permissions to a public folder.

Although at time of creation, a public folder inherits the permissions of its parent object, changes made subsequently to the parent object are not automatically propagated to the child object. You can force the permissions on the parent object to be propagated to the child object by manually propagating the permissions from the parent object. Note that this process overwrites the existing permissions configured on the child object.

The three categories of public folder permissions are detailed in Table 6.1.

Table 6.1. Examining the Various Exchange Public Folder Permissions

Permission Type	Description
Client permissions	Used to specify which clients (users) are to have access to the public folder. For example, you can specify which users are allowed to have read permissions and which users are allowed to have read/write permissions.
Directory rights	Used to specify which users are allowed to perform configuration on the mail-enabled public folder object in Active Directory.
Administrative rights	Used to specify administrative rights to public folders to control which administrators are allowed to exercise administrative control over a specific public folder.

We examine each type of public folder permission in more detail in the following sections.

Client Permissions

The client permissions on a public folder are a bit different than what you might typically be familiar with when configuring NTFS permissions. As you can see in Figure 6.1, client permissions revolve around roles.

Figure 6.1. Examining public folder client permissions.

You can choose from the following roles:

• Owner The user has full permissions on the public folder and can create, read, modify, and delete all items contained in the public folder. The user can also create new child folders and can change permissions on child folders.

• Publishing Editor The user has permission to create, read, modify, and delete all items within the public folder. The user can also create new child folders within the public folder.

• Editor The user has permission to create, read, modify, and delete all items in the public folder.

• Publishing Author The user has permission to create and read items in the public folder. The user can also modify and delete items they have created as well as create new child folders within the public folder.

• Author The user has permission to create and read items in the public folder. The user can also modify and delete items they have created within the public folder.

• Nonediting Author The user has permission to create and read items in the public folder.

• Reviewer The user has permission only to read items in the public folder.

• Contributor The user has permission to create new items in the public folder but cannot view the contents of the folder.

• None The user has no permissions configured for the public folder.

Directory Rights

By configuring the directory rights on a public folder, you can configure the standard NTFS permissions that you might be familiar with from the public folder object within Active Directory. The Directory Rights dialog box with a sample public folder is shown in Figure 6.2.

Figure 6.2. Directory rights allow you to control who can configure permissions on a public folder.

When configuring directory rights, you should be aware of the default status of the following groups:

• Domain Admins Members of the Domain Admins group are responsible for all administrative tasks within their domain. They can manage user accounts, contacts, groups, mailboxes, client computers, and servers within their domains. Although members of the Domain Admins group have a fair amount of control over Exchange servers, they do not have full control.

• Enterprise Admins Members of the Enterprise Admins group are the highest level of administrators within an enterprise and can manage any Active Directory object in the entire enterprise. Members of the Enterprise Admins group have full control over Exchange servers and can, thus, perform any configuration or management task they choose.

Administrative Rights

The final type of public folder permission is administrative rights. Administrative rights allow you to configure who will be able to actually administrate the public folder something that client permissions and directory rights do not do for you. The Administrative Rights dialog box for an example public folder is shown in Figure 6.3.

Figure 6.3. Administrative rights allow you to configure who can administer the public folder.

The rights you can configure from this area are different than those granted by the Owner client permission. These rights deal with the system configuration of the public folder, not with the user permissions associated with the public folder.

Public Folder Replication

By default, any newly created public folders are not replicated to other Exchange servers only one copy, the original copy, exists. For many reasons, you might want to configure your public folders to replicate to other public folder servers, thus creating replicas on these servers. Having replicas of public folders helps to evenly distribute the load caused by an abundance of client access to public folders as well as provides a form of redundancy in the event one or more public folder servers becomes unavailable. Just like Active Directory, Exchange public folder replicas exist in a multimaster environment in which no one public folder is the master copy. All replicas of a given public folder are identical (after replication has completed) and a change made to any replica is then replicated to all other replicas, including the original public folder.

Public folder replication occurs through SMTP. Don't let this throw you for a loop though. Consider the obvious benefits this allows for public folder replication to occur using the same protocols and connectors you've already got installed in your Exchange organization. Because of this, replicas can exist on public folder servers that might actually be located on a different physical network or subnet, again providing a load-balancing effect for client access.

Public folder replication is actually a somewhat complex process that is controlled by two different services.

• Exchange Information Store Service Responsible for the actual replication of public folder trees. This service is also responsible for the replication of the actual public folder content itself, which includes message body, message header, and any attachments.

• Active Directory Responsible for the replication of mail-enabled objects within the public folder. These objects are replicated to domain controllers and global catalog servers, just as user accounts and groups are.

As much sense as creating replicas of public folders makes, there are actually times when you might not want to configure a replica for a public folder. For example, if your public folder is used to hold Usenet newsgroups, the extra traffic due to replication is probably not worth any benefit you might reap. You would be better off, in this instance, to simply configure multiple public folder servers to independently provide this service, if required.

Another instance in which you might not want to configure replication to occur is if you must maintain absolute version control over the contents of the public folder and ensure it is always 100% up to date. In this situation, you would be better off to ensure that all clients, local and remote, have adequate access to the single public folder location. These are two somewhat extreme cases, however. In the vast majority of public folder instances, you need to give consideration to configuring multiple replicas to increase availability and provide load balancing as discussed previously.

Now that we've discussed public folder replication in general terms, we need to examine exactly how it works. The public folder replication process breaks down nicely into four distinctly different processes:

• Hierarchy replication During this stage of the public folder replication process, public folder trees are replicated to all of the associated public folder stores within your Exchange organization.

• Content replication During this stage of public folder replication, the actual data contained within the public folder is replicated between all associated public folder stores. When changes are made to this data, messages are triggered that replicate these changes to all of the other replicas.

• Backfill replication During this stage of public folder replication, stores receive any missing updates that they need to be fully synchronized with all other stores. Backfill replication typically occurs when a public folder store has become out of synchronization.

• Content conflict resolution During this final stage of public folder replication, more of an error mechanism than anything else, content conflict resolution occurs. A content conflict generally occurs when the same item has been modified by more than one user at the same time using different public folder servers. As you might suspect, two different types of conflicts can occur: message edit conflicts and folder edit conflicts. In the event of a message edit conflict, a message is sent to the public folder contact (responsible person) who determines which version to retain. In the event of a folder edit conflict, the most recently saved version is kept.

Public Folder Referral

The final topic we must cover here is that of public folder referral or how clients actually make connections to public folders. The public folder to which the user wants to make a connection might be located in the same routing group as that user or perhaps on a server in another routing group. Recall that Exchange routing groups are similar to IP sites in that they are groups of servers that are connected by high-quality, permanent links.

If a user is attempting to connect to a public folder that has a replica in the same routing group as the client (the routing group that contains the user's mailbox store), the client first attempts to connect to the replica using the default public store that is associated with the mailbox store for that user account. Recall from Chapter 5, "Managing Address Lists and Exchange Policies," the discussion on configuring mailbox store policies in which you could configure a default public folder store for a mailbox store. In the event that the replica in question does not exist on the default public folder store, the client then makes a connection to a randomly selected replica within the client's routing group. The process continues until the client either locates the desired replica or runs out of local replicas. In the event that the desired replica is not found locally (within the client's routing group), the client needs to gain access to a replica located in another (remote) routing group herein lies the act of public folder referral.

Routing groups are connected to each other using group connectors. Routing group connectors have a cost value (think metric) associated with them that determines the flow of traffic out of that routing group. Cost values range from a low value of 1 to a high value of 100, with the lower values being the more preferred routes out of the routing group. When a client needs to connect to a remote routing group to access a public folder replica, the lowest cost connection is used. However, one more issue must be kept in mind in this situation whether public folder referrals are allowed across that routing group connector. By default, public folder referrals are allowed on routing group connectors. In addition, both routing group connectors in both routing groups must be configured to allow public folder referrals. As an alternative (and you knew there had to be one), you can actually configure a referral list directly on a public folder store, thus forcing clients seeking a referral to choose a store from the list.