Exchange OOF Ghost Rule

The Mysterious OOF Ghost

A strange issue that can easily be filed as a “Ghost in the machine” surfaced with a user in Exchange not too long ago. The peculiarity of the problem was unique in nature because without digging deep into the user’s Exchange account, we may have not found the problem and would have settled for a Band-Aid fix (either that or settle for having to recreate the account in Exchange). So, what is this problem? 

First, let me clarify a quick term that not everyone is familiar with: OOF. It is an acronym used for “Out Of Facility” or better known today as “Out Of Office”. Here’s a link describing this better: http://blogs.technet.com/b/exchange/archive/2004/07/12/180899.aspx

Ok, now back to the mysterious issue…

UserA sets up their Out Of Office reply in Outlook. When someone emails UserA, their OOF notification goes to work and replies to the sender with the OOF message already configured as it should. Here’s where the fun begins… UserA then receives an NDR (Non-Delivery Receipt) email for every OOF notification that gets sent out. Upon looking at the NDR, it appears that Exchange is attempting to forward the email to an address that does not exist within the environment (UserB) while also taking care of the OOF notification to the original sender.

Well, immediately – this sounds like some sort of rule is possibly configured at the client that is causing this mayhem. However, when troubleshooting the client, no rules were found with this configuration. Using PowerShell on the Exchange Management Console pointing to UserA’s mailbox didn’t yield any results either. The ‘Band-Aid’ here was to create a new rule that would immediately delete the NDR when received… but this was not a resolution, only a ‘Band-Aid’. This required much more in-depth troubleshooting.

Deep-Dive Analysis:

This is where my colleague and I began analyzing using MFCMAPI (http://mfcmapi.codeplex.com) to further investigate our Exchange 2013 environment. Now for those who are unfamiliar with MFCMAPI, it “provides access to MAPI stores to facilitate investigation of Exchange and Outlook issues.” (Sounds like the right tool to use in this instance to me!)

After giving our Exchange Administrator account full delegation rights of UserA, we opened up MFCMAPI and pointed it to that mailbox. From there, we right clicked on “Inbox” and selected the “Open associated contents table” option.

On the new window, sort the columns by “Message Class” and look for any “IPM.Rule.Vers…” In our example, UserA shows to have 2 rules on their Exchange account. One is visible in Outlook (our ‘Band-Aid’ rule deleting the NDRs), but notice that here in Exchange using MFCMAPI we can see a SECOND rule!

So, clicking on the Message Class (rule on the top pane will reveal some very critical information regarding this anomaly. There are two things of interest that we will be looking for (again, keep in mind that when troubleshooting this type of issue a user can have multiple rules in Exchange! This is why the following part of the analysis is crucial… to select the RIGHT rule!)

The first piece of the puzzle on this example is the Property Name:  “PR_RULE_MSG_PROVIDER…”

Notice that the property has a value of:  “MSFT:TDX OOF Rules”. Remember the acronym OOF from earlier? Looks like we’re on track! Now on to the next Property Name:  “PR_RULE_MSG_STATE…” Notice, this time, the Smart View column: “Flags: ST_ENABLED | ST_ONLY_WHEN_OOF”. Thinking analytically, this particular view identifies the action of the rule: “only when OOF”.

Let’s go a little further to make sure we’re looking at the right rule. Double click on the Property Name: “PR_RULE_MSG_STATE…” On the new window, look for the following Property Name: “PR_EXTENDED_RULE_MSG_CONDITION…” and double click the property.

Here it is! On the middle pane is where we found UserB’s name next to SMTP. This confirms the ghost rule! To be safe, we exported the rule before deleting it. After removing, as expected, the issue went away!

Conclusion:

In this example, we were able to find the Ghost rule in Exchange using MFCMAPI. Again, please keep in mind that these type of issues may not be common in every environment. Use these steps for troubleshooting with caution! Also ensure that you have the correct rule before making any modifications. As always – BACKUP, BACKUP, BACKUP!! You can export the rule in question prior to deletion. If this does not solve the problem, you can import the rule back. Hope this helps anyone else experiencing “ghosts” in Exchange!