Exchange Public Folder Best Practices: Mail-Enabling Public Folders

A mail-enabled public folder is a public folder that has a directory entry. Users can look up a mail-enabled public folder in the address book and send e-mail to it. In Microsoft® Exchange Server 5.5, all public folders were mail-enabled and hidden by default. In Exchange 2000 Server and Exchange Server 2003, folders can be mail-enabled or mail-disabled, depending on whether the Exchange Server organization is in mixed mode or in native mode. For information about mail-enabling a public folder, see Mail-Enabling a Public Folder.

When an Exchange Server organization is in mixed mode, all folders in the MAPI top-level hierarchy (TLH) are mail-enabled. Public folders in MAPI TLH are mail-enabled in mixed mode for backward compatibility with Exchange Server 5.5. The Exchange Server 5.5 administration program expects to find a directory entry for every public folder. Without a directory entry for every public folder, you cannot administer folders from the Exchange 5.5 administration tool.

When you switch the Exchange Server organization to native mode, public folders in the MAPI TLH can be mail-enabled or mail-disabled. For new Exchange 2000 Server folders or new Exchange Server 2003 public folders, the default configuration is mail-disabled. The application TLH can be mail-enabled or mail-disabled in a mixed mode, but the default configuration is mail-disabled. In native mode, the application TLH can be mail-enabled or mail-disabled, and the default configuration is mail-disabled.

The following table summarizes mail-enabled status as discussed here.

If you have many mail-enabled public folders in your organization, you should understand how public folder posts that are sent over e-mail are routed to each replica in your organization.

When public folders are mail-enabled, an Active Directory® directory service entry of objectClass publicFolder is created. The public folder entry contains mail-specific attributes. For example, the public folder entry has the following attributes:

• proxyAddress

• mailNickname

• homeMDB

It is important to note that the public folder entry does not contain an attribute that explains where the replicas for the public folder exist.

It takes two steps to deliver a public folder post through e-mail.

1. Exchange Server uses Active Directory to identify which public folder store holds the folder hierarchy to which the folder belongs. Then Exchange Server forwards the message to that public folder store. The receiving public folder store then transports the message to a folder replica as described in step 2 later.

   When an Exchange Server receives a message that is bound for a public folder, it queries Active Directory to determine the homeMDB attribute of the public folder. The homeMDB attribute contains the distinguished name (DN) of the folder hierarchy in which the public folder resides. The folder hierarchy entry, in turn, contains the msExchOwningPFTreeBL attribute. The msExchOwningPFTreeBL attribute specifies the DNs of all stores that make up the folder hierarchy. At this point, the final destination, which is the folder replica, is still unknown. However, because Exchange Server knows the names of all stores that contain the folder hierarchy, the receipt of the message by any one of these stores causes a referral to an appropriate replica. Exchange Server selects one of the stores that are listed in msExchOwningPFTreeBL and sends the message according to the following criteria:

   • If the store of the local Exchange server, which is currently processing the message, is listed in the msExchOwningPFTreeBL attribute, Exchange Server submits the message to its local store.

   • If the local store is not listed, Exchange Server tries to locate a store in the local routing group.

   • If no store is listed in the msExchOwningPFTreeBL attribute that is in the same routing group, Exchange Server uses the first store that is returned.

   The msExchOwningPFTreeBL attribute always returns the public folder store that was most recently added first. A public folder store is created when a new server is installed. Therefore, frequently, the most recently installed servers are returned first. If the server is new, it may not contain a replica of the public folder hierarchy yet. Therefore the delivery of the message to this store causes an non-delivery report (NDR). In the Exchange 2000 Server Post-Service Pack 3 (SP3) Update Rollup and Exchange Server 2003, this logic has been changed so that messages are not submitted to a public store if the public store is less than two days old. However, if no public stores older than two days exist, the message is submitted to the new store anyway.

   Note

   You can configure the age (in days) that Exchange Server will submit messages to for this operation. For more details, see Public folder routing is enabled before the hierarchy is replicated.

