This error can turn up in Exchange Server when Exchange Server is trying to resolve the object that it should deliver a message to. Exchange queries Active Directory and expect that if the object exists in the directory, that the object exists only once. If the object exists more than once, this is the error – as Exchange does not know who to deliver the email to.
The error is visible when running Get-Queue in Exchange Management Shell, and seeing that there are lots of emails in the Submission Queue. If you run Get-Message –Queue servername\Submission | FT Identity,FromAddress you can pick one to look at, and for that one run Get-Message server\submission\ID | FL where server\submission\ID is the Identity value from Get-Message cmdlet. Here you will see LastError and Recipients showing the ambiguous address error.
There are a number of articles on the internet covering this issue, but I came across a unique one today.
The easy way to search for the issue is to find the address that is in duplicate. This will be listed in Event Viewer under MSExchangeTransport as the source and Event ID 9217. The Task Category will be Categorizer, as the job of working out who is going to get the message is the role of the Categorizer.
An example of this error is shown.
So the fix. Often suggested is to do a custom AD query for “proxyaddress=smtp:name@domain.com” where name@domain.com is the email address shown in the event log error. If this returns two or more recipients, and this will be across all the domains in the forest, then you need to decide which is the primary one and carefully delete the rest.
By carefully I mean that you want to leave either one contact, or one mail user or one mailbox etc. If the duplicate is two contacts, then find the one with the most correct information on it and carefully delete the other. If you find two mailboxes, work out which the user is actually logging into and has email in it – and carefully delete the other etc.
And by carefully, here I also mean that on the object you are going to delete, copy the legacyExchangeDN value and then delete the object. Then find the real correct object and add a new x500 email address to the proxyAddresses attribute of the correct user. The value of the x500 address will be the legacyExchangeDN that you copied from the deleted contact.
This will ensure that users who have previously emailed the now deleted contact before, will still be able to email the remaining object.
But what is unique about that? At the customer I am working on at the moment the issue was that doing the proxyaddresses=smtp:name@domain.com search only returned one object across the entire forest – what is duplicate about that? Well in my case, the user had user@domain.com added to their proxyaddresses twice – they were the duplicate object to themselves.
Opening this user via the search results as shown above, and with Advanced Features enabled from the View menu, you can see the Object tab:
Opening the object value directly, redacted in the picture above, I can change to the Attribute Editor tab and open proxyAddresses attribute. Here i saw the following:
name@domain.com
name@mail.domain.com (used as a target for forwarding emails from another system)
smtp:name@old-company.com
SMTP:name@domain.com
x500:legacyExchangeDN from Exchange 2007 migration
Note that the name@domain.com value, the one in error in the logs, appears twice but not starting SMTP (primary address) or smtp (secondary address) but without an address protocol at all!
Querying the user in Exchange Administration Console returned:
And also then opening the user in Exchange Management Console showed that the address without the smtp: value was shown with it.
Remove one of the two addresses and within ten minutes the emails queued to this user in the submission queue will be delivered. Restarting the transport service will also kick start the submission queue as you cannot use Retry-Queue against this queue.
Leave a Reply