My client is in the process of being divested from a parent company, and users have already been migrated to a new AD forest and Exchange org. On the parent company, they want autoreplies for the divested users (easy enough), but they want them to always fire for every received message.
In Exchange 2010 and the OWA GUI, it states that the OOO/autoreply will be sent once for each sender. This is not configurable, AFAICT. Management wants the configured autoreply to fire every time. Is this something that I can force?
Alternatively, I considered creating a simple inbox rule to fire on every message that is received after "x" date (today), with the action to have the server reply with an appropriate message. However, this rule is only visible/configurable in Outlook, not OWA.
Thus I can't have my users (already migrated, thus Outlook is using the new domain) set this in Outlook in the old domain - not without walking them through trying to make new profiles manually connected to the old Exchange org. No thanks.
Also, the New-InboxRule cmdlet does not appear to be able to configure the "reply" action, unless I'm missing something, so I can't do this in a PowerShell script.
Any ideas on other ways to solve this problem? A custom bounce Transport rule looks likely to be ignored by senders - since the custom message is buried in the 5.7.1 error code, and it does not resemble normal OOO messages.
/ Bah humbug. Just found this one. Unless things have changed, I'm likely out of luck. Exchange out of office, sending an OoO reply for every email
I work in a ~300 person subsidiary of a 20x larger parent company, and we have mail contacts in the parent exchange org configured with a forwarding rule. Since your divestiture is a one-time occurrence, there would not need to be further upkeep with regard to mail contact maintenance if you did something similar.
OOO handling is a single reply for a number of reasons, mostly how easy it would be to cause a forwarding loop if it wasn't a one-time rule.
Given that you're setting up a new Exchange domain (presumably with a new .com domain for email), perhaps you could make a transport rule that returns a message to sender in addition to forwarding in the scenario I described above. Mail Delivery Options work a little differently from a transport rule, so I'm not sure this approach is feasible.
RFC 3463 seems to be designed to be helpful in your case, a status code of 5.1.2 would apply directly (Permanent Failure: Mailbox has moved). Unfortunately you will probably never be able to rely on outside partners parsing that correctly.