Article by Pascal L’Huriec, Senior Premier Field Engineer.
I recently faced an issue with Out-of-Office (OOF) replies not working properly under Exchange 2007 SP3 with RU3 which was not easy to identify, and I thought it was interesting enough to share with you, along with the associated solution.

The Symptoms:

The OOF doesn’t trigger for all mailboxes located on a server. Only one server was impacted in a large organization, it was running Exchange 2007 SP3 with RU3 with CAS, Hub and Mailbox roles.

When we moved the impacted mailboxes to another server the OOF worked fine. However, when we moved the mailboxes back to the original impacted server, the OOF worked the first time, but as soon as the client turned-off their OOF, and later turned it on, the OOF stopped triggering.

In addition to that, when turning on or off the OOF from the Outlook 2010 or OWA client, the MAPI property PR_OOF_STATE did not toggle to True or False, as it should.

Troubleshooting Steps:

You can check the PR_OOF_STATE property using MFCMAPI (the Microsoft Exchange Server MAPI Editor) against a mailbox:

  • Start MFCMAPI.exe and click OK in the first dialog box that appears.
  • On the Session menu, click Logon and Display Store Table.
  • Select the profile for the mailbox.
  • In the list of stores for the profile, select the Mailbox - <mailbox name>.
  • In the Property pane, scroll down to the PR_OOF_STATE property.
  • PR_OOF_STATE showing True indicates the OOF is turn on, and False indicates the OOF is turned off.

You also need to increase diagnostic logging for the following categories and check the application event viewer:

  • MSExchangeMailboxAssistants\Service
  • MSExchangeMailboxAssistants\OOF Assistant
  • MSExchangeMailboxAssistants\OOF Library
  • MSExchangeIS\9000 Private\Rules

In my situation the following event was reported:

Source: MSExchangeIS Mailbox Store

Event ID: 1033

Task Category: Rules

Level: Warning

Keywords: Classic

User: N/A

Description:

The rule (MSFT:TDX OOF Rules) with sequence number 50 is being ignored because it is disabled.

So What’s Happening?

  1. After starting, the Mailbox Assistants service does several tasks: it queries which databases are online, and creates multiple assistant objects (including the OOF assistant) for each database.
  2. It will scan through the list of mailboxes to see how many mailboxes are in each database.
  3. It creates a session to each database and connects to all mailboxes, one by one. If the OOF is enabled for a mailbox, it will load the user’s OOF settings in a cache. This step MUST be completed before the Mailbox Assistants service can process events for the mailboxes, otherwise it fails. If the System Attendant fails to logon to one of the mailboxes, the Assistants service will not process any mailboxes on that server.
  4. Once steps 2 and 3 are completed, the Assistant objects are ready to start and attached to each database.
  5. After that, the OOF assistant can process the mailboxes, like updating the PR_OOF_STATE attribute when the user enables or disables OOF in Outlook or OWA. Hidden rules are created in the mailbox so that OOF can run.

How Did We Solve It?

We ran Test-MAPIConnectivity against all mailboxes on that impacted server, as follows:

Get-Mailbox –Server servername | Test-MapiConnectivity (with | fl and | more if you want)

The test was failing for one of the mailboxes. As this mailbox was not needed anymore, we deleted it.  Recycle the “Microsoft Exchange Mailbox Assistants” and all OOFs started working fine.

So in this case, a single logon failure on one mailbox caused all OOFs on the server not to trigger. Good reason to clean-up un-needed mailboxes!

Hope  you found this helpful!