解决Exchange 2007 SP1环境下向部分邮箱发送邮件提示未送达“#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##”问题

Because Exchange auto-complete cache uses X.500 addresses for e-mail sent to addresses within the Exchange organization, it will bounce back messages from a re-created mailbox even after you give the user account all the old SMTP addresses.
This is because the old X.500 address in the auto-complete cache is missing, and this causes Exchange to reject the messages. Ben Lye explains how to solve this common problem.
A little while ago I had a case where, after all other troubleshooting had failed, I had to solve a mailbox corruption problem by exporting the mailbox content to a PST file, removing the existing mailbox, recreating a new mailbox, then finally
importing the PST file back in. This solved the immediate problem of the corrupt mailbox, but created a new one – when Outlook users tried to e-mail the user either by replying to an existing message or by using Outlook’s auto-completion of the user’s e-mail
address, the message would bounce back to the sender. This happened even though I had re-added all the SMTP addresses that the user previously had. E-mail from external senders was being received properly, and replies to new messages were OK.
This problem occurs because while the Outlook auto-complete cache stores SMTP addresses for e-mail sent to external addresses, it uses X.500 addresses for e-mail sent to addresses within the Exchange organisation. Even though we had given the
user account all the old SMTP addresses, the old X.500 address which Outlook was sending to was missing, and this was causing Exchange to reject the messages.
The use of X.500 addresses goes back to before Exchange 2000, when previous versions of Exchange maintained their own LDAP directory. Since Exchange 2000 the mailbox’s X.500 address has been stored in the
legacyExchangeDN attribute in Active Directory. The legacyExchangeDN value is set when a mailbox is created, and includes the name of the Exchange administrative group where the mailbox belongs.
LegacyExchangeDN values typically look like this:
/o=Organisation/ou=Administrative Group/cn= Recipients/cn=Username
if you’ve ever wondered

why the Exchange 2007

admin group has the name

FYDIBOHF23SPDLT, it’s

the text EXCHANGE12ROCKS,

with all the characters shifted

to the right by one!)
Because the legacyExchangeDN value includes the administrative group name changes to admin group names will influence
legacyExchangeDN values. For example when you upgrade from Exchange 2003 to Exchange 2007 your user-defined admin groups are replaced by a single admin group named “Exchange Administrative Group (FYDIBOHF23SPDLT)” – existing mailboxes are
unaffected, but mailboxes created after the upgrade will use the new admin group name in their
legacyExchangeDN values. (Incidentally, if you’ve ever wondered why the Exchange 2007 admin group has this name, or what it means, it’s the text EXCHANGE12ROCKS, with all the characters shifted to the right by one!)
The current X.500 address of a mailbox can be retrieved from Active Directory using a tool such as ADSIEdit, or LDP.exe, or by using the Exchange Management Shell:
[PS] C:\>Get-Mailbox juser | fl LegacyExchangeDN

LegacyExchangeDN : /o=Example/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=juser

[PS] C:\>
The X.500 address of a message sender can be retrieved using a tool such as

Microsoft Exchange Server MAPI Editor to open a message and get the PR_SENDER_EMAIL ADDRESS property:

Alternatively, you can use a hex editor to open the Outlook auto-completion cache file and retrieve X.500 addresses from there. The cache is stored in a file in the user’s profile, typically ...

%userprofile%\AppData\Roaming\Microsoft\Outlook\[Outlook profile name].NK2

... on Windows Vista, or ...

%userprofile%\Application Data\Microsoft\Outlook\[Outlook profile name].NK2

... on Windows 2000, XP or 2003. There are also other tools available on the Internet which will allow viewing and editing of the content of the auto-completion cache file, but they may not expose the X.500 addresses.
Diagnostic information for administrators:

Generating server: demo01.example.com

IMCEAEX-_O=COMPANY_OU=USA_cn=Recipients_cn=juser@company.com

#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##
In my case, due to our upgrade to Exchange 2007, the user’s
legacyExchangeDN value had changed from this on the old mailbox (which had been created prior to the Exchange 2007 upgrade):
/o=Example/ou=USA/cn=Recipients/cn=juser
To this on the new mailbox:
/o=Example/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=juser
Any new e-mail sent from Outlook using the previously cached X.500 address was being rejected because the old X.500 address no longer existed in the organisation.
The solution to the problem is actually quite simple – add the old
legacyExchangeDN X.500 address to the new mailbox as a proxy address. You can add an X.500 proxy address through the Exchange Management Console, or the Exchange Management Shell.
To add the proxy address in the console, double-click the mailbox you need to add the proxy address to, go to the E-Mail Addresses property page, and add a new custom address:
To add the proxy address in the shell we use the Get-Mailbox and
Set-Mailbox cmdlets:
[PS] C:\>$ProxyAddresses = (Get-Mailbox juser).EmailAddresses
[PS] C:\>$ProxyAddresses += [Microsoft.Exchange.Data.CustomProxyAddress]("X500:/o=Example/ou=USA/cn=Recipients/cn=juser")
[PS] C:\>Set-Mailbox juser -EmailAddresses $ProxyAddresses
Breaking these commands down:
[PS] C:\>$ProxyAddresses = (Get-Mailbox juser).EmailAddresses
...retrieves the existing proxy addresses for the mailbox and stores them in the $ProxyAddresses variable.
[PS] C:\>$ProxyAddresses += [Microsoft.Exchange.Data.CustomProxyAddress]("X500:/o=Example/ou=USA/cn=Recipients/cn=juser")
...adds the new X.500 proxy address to the variable which contains the existing proxy addresses.
[PS] C:\>Set-Mailbox juser -EmailAddresses $ProxyAddresses
Updates the mailbox with the new set of proxy addresses
This technique can be used to solve this problem in a number of other scenarios where the
legacyExchangeDN attribute has changed, and is not limited to mailboxes. For example, if someone leaves the Exchange organisation and you want their e-mail to go to an external e-mail address you would create a contact record with the necessary
SMTP proxy addresses. If you also added the legacyExchangeDN of the old mailbox to the contact record as an X.500 proxy address Outlook users wouldn’t get bounced messages if they used the old entry in their auto-complete caches.