Chapter 06: Using Public Folders (Part4)

Public Folder Permissions

Public folders, like most objects in Active Directory, have permissions that can be configured on them. Also like other objects in Active Directory, public folders inherit their permissions from their parent objects. A top-level public folder inherits its default permissions from the administrative group to which it belongs. Child folders inherit their permissions from the parent folder under which they are created. Unlike most other objects in Active Directory, public folders have a somewhat complex—and confusing—permissions structure.

Note

Changes that are made to the permissions on a public folder’s parent object will not automatically be propagated down to that child object as with NTFS permissions. If you have changed the permissions on a parent object and you desire these changes to be propagated down to the child folder objects, you can do so manually. As you might expect, this action will cause any existing permissions on the child folder object to be overwritten by those being propagated from the parent object.

Public folders have three different sets of permissions that can be configured on them: client permissions, directory rights, and administrative rights. Permissions are configured from the Permissions tab of the public folder Properties dialog box, as seen in Figure 6.11. We’ve already examined the client permissions in the “Configuring Public Folders from Outlook” section of this chapter. We will examine the other two permission types here.

Figure 6.11: Public folders permissions

Directory Rights

Directory rights are used to configure the NTFS permissions that determine who can perform modifications on the public folder object that is stored in Active Directory. Clicking the Directory rights button on the Permissions tab opens the Permissions dialog box seen in Figure 6.12.

Figure 6.12: Configuring directory rights

In most cases, you will not need to change any of the default permissions that have been configured here.

Administrative Rights

Administrative rights allow you to assign NTFS permissions to users and groups that determine who is actually allowed to perform administrative tasks on the public folder. For example, you might have five administrators within your organization, but only two of them are to be allowed to configure and manage replication properties on specific public folders. Clicking the Administrative rights button on the Permissions tab opens the Permissions dialog box seen in Figure 6.13.

Figure 6.13: Configuring administrative rights

As mentioned previously, you may find any number of reasons to configure custom settings for the administrative rights on a public folder depending on the needs of your organization.

Public Folder Referrals

When a client attempts to connect to a public folder, the public folder might or might not be located in or have a replica in the same routing group as the user’s Exchange mailbox. In addition, in any routing group there will likely be more than one public folder store. These factors combine to cause a public folder referral to be necessary to allow clients to successfully connect to the desired public folder. Two different, but related, scenarios exist with public folder referrals: one in which the public folder or a replica does exist within the same routing group as the user’s mailbox and one in which the public folder or a replica does not exist within the same routing group as the user’s mailbox.

When a user attempts to connect to any public folder, the connection is first attempted on the public folder store that is configured as the default public folder store for the mailbox store that houses their Exchange mailbox. If this public folder store does not contain the public folder in question or a replica of it, then the client will connect randomly to another public folder store in the same routing group. This process will continue until the desired public folder or its replica has been located or until all the public folder stores have been exhausted within the routing group. When this happens, a public folder referral must occur in order for the user to successfully connect to the desired public folder.

Although we will examine this in much more detail in Chapter 8, “Building Administrative and Routing Groups,” we’ll briefly mention here that routing groups are connected to each other using routing group connectors. Routing group connectors, much like a link between two routers, have a cost value associated with them. The cost value can range from a low value of 1 to a high value of 100, with lower values indicating the more preferred routes out of the routing group. When a client needs to connect to a remote routing group (for any reason, including public folder referral), the routing group connector that has the lowest cost value will be used if the routing group connector is configured to allow public folder referrals across it (see Figure 6.14). By default, all routing group connectors are configured to allow public folder referrals; however, this can be disabled by selecting the Do Not Allow Public Folder Referrals option. If a routing group connector allows public folder referrals across it, then the client will continue the process of attempting to locate the public folder or a replica of it in any routing group to which it can connect.

Figure 6.14: Allowing public folder referrals across a routing group connector

As an alternative to allowing “random” public folder referral, you can configure servers that contain public folder stores with a predefined list of referrals, thus forcing clients to use the configured list. The Public Folder Referrals tab of the server Properties dialog box, seen in Figure 6.15, allows you to change the default option of Use Routing Groups to Use Custom List. When you select the Use Custom List option, you can then configure specific servers and the cost values that are to be used for public folder referrals.

Figure 6.15: Configuring a custom referral list

Summary

Public folders are an efficient and effective way to share data among several people. Permissions, forms, rules, and views can be configured on public folders to create folder-based applications. Users can easily create public folders and perform certain management functions using Outlook.

Permissions enable a folder owner to specify who can access a folder and what users can do in that folder. Associating a form with a public folder assists users in submitting structured information into the folder. Rules on public folders can perform automated actions when the appropriate conditions are met. Public folders can hold a large quantity and variety of information, so views can be leveraged to display the pertinent items in a desired way.

Adding content to public folders is very easy. It can be done by posting directly to a public folder or by sending the public folder regular e-mail messages.

Public folders can also be created using the Exchange System Manager. In addition, Exchange System Manager offers many more management options than are available in Outlook. You can configure public folder–related settings at the level of the Public Information Store for a server and at the level of the individual server. Settings made at the folder level typically override settings made at the Public Information Store level. As well, you can configure directory rights and administrative rights for public folders using the Exchange System Manager. Outlook allows the configuration of client permissions only on public folders.

Exchange Server 2003 offers the ability to use multiple public folder trees. The default tree in an organization, named All Public Folders, is also referred to as a MAPI top-level hierarchy. This public folder tree can be accessed by any type of client, including MAPI, NNTP, and HTTP. Additional public folder trees are referred to as general-purpose trees and may not be accessed by MAPI clients such as Outlook. They can be accessed by other types of clients.

Each public folder is created on a single Exchange server, but replicas of that folder can be created on other servers. Once replicas are created, replication of folder content happens according to a predetermined schedule. Public folder replication follows the multimaster replication model, in which every replica of a public folder is considered a master copy.