7.12 Laying out a public folder design

---

As with any other repository intended to be a source of information to users, you need to put in some work to design a good structure for public folders. A well-designed hierarchy is easy for users to navigate and easy for administrators to manage. The design should address the following points:

• Top-level folder layout: What are the folders immediately under the root and who has the permission to create new top-level folders?

• Folder organization: Do you want to organize folders on a geographical, business unit, or other basis? The hierarchy is difficult to reorganize once it is in place, so it is a good idea to get it right the first time. You should establish a taxonomy for folder organization and communicate it to anyone who is responsible for creating or managing public folders. If you use other repositories (file shares, SharePoint Portal Server) in the company, it is a good idea to lay down rules for what content is stored and where and how it is organized and named.

• Folder naming convention: Are folders named in such a way that people can immediately understand what the folders might contain? Figure 7.30 illustrates a PF hierarchy that is easy for users to follow, because it is divided into organizational units (such as divisions) and geographies, so it should be easy to find information.

  
  Figure 7.30: A well-laid-out PF hierarchy.

• Folder administration: Who is responsible for creating new folders? What logic drives folder creation? You do not want to restrict public folders so much as to force users to complete 14 forms before an administrator creates a new folder, but equally you do not want to grant the freedom to all to create folders unchecked. Some large companies have allowed such freedom and the resulting chaos takes months to sort out.

To manage public folders better, you may wish to move the default public folder container into a separate administrative group and assign the permissions to manage the administrative group to a limited set of users (it is best if you manage these users as a universal security group). In addition, what expectations do you have about how folder owners manage the content held in the folders? It is best practice to deny the ability for any user to create new top-level folders. Every time you introduce a new Exchange server into the organization, the installation procedure grants the ability to create new top-level public folders to "Everyone," which is not a good idea. Microsoft fixed this bug in Exchange 2003, but while you continue to deploy Exchange 2000 servers, you should check that the correct permissions remain in place after each installation and that folder creation remains restricted. It is a good idea to install all public folder servers during the early part of the deployment in order to sort out permissions, replication schedules, ownership, and so on, taking the following points into consideration:

• Folder control: What are the default values for deleted item retention, storage quotas, age limits, and so on? You have to make a decision to impose these values on an individual server-by-server basis or use a system policy to impose a policy across multiple servers. Unfortunately, the mailbox manager does not process public folders, so age limits and quotas are the only way to restrict what people can keep in public folders.

• What clients will access the public folders? If you exclusively use MAPI clients, you are restricted to a single top-level hierarchy. If you use IMAP4 or Web clients, you can create and use new hierarchies, but you need to have a good reason for doing so.

With Exchange 2000 and 2003, you can create new folders through ESM or Outlook, and you can post items into the folder using the Exchange 2003 version of ESM (previously, posting is only supported by clients). However, if you want to use a public folder to host a shared calendar, you should create it through Outlook and select the appointment item option from the Create New Folder dialog box (Figure 7.31).

Figure 7.31: Creating a new calendar folder from Outlook.

Whatever public folder design you use, make sure that top-level folder creation is restricted to a very small number of users, preferably secured through a single universal security group. If you allow people to create a folder anywhere in the hierarchy, they will, and you end up with a horrible mess.

7.12.1 Top-level hierarchies

The first versions of Exchange organize public folders into a single top-level hierarchy (TLH). In other words, there is a root (called "Public Folders") and the Store arranges the folders under the root. A single hierarchy is easy to access and the root is the obvious point to start looking for public folders, but the more folders you add, the harder it can become to navigate to the right place. Sometimes, the Exchange documentation refers to a TLH as a public folder tree.

You create a default TLH, called "All Public Folders," when you install the first Exchange server in an organization. If you migrate from Exchange

5.5, the default TLH comes over too. Today, you can create multiple TLHs, albeit with the one major caveat that the new hierarchies are invisible to MAPI clients, since the original MAPI design does not accommodate multiple hierarchies.

