Freigeben über

The Resolver

  • Artikel

While “The Resolver” would be a great nickname for a councillor, that’s not quite what we are talking about here. When processing inbound messages, Exchange Online (not EOP Stand Alone) will always resolve the recipient to the primary SMTP address before evaluating transport rules. Why does this matter? If you are writing transport rules that trigger based on the recipient, you must specify the primary address and not the secondary. If the secondary address is specified in a transport rule it will never trigger.

The exception here is if the user object and mailbox exist on-premises and you are not using DirSync. In this scenario, resolving will not take place in the cloud because Exchange Online will not be aware of the primary and secondary aliases for the user.

At a high level, here’s what inbound mail flow looks like and where resolving takes place.

Who does this impact?

If you have Exchange Online licenses, EOP will resolve all recipients of inbound mail to your environment to the primary SMTP address. Even if you do not have mailboxes in the cloud but are using DirSync, the resolving will still take place prior to rule processing.

Verifying Resolving is Taking Place

You can easily see resolving taking place when looking at an Exchange Online Message Trace. If a message has been received that is destined to a secondary address, you will see two entries in the Message Trace for this single message. The first entry will show that the recipient address has been resolved, and the second entry will show the processing for the message as it continued through EOP.

The following is a single incoming message that was destined to a secondary address which was resolved to the primary.

Troubleshooting

This section assumes you have a hybrid setup with Exchange Online Licenses, but with mailboxes stored on-premises in Exchange and DirSync is being used to sync user objects to the cloud. This is the type of scenario you may be in if you have just configured a hybrid environment.

For our on-premises users, all email aliases are stored in Active Directory so let’s begin our journey there. Find the ProxyAddresses AD attribute for a mail enabled user. You will see something like this.

The primary address is what you see beside the uppercase SMTP. All addresses beside lowercase smtp will be the secondary aliases.

Next, let’s see if the addresses have been properly synced to Exchange Online through DirSync. This can be done in one of two ways.

  1. In the Exchange Admin Center, browse to recipients. If the user has a cloud mailbox then click mailboxes, or if the user is still on-premises, then click contacts. Open the user object and select email addresses. Here you will see the primary and secondary addresses that Exchange Online is aware of.

  2. The email aliases can also be obtained using PowerShell. First you will need to connect to Azure AD. Once connected, use Get-MsolUser to query one of your users and look at the ProxyAddresses property.

    Here we can see all the aliases that Exchange Online is aware of. Another piece of interesting information you can obtain with Get-MsolUser is when the user object was last synced from on-premises. This property is called LastDirSyncTime.

    If the last sync time is not current, then the first place to check is your DirSync server on-premises.

Happy resolving and directory syncing!

Comments