Sleezed
asked on
Exchange NDR X500 issue
Background: I have a customer which we migrated to Exchange 2013 SP1 from Exchange 2007 a while ago. The migration was done in a PST transfer manner with the import/export-pst cmdlets. The Exchange is running on a Win Server 2012 R2 VM on VMware ESX 5.5. Users use Outlook 2007 internally, as well as OWA and ActiveSync mobile externally. Let's call the domain contoso.com for security purposes.
Issue: Joe Doe is intermittently receiving NDR messages when sending/replying to internal emails to Maria Smith. Please note that Maria Smith was originally Maria White. The surname change happened BEFORE the migration, but this issue began AFTER the migration. The NDR is the following:
What we did so far:
NB. I tried sending an email directly to that X500 address internally from Outlook to test, but it sees it as an invalid address...not sure if its normal behavior or because the structure of the address is wrong...
I've read countless blogs and posts of people with exactly the same issue...and they solve it immediately with the X500 alias method...it isn't working for me and it's driving me nuts. Any ideas?
Issue: Joe Doe is intermittently receiving NDR messages when sending/replying to internal emails to Maria Smith. Please note that Maria Smith was originally Maria White. The surname change happened BEFORE the migration, but this issue began AFTER the migration. The NDR is the following:
Diagnostic information for administrators:
Generating server: EX.contoso.local
IMCEAEX-_O=CONTOSO_OU=First+20admini strative+2 0group_cn= Recipients _cn=maria+ 2Ewhite@co ntoso.com
Remote Server returned '550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found'
Original message headers:
Received: from EX.contoso.local (192.168.0.150) by EX.contoso.local
(192.168.0.150) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 10 Dec
2014 16:33:14 +0100
Received: from EX.contoso.local ([::1]) by EX.contoso.local ([::1]) with
mapi id 15.00.0847.030; Wed, 10 Dec 2014 16:33:14 +0100
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding:binary
What we did so far:
Cleared auto-complete cache in Outlook
Added the IMCEAEX address shown in the NDR as an X500 address alias in Maria Smith's mailbox. The resultant X500 address we used is:
/O=CONTOSO/OU=First administrative group/cn=Recipients/cn=mar
/O=CONTOSO/OU=First administrative group/cn=Recipients/cn=mar
Removed the .NK2 cache file from the Outlook profile
Checked Maria's LegacyExchangeDN attribute in the current AD object...its a jumble of numbers and characters...but I found some people online which said that I can ignore this.
NB. I tried sending an email directly to that X500 address internally from Outlook to test, but it sees it as an invalid address...not sure if its normal behavior or because the structure of the address is wrong...
I've read countless blogs and posts of people with exactly the same issue...and they solve it immediately with the X500 alias method...it isn't working for me and it's driving me nuts. Any ideas?
Is the address book properly updating? You can run update-offline address book from the ems and then in outlook go to send and receive and select send and receive group download addressbook. Uncheck download changes since last send and receive this should download the whole address book
ASKER
Yes it's updating no problem...checked it from the user's Outlook personally
Get-OfflineAddressBookUpdate-OfflineAddressBook -Identity "Default Offline Address Book"ASKER
What will I gain by updating the OAB again? As mentioned I already did this and checked from the email client and it was updated successfully.
I had the same issue when updating from 2010 to 2013 and pulled my hair out with this issue. It was only resolved by updating the oab on the server. Hope that helps you.
Seems you are missing the @contoso.com part. That is what the server is looking for.
ASKER
I read in several locations that the @contoso.com part needs to be removed. In fact, I had originally done it with @contoso.com, but it still didn't work.
I know all the blogs mention differently, but if you look at the problem that is what server needs. I assume I should settle with this and the test was unsuccessful.
Can you post/send me get-mailbox | fl for the user?
Can you post/send me get-mailbox | fl for the user?
ASKER
What are the attributes that you need exactly? The LegacyExchangeDN? It's this, but keep in mind this is the CURRENT legacyexchangeDN:
LegacyExchangeDN : /o=CONTOSO/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recip
LegacyExchangeDN : /o=CONTOSO/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recip
Hello,
Yeah, I agree it is weird, but it looks for the old legacyExchangeDN and not the new one.
I am wondering if the name change also has something to do.
To test add x500 with the old name and also test with @contoso.com.
Btw, did you add X500: at the beginning of the address?
Yeah, I agree it is weird, but it looks for the old legacyExchangeDN and not the new one.
I am wondering if the name change also has something to do.
To test add x500 with the old name and also test with @contoso.com.
Btw, did you add X500: at the beginning of the address?
ASKER
I added four X500 alias variations till now:
I added the last 2 today, and the issue is intermittent so I can't say for sure if they made any difference. I had added the second one two weeks back on its own, and it hadn't made a difference.
Unfortunately the old server has been decommissioned. I might be able to find a way to get hold of the old legacyExchangeDN attribute...but it will be a nightmare. Having said that, shouldn't the one listed in the NDR suffice?
Type:X.500 Value:/O=CONTOSO/OU=First administrative group/cn=Recipients/cn=mar
Type:X500 Value:/O=CONTOSO/OU=First administrative group/cn=Recipients/cn=mar
Type:X.500 Value:X500:/O=CONTOSO/OU=First administrative group/cn=Recipients/cn=mar
Type:X500 Value:/O=CONTOSO/OU=First administrative group/cn=Recipients/cn=mar
I added the last 2 today, and the issue is intermittent so I can't say for sure if they made any difference. I had added the second one two weeks back on its own, and it hadn't made a difference.
Unfortunately the old server has been decommissioned. I might be able to find a way to get hold of the old legacyExchangeDN attribute...but it will be a nightmare. Having said that, shouldn't the one listed in the NDR suffice?
The fourth value in the list should be sufficient. If the senders still receive delivery failure then its possible that their cache had a different legacy email address and you must collect the address from NDR and add it.
ASKER
I may have narrowed it down a bit. Even though I'm adding proxy addresses and they are appearing in the user properties in the GAL/OAB, the X500 address doesn't actually resolve when I try sending an email to it (To > Check Names doesn't work), from both Outlook and OWA.
ASKER
Update: Only one of the proxy addresses I added resolves successfully, and the emails go through:
X500:/O=CONTOSO/OU=First administrative group/cn=Recipients/cn=mar
The rest do not resolve with Check Names in either Outlook or OWA.
X500:/O=CONTOSO/OU=First administrative group/cn=Recipients/cn=mar
The rest do not resolve with Check Names in either Outlook or OWA.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.