In an Exchange 2010 SP3 Hybrid deployment with Office 365, a client noted that they were unable to send email from their Office 365 mailbox to an on-premises mailboxes. The user in Office 365 received an undeliverable message stating that Delivery has failed to these recipients or groups and the email address wasn’t found at the destination domain. That was not the case as there certainly was a mailbox on-premises with that email address assigned to it, and it was quite happily sending and receiving email to lots of other people.
The undeliverable message will help us troubleshoot the issue.
Update 26-8-2015 – added the new enhanced NDR in addition to the older one.
This the new enhanced NDR:
And the older one, which has less detail.
The relevant sections were:
DSN 5.1.10 Errors in Exchange Online and Office 365
Remote Server returned 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup.
As far as the Office 365 tenant was concerned, the other mailbox did not exist. Why?
The World As The Tenant Sees It
Office 365 did not want to route the email to this mailbox. Was the domain for the mailbox present? The Tailspintoys.ca domain was correctly added and verified in the tenant. We can see this below:
And for the Exchange Online portion, how does Exchange see the Tailspintoys.ca domain?
That all looks good.
Since the domain type is set as Authoritative this means that Exchange believes it knows all of the recipients in the given domain. For more details on Authoritative and the other domain types please see TechNet.
Exchange Online is saying it has no knowledge about the on-premises mailbox.
What normally replicates the on-premises directory to Office 365? AAD Sync, or the previous DirSync tool.
This begs the question - How healthy was DirSync?
Directory Sync (Or Rather Lack Of)
In this case the customer had changed the password for the service account that was used to authenticate to Windows Azure Active Directory (WAAD). Since they never then updated the Directory Sync tool, no more updates were flowing between on-premises AD and WAAD. because of this Exchange Online had no idea that there was a newly created mailbox on-premises. After providing updated logon data, Directory Sync picked up where it left off, and once the changes had been pushed to Office 365 mail flow was working as expected.
In addition to changing the service account’s password, it is also possible to also run into the issue where AAD Sync does not automatically execute due to the option selected at installation time.
As a parting note, I am seeing multiple instances where AAD Sync or DirSync is installed and then never monitored. Directory Synchronisation is a critical part of your Office 365 solution, give it the love it deserves!
For additional issues related to Directory Synchronisation, review the Managing Directory Synchronization - Notes From The Field post.
Cheers,
Rhoderick
