Last week I installed a new exchange server into the Dallas Administrative Group and the Dallas Routing Group. Default installs of exchange include a mailbox database and a public folder database. I wasn’t really concerned with the public folder database (not intending to keep it) so I just left it there for now (planning to delete it at a later date) and proceeded to create a journaling mailbox on the mailbox database. (This journal mailbox isn’t pertinent to this post other than it only RECEIVED mail and didn’t DELVIER any of it).
Today I noticed that there were a LOT of messages backed up in the various queues on the new server (Ex3) – including over 2900 messages in the Local Delivery Queue destined for public folders on OTHER servers! This, I thought was quite strange. Why would those messages be delivered to Ex3 if it doesn’t host any of the public folder replicas???
However, what I didn’t notice at first were ACLs on the “Connection” & “Relay” access on the SMTP virtual servers on every other Exchange server in the Org. So the new server (Ex3) couldn’t telnet to any other exchange server to deliver messages. The Journal mailbox was receiving messages just fine because the default configuration on SMTP virtual servers when you install Exchange is to accept all authenticated connections – which would include other Exchange servers.
So I did a little research. Public folder routing happens like the following:
1. Message comes in from the internet.
2. Categorizer looks up homeMDB for the recipient where it finds the DN of the top-level public folder hierarchy.
3. Next, the categorizer looks up the top-level hierarchy object that is retrieved from the folder's homeMDB attribute to obtain a list of all the servers in that hierarchy from the msExchOwningPFTreeBL value.
4. To determine which public folder store or server to deliver to, the categorizer uses the following criteria:
· Does one of the public folder stores exist on the local server? If so, Exchange uses that store.
· Does one of the public folder stores exist on an Exchange server in the local routing group? If so, Exchange uses that store.
· Does one of the public folder stores exist on any Exchange server? If so, Exchange uses that store. Otherwise, Exchange uses the first store in the list.
In my case, there are 3 servers in the Dallas routing group: Ex1, Ex2, and (new) Ex3. Ex1 and Ex2 both receive messages from the internet edge servers directly. Ex1 has a public folder database but Ex2 does not since it’s just basically a Front-End server that’s also used for message routing. The folder hierarchy is homed on Ex1.
So – Ex2 was receiving messages from the internet destined for public folders. Based on the 2nd bullet point in #4 above, it would deliver messages to the public folder store on either Ex1 or Ex3 since they were both in the local routing group and had a public folder store in the hierarchy. BUT since Ex3 couldn’t telnet TO any other server and could only RECEIVE, messages backed up in the local delivery queue. That’s when I added the IP address for Ex3 to the SMTP virtual servers on all the other Exchange servers in the Org.
The queues on Ex3 to the other routing groups emptied quite quickly once telnet was working – but what they were delivering was hierarchy messages from Ex3 to the other public folder stores (to announce there’s a new public folder store on Ex3 and request a hierarchy replication back to Ex3 so it knows what folder is located where, etc). However, the Local Delivery Queue on Ex3 wasn’t moving at all and this made me a little concerned.
What I didn’t realize at first was that the PF store on EX3 had to wait for ALL public folder hierarchy replication to complete and come back to EX3 with the full hierarchy before EX3 knew where to deliver those messages stuck in the queue – which explains why the local delivery queue took so long to empty.
After all the messages got delivered successfully, I verified that there were NO replicas in the public folder store on EX3 and promptly deleted it so that it wouldn’t be included in public folder mail delivery again. Whew!
