Working with the Public Folder Hierarchy

You can create public folders in any available public folder store on any Exchange mailbox server. By default, public folder stores are not created on Exchange 2007 mailbox servers unless you specify that the server will be used with clients running Outlook 2003 and earlier. When you create a new public folder store on an Exchange 2007 mailbox server, you can create a new storage group for it or place it in a storage group that already has one or more mailbox stores in it.

A public folder hierarchy, or public folder tree, is a list of public folders and their subfolders that are stored in the default public folder stores on the Exchange servers in an Exchange organization. The hierarchy also includes the name of the server on which a copy of each folder resides. Because the hierarchy exists in Active Directory as a separate object, it does not contain any of the actual items in your various public folders. There is one organization-wide public folder hierarchy object, although in previous versions of Exchange, you could create additional public folder trees that were not visible through the Public Folder object in Outlook but could be accessed through other methods, such as NNTP.

Note 

You cannot create non-visible public folder trees using the management tools in Exchange 2007; you will need to continue using the Exchange 2003 System Manager if you need to create these objects.

Replicating Public Folders

In a single Exchange server environment, the hierarchy exists and is stored on the Exchange server. In an environment with multiple public folder stores, each Exchange server that has a public folder store has a copy of the public folder hierarchy. Exchange servers work together to ensure that each Exchange server in an administrative group has an up-to-date copy of the public folder hierarchy. This process, called public folder hierarchy replication, is automatic. In Exchange 2000 and Exchange 2003, there were certain limitations with this process when replication crossed administrative and routing group boundaries. Once you've fully migrated to Exchange 2007, these limitations will be a thing of the past; all Exchange 2007 servers are in a single separate administrative group that has been created for backward compatibility with Exchange 2000 and Exchange 2003 servers in the organization.

The Exchange 2003 System Manager uses the public folder hierarchy to appropriately display public folder objects in various containers and to retrieve information about public folders, whether that information is stored in the hierarchy or on the server where the public folder physically resides. E-mail clients such as Outlook and OWA use the hierarchy to display a list of public folders available on all servers in the organization and to access items in a specific folder. Security limits associated with a given public folder, of course, limit the actual access granted to administrators and users.

Note 

The public folder hierarchy also includes what are called system folders, such as the Schedule + Free Busy folder. We'll talk about it and the other system folders later in this chapter.

How public folders are accessed depends on the client version. By default, Outlook 2007 and Outlook Web Access clients use the new Exchange 2007 web services to determine the location of a public folder. Previous versions of Outlook will first look for a public folder on the user's public folder store, which might or might not be the same Exchange server where the user's mailbox is located. The default public folder store is configured on the General property page of the Properties dialog box for a mailbox store (see Figure 14.3).

Figure 14.3: The default public folder store property of the mailbox store

If a specific public folder doesn't exist in the default public folder store, the client is directed to a server where the public folder resides. As you can imagine, when many public folders are accessed over a lower-bandwidth network, server and network loads can get pretty heavy as users access public folders on one or a limited number of Exchange servers. If you need to, you can replicate folders on one Exchange server to other Exchange servers.

Why would you want to replicate public folders? Well, we can think of four reasons:

• When you need to balance public folder access loads on your Exchange servers. Having all of your users connect to a single server for all of their public folder access can quickly result in an overwhelmed server if you have a large number of users or if you have heavy public folder usage.

• When you have an Exchange server or group of Exchange servers separated from other servers in your organization by low-bandwidth links. In that case, you may be better off to have limited replication traffic over your links and allow users to connect to local replicas, keeping their traffic on the LAN.

• IMAP4 clients see folders only on the Exchange server to which they connect, including public folders. If you want an IMAP4 client to be able to see a specific public folder, you must create a replica of that folder on the IMAP4 user's mailbox server.

• Public folder replication is essential when you're planning to remove an Exchange server from your organization (like all those Exchange 2003 servers you're migrating away from). If the server you're removing hosts the only replica for a set of public folders and you don't want to lose those folders, you must replicate them to another Exchange server in your organization.

Now that we've whetted your appetite regarding public folder replication, we'll tackle the subject in further detail in the next section.

Managing Public Folders

All of what we said about public folders in single administrative group environments in an earlier section of this chapter ("Replicating Public Folders'') applies to public folders in multi-administrative group environments. Again, remember that with Exchange 2007, you may have multiple administrative groups while you're in the process of upgrading your organization from an earlier version of Exchange, but you will end up with a single administrative group when you've finally switched completely to Exchange 2007. Until that day, though, you'll need to use the Exchange 2003 ESM to fully manage some of the complications listed in this section.

Public folder management gets to be more complex as additional administrative groups are created and connected by routing groups. Two issues come immediately to mind.

First, an Exchange organization's one and only MAPI-based default public folder tree can remain in the administrative group where it was originally created or it can be moved to another administrative group. In either case, when the default public folder tree has been moved to a new administrative group, control of its management can be delegated to a specially constituted Windows 2003 group.

Warning 

Do no delete the administrative group where the Exchange public folder hierarchy is found. Public folders will stop working.

Second, as Exchange organizations grow in size and complexity, nothing becomes more important on the public folders side than the location of public folders and replicas of public folders. You can significantly reduce network traffic and decrease folder access times by replicating heavily accessed public folders to Exchange servers in different routing groups with relatively low-bandwidth links to the Exchange servers where the public folders currently reside.

Let's take a closer look at public folder tree management and public folder replication.

Accessing Public Folders Using the Exchange 2003 System Manager

You can still create and manage public folders using the Exchange 2003 System Manager; many administrators will be more comfortable with this option than using the EMS, at least at first. For the most part, public folder management is straightforward in multiserver Exchange Server environments.

Look at Figures 14.4 and 14.5, which show the public folders on the two servers RED-EXCH01 and RED-MSG01, an Exchange 2003 server and an Exchange 2007 server, respectively.

Figure 14.4: Public folders on RED-EXCH01

Figure 14.5: Public folders on RED-MSG01

First, notice that RED-EXCH01 has many public folders that don't exist on RED-MSG01. This should demonstrate that by default the Public Folders container on each Exchange server contains only those folders that have replicas located in that store. So far, this is simple and makes sense; ready for the curveball?

Let's say that we want to create a new public folder on RED-MSG01. First, we need to locate the Public Folders container that holds the default public folder tree for our organization. We've selected that container in Figure 14.6.

Figure 14.6: The default public folder tree container

To ensure that we're working with the right public folder store, we need to right-click the Public Folders container, select Connect To from the menu, select the appropriate public folder store from the Select a Public Store dialog box, and click OK. See Figure 14.7.

Figure 14.7: Choosing a public folder store

Now we know that we're working on the correct public folder store, and we can graphically manage and create public folders on our Exchange 2007 server to our heart's content.

Note 

You can't be sure that you're connected to the correct public folder store by the folders that are displayed in the Public Folders container. This display is based on the organization-wide public folder hierarchy, so you see all public folders in your organization regardless of what server they are stored on in the Public Folders container.

While you've still got legacy Exchange servers in your organization, you can control management access to the default public folder tree by moving that tree to an administrative group other than the one in which the tree was originally created. You should aim to move the public folder tree into the Exchange 2007 administrative group.

To do this, you must create a new Folders container in the desired administrative group and then drag and drop the default public folder tree into the new Folders container. See Figure 14.8 for an example of this being done on RED-MSG01, an Exchange 2007 mailbox server in our organization.

Figure 14.8: Creating a new Public Folders container on an Exchange 2007 server

For example, say we've dragged our default public folders tree from its default location to the Exchange 2007 administrative group and created a new Public Folders container just for public folder management. Delegated administrators can both view and change the properties of all public folders in the tree and create new folders in the tree. We've delegated control over our administrative group Public Folders Management to a new Windows 2003 security group PFAdmins; members of this group includes only those users we want to be able to manage the public folders in our organization. We then modify the management permissions for the Public Folders container to only allow management functions to members of the PFAdmins group.

After these changes the managers of our Exchange 2003 Los Angeles and New York administrative groups who are also members of the new security group will have full control over the public folders in their administrative groups. Managers of our Los Angeles and New York administrative groups who aren't also members of the PFAdmins security group can no longer create new public folders. That's because administrative creation of public folders can be done only on the default public folders tree, to which they no longer have access.

Tip 

You can limit all administrative access to public folders in administrative groups that contain Exchange servers (Los Angeles and New York, in our case). You do this by creating an administrative group and installing Exchange servers that support only public folder stores into the new administrative group. Then you delegate control over the new administrative group to a Windows 2003 security group that includes only those Windows 2003 users whom you want to be able to manage public folders.

Performing Public Folder Replication

Technically, all copies of a public folder, including the one on the Exchange server where the folder was originally created, are called replicas. There's good reason for this. After a folder has been replicated, users will place items into it via the replica on their own default public folders server or on the nearest server as calculated using connector costs. So no replica of the folder can be considered a master copy. The replicas of a folder update each other on a regular basis, reinforcing the idea that there is no master copy.

You can set up replication of a public folder on either the server that will provide the folder or the server that will hold the new replica of the public folder. To replicate a folder, follow these steps:

1. Right-click the folder in either the Public Folders subcontainer of the Public Folders Store or the default public folders tree. Then select Properties from the pop-up menu. This opens the Properties dialog box for the public folder.

2. Tab over to the folder's Replication property page. In Figure 14.9, we're setting up a replication of Barry's First Public Folder from RED-EXCH01 (in our Exchange 2003 administrative group) to RED-MSG01 (in the Exchange 2007 administrative group). We clicked Add on the Replication property page to open the Select Public Store dialog box.

3. Clicking OK in the Select a Public Store dialog box adds RED-MSG01 to the list of public folder stores to which the folder's contents will be replicated. You can see this in Figure 14.10.

Figure 14.9: Setting up replication of a public folder

Figure 14.10: Viewing the new replica on the Exchange 2007 mailbox server

Let's look quickly at some of the other properties that you can set on the Replication property page. The public folder replication interval is based on a schedule that you can set. Depending on the importance of the contents of the folder and the available network bandwidth, you can accept the default Always Run, select other options from the drop-down list, or create your own custom schedule for replication of this folder.

When replication has started, the Replication Message Received field shows the latest replication status message when you click the Details button. You can give replication messages for a folder higher or lower transmission priority. Options include Not Urgent, Normal, and Urgent. Select Normal or Urgent for folders with contents of some importance to your organization; select Not Urgent for messages of lesser importance.

When replication has taken place, you should see the folder in the Public Folders container of the public folders store on the server on which the new replica was created. The property page will also show you whether the replication status is current or not.

That's really all there is to public folder replication. Monitoring replication is a matter of attending to the replication status of your replicas and, of course, ensuring that the connectors between your routing groups are up and running.

Replicating System Folders

The legacy Exchange systems use a special type of public folder to hold information used by Exchange servers and their clients. However, these system folders are normally invisible to the Exchange 2003 System Manager. To see the system folders, right-click Public Folders in the Folders container and select View System Folders.

Some of these folders must be replicated to assure smooth functioning of your Exchange system. One of these is the Schedule + Free Busy folder, which holds calendar information for every mailbox in the administrative group. If this folder isn't available to other mailbox servers, users will not be able to schedule meetings while looking at the free/busy times for people they want to invite. This folder's absence can also cause some Outlook clients to issue regular and very annoying warnings about not being able to find free busy information.

Ensure that at the very least the free/busy folder is visible across administrative groups, and if that's going to be a problem, consider replicating it. Do remember, though, that Exchange 2007 no longer requires system public folders to handle free/busy information for users on Exchange 2007 mailbox servers when dealing with newer clients (Outlook 2007 and above).

Be careful about most of the other system folders. Unless you know what you're doing, let the system replicate them.

Sometimes replication doesn't seem to be happening, even though ESM says all is well. You can push replication along in two ways. First, make sure that there is at least one item in the public folder you're replicating. Second, in the Folders\Public Folders subcontainer, right-click the folder you're interested in and select All Tasks Ø Send Contents. Use the Send Contents dialog box that pops up to select the server or servers you want to synchronize and the number of days into the past that you want to resend the contents.

Tip 

Don't forget that newsgroups are public folders that you can replicate like any other public folder. Everything works as it does with other public folders.

Warning 

Remember that you can't provide NNTP access to public folders from Exchange 2007 servers.

Setting Public Folders Options

While a good deal of public folder management has to do with replication and limits, there is more to public folder life. Let's take a look at some of the public folder configuration options available to you. You can use the EMS cmdlets to set these options, but we'll continue to show examples using the Exchange 2003 System Manager.

Go ahead and launch the System Manger right now and open the Properties dialog box for your chosen public folder. We'll cover at least a bit about the General, Exchange General, Exchange Advanced, Permissions, and Member Of property pages.

General

The only thing on this page that wasn't on the General property page of the dialog box that you used to create the folder is the Address List Name field. See Figure 14.11.

Figure 14.11: The General tab of the public folder property sheet

Before we explain this field, we need to fill you in a bit on e-mail-enabled public folders. Public folders created in the Public Folders tree - that is, inside the Public Folders container - are automatically e-mail-enabled. This means that they are assigned e-mail addresses. E-mail-enabled public folders can receive and even send messages.

You send a message from a public folder by having Send-on-Behalf-of or Send-As permissions on the folder. You can then modify the From field in an Outlook message.

Note 

As you'll see later in this chapter, not all public folders are automatically e-mail-enabled. You can actually create additional public folder trees that are parallel to the Public Folders tree. Folders created in these trees are not automatically e-mail-enabled.

Back to the Address List Name field, you can use this field to have Exchange display a different name for the folder in Exchange's address lists than the name you gave the folder when you created it.

Exchange General

This page is very much like the Exchange General property page for a mailbox and is shown in Figure 14.12.

Figure 14.12: The Exchange General tab of the public folder property sheet

It has buttons for opening property pages for delivery restrictions (size of incoming and outgoing messages and from where messages will be received) and delivery options (delegate send-on-behalf-of permissions and set a forwarding address). These pages look and behave just like the same pages for a mailbox.

Exchange Advanced

The Exchange Advanced property page, shown in Figure 14.13, is similar to the same page for a mailbox.

Figure 14.13: The Exchange Advanced tab of the public folder property sheet

You can use it to set a simple display name and to unhide and hide a public folder from Exchange address lists. By default, a new public folder is hidden from address lists. You must deselect Hide from Exchange Address Lists to expose it to the address lists.

The Exchange Advanced property page contains a Custom Attributes button. Click it to enter custom information for this recipient.

Permissions

The Permissions property page is shown in Figure 14.14.

Figure 14.14: The Permissions tab of the public folder property sheet

This property page for a public folder includes a range of security options. These options cover client permissions, directory rights, and administrative rights. We'll cover each of these next:

• Client Permissions When you click on the Client Permissions button, you open a separate Client Permissions dialog box. You can use this dialog box to assign specific folder access rights to Exchange users and distribution groups, who can then work with a public folder using their Outlook clients. For emphasis, let us restate what we just said in a somewhat different form: You grant public folder access permissions to Exchange recipients, not to Windows 2003 users and groups. Once access to a public folder is granted, Exchange recipients access the folder in their Outlook client while connected to their mailbox.

  For a graphic reinforcement of this point, click Add in the Client Permissions dialog box to start adding a new user or group that will have access to this public folder. This action opens a dialog box that looks very much like the Outlook Address Book that you use to select recipients to send a message to, not the dialog box that you use to select Windows 2003 users and groups. Click Cancel to get out of the Add Users dialog box.

  Because we created the public folder in Exchange System Manager while logged in as the domain administrator, Administrator is given the role of Owner. The owner of a public folder has complete control over the folder.

  If a user has the correct permissions on a public folder, that user can change access permissions on the folder for other users. Permissions on a public folder can be modified in two places. They can be modified from within the Outlook client using the Permissions property page for a public folder. Permissions can also be modified using the Client Permissions dialog box that is available in Exchange System Manager.

  Which of these you use depends on your security rights. If you are an Exchange user with no extraordinary permissions who is an owner of a public folder, you manage permissions for the folder in Outlook using the Permissions property page for a public folder. If you're an Exchange administrative user, you can change permissions on any public folder using the Client Permissions dialog box.

  There is a group named Default that includes all Exchange recipients not separately added to the Name list box. When the folder is created, this group is automatically given the default role of Author. Note that Authors don't own the folder and can't create subfolders. Also note that Authors can edit and delete only their own folder items.

  Microsoft has come up with several interesting roles - including Owner, Publishing Editor, Editor, Publishing Author, Author, Nonediting Author, Reviewer, Contributor, and Custom - each with a different combination of client permissions. We'll leave it to you to check out the specific permissions assigned to each of these roles. We'll also leave it to you to explore your options regarding public folder access permissions. Generally, the default settings work fine for most folders.

• Directory Rights Users and groups with appropriate permissions at the directory rights level can change the properties of a public folder object in Active Directory. The Directory Rights property page that pops up when you click the Directory Rights button is the same as the Security property page for other Exchange recipients. That's why public folders don't have a Security property page.

• Administrative Rights Administrative rights are permissions to manage a public folder using Exchange System Manager. Click the Administrative Rights button to open the Administrative Rights property page. Administrative permissions include rights to modify the public folder access control list and the public folder administrative access control list. These rights include permission to use the Directory Rights property page and the Administrative Rights property page, the very page that we're talking about right now. Permissions also include the right to set deleted-item retention time and space quotas for the public folder. You had the option of exercising both of these rights on the Limits page when you created your public folder earlier in this chapter.

Let us conclude this section by pointing out that administrative rights are granted to Windows 2003 users and security groups, not to Exchange recipients and distribution groups.

Member Of

We don't need to say a lot about the Member Of property page in the public folder Properties dialog box; we just want to point out that public folders, just like other Exchange recipients, can belong to security and distribution groups. When you send a message to a distribution group that includes a public folder, the message appears in the folder.

Creating Public Folder Stores

Before you can create a new public folder store, you need to understand how public folder stores and what are called public folder trees relate to each other. You'll have a hard time using public folder stores without this knowledge.

Each public folder store is directly linked to a public folder tree. The default public folder tree on an Exchange server, Public Folders, is linked to the default public folder store, Public Folder Store (SERVER_NAME) on the server. A public folder store can link to only one public folder tree and vice versa. You can not link any more public folder trees to the default public folder store.

The default public folder tree and store are unique: They are the only tree and store combination that is MAPI-enabled. If you create additional public folder trees on a server, they cannot be MAPI-enabled. This means that the default public folder tree is the only one that can be accessed by MAPI-aware e-mail clients such as Outlook and IMAP4 clients.

When you look at public folders in Outlook, you're looking at the default tree defined by the mailbox store that contains your mailbox. By configuring this association at the mailbox database level, you tell Exchange from which server to access public folders replicas when a client such as Outlook opens a mailbox in your new mailbox store.

If clients such as Outlook can see only the default public folder tree on an Exchange server, of what use are additional public folder trees? Good question. The answer is simple. You can access additional public folder trees using any of the following clients:

• An enhanced Internet-standard Web Distributed Authoring and Versioning (WebDAV) client

• An Internet-standard Network News Transfer Protocol (NNTP) client

• Any process accessing the Exchange server through the new .NET APIs

Warning 

The Exchange 2003 Installable File System (IFS) is gone in Exchange 2007; while it provided another way to access additional public folder trees in Exchange 2003, you can't use it in Exchange 2007.

WebDAV clients are implemented in web browsers. Microsoft has enhanced the WebDAV Internet draft standard to allow it to work seamlessly with Exchange. WebDAV is, however, a deprecated access method in Exchange 2007.

Finally, additional public folder trees can be made available through the NNTP server protocol, which can be accessed with a Network News Transfer Protocol client such as the one in Microsoft's Outlook Express. If you require NNTP access, though, you have to have legacy servers in your organization; Exchange 2007 removes support for NNTP.

Note 

Exchange 2007 does not support general purpose public folder trees. We are including information about them if you are inter-operating with Exchange 2000/2003. You must move all data in the general purpose public folder trees to the default public folder tree prior to removing Exchange 2000/2003 from your enviornment.

Now that we've addressed our public folder trees, let's create a public folder store. Before you can do so, however, you must create a public folder tree to associate it with. To create a new public folder tree, find and right-click the Folders container for your administrative group, then select New Ø Public Folder Tree from the pop-up menu. The public folder tree Properties dialog box opens. Enter a name for the tree. We're going to call ours Demo Public Folder Tree. When you're done, click OK. You should now see your tree in the Folders container.

Now you can go ahead and create your public folder store. Right-click either your default storage group or the storage group that you created earlier in this chapter. Then select New Ø Public Store from the pop-up menu to open the public folder store Properties dialog box. Name your new public folder store in the General property page. Next, click Browse next to the Associated Public Folder Tree field and select the public folder tree that you just created.

The Database property page looks and works exactly like the same page on the mailbox store Properties dialog box. The Limits page has a Deleted Items field, but it doesn't have a Retention field for mailboxes, for obvious reasons. Public folder stores don't hold mailboxes. The Limits page also has an additional field, Age Limits for All Folders in This Store. Use this field to set a default number of days before an item in any public folder in the store is deleted. You can override the default using the Limits page for any public folder.

When you're done creating your public folder store, click OK on the public folder store Properties dialog box. Now you should create a public folder in your new public folder tree.

Managing Public Folder Stores

Based on your experience with it when creating a public folder store, you should have no trouble using the public folder store Properties dialog box to manage your new public folder store. We won't discuss the dialog box any further here; instead, we're going to discuss three aspects of public folder store management in this section:

• Using public folder store management containers

• Mail-enabling public folders in a non-default public folder tree

• Providing access to public folders in a non-default public folder tree

Using Public Folder Store Management Containers

A public folder store has a range of subcontainers, just like a mailbox store. As with mailbox stores, these subcontainers are used for managing the store. Many of the subcontainers are used in the same way they're used for mailbox stores:

• Logons Works just like the Logons subcontainer for mailbox stores.

• Public Folder Instances Shows information for all public folder instances in a public folder store. This includes not only the folders in the Public Folders subcontainer, but also folders that have been replicated to this server from other Exchange servers.

• Public Folders Shows resource usage and other information for all public folders in the store in a manner similar to the Mailboxes subcontainer for mailbox stores. These are folders that originated in the store or, to put it another way, that are local to the store.

• Replication Status Shows progress when folders are replicating across Exchange servers.

• Full-Text Indexing Works just like the same subcontainer for mailboxes. In fact, you set up full-text indexing for public folder stores exactly as you set it up for mailbox stores.

Mail-Enabling Public Folders in a Non-default Public Folder Tree

As we noted in the section "Managing Public Folders'' earlier in this chapter, when you create a public folder in the default public folder store, it is automatically mail-enabled. It can send and receive messages. Public folders created in other public folder stores can send and receive e-mail messages too, but you have to mail-enable them before this is possible. Let's mail-enable the folder Test that you created earlier. To mail-enable a public folder, right-click it and select All Tasks Ø Mail Enable from the pop-up menu.

After a few seconds, select Refresh from the Actions menu and open the Properties dialog box for the folder. The folder now has an E-Mail Addresses property page and a set of e-mail addresses to boot. Open your Outlook client and notice that the folder is in the address book. You can send messages to it. Don't close your Outlook client; we're going to use it in the next section.

Providing Access to Public Folders in a Non-default Public Folder Tree

Just to prove that non-default public folder trees are unavailable to Outlook clients, look at the public folder hierarchy in your client. You see the default public folder tree, Public Folders. However, you don't see the new tree that you just created.

Because non-default public folder trees don't support MAPI content, you can't post Exchange messages in them. However, you can send messages to them if they're mail-enabled, and you can drag and drop Exchange items such as messages from an Outlook client into them. You can also drag and drop any file that you want into them. Finally, you can right-click the folder and choose to begin creating a new file using whatever applications are supported on your computer.

Warning 

Be careful when you share a public folder or a public folder tree. Initially, the Windows 2003 group Everyone, which includes all Windows 2003 user accounts (but not anonymous connections), has a lot of control over the folder. By default, members of this group can read and add items to the folder, including subfolders. Thankfully, the group Everyone does not have delete rights by default, but you might not want it to have all of the rights granted by default. You can change Everyone's rights in the Security tab.