Export (0) Print
Expand All
Expand Minimize
5 out of 9 rated this helpful - Rate this topic

Public Folder Routing

 

Topic Last Modified: 2006-03-09

By Kent Tilger

The purpose of this article is to describe the public folder routing behavior in an attempt to understand public folder mail flow scenarios and document recovery options for misrouted public folder e-mail messages. Messages that have been erroneously routed to a public folder server that does not have the full hierarchy, or mail that is destined to a server that is currently unavailable, does not have to end up in a non-delivery report (NDR). There are other possible options for successful delivery.

Public folder routing is a two stage process. Although a brief description of Stage 2 is presented, this article focuses on Stage 1.

  • Stage 1: Because Microsoft® Exchange transport cannot determine the location of the best replica on its own using the directory, the message needs to be delivered to a store containing the public folder hierarchy for the purpose of identifying a store where an actual replica exists. Transport determines a public folder store that holds the hierarchy, and routes the message to that store.
  • Stage 2: After the message has been delivered to the server defined in Stage 1, the public folder store either accepts the message for local delivery if it contains a content replica of the mail-enabled folder, or it refers transport to a content replica on a different server.

When the categorizer receives a message, it looks up the e-mail address in the directory. If the e-mail address resolves to a public folder directory entry, special action is needed. Public folder directory entries exist to allow you to send e-mail messages to a public folder. Public folder directory are not involved with replication, posting to, or reading from a public folder. Only mail-enabled public folders have directory entries. Therefore, only mail-enabled public folders can have e-mail messages delivered to them. Public folder directory entries exist in the Microsoft Exchange System Objects container in the Active Directory® directory service.

Consider the following scenario.

  SMTP: NONE

  X500: NONE

  X400: NONE

  LegacyEXDN: /O=EX/OU=EXB/cn=Recipients/cn=PFReplica 080F3334741354B0CF073A92C149B21007153

  Unable to get MDB guid, hr 800300fd

  RP_DOMAIN: NONE

The categorizer looks up the homeMDB attribute of the public folder's directory entry. This shows which public folder hierarchy the folder belongs to. Usually, there is only one public folder hierarchy, and that is the default public folder hierarchy associated with the default public stores that are created automatically.

Next, the categorizer looks up the hierarchy's directory entry. This contains a list of all the stores in this hierarchy (msExchOwningPFTreeBL). Even though the categorizer still does not know the location of a replica of the folder, it knows which stores hold the right hierarchy, and can tell it where to go.

When a new public folder store is created, the back link is added to the msExchOwningPFTreeBL attribute. The most recently installed servers will be at the beginning of the list. The built-in two day delay was added to account for the time necessary to fully replicate the hierarchy to a specific server. In large organizations, this can be a lengthy process.

The categorizer determines the public folder server destination by issuing a series of Lightweight Directory Access Protocol (LDAP) requests with specific filters to identify a server that contains a public folder hierarchy.

The categorizer considers the local server the best choice, if there is a local hierarchy. If the local server contains no hierarchy, the categorizer searches for the routing group that this computer is located in. It reads the msExchRoutingGroupMembersBL attribute on this routing group object. Then, it gets the distinguished name of the public folder tree and reads the msExchOwningPFTreeBL attribute, which is the message database (MDB), distinguished names of the MDBs that contain that public folder tree. From the MDB distinguished name, the categorizer gets the owning server distinguished name. It gets the server name for each MDB distinguished name. It uses the owning server distinguished name for each server to search for membership within the routing group. The newest public MDB is chosen from the available servers within the routing groups. Servers running Exchange Server 2003 or Exchange 2000 Server will be preferred over Exchange Server version 5.5 servers. When picking the public MDB, only servers whose MDB creation history is longer than two days, by default, will be chosen. If only Exchange Server 5.5 servers contain hierarchy within a specific routing group, there is the possibility that NDRs destined to public folders will loop. If no server within the routing group contains a hierarchy, the administrative group will be evaluated. If no server is found, the most recent server on the msExchOwningPFTreeBL list is chosen.

The following is the directory entry for the public folder recipient.

  > distinguishedName: CN=PFReplica,CN=Microsoft Exchange System Objects,DC=domain,DC=com; 

  > proxyAddresses: SMTP:PFReplica@domain.com

  > targetAddress: expf:PFReplica 080F3334741354B0CF073A92C149B21007153; 

  > legacyExchangeDN: /o=EX/ou=EXB/cn=Recipients/cn=PFReplica 080F3334741354B0CF073A92C149B21007153;

Consider the following scenario.

  SMTP: PFReplica@domain.com

  X500: CN=PFReplica,CN=Microsoft Exchange System Objects,DC=domain,DC=com

  X400: c=US;a= ;p=Buckeyes;o=EXB;s=PFReplica;

  LegacyEXDN: /O=EX/OU=EXB/cn=Recipients/cn=PFReplica 080F3334741354B0CF073A92C149B21007153

  MDB guid: {67ECF964-2E4B-442A-9E6C-03CEEFD0C89D}

  RP_DOMAIN: SERVER2.domain.com

The MDB GUID maps to a public folder store. This can be the first store listed in the BL list.

The RP_Domain maps to the server FQDN that contains the top level hierarchy.

The following is the public folder store directory entry.

  >distinguishedName: CN=Public Folder Store(SERVER2),CN=First Storage Group,CN=InformationStore,CN=SERVER2,CN=Servers,...

  > homeMDBBL: CN=SMTP (SERVER2-{67ECF964-2E4B-442A-9E6C-03CEEFD0C89D}),CN=Connections,...

  > objectGUID: 67ecf964-2e4b-442a-9e6c-03ceefd0c89d;

