Getting a piece of email to a main-enabled public folder actually takes a bit more work than one might expect. That is because public folders have some interesting characteristics that separate them from other mail-enabled objects in the directory:
- There are actually many correct final destinations for a message bound to a public folder.
- This list of final destinations is not actually in the Active Directory.
This is because public folders are actually partitioned in 2 ways. First a public folder belongs to a specific top-level-hierarchy (aka TLH). The TLH a folder belongs to is determined by the public MDB is it created on. A public MDB is either a part of the MAPI-TLH (visible to Outlook), or part of an application-TLH (visible only via DAV, IFS, etc). There is only one MAPI-TLH per organization, but there can be multiple application TLH’s.
Just because an MDB is part of the same TLH as a folder does not mean that the content of that folder is replicated to that MDB. This is the 2nd way in which public folders are partitioned. Only the TLH membership of the folder appears in the ActiveDirectory… the location of content replicas is only kept in the public MDB’s themselves.
Knowing this, let’s take a look at how mail-enabled PF's work. This is basically a 2 step process:
1. A hierarchy public MDB is chosen from the TLH and mail is routed there first
2. This public MDB either accepts the message or refers transport to a content-replica
This can get a little tricky when you consider interaction with 5.5 and the potential for mail loops. To avoid mail loops, once a choice in step #1 is made, it must be honored by all servers.
For step #1… all servers in the TLH are ranked in order of preference. This preference is:
- MDB is on local server
- MDB is on other E2K+ server is same routing group
- MDB is on other E2K+ server in same admin group
- MDB is on other E2K+ server in your org
- 5.5 servers
In cases of a tie… an arbitrary choice is made (order in which servers are returned by the DC). At one point this was described as random by the AD folks, but in practice this is usually the server most recently added to the TLH.
However, if the hierarchy had not had a chance to replicate to the chosen server in step #1, this lead to mail getting stuck in the local delivery queue. This lead to a change in Exchange 2003, where we preferred MDB’s with a create time of > 2 days in the past (to give the hierarchy a fighting chance to replicate).
One question that is sometimes asked is “wouldn’t it be simpler if the information about content replica’s was stored in the AD?”. The answer is yes, delivery would be simpler, but this would complicate a number of other things:
- Adding more globally replicated data to the AD is typically the last choice
- This would require a backlink of some sort per-folder/per-replica
- Deleting a public MDB would cause a massive replication update (instead of simply updating the TLH object).
- The data already is replicated around as part of the PF replication engine… why replicate it again?
- Mike Swafford
