Public Folder routing
Posted in When decommissioning Exchange servers, I like to stop the Exchange services or shut the server down for a week or so before uninstalling Exchange from the server; that way if I have overlooked anything and an issue arises I can bring the server back online very quickly. This week I was planning the removal of an Exchange 2003 public folder server. I re-homed all of the public folders and waited until they had all disappeared from the public folder instances container for the pubic store on the server in question. The next day I shut the server down and after a while noticed that there was mail queuing on the front-end servers to the public folder server that I had shut down.
At first, it didn’t make sense to me why the mail was queuing for the public folder server that I had shut down - there were no public folder replicas on the server, so in my mind there was no reason for any mail to be delivered to that server at all. After closer inspection of the messages in the queues, I could see that the messages were queuing for public folders that never had replicas on the server in question, which led me to believe that the server was playing some type of ‘bridgehead’ role that I didn’t know about.
I came across this Technet article that explains how public folder routing works and it cleared up the confusion that I had. In summary, when a message is received by a front-end server (or any Exchange server that doesn’t contain a public store), the server queries Active Directory for a public folder server that contains a copy of the public folder hierarchy. The transport then delivers the message to the server that contains the hierarchy based on the result of the AD query. The server with the copy of the hierarchy then determines which server or servers contain a replica of the public folder that the message is addressed to and passes it on to the appropriate public folder server containing the replica.
As the article explains, the query result will always be the most recently deployed public folder server for the routing group. This was consistent with the issue that I had – the server that I shut down was in fact the most recently commissioned public folder server, so it made sense why the messages were queuing up. Of course, I powered the server back on to allow the messages to deliver, and then began to look at how I should approach the situation.
Uninstalling Exchange would had been the easiest fix, but I still wanted to keep the server offline for a few days before uninstalling Exchange. The article mentions that you can modify the msExchOwningPFTree attribute on the public store object, and this is the solution that I decided to go with:
“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 article doesn’t explain how to atually edit the attribute so I thought I’d post the solution here so that others could refer to it. Note that after I cleared the attribute I wasn’t able to mount the store without putting the attribute back in place again. Also, you can avoid this scenario by mounting an empty public folder store on each front end server. The solution below however provides an easy way overcome a mail routing issue similar to the scenario that I had, particularly if you have already shut down the server and can’t bring it back up immediately.
If you want to temporarily prevent a particular public store from being used as the initial delivery point for messages destined for public folders in a routing group, you need to clear the msExchOwningPFTree attribute on the public folder store object using ADSI Edit:
- Launch mmc.exe
- Add the ADSI Edit snap-in to the console
- Right click on the ADSI Edit container and click on Connect to
- Choose the Select a well known Naming Context option and select Configuration from the drop-down list, then click on OK.
- Expand the Configuration container, then expand out each container as follows: CN=Services then CN=Microsoft Exchange then CN=YourExchangeOrg then CN=Administrative Groups then CN=AdminGroupofyourPFServer then CN=Servers then CN=YourPFServer then CN=InformationStore and then click on CN=StorageGroupContainingYourPFStore. In the pane on the right you see the public store object listed. Right click on the object and click on properties.
- In the list of attributes, double click on the msExchOwningPFTree attribute and then click on Clear and and then OK
.
Once I cleared the msExchOwningPFTree attribrute I shut the server down again. I sent some test messages and monitored the queues on the front-end servers. The messages were delivered to the public folders, and no messages queued on the front-end servers. When it came time to remove Exchange, I put the attribute back in place so that I could mount the public store, take a final backup and uninstall Exchange.
