This article is going to address how to deal with 1-off issues surrounding “Out of Facility” responses in Outlook. Over the years I have seen many strange cases surrounding OOF responses. However, generally speaking they fell into one of the following categories:
- A user compains that although he/she has composed and activated an OOF response within Outlook no OOF message is being sent.
- The wrong or duplicate OOF messages are being sent.
- An extremely old OOF response (invisible to the end user in Outlook) is being sent.
In my experience there have been lots of these sorts of issues and typically the “root cause” turns out to be minor corruption of the OOF message within the Outlook Inbox. “Usually”, these issues boil down to how and when the original OOF message was created (e.g. the Inbox Assistant, Rules Wizard, OWA, etc.), versions of Exchange Server that have or “may have” been in existance at a company (and hence how many times the mailbox itself has been moved between different versions of Exchange).
It is not the intention of this article to provide a “slash and burn” approach to dealing with these sorts of issues. I would not recommend you begin your troubleshooting here. In short, it is my expectation that you have done your dillegence and have arrived here as a “last resort” or sorts. I would like to emphasize that if you do not feel comfortable with any of the steps I have listed here or if you have further questions/concerns that you open an issue with Microsoft Product Support. The engineer who assists you will be able to provide you with a detailed analysis, action items, and summary for your specific issue. Perhaps you might even reach me.
A thorough discussion of MFCMAPI is well outside the scope of this entry. There is a tremendous amount of public information about MFCMAPI for consumption. However the short story is that MFCMAPI is a graphical MAPI editior (much like Outlook) that allows a user (with sufficent permissions) the ability to access and modify items within a mailbox or public folder. It is commonly used within Microsoft Product Support to facilitate investigations of “strange” issues between Exchange and Outlook. It does have a wide range of applications but most commonly it is used to perform one of the following operations:
- Delete Corrupted Mail or Public/System Folder Items that cannot be removed via conventional means (Outlook, OWA, etc.).
- To clear (or “cleanse”, as I like to say), the Exhcange Temp Tables on a given server.
- Inspection of Hidden Folders present within a mailbox or public folder.
- Troubleshooting Replication of Individaul Free Busy messages (this will be the subject of a future blog entry).
- Removal of a corrupt rule.
Today we will focus on removing a corrupt Inbox OOF rule, although the steps presented here would be just as applicable to other rules with minor exceptions with respect to the Message Class of the rule, where it might be located, et cetera.
A user contacts you (the administrator), because they are experiencing problems where an old OOF response if being sent out once the “Send Out of Office auto-replies” has been enabled within the Out of Office Assistant.
As an administrator you have done your dilligence and cannot locate this OOF response anywhere (in Rules and Alerts, within the OOF Assistant, et cetera). As such, you decide to further investigate with MFCMAPI.
1. Prior to performing any editing you will want to take a valid export of all rules configured within the user’s profile (Tools, Rules and Alerts, Options, Export Rules, give the export a name (file extension should be .rwz), and click OK. Verify the file has been created and that it is valid — to really test, you could important the rules into a dummy mailbox and verify they are valid.
2. It would also be helpful to have a copy of the incorrect OOF message being sent (with the OOF Assistant enabled for the impacted user, send a test message and verify that you receive the invalid response).
3. Turn off the OOF Assistant if it currently enabled then close Outlook.
4. You will need to have a valid MAPI profile to use MFCMAPI. So you can download MFCMAPI to the user’s desktop (where Outlook is installed), or create a new MAPI profile for the user.
5. Start MFCMAPI and from the “Session Menu” select “Logon and Display Stores”, and choose the proper Outlook profile.
6. Open the Mailbox of the profile that you want to inspect or “delete” the OOF rule for (this can be done either via a double-click on the mailbox or a right-click with a selection of “Open Store”.
7. This will bring you to the root of the user’s mailbox. At this point you will want to navigate down to the Inbox Folder (path PRE-Exchange 2007: Root-Mailbox – IPM-Subtree – Inbox, Exchange 2007 Path: Root Container – Top of Information Store –Inbox).
8. Right-Click the Inbox folder and select “Open Associated Contents Table”.
9. Once you are in the associated Contents Table, you will want to sort on the “Message Class” column. The valid classes for OOF messages are:
10. If you are performing these operations on a workstation that has Outlook installed, you can actually open the item by right-clicking and selecting “Open Message” or simply double-clicking.
11. Open all items of type IPM.Note.Rules.OofTemplate until you locate the OOF template that matches the invalid one (verified in Step-2).
12. Initially, try just deleting the matching OofTemplate and moving on. You can always come back and delete all messages at a later point if need be.
13. To delete, simply select the OofTemplate , right click the instance, and select “Delete Message”.
14. Close MFCMAPI properly by selecting Exit to each screen that has been presented. On the Final dialog, where the actual tree is located, select the Session menu then select “Logoff” (this will clear the windows). Then from the file Menu, select Exit.
15. Start Outlook with the proper user profile.
16. Synchronize the mailbox with Exchange (if the user were in cached mode for example) by pressing F9 or the Send/Receive button.
17. Create a new OOF message and turn on the Automatic Replies for the OOF Assistant (note: at this point you could actually close Outlook, then double check that the new OOF message was created properly by using MFCMAPI to verify there is a new OOF template).
18. Test sending mail to the user and verify that the new OOF response is delivered successfully
Hope you find this useful.