2. After the message is sent to a store in the folder hierarchy, the message is redirected to a store that holds a replica of the folder. Exchange Server redirects the message by using a logic that is similar to how Exchange Server provides client referrals to replicas. If the receiving server contains a local replica, the message is submitted locally. If no local replica exists, Exchange Server searches for a replica in the same routing group. If no replica exists in the routing group, Exchange Server delivers the message to a replica that is outside the routing group across the path with the lowest cost.

   However, Exchange Server treats public folder messages differently from replication messages. Exchange Server treats public folder messages much like it treats regular mail messages. Message size restrictions and delivery restrictions apply. Exchange Server refers to the link state table to verify that the destination server is reachable. Note that restrictions on public folder referral and the custom Per Server referral lists are ignored.

By understanding how public folder e-mail messages are routed, you can now determine how to configure Exchange Server to optimize message delivery for public folders.

If your organization requires heavy use of mail-enabled public folders, you should consider replicating full hierarchies to servers that might be the initial receivers of mail that is destined for public folders but does not replicate content to them. These servers are typically bridgehead servers. This configuration causes mail to be routed based on link state information because mail will always be submitted to the local store first and then routed.

By specifying bridgehead servers in this way, you can also manage connector costs if the bridgehead servers or connectors fail. If the bridgehead server or connectors fail, you can temporarily raise the connection cost so new messages can take lower cost paths until the bridgehead server or connector comes back up. One trade-off to consider, however, is that replication traffic will increase somewhat because there is another hierarchy in your organization.

For more information about how public folder e-mail messages are routed and why Active Directory does not just contain a list of replicas, see these Exchange Team Blog entries:

• "Why on earth did my email to a public folder go there?"

• "How mail-enabled Public Folders work"

External E-mail Sent to Public Folders

When you send Simple Mail Transfer Protocol (SMTP) mail, which is mail that is not from a MAPI source, to an Exchange 2000 Server or an Exchange Server 2003 server public folder, the message class is IPM.Post. In Exchange Server 5.5, the message class of a message that is sent to a public folder is IPM.Note. This difference is important for organizations that have created mail archiving solutions by using public folders and Exchange 5.5.

A message class of IPM.Note translates to a basic mail MAPI mail message. A message class of IPM.Post translates to a MAPI public folder post. The two message class types have different properties. Microsoft Office Outlook® displays them differently, and Exchange Server transforms them differently when you convert for other clients.

You can change the behavior of Exchange 2000 Server and Exchange Server 2003 by setting a registry key. The registry key stores all SMTP messages that are submitted to public folder addresses as IPM.Notes. For more information about setting this registry key, see the Microsoft Knowledge Base article, "Update to permit the caching of incoming SMTP messages as IPM.Note in Exchange Server 2003."

Finally, if you want to enable users who are outside your organization to post messages to public folders, you must make sure that the permissions on the public folders are set appropriately. In Exchange Server 5.5, all public folders were configured so that the Everyone security principle had Contributor permissions. All non-authenticated inbound SMTP messages were treated as if they were sent from Everyone, and external posts were delivered.

In Exchange 2000 Server and Exchange Server 2003, the Everyone security principle was removed from default folders in the MAPI TLH. Instead, Exchange 2000 Server and Exchange Server 2003 use the Anonymous security principle and assign Contributor permissions to Anonymous by default. In Exchange 2000 Server and Exchange Server 2003, inbound, non-authenticated messages are treated as Anonymous.

For more information, see the Knowledge Base article, "Anonymous Permissions for Public Folder Are Set to Contributor in Exchange 2000."

For More Information

To learn more about public folders in Exchange Server, see the following resources:

• Best Practices for Exchange Server Public Folders

• Selecting the Appropriate Public Folder Solution

• Selecting the Appropriate Client for Exchange Public Folder Access

• Exchange Public Folder Best Practices: Implementing Replication

• Exchange Public Folder Best Practices: Understanding Referrals

• Exchange Public Folder Best Practices: Managing Data

• Exchange Public Folder Best Practices: Scalability

• Exchange Public Folder Troubleshooting Resources

• Mail-Enabling a Public Folder