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.

 Recipient Pre-Categorizer

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.

 How Is the Stage 1 Public Folder Server Destination Determined by Transport?

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;

 Recipient Post-Categorizer

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.
  

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

• 279616, "XCON: Adding a Registry Key to Re-Categorize Messages"
  
• 328870, "Public folder routing is enabled before the hierarchy is replicated"