Lesson 3: Public Store Configurations

As outlined earlier, public folders consist of a reference in a hierarchy, and the content is hosted in a public store. This relationship is reversibly unambiguous. Each public store contains the contents of exactly one public folder tree and a public folder tree cannot be split across multiple stores. At the public store level, you define default parameters that affect all public folders in the associated hierarchy.

This lesson covers the configuration of important public store parameters. It also discusses the purpose of public folder referrals and how public folder content is accessed across routing group boundaries.

---

At the end of this lesson, you will be able to:

• Configure public stores.
• Specify public folder affinities.
• Describe how MAPI-based clients locate public folder contents.

Estimated time to complete this lesson: 45 minutes

---

Managing Public Stores

As outlined in previous chapters, you can maintain public stores for each server individually (see Chapter 14, "Managing Server Configuration") or combined through public store policies (see Chapter 12, "Management Tools for Microsoft Exchange 2000 Server") using Exchange System Manager. Most of the important settings, including replication schedule, age and storage limits, and so on, are available at both levels. Only store-specific parameters, such as for associated public folder trees and database paths, are unavailable in policies. Effective policy settings have higher priority than store settings and cannot be changed at the public store level.

Controlling Public Store Sizes

Public store databases have a size limit of 16 GB (Standard Edition) or no internal size limit (Enterprise Edition), in which case they are restricted only by the capacity of the server's local disk space. They are restricted only by the capacity of the server's local disk space. Storage quotas that you can set in the Limits tab of each individual public store or within a public store policy—Issue Warning At (KB), Prohibit Post At (KB), and Maximum Item Size (KB)—give you control over the amount of disk space a public store might eventually occupy. For instance, Issue Warning At (KB) allows you to specify a size limit for the entire public store. If this limit is exceeded, a warning message is generated indicating that items should be removed. Exchange 2000 Server generates this message at the specified warning message interval. By default, warning messages are generated daily at midnight. The text of the warning message cannot be edited.

Prohibit Post At (KB), on the other hand, allows you to define a definite size limit for the public store. As soon as this limit is reached, new information cannot be contributed until data is deleted from this store. Maximum Item Size (KB), again, defines the maximum size for objects in public folders. Items larger than the limit are rejected. Reasons to restrict item size are given in Chapter 18, "Public Folder Replication."

NOTE

---

Size limits at the store or policy level apply to the entire public store. You can also specify storage limits on a per-folder basis using the Limits tab of the corresponding public folder object in the hierarchy. However, it is not advisable to select the Use Public Store Defaults option for a public folder because in this case the public folder is allowed to consume the entire space in the public store. It is advisable to configure size limits for public folders individually.

Specifying Age Limits

Age limits determine how long a public folder retains items before deleting them automatically. This mechanism can ensure that old information in a public folder will not remain there indefinitely. To give an example, if you have subscribed a public folder to a mailing list as explained earlier, or use public folders as newsgroups, as explained in Chapter 11, "Internet-Based Client Access," you may want to define an age limit to ensure that outdated content does not impair the usefulness of your forums.

To set an age limit for all public folders in a public store, use the Limits tab of the public store object. Select the Age Limit For All Folders In This Store (Days) check box to specify the lifetime of items in days. By default, all public folders use the settings defined for their public store. However, you can also specify an individual age limit for a public folder in its Limits tab. Deselect the Use Public Store Defaults check box, and specify the limit under Age Limit For Replicas (Days).

NOTE

---

Specifying age limits per public store allows you to maintain different age limits for a public folder on different stores. Setting the age limit at the public folder level defines a common item lifetime for all replicas.

Obtaining Public Folder Status Information

Using the Public Folders object (located under the public store object), you can display status information about the public folder resources in a particular store. Among other things, you can view the disk space used in a given public folder, the total number of items per folder, the last access time, and the path to a folder in its hierarchy. To examine available information and add interesting columns to the details pane of Exchange System Manager, right-click the Public Folders object, point to View, and select Choose Columns. Make your choice in the Modify Columns dialog box.

Next to the Public Folders object, you will find further containers that provide you with information about users who are currently connected (Logons object), allow you to view and configure public folder replicas in the public store (Public Folder Instances object), give a quick overview about the replication status of each public folder (Replication Status object), and allow you to check the current index state (Full-Text Indexing object).

Public Folder Referrals

As long as you navigate through a public folder tree, the client communicates with the associated public store on the local server. Using Outlook 2000 and the MAPI-based hierarchy, this is the default public store, as defined in your mailbox store's properties. Usually, the default public store resides on your home server. When you select a particular public folder in the tree to open it, the client will look for the contents in the associated public store on the local server first, then possibly check other servers in the same routing group or in remote routing groups (see Figure 17.10).

Referrals Across Routing Groups

The routing group defines the boundary in which permanent and reliable network connections are assumed and direct public folder access is allowed. Every RGC provides a Do Not Allow Public Folder Referrals check box, which you can use to control public folder access across routing groups. The cost value of the connector establishes the public folder affinity. The lowest affinity cost determines the most preferred routing group if multiple routing groups exist. In addition, public folder referrals are transitive. If referrals are allowed between routing group A and routing group B, and between routing groups B and C, then referrals are implicitly allowed between A and C as well. All connectors allow referrals by default. Therefore, access to public folders is theoretically possible across the entire organization.

NOTE

---

You should not allow referrals to routing groups over connections that do not support RPCs, such as routing groups connected through the Internet and firewalls.

Public folder referrals have the following characteristics:

• They can be defined for routing groups, not for single servers.
• If multiple routing groups have the same value, they are pooled and then contacted in a random order.
• Referrals based on routing group connectors are unidirectional; each routing group must maintain its own routing group connectors and its own referrals.
• Routing groups with the lowest public folder referral are tried first.
• Referrals specify the order in which remote routing groups are contacted if the public folder content is not in the local routing group.

