Why on earth did my email to a public folder go there?
Published Sep 10 2004 04:25 PM 3,034 Views

The following has come up in various guises in internal questions and so I thought it was about time this was given to a wider audience.

 

I’ve just sent an email to a public folder – how did it actually get there, given I have multiple replicas of the folder...?

 

Delivering an email to a mailbox is relatively simple. A mailbox is located on a specific mailbox store, on a specific server. Every mailbox has an entry in the active directory, which the transport code can use to work out where the mailbox is and how to get there.

 

The problem with delivering to a public folder is that it may exist on multiple servers. There’s no “home server” for a public folder.  The replica list of a folder (the property that governs where the folder’s contents are physically stashed), is actually not in the Active Directory at all – it’s a property found only in the public store database.  How on earth does the transport code know which public folder store to deliver the email to?

 

It uses a “two stage process” (insert funny finger wiggling quotes if you desire).

 

Stage 1 is where transport looks for a public folder store which holds the hierarchy that the folder belongs to and forwards the message to that store. This store can then tell transport where an actual replica exists.

 

Stage 2 is when the message is redirected to a store that actually holds a replica of the folder.

 

Once the message has been successfully placed in a folder, it will replicate to all other replicas of the folder by normal public folder replication.

 

Stage 1

 

Stage 1 occurs when Exchange’s transport mechanism (SMTP and the categorizer) first gets hold of the message – either from an external source (in which case this would be your inbound Exchange gateway server), or an internal source.

 

  1. When the categorizer receives a message, it looks up the email the address in the directory.  If the email address resolves to a public folder directory entry it knows that it has to do something special.

How, what and where are public folder directory entries?  Public folder directory entries exist purely to allow you to email a public folder, they have nothing to do with replication, posting to or reading from a public folder.  Only “mail enabled” public folders (right click on public folder in Exchange System Manager and choose mail enable) have directory entries – hence only mail enabled public folders can have email delivered to them.  Public folder directory entries exist in the “Microsoft Exchange System Objects” container in the Active Directory. Public folder directory entries have an objectCategory of “ms-Exch-Public-Folder” and an objectClass of “publicFolder”.

 

  1. The categorizer looks up the homeMDB attribute of the public folder’s directory entry.  This tells it which PF hierarchy the folder belongs to (usually there’s only one PF hierarchy and that’s the default “Public Folders” hierarchy associated with the default public stores that get created automatically).

What is a PF hierarchy?  By default an Exchange organization contains only one hierarchy – the “Public Folders” hierarchy. You can see this hierarchy when you look at your list of public folder through Outlook or OWA. Sometimes this is referred to as the MAPI hierarchy as it is available to MAPI clients (Outlook).  Additional hierarchies can be created, and new public stores can be created and assigned to hold data for these hierarchies.  They tend to be used for specialized applications or data storage, not designed to be access directly by clients.

 

  1. Now it looks up the hierarchy’s directory entry.  This contains a list of all the stores in this hierarchy (msExchOwningPFTreeBL).  So even though the categorizer still doesn’t know the location of a replica of the folder, it at least knows which stores hold the right hierarchy and can tell it where to go.

  2. It picks a store from this list and sends the message to it. The store is picked in the following order:

    • If its own local store is in the list – it will use that.

    • If not then the first store in the list which is in the same Routing Group

    • If there is no store in the same Routing Group, then simply the very first entry in the list.< /font>

This list always has the most recently added public folder stores to the organization at the top (and as a public folder store is created when a new server is installed, normally this means the most recently installed servers will be at the top of the list).  What could happen is we pick a server that has just been added to the org and may not have the full public folder hierarchy yet (and hence not know what to do with the message). To prevent this in Exchange 2003, we don’t select any stores younger than two days, unless there is no alternative.

 

Stage 2

 

Stage 2 now occurs. We’ve delivered the message to a store that at least knows where a replica exists – what next?

 

  1. If there is a replica on this store, then the message is simply delivered. If not the store returns the location of the closest replica and hands the message back to transport – which then sends it on to the store which actually holds the replica.  The process of choosing the “closest replica” is somewhat similar to the client referral mechanism (pick servers in same routing group first, then go by link cost) but with three significant differences (after all we are trying to deliver an email message, not refer a client to a server).

    • We take account of link state information, so we don’t pick servers we can’t currently send email to.

    • We don’t use the new custom referral list available in Exchange 2003.

    • The “Do not allow public folder referrals” setting on a connector has no impact.

Hopefully this explains why email messages to public folders may travel in a certain direction and explain why they are delivered (or queued for delivery) to a particular server. Finally in case all of the above made absolutely no sense whatsoever, here are a few quick examples that show this in action:

 

  • If a message is submitted from a mailbox (or has arrived at this server from an external source) and there is public folder store on this server and this server also has a replica of the folder itself, then the message will never leave the box. It will be delivered to the local replica.

  • If a message is submitted from a mailbox (or has arrived at this server from an external source) and there is public folder store on this server but this server doesn’t have an actual replica of the folder, the message will be forwarded to a server than actually has a replica of the folder.

  • If a message is submitted from a mailbox (or has arrived at this server from an external source) and there is no public folder store on this server, the message will be sent to a server that has a public folder store (stage 1). If this server doesn’t have a replica of the folder, the message will then be forwarded on to a server that does have a replica (stage 2).

Hope you found this helpful J

 

- Andrew Moss

 

2 Comments
Version history
Last update:
‎Jul 01 2019 03:00 PM
Updated by: