A Note on Defer and Fail Event IDs in Exchange 2010 Message Tracking Logs

 

So you may have seen DEFER or FAIL eventids in your tracking logs and wondered why they are there.

If we look on our documentation on TechNet here we see-

Event name

Description

DEFER

Message delivery was delayed.

FAIL

Message delivery failed.

Pretty self-explanatory, right?

Now sometimes you may see these eventids even though a message was not deferred/delayed or failed delivery.

Well there is another reason that would cause these events logged.

The first event id we will talk about is the DEFER.

When we run Get-MessageTrackingLog we see a DEFER eventid with a source of AGENT below.

clip_image002

Expanded below we see the SourceContext is Transport Rule Agent

clip_image004

So let’s go look at our transport rules-

clip_image005

Here we see we have a transport rule that adds a recipient to the TO: field.

Now when we have a transport rule that adds or removes a recipient from a message header we will log a DEFER eventid in message tracking logs. This is known as a “zero defer” since the message is not really deferred but just pushed back to the submission stage of categorization so we can re-resolve the new recipient. In other words the event is more “cosmetic” since there is no delay we just need to re-categorize the message in the transport pipeline with the new recipient added/removed.

As we can see below the message was not deferred at all-

 image

 

Now what about FAIL eventid?

image

As we can see in the above message tracking log we log a FAIL eventid from SourceContext Transport Rule Agent. So let’s go back to our rules and see what they are doing-

image

Here we have a redirect rule. Now as opposed to adding/removing recipients a redirect rule silently drops the original recipient and redirects a message to the added recipient. This will cause us to log a FAIL eventid since we actually failed in delivering to the original recipient (due to redirection) and a DEFER since we are adding a new recipient and putting the message back to the submission portion of the transport pipeline.

 

image

As we can see the message was successfully delivered.

Hope this helped clear up some confusion on these two eventids.

Until next time.