Figure 17.10 Connecting to public folder content

Public Folder Referral Process

When a client sends an open request to its local public server and this server has a replica, access to the content is possible immediately. Yet, the content may not be available locally. However, the server has complete information about the configuration and can determine where the public folder resides. Consequently, the server will compile a referral list containing all replica servers for the public folder, sort the servers according to affinity costs, and send this list to the client (see Figure 17.10). Based on this list, the client can determine where the folder is located and connect to the nearest server. If a server is unavailable for any reason, the next server in the list is tried.

The order in which a client searches for servers that have the public folder content available is as follows:

1. The client checks the server that holds the default public store of the user's mailbox store. If the content is not available, the client receives a list of replica servers.
2. The client uses a server to which a connection currently exists.
3. If there are no relevant server connections, the client chooses a server within the local routing group of the default public store and establishes a connection to request the content. If multiple servers have the content available, servers are chosen in a random order.
4. If there are no servers in the local routing group that hold a replica, or if these servers cannot be contacted at present, the client selects a server in another routing group based on affinity cost values, beginning with the lowest value.
5. Servers in routing groups with the same affinity value are pooled and contacted in a random order.
6. The client contacts the routing group with the next highest affinity value if it was not able to access the content. This continues until the content is located or until all servers in the list have been checked.

Breaking Through Routing Group Boundaries

The public folder referral process begins in the routing group that is local to the user's default public store. This is not necessarily the local routing group where the mailbox store resides. In other words, it is possible to configure a default public store for a mailbox store that is in a different routing group. In this case, access to hierarchy and content would require communication across routing groups. You need to make sure that a local area network (LAN) connection exists between these routing groups.

IMPORTANT

---

Access to the default public store cannot be restricted by means of an RGC or the Do Not Allow Public Folder Referrals check box. Clients must always be able to access their default public store, even if it resides in a different routing group.

Exercise 3: Public Folder Access Across Routing Group Boundaries

In this exercise you will block access to public folder contents across routing group boundaries. The task is to prevent access; in Chapter 18, "Public Folder Replication," you will make resources available by means of public folder replication.

To view a multimedia demonstration that displays how to perform this procedure, run the EX3CH17*.AVI files from the \Exercise_Information\Chapter17 folder on the Supplemental Course Materials CD.

Prerequisites

• Make sure your test environment is configured with two routing groups that are connected using an X.400 Connector, according to the exercises in Chapter 16, "Message Routing Administration."
• Complete Exercises 1 and 2, earlier in this chapter.
• Start BLUESKY-SRV1, BLUESKY-SRV2, and BLUESKY-WKSTA.
• Log on as Administrator to all machines (it may be necessary to logoff as Carl Titmouse from BLUESKY-WKSTA).
• Make sure the Administrator mailbox resides in the mailbox store VIP Mailboxes on BLUESKY-SRV2, according to Exercise 1 of Chapter 14, "Managing Server Configuration." Otherwise, move the mailbox to BLUESKY-SRV2 using Active Directory Users and Computers.

To prevent access to public folder contents across routing group boundaries

1. On BLUESKY-SRV1, launch Exchange System Manager, expand the Folders object in the First Administrative Group, expand Public Folders, right-click BackDoor, and select Properties.
2. Click on the Replication tab, and verify, under Name, in the Replicate Content To These Public Stores list, that only Public Folder Store (BLUESKY-SRV1) is listed. (This folder exists on BLUESKY-SRV1 and the Administrator mailbox resides on BLUESKY-SRV2. Both servers exist in separate routing groups.)
3. Click on the Permissions tab, click Client Permissions, and make sure that the Administrator account is listed as the owner of the public folder with all permissions.
4. Select Carl Titmouse, and click Remove to grant this account the Default permissions of an Author again. Click OK twice.
5. Right-click BackDoor, point to All Tasks, select Propagate Settings, and, in the Propagate Folder Settings dialog box, select the Folder Rights check box. Then click OK. (Carl Titmouse's mailbox resides on BLUESKY-SRV1.)
6. Under Routing Groups, expand the First Routing Group, and then expand Connectors. Right-click X.400 To BLUESKY-SRV2, and then select the Disallow Public Folder Referrals option (this is the same as selecting the Do Not Allow Public Folder Referrals check box in the connector's General tab).
7. Launch Exchange System Manager on BLUESKY-SRV2, expand the Second Routing Group under Routing Groups in the First Administrative Group, expand Connectors, right-click X.400 To BLUESKY-SRV1, and then select the Disallow Public Folder Referrals option.
8. Wait for the directory replication to propagate the changes to both servers, and then, on BLUESKY-WKSTA, launch Outlook 2000, and make sure you are connected as Administrator.
9. Open the View menu, and make sure the Folder List option is selected to display the list of mailbox and public folders.
10. Expand Public Folders, All Public Folders, and BackDoor. Notice that you can navigate the hierarchy without problems.
11. Select BackDoor, and verify that Outlook 2000 is unable to display the folder content (see Figure 17.11).
12. Log off as Administrator, and log on as Carl Titmouse. Check that Carl is able to work with the public folder content because his default public store has the folder available.

    

    Figure 17.11 Preventing public folder access across routing groups

Exercise Summary

The routing group defines the boundary within which Outlook 2000 can access any server directly via RPCs to request the content of a public folder. Between routing groups, however, access must be granted explicitly by means of routing group connectors (RGC, SMTP Connector, or X.400 Connector). If routing groups are connected via slow and unreliable connections or connections that do not support RPCs, it is advisable to prevent public folder referrals in the routing group connector configuration. Routing groups and connectors are covered in Chapter 16, "Message Routing Administration."