There are two problems here. First, the vast majority of clients remain MAPI, so the new hierarchies are only available to a minority of users. Second, IMAP4 and Web clients typically only use email, which further reduces the potential user community. You can use ESM to examine the properties of a TLH to know what clients it supports. Figure 7.32 shows the properties of two TLHs. The left-hand screen is marked "general purpose," which means that MAPI clients cannot see it and use the contents of its folders, while the right-hand screen is marked "MAPI clients," which means any client can access the hierarchy and content. Confused? Consider too that each TLH is associated with one or more Public Stores, and you cannot have two Public Stores on the same server sharing the same tree. In addition, the two types of TLH are very different, and you cannot change a MAPI TLH to become a general-purpose TLH or vice versa, even by manipulating their properties programmatically.

Figure 7.32: TLH properties.

Apart from ASPs that host multiple companies in a single Exchange organization and need to offer public folders to each company, it is hard to think of major deployments that have made extensive use of multiple TLHs and equally hard to come up with reasons to argue for their creation. However, here are a few:

• Administrative control: Dividing folders across multiple TLHs allows you to assign different administrative control over complete hierarchies. For example, you could create a hierarchy for HR folders and assign permissions over the TLH to specific users. However, you could also create a subroot for HR folders under the default TLH and assign control from the subroot down. Dividing folders into multiple TLHs is really only of value when you host multiple companies in one organization and must maintain a clear separation of data between the different companies.

• Scalability: While you can create multiple Public Folder Stores, you cannot combine folders belonging to multiple TLHs in one Store. When you create a new Public Store, you associate it with a single TLH. Naturally, just as multiple Public Stores on multiple servers share the default MAPI hierarchy, you can create new Public Stores on other servers to share the same general-purpose TLH. While few companies generate enough MAPI public folders to cause scalability concerns, you can easily create a scenario where multiple companies hosted by the same Exchange organization need to use tens of thousands of folders. Here you need to create multiple TLHs to ensure that Exchange can scale to provide good service to clients when they access the folders.

• Reduce the impact of failure: If you put all your eggs into one public folder basket, any corruption of a database affects everyone who depends on a folder in the database. Dividing folders across multiple hierarchies and multiple databases mitigates the potential impact of any problem.

These factors affect few deployments, so the general advice is to pause long and hard before you create a new TLH. Remember that Outlook clients cannot see folders in general-purpose TLHs, so you have to use a redirect method by associating a link (URL) from a MAPI public folder to the folder in the other TLH. Do this by first finding out the URL to the folder with OWA and then inputting the URL in the Home Page property for the folder. When Outlook next attempts to open the folder, it will use the URL to access the contents.

7.12.2 Should you deploy dedicated public folder servers?

Older Exchange designs invariably feature dedicated servers that are set aside to host and manage public folders. This is an anachronistic hangover of old design practices that attempted to isolate mailbox and public folder traffic, largely because older servers are unable to cope with the load generated by users and background replication activities. The situation is different now. Current servers are so powerful and have so many disks available that you can usually host both mailboxes and public folders on the same server without worrying too much.

On the other hand, you can argue the case that deploying some dedicated public folder servers makes replication easier to manage because there are less Public Stores to work with. A further advantage is that by concentrating public folders on a small number of dedicated servers, you eliminate the replication traffic that Exchange generates to update folder hierarchies to every server in the organization that holds a Public Store. In a large organization, these replication messages can amount to tens of megabytes daily. You can also make a case to allocate a dedicated public folder server to host a newsfeed from USENET, if you want to host USENET feeds.

If you do decide to deploy dedicated public folder servers, make sure that your design allows Outlook clients to connect to a nearby server. Do not seek to minimize the design so much as to force clients over extended network connections each time that they need to access a public folder. Another design point is that at least one server in every administrative group must hold the default MAPI public folder tree to allow access to system folders. In addition, make sure that you replicate the system folders, such as the Schedule+ free/busy information, offline address book, and eforms registry, to the dedicated servers.

Figure 7.33 shows the replication schedule for a free/busy folder. The screen shot does not show the full name of the folder, but the hint that it is a free/busy folder comes from the folder name shown in the title bar. This begins with EX:/ followed by the distinguished name of the administrative group that owns the free/busy information. While the name might not be important, the schedule is, and in this case we can see that Exchange replicates content from this folder according to the default schedule (typically every 15 minutes) for the Public Store. You can check the replication schedule for your free/busy folder through ESM by looking through the free/ busy section of the system folders. Select the folder for your administrative group and then view its properties to see the information shown here.

Figure 7.33: Replication for the Schedule+ free/busy folder.

