Tracking down Public Folder hierarchy replication (Exchange 2010)

  • Article

It has come to my attention after dealing with multiple cases on the issue that tracking down Public Folder messages can be a pain. To help remove that pain, I am writing this in the hopes that it will be of some use to some of you in your daily Exchange-related activities!

To begin to understand hierarchy, we should firstly pay close attention to the Application Event log on the sending and receiving server. There are two events we want to pay close attention to on the sending server: 3017 and 3018. In a healthy scenario, we should be seeing plenty of both types of these events logged. However, there can be occasions where only 3017 events are being logged, with minimal or no 3018s present. Explanation of events below:

3017 - This is the outbound replication message (status). This event is logged on the computer that sends the status replication message.

3018 - This is the outbound replication message (hierarchy). This event is logged on the computer where the hierarchy change was made. This computer then sends the hierarchy change message to all the other public folder server computers that are in the same top level hierarchy (TLH).

So, if we are seeing multiple instances of 3017 being logged, but no 3018s present whatsoever, it indicates that status change messages are being exchange between the two (or more) Public Folder servers, but no hierarchy is being replicated. It means that the sending server isn't even attempting to send replication messages out, which would surely explain why we don't see any changes if, for example, we create a Public Folder on that server.

The usual culprit for the above mentioned issue lies within rules created by users within the Public Folders themselves. Sometimes these can become corrupt. If so, you're likely to see an event message logged on the server similar to the below:

*******************************************************************************
Log Name: Application
Source: MSExchangeIS Mailbox Store
Date: 2016-02-24 14:15:00
Event ID: 8533
Task Category: Move Mailbox
Level: Error
Keywords: Classic
User: N/A
Computer: dns.computer.name
Description:
A problem occurred while getting the properties for the automatic reply message from <NULL>.
Error code: -2147221233.
Try to clear the rules or run ISINTEG to check for any problem in the database "PFDBNAME".
************************************************************************************

This almost certainly points to corrupted rules being the culprit. Unfortunately, with the troubleshooting tools provided by Microsoft, there is no easy way for us to determine what the name of the Public Folder with the corrupt rules actually is. So we can address this one of two ways:

  1. Start removing rules from Public Folders one at a time. We can do this either with MFCMAPI or with an Outlook profile pointed towards the problematic Public Folder store. Eventually, you're going to remove the corrupted rule and things will be good. To narrow this down even further, the chances are Outlook will not be able to open the corrupt rules to view them in the first place. So if you get any Outlook generated messages when you attempt to view them in the first place, these are likely the ones you want to remove with MFCMAPI.
  2. Contact Microsoft Support. We'll be able to collect an ExTRA trace for you, and tell you precisely the name of the affected Public Folder.

This is the first part in a 3-part series I'm writing dealing with Public Folder replication, and naturally only covers one of the potential issues you may encounter. I will be expanding on this, and more, in my next article, so stay tuned!