Tuesday, 9 February 2010

Weird NDRs after migration to Exchange 2010

Recently we finished an E2007 migration to E2010.
No major issues, overall a smooth migration.
Users did not complain and did not report errors.
So we started to fear the worst, like everything was going to fall apart once we finished.
Well…It didn’t :)
But we got reports of a weird issue.

When some secretaries send out meeting requests they received an NDR like.

Your message could not be delivered to the following recipients:

The e-mailsystem of the recipient does not receive messages now. Try sending the message at a later time or try to contact the recipient directly.

Diagnostic data for administrators:

#550 4.3.2 Transport.Rules; message is deleted by mailbox rules ##


So initially we though; a user had a mailbox rule which deletes messages from specific users.
Embarrassing but not really an issue...
Well it turned out; the user did not have any rules on his mailbox. And more and more users started to complain about this issue.

After investigation I found that the NDRs were generated on the HUB server and it concerned only a few mailboxes. There were no transport rules defined on the HUB transport servers and no mailbox rules defined on the mailboxes.

We tried boosting the diagnostic logging on the HUB server but did not find anything useful.
So I started to look at the mailboxes.
I used MAPIMFC to open the mailbox and see what rules were defined on the inbox. I did find mailbox rules on the inbox although the user did not create mailbox rules.
As you can see in the picture below the name of the rule is “Schedule+ EMS interface”

If you open the PR_RULE_ACTIONS attribute you will see something like the listing below.

lpActions->ulVersion = 0x00000001 = EDK_RULES_VERSION
lpActions->cActions = 0x00000002
lpAction->acttype = 0x00000008 = OP_DELEGATE
lpRes was NULL
lpAction->ulFlags = 0x00000000 = (null)
lpAdrList->cEntries = 0x00000001
lpAdrList->aEntries[0x00000000].cValues = 0x0000000C
lpAdrList->aEntries[0x00000000].rgPropVals[0x00000000].ulPropTag = Tag: 0x0FFF0102
Property Name(s): PR_ENTRYID, PR_MEMBER_ENTRYID, PidTagEntryId, PidTagMemberEntryId, ptagEntryId
DASL: http://schemas.microsoft.com/mapi/proptag/0x0FFF0102
Property Name(s): PR_DISPLAY_NAME, PR_DISPLAY_NAME_A, ptagDisplayName
Other Names: PR_DISPLAY_NAME_W, PidTagDisplayName
DASL: http://schemas.microsoft.com/mapi/proptag/0x3001001E
lpAction->ulActionFlavor = 0x00000000 = (null)
lpAction->lpPropTagArray = NULL
lpAction->acttype = 0x0000000A = OP_DELETE
lpRes was NULL
lpAction->ulFlags = 0x00000000 = (null)
lpAction->ulActionFlavor = 0x00000000 = (null)
lpAction->lpPropTagArray = NULL

So we know now the rule was created by exchange and has to do with mailbox delegations.
When I opened a mailbox and checked the delegates at first I did not see anything out of the ordinary.

Delegate was added and the permissions were also set as default.
So everything seems OK, or not?
Well there is one difference with the defaults.
The default setting for request handling is:
“My delegates only, but send a copy of meeting requests and responses to (recommended)”
But here it is set to:
“My delegates only”
What does this mean?

Well when UserA has a delegate UserB, UserB normally has the calendar of UsersA in outlook (typically like a secretary).
So now UserA want to schedule an appointment and asks UserB to schedule a meeting.
UserB will create a meeting request for UserA and sets UserA as the owner of the meeting.
UserA is also in the recipientlist.
When UserB sends the meeting request, the exchange HUB transport server will process the message and he delegation mailbox rule which states “send meeting request and responses to my delegates and not to me”. So the exchange HUB transport deletes the message which was send to userA.

This seems like default behaviour only exchange 2010 sends an NDR. Which will cause confusion with the users. It looks like it's a bug in Exchange 2010.

To solve this issue just tick the “My delegates only, but send a copy of meeting requests and responses to (recommended)” setting in the delegates setting. Like the screenshot below.

There will still be a “Schedule+ EMS interface” mailbox rule on the mailbox; the only difference is that the OP_DELETE entry has disappeared from the rule.
Since we changed the setting we have not had any reports from users about these NDRs.