Even if you use dedicated public folder servers, anyone upgrading from Exchange 5.5 should review the number and configuration of existing public folder servers to determine whether you can reduce the number of servers in the organization and reduce replication activity by removing the public folder server. Naturally, before you remove any public folder server, ensure that replicas of all the folders it hosts exist elsewhere in the organization.

7.12.3 Auditing public folders

Some companies have tens of thousands of public folders, but you have to wonder whether anyone knows what the folders hold, who manages the content and access control for the folders, why the folders were originally created, and who has a full understanding of what bandwidth the folder replication traffic consumes. These questions point to a need for public folder management that is often ignored in production when keeping email flowing becomes the major concern for administrators. Apart from the options available through ESM, you can use other utilities to manage public folders.

PFTREE (part of the Exchange Resource Kit) counts the number of folders, subfolders, and items in the default MAPI TLH, but not much else (Figure 7.34). However, it is a good way to get some statistics about the number of public folders and the information that they hold. If you record these statistics regularly, you can track the growth in public folder use. If you record statistics, you should also track the growth in size of the Public Store.

Figure 7.34: PFTREE.

The Outlook Folders program (Figure 7.35) is a more interesting utility because it exports details of the public folders that it analyzes, which you can then open with Excel or load into a database like Access for further analysis. This program replaces the older PFINFO utility, which was part of the Exchange Resource Kit. Outlook Folders can export a file that you can then use as input to PFADMIN, a command line utility that you can use to create new replicas, list existing replicas, rehome a folder (Exchange 5.5 only), or even search for specific file types (for example, find all AVI files in any public folder). The syntax used with PFADMIN is cryptic, so it is a good idea to practice on a test server before launching yourself upon a full set of production public folders. Better again, you can ask Microsoft for a copy of PFDAVADMIN, an upgraded version of PFAFADMIN based on the .NET Framework that has a better user interface and addresses some of the bugs in PFADMIN. All of these tools use MAPI, so they do not process any folders held in alternate TLHs. Remember that these tools are not part of the Exchange product, so if they do not meet your needs, you can consider commercially available programs that report on different aspects of Exchange. For example, MessageStats from Quest Software is able to generate reports on folders and replicas.

Figure 7.35: Outlook Folders utility.

7.12.4 Mail-enabling a public folder

A mail-enabled public folder has a set of email addresses similar to mail- enabled users and contacts, so to mail-enable a public folder Exchange must create suitable addresses (by reference to recipient policies) and stamp the addresses into the public folder object in the AD.^[4] When you mail-enable a folder, it can appear in address lists and its address can be used to send and receive email. In addition, unlike MAPI and OWA clients, you need to mail-enable a public folder to allow IMAP4 clients to access its contents. Windows also assigns an ACL for the folder. In most cases, you do not want to see public folders in the GAL, so the normal approach is to hide the folder from address lists.

Up to Exchange 2000, public folders were automatically mail-enabled when created. In a mixed-mode Exchange environment, folders are also automatically mail-enabled for backward compatibility with Exchange 5.5. Once you move to a native-mode Exchange organization, you have to explicitly mail-enable a new public folder if you want users to be able to post infor- mation to the folder by sending it messages. To mail-enable a folder, select it from ESM, right-click, and select "Mail Enable" (Figure 7.36).

Figure 7.36: Mail-enabling a public folder.

Users do not automatically have the right to enter data into a public folder even if it has email addresses. You must also grant users the permission to create new content in the folder. For example, if you mail-enable a public folder because you want to include it in a distribution list so that it receives a copy of every message sent to the list, you have to either add the distribution list to the folder's access control list or allocate the "contributor" role to the special "anonymous" user.

7.12.5 Public folder favorites

Because large organizations can have thousands of public folders, it would be unreasonable to ask users to navigate a complex hierarchy each time they want to access a specific folder. Public folder favorites, a unique feature of MAPI clients, allow you to access marked folders with a single click by placing them into a set of folders stored as properties of your mailbox (Figure 7.37).

Figure 7.37: Public folder favorites.

Apart from being easier to access, you can also take public folder favorites offline by synchronizing them to an OST (something that happens automatically if you use the local cache in Outlook 2003). Offline storage is convenient, but it can have undesired effects. For example, let us assume that you have permissions to delete items from a folder. The same permission is active when you work offline, and situations have occurred when users have unwittingly "cleaned up" a folder offline under the impression that the delete commands only influence the OST. Unfortunately, the next time they synchronized the folder with the Store, Exchange executed all the delete commands and removed the affected content from the online folder.

