This is one of those ye olde issues that keep coming back up in Exchange. Have you every removed a mailbox, re-created it with the exact same SMTP address and then some people complain that they cannot send to the mailbox?
This can happen in a few circumstances. For example if the Exchange administrator has an “oops” and accidently deletes the account. If they do not use the AD DS recycle bin feature or an authoritative restore to bring back the original object they will run into this issue. This is because the new object does not have the same addressing information as the original.
But why you say! Did we not create it with the same SMTP address as the original. Oui mon cherie – you did, but that is not the issue.
Read on…..
Test Account Configuration
The below is the relevant field from on-premises AD. This is a remote mailbox where the user was migrated to Exchange Online. This scenario was chose to illustrate that it is not limited to on-premises.
We will send mail from user-1@tailspintoys.ca to another test account called kim@tailspintoys.ca - it is the latter which we will "accidentally" delete. Then after recreating the mailbox, we will examine the experience from user-1’s perspective.
The attribute we are interested in is called legacyExchangeDN
The below shows this in text format:
/o=TailspintoysCanada/ou=External (FYDIBOHF25SPDLT)/cn=Recipients/cn=Kim Akers60c
Note that the legacyExchangeDN ends in "60C" - we will come back to that later.
What The Butler Saw
The user account for Kim was "accidentally" removed – oops!
A new account is created with the same SMTP address and other fields. It does not matter if the UI or Exchange Management Shell was used. The below are PowerShell examples, and the same will happen for remote mailboxes or regular mailbox enabled users.
New-RemoteMailbox -Name 'Kim Akers' -OnPremisesOrganizationalUnit 'Tailspintoys.ca/Accounts' –UserPrincipalName kim@Tailspintoys.ca' -FirstName 'Kim' -LastName 'Akers' -Initials '' –Password $Cred.Password -ResetPasswordOnNextLogon $false
Once the mailbox was recreated, the legacyExchangeDN attribute can be checked. Note that they are now different, and the string is different, it now has "897" at the end:
/o=TailspintoysCanada/ou=External (FYDIBOHF25SPDLT)/cn=Recipients/cn=Kim Akers60c
/o=TailspintoysCanada/ou=External (FYDIBOHF25SPDLT)/cn=Recipients/cn=Kim Akers897
This is the reason why you are unable to reply to old messages. Exchange uses the legacyExchangeDN address rather than the SMTP which the Outlook client UI shows. Since the legacyExchangeDN value is now different, Exchange treats them as different recipients. The original address is no longer present and this explains the NDR.
While the attribute may be considered as "legacy" from an Active Directory perspective, it is certainly not for Exchange.
Resolution
The below article discusses how the old legacyExchangeDN can be calculated and added back to the mailbox as an additional X.500 proxy address. In addition to this you will find a multitude of scripts on the Internet that do the calculation for you.
IMCEAEX non-delivery report when you send email messages to an internal user in Office 365
This issue occurs because the value for the LegacyExchangeDN attribute changed. The auto-complete cache in Microsoft Outlook and in Microsoft Outlook Web App (OWA) uses the value of the LegacyExchangeDN attribute to route email messages internally. If the value changes, the delivery of email messages may fail with a 5.1.1 NDR. For example, the recipient address in the NDR resembles the following:
IMCEAEX-_O=MMS_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=User6ed4e168-addd-4b03-95f5-b9c9a421957358d@mgd.domain.com
As an aside, there have been some issues with Exchange over the years when the capability to reply to old emails had an issue. This was resolved with Exchange 2016 CU13 and Exchange 2019 CU2.
Bootnote
Why the extra three characters at the end of the LegacyExchangeDN you may ask. Was it always that way? But I have some users without those three random characters.
This was a change in Exchange 2010 SP1 RU6. Mailboxes created prior will NOT have the three random characters. The intent of adding the charcters was to reduce collisions in cross forest mailbox moves. Even if you have two Jane Does, the legacyExchangeDN will not conflict as long as one of them was created with the random characters.
Cheers,
Rhoderick