The following items are not considered during Stage 1:

  • Routing infrastructure, including routing group and connector configuration.
  • Connector configuration for allowing or disallowing public folder referrals.
  • Exchange Server 2003 custom public folder affinity.

There is no built-in logic to try to reroute the message. After the message is submitted and is in a queue destined to a particular MDB GUID on a particular server, transport has no idea that it needs to do something different with this message. The store tells transport to send this message to a particular server regardless of whether this server is functional or not.

If the message is already on the hierarchy server in local delivery retry, nothing can be done. However, in special circumstances, where the mail is in remote delivery destined to a possible hierarchy server, you can redirect the messages to different public folder hierarchy servers. This can be beneficial in cases where the server chosen in Stage 1 is unavailable for an extended period of time. The following methods can be used to change the Stage 1 routing decision:

  • Setting ResetMessageStatus to force re-categorization of mail.
  • Setting IgnorePFTimeLimit to define the number of days to ignore new public stores. If the messages have arrived at the destination server through Simple Mail Transfer Protocol (SMTP), this setting can be used with ResetMessageStatus. Or, the message can be dropped into the \Pickup folder. If the message is in remote delivery on the sending server, IgnorePFTimeLimit will not be effective.
  • Editing the msExchOwningPFTreeBL attribute directly is not possible, because it is a back link. However, you can delete the msExchOwningPFTree attribute on a specific public store object. If you delete the msExchOwningPFTree attribute on the public store object that is unavailable, the msExchOwningPFTreeBL back link attribute will be automatically removed from the back link list. By changing the msExchOwningPFTree attribute, you change the list in the msExchOwningPFTreeBL list, and thus alter the public folder routing decision.

The following failure scenario is an example of when you might consider redirecting the public folder messages:

  • The public MDB destination server chosen in Stage 1 does not have full hierarchy.
  • The message is delivered to a remote server and hangs in the Local Delivery queue. An .eml file is present in \Queue folder.
  • As long as the messages are in SMTP (\Queue), the Stage 1 decision is not determined.
  • Messages can be resubmitted to transport, if available in SMTP \Queue, to force the Stage 1 routing decision to take place again.

The following failure scenario is an example of a situation where the Stage 1 decision is commonly considered to be determined, but can still be rerouted:

  • The public MDB destination server chosen in Stage 1 is down or unavailable.
  • The message stays on the originating server in the Destination Unreachable queue.
  • Having been submitted by a MAPI client, the message is located in the Temp tables in the store and will not be re-categorized even if you set ResetMessageStatus to 1.
  • To work around this situation, you can remove these messages from the temp table using a tool such as MFCMapi, save the messages as .eml files, and replay the messages through the system by placing them in the \Queue folder after stopping SMTPSvc. When SMTPSvc is restarted and ResetMessageStatus is set to 1, the message will be re-evaluated, and transport will start over at Stage 1.

Inbound mail from the Internet destined to public folders can present an issue depending upon which hierarchy server is chosen in Stage 1. If there are multiple hops to remote routing groups that contain hierarchy servers, it could be advantageous to configure gateways or bridgeheads with hierarchy-only public folders, or at least have hierarchy servers available within the inbound routing group.

The configuration option is to mount a public folder store with the top level hierarchy. on the inbound gateway server or on a server within the inbound routing group. That way, it would always select itself for the TLH lookup. It does not have to hold any content. When it first gets added, it will take a few days for this server to get the full hierarchy. Moving forward, this server will be chosen for Stage 1 routing.

In some cases, it may be advisable to put public stores back onto their mailbox stores. This also solves other issues regarding logons and loading.

These stores are hierarchy-only servers. They hold no content, but serve three useful purposes:

  • Prevent clients from hanging, because their dedicated public folder store is unavailable, even though their mailbox server is available.
  • Reduce the load on the public folder content servers. Every time a client logs on, they connect to their public folder store, regardless of whether they actually want to look at a public folder.
  • Clients will use the local public folder hierarchy for Stage 1 routing instead of relying on the msExchOwnignPFTreeBL logic.

The configuration option is to mount the public folder store on every mailbox store just for the hierarchy.

This practice spreads the initial TLH lookup load around, because it will be done on the local mailbox store.

For information about rerouting messages and the ResetMessageStatus registry key, see Microsoft Knowledge Base article 279616, "XCON: Adding a Registry Key to Re-Categorize Messages."

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC\Queuing\

  Value Name: ResetMessageStatus

  Data Type: REG_DWORD

  Radix: Hexadecimal

  Value: 1

For information about the IgnorePFTimeLimit registry key, see Microsoft Knowledge Base article 328870, "Public folder routing is enabled before the hierarchy is replicated."

When a new server is introduced that contains a public store, its distinguished name is added to the msExchOwningPFTreeBL attribute in the Folder Hierarchies - Public Folder object in Active Directory. To configure the number of days that the routing engine bypasses the new public folder store, configure the following key with the number of days the routing engine will ignore the public folder. The default is two days.

  HKLM\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters

  Value Name: IgnorePFTimeLimit

  Data Type: REG_DWORD 

  Radix: DECIMAL Value: Number of days the routing engine will ignore the public folder. (Default = 2 Days)

  Restart the Internet Information Services (IIS) Admin service (IISAdmin).

For more information, see the following Microsoft Knowledge Base articles:

 
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.