{"id":726,"date":"2020-05-27T10:40:09","date_gmt":"2020-05-27T15:40:09","guid":{"rendered":"https:\/\/itblog.ldlnet.net\/?p=726"},"modified":"2020-05-27T10:42:19","modified_gmt":"2020-05-27T15:42:19","slug":"troubleshooting-oof-ooo-out-of-office-replies-in-exchange-and-exchange-online","status":"publish","type":"post","link":"https:\/\/itblog.ldlnet.net\/index.php\/2020\/05\/27\/troubleshooting-oof-ooo-out-of-office-replies-in-exchange-and-exchange-online\/","title":{"rendered":"Troubleshooting OOF\/OOO (Out of Office) Replies in Exchange and Exchange Online"},"content":{"rendered":"\n

Since the COVID-19 virus has managed to get me laid-off and not working, I have not had too much to post in the past months. And although it has wavered greatly, I will remain positive and hope that someone will see the value that I can bring to their organization in the near future.<\/p>\n\n\n\n

With that said, I wanted to repost this article that was sent to me as this issue arises quite often in the workplace when someone has left for vacation and is not in the office. So, here it is:<\/p>\n\n\n\n

Understanding and troubleshooting Out of Office (OOF) replies<\/a><\/h2>\n\n\n\n

Out of Office replies can sometimes be a bit of a mystery to people; how do they work? What do you do if they don\u2019t work? In this blog post, we will discuss the bits and pieces of Out of Office and some of the main reasons why an Out of Office (aka. OOF) reply might not get delivered to users. Note that while we are writing this from the viewpoint of an Exchange Online configuration, many of same things can be applied to on-premises configuration also. By the way \u2013 did you ever wonder why \u201cOOF\u201d is used instead of \u201cOOO\u201d? If you did, see this<\/a>!<\/p>\n\n\n\n

What is an Out of Office reply?<\/h3>\n\n\n\n

Out of Office replies are also known as OOF (or OOO) replies or automatic replies. They are Inbox rules that are set in the user\u2019s mailbox by the client. OOF rules are server-side rules, so the response is sent regardless of whether a client is running, or not.<\/p>\n\n\n\n

There are several ways of setting up automatic replies:<\/p>\n\n\n\n

First, it can be set up as an automatic reply feature from Outlook, like this<\/a>. It can also be configured using other clients, such as Outlook on the web (OWA), PowerShell command (Set-MailboxAutoReplyConfiguration<\/a>). Admins can set up OOF replies on behalf of (forgetful) users from the M365 Admin Portal.<\/p>\n\n\n\n

Other than using built-in OOF functionality, another thing people sometimes do is use rules to create an Out of Office message<\/a> while they are away.<\/p>\n\n\n\n

By design, Exchange Online Protection uses the high risk delivery pool<\/a> (HRDP) to send the out of office replies, because they are lower priority messages.<\/p>\n\n\n\n

Types of OOF rules<\/h3>\n\n\n\n

There are three types of OOF rules: Internal, External and Known Senders (Contact list). They are stored in the mailbox with the names in the following table. If a mailbox has set only Internal OOF, there will be no external rule created and the mailbox will have one OOF rule.<\/p>\n\n\n\n

Type<\/td>Message Class<\/td>PR_RULE_MSG_NAME<\/td><\/tr>
Internal<\/td>IPM.Rule.Version2.Message<\/td>Microsoft.Exchange.OOF.KnownExternalSenders.Global<\/td><\/tr>
External<\/td>IPM.Rule.Version2.Message<\/td>Microsoft.Exchange.OOF.AllExternalSenders.Global<\/td><\/tr>
Known External<\/td>IPM.ExtendedRule.Message<\/td>Microsoft.Exchange.OOF.KnownExternalSenders.Global<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Note: <\/strong>Apart from OOF rule, other rules like the Junk Email rule will also have the \u201cIPM.ExtendedRule.Message\u201d  message class; the MSG_NAME will determine what the rule is for.<\/p>\n\n\n\n

OOF rule details<\/h3>\n\n\n\n

All Inbox rules can be viewed using MFCMapi<\/a> tool:<\/p>\n\n\n\n

Logon > profile that you are accessing > Top of information store > Inbox > right click \u2018Open associated contents table\u2019. They are listed under the Message Class column. All Inbox rules will have the same message class IPM.Rule.Version2.Message and there is one message class and name for each Inbox rule.<\/p>\n\n\n\n

For all rules, the name of the rule is in stored in the PR_RULE_MSG_NAME property. So, if there are 4 Inbox rules, there will be 4 IPM.Rule.Version2.Message one for each rule, and the name of the rule is stored in PR_RULE_MSG_NAME.<\/p>\n\n\n\n

OOF rules in MFCMapi:<\/p>\n\n\n\n

\"OOF01.jpg\"<\/figure>\n\n\n\n

And OOF rule templates in MFCMapi:<\/p>\n\n\n\n

\"OOF02.jpg\"<\/figure>\n\n\n\n

History of OOF replies<\/h3>\n\n\n\n

OOF response is sent once per recipient. Recipients to whom the OOF was sent are stored in the OOF history and are cleared out when the OOF state changes (enabled\/disabled) or the OOF rule is modified. OOF history is stored in the user\u2019s mailbox and can be seen using MFCMapi tool at: Freebusy Data > PR_DELEGATED_BY_RULE.<\/p>\n\n\n\n

\"OOF03.jpg\"<\/figure>\n\n\n\n

Note: <\/strong>If you want to send response to the sender every time instead of just once, you can apply mailbox server side rule “have server reply using a specific message” to send automatic reply instead of using the OOF rule. This server-side rule will send reply to the sender every time a message is received.<\/p>\n\n\n\n

Now that we know what OOF replies are and how they are stored on the server, we can move on to address some of the scenarios where OOF is not sent to the sender. We will also discuss possible fixes and some more frequently seen issues you may have with OOF configuration.<\/p>\n\n\n\n

The first category of issues we will talk about are issues related to OOF replies not being received by the sender of the original message.<\/p>\n\n\n\n

OOF issues related to transport rules<\/h4>\n\n\n\n

When OOF doesn\u2019t seem to be sent for all<\/strong> users in the tenant, usually there is a transport rule causing the issue. Check all the transport rules that may apply to the affected mailbox using step two of this<\/a> article.<\/p>\n\n\n\n

If you suspect a delivery problem, run a message trace<\/a> from the Office 365 tenant.  We know that OOF response is sent back to the original sender of the message, so for OOF messages, the sender of the original message becomes the recipient when tracking. We should then be able to tell if OOF reply has been triggered and sent to external or internal recipient. If a Transport rule is blocking the OOF response, the message trace will clearly show you that.<\/p>\n\n\n\n

There is one scenario I would like to highlight when it comes to transport rules blocking OOF replies. Let’s assume that you moved the MX record to a 3rd<\/sup> party anti-spam solution; you have created a transport rule to reject any email coming from any other IP address than the 3rd<\/sup> party anti-spam.<\/p>\n\n\n\n

The transport rule will look something like this:<\/p>\n\n\n\n

Description:
If the message: Is received from ‘Outside the organization’ Take the following actions: reject the message and include the explanation ‘You are not permitted to bypass the MX record!’ with the status code: ‘5.7.1’ Except if the message: sender ip addresses belong to one of these ranges: \u20181xx.1xx.7x.3x\u2019

ManuallyModified: False

SenderAddressLocation: Envelope<\/p>\n\n\n\n

As OOF replies have a blank (<>) Return-Path, you will see that the rule is unexpectedly matching the transport rule and the OOF responses are getting blocked.<\/p>\n\n\n\n

In order to fix this, you can change the transport rule property of ‘Match sender address in message’ to ‘Header or envelope’, so the checks will also be done against \u2018From\u2019 (also known as the \u2018Header From\u2019 address), \u2018Sender\u2019 or \u2018reply-to\u2019 fields. More information about the mail flow rule conditions is here<\/a>.<\/p>\n\n\n\n

\"OOF04.jpg\"<\/figure>\n\n\n\n

JournalingReportNdrTo mailbox setting<\/h4>\n\n\n\n

If the affected mailbox is the one which is configured under JournalingReportNdrTo, OOF replies will not be sent for that mailbox. Moreover, journaling emails may be affected as well. It is recommended to create a dedicated mailbox for the JournalingReportNdrTo setting. Alternatively, you can set it to an external address.<\/p>\n\n\n\n

For more details on how to solve this, please see this KB Article<\/a>.<\/p>\n\n\n\n

Forwarding SMTP address is enabled on the mailbox<\/h4>\n\n\n\n

If the affected user mailbox has SMTP forwarding<\/a> enabled, OOF replies won\u2019t be generated. This can be checked in user mailbox settings (OWA):<\/p>\n\n\n\n

\"OOF05.jpg\"<\/figure>\n\n\n\n

In PowerShell:<\/p>\n\n\n

Get-Mailbox -Identity Daniel | fl DeliverToMailboxAndForward, ForwardingSmtpAddress, ForwardingAddress<\/pre>\n\n\n\n
\"OOF06.jpg\"<\/figure>\n\n\n\n
Or, in the M365 Portal, user properties:<\/p>\n\n\n\n
\"OOF07.jpg\"<\/figure>\n\n\n\n
Please follow the action on step one of this<\/a> article for more information.<\/p>\n\n\n\n
The type of the OOF reply set on remote domains<\/h4>\n\n\n\n
Remote<\/a> domains offer you (among other settings) the opportunity to set the type of OOF reply that can be sent to users.<\/p>\n\n\n\n
These types are the following:<\/p>\n\n\n\n