Cleaning out a folder when you work offline is OK if it is a folder that holds transient content, such as newsgroup postings, but this can create difficulties if you delete copies of the current budget, operations plan, or similar documents. Fortunately, Exchange supports deleted item recovery for public folders, but only if you set a deleted item retention period for the folder. You can set a specific deleted item retention period for a folder or inherit the general value set for the Public Store database, and you can set the same value across multiple stores by applying a system policy. Figure 7.38 shows how you set the retention period for a folder. Five hundred days is probably a little excessive and 30 days is a more typical value.

Figure 7.38: Setting a deleted item retention period.

7.12.6 Public folder permissions

You access public folder permissions through folder properties. The "per- missions" page separates permissions into three separate groups (left-hand screen in Figure 7.39): client permissions, directory rights, and administrative rights.

Figure 7.39: Setting administrative permissions on a public folder.

Client permissions define which users can access the folder and the privileges they have when working with folder content. To make things easier for users, Exchange masks the complexities of Windows ACLs and security descriptors by representing permissions as a set of roles, each of which represents the collection of permissions that a user must possess to be able to perform specific actions on a folder. You can only assign folder permissions to AD objects that hold a security principal: mail-enabled accounts and mail-enabled security groups. You can assign permissions to a mail-enabled universal distribution group, but Exchange will automatically convert it to a mail-enabled universal security group afterward. You can stop automatic group conversion by using ADSIEDIT to set the value of the "MsExchDisableUDGConversion" attribute of the Exchange organization to either 1 (to block client-initiated conversions) or 2 (to block all conversions). The default value (0) permits conversions.

The roles are:

• Owner:   Users can create, read, change, and delete all items. They can create subfolders. When you create a new folder, you automatically become the owner of the folder and retain that role until you assign it to another user. More than one user can be folder owners. The folder owner is also a folder contact.

• Publishing editor:   Users hold the same rights as the owner, except that they are not marked as a folder owner or contact.

• Editor:   Users can create, read, and change items, but they cannot create subfolders.

• Publishing author:   Users can create items and subfolders and can read everything, but they are only able to edit items that they author.

• Author:   Users can create and read items, but they can only edit items that they author.

• Nonediting author:   Users can create and read items, but they cannot edit any items, even those that they author.

• Reviewer:   Users are only able to read items.

• Contributor:   Users are able to create new items, but they cannot read or edit them afterward. This is the correct permission to allocate to the Anonymous user to allow anyone to post items into a public folder that you set up as an archive for a distribution list.

• None:   Users cannot access the folder.

If none of these roles meets your needs, you can build a custom role and associate the set of permissions necessary for users to do their work. You only see the "Directory Rights" button if the folder is mail-enabled. When you mail-enable a folder, AD creates a folder object in the System\Exchange container under the domain root. You can see these objects by turning on Advanced View for the AD Users and Computers snap-in, and then expanding the System and Exchange containers. Folders can appear in the GAL after they are mail-enabled, but it is usual to hide folders from address lists (this option is available through the Exchange Advanced property page).

Administrative rights (right-hand screen in Figure 7.39) allow you to allocate the ability to set quotas and item retention periods for the folder, modify the ACL on the folder, mail-enable the folder, and so on. You can also use Outlook to control user access to a public folder (Figure 7.40). This feature, which is unique to MAPI clients, allows you to delegate day-to-day control over a folder to someone else, usually the folder owner. However, you can obviously only use this feature with a folder that MAPI can access, so it must be in the default TLH.

Figure 7.40: Controlling public folder access from Outlook.

Public folder ACLs can be afflicted by zombies, lingering remnants of permissions belonging to objects that used to be in a directory but do not exist today. Usually, zombies arise through a migration from Exchange 5.5, and the ACEs refer to directory entries that have not yet been migrated or no longer exist. In either case, the Exchange 2003 Store is able to detect zombies and remove them to clean up public folder permissions.

^[4] . The AD stores the folder objects in the Microsoft Exchange System Objects OU. You can only see this OU if you use the Advanced View for AD Users and Computers console or an LDAP utility.

---