I can't create working Contacts in Exchange 2007 - they always bounce and the addresses on the DNR error 5.1.1 are pretty much mangled and are targeted to our domain instead of the external address, for example, here is the address from a DNR I got: e.g.=B57FD40C9308F7479BF159E9F227E5DD_cn=E5D7F3DC762455418BB3D96C1B7C13BC@domain.edu. The difference I see between the ones created in Exchange 2007 and our legacy 2003 Contacts are that there are entries in the SMTP, X.400 and the External E-mail Address fields on the Exchange 2007 created Contacts that all fail to route correctly. The Exchange 2003 created contacts have an External E-mail address only. I believe this difference is responsible for the bounces I am getting for all E2K7 contacts.I assume that I need to modify the legacy Default Recipient Policy and so I upgraded it to Exchange 2007.Now I amwondering how it should be configured. Currently, the 2 entries are SMTP, which is defined as @domain_name and the X.400, which I assume I still need until Exchange 2003 is gone.So, 2 questions:Am I right that the Default Recipient Policy is amiss? (If not, then what is wrong?)Whatdo I need to change?SnoBoy

Hi SnoBoy, It is normal that we have two SMTP address when creating a new Contact on Exchange 2007: user@externaldomain.com user@yourdomain.com Please understand the user@externaldomain.com should be the primary (external) email address. Whether the sender sends email to user@externaldomain.com or user@yourdomain.com. The message will be resolved to primary email address and delivered after categorizer process on hub transport server. Therefore, would you please let me know the entire NDR message or code you received? Please also let me know how the message is delivered to the contact (POP3/SMTP or Outlook(Exchange Mode), Send from external or internal and so on). Mike

Here is the full report with (obfuscated domain): Diagnostic information for administrators: Generating server:FQDN of cdomain IMCEAEX-_O=NT5_ou=B57FD40C9308F7479BF159E9F227E5DD_cn=377ECE0B4A7C8F4783EF39C4CE9ED02C@FQDN of cdomain#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ## Original message headers: Received: from mailbox server ([IP]) byCAS server with mapi; Wed, 7 Jan 2009 16:03:01 -0600Content-Type: application/ms-tnef; name="winmail.dat"Content-Transfer-Encoding: binaryFrom: my addressTo: Test Tester <IMCEAEX-_O=NT5_ou=B57FD40C9308F7479BF159E9F227E5DD_cn=377ECE0B4A7C8F4783EF39C4CE9ED02C@domain name>Date: Wed, 7 Jan 2009 16:03:00 -0600Subject: TestThread-Topic: TestThread-Index: AclxE7R8iBnYGxdzQ46okLzADqJDUw==Message-ID: <D1F27CE6E55190438E944C4AAE2AC01501A5A6D46D@email2>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach:X-MS-TNEF-Correlator: <D1F27CE6E55190438E944C4AAE2AC01501A5A6D46D@email2>MIME-Version: 1.0 The really strange thing is that I have 2 Contacts set up, exactly the same configuration as far as external address being the reply to (primary) address, the only difference is the external address and one works, one bounces. Message tracking tells me nothing because it gets far enough to log anything. Both external addresses are valid (both are my test GMAIL accounts).This is really frustrating when there i8s no visible difference and one works and one does not. Once the Monday morning craziness gets over, I will look at both COntacts with ADSIedit and see if they really are the same - sometimed the GUI lies as I have discovered in my years of Exchange admin work.If you think of something else to try, let me know.SnoBoy

Icompared a working Contact to a non-working contact and saw the the difference was the one having the legacyExchangeDN entry set to the Exchange 2003 first admin group worked and the one missing the information did not work. And of course, if I manually added it via ADSIedit, it starts working.But every new Contact I create is missing the legacy domain information - so how do I fix that? Running Update-EmailAddressPolicy did not fix broken Contacts - the legacyExchangeDN entry is still not set. Is there a change I need to make to the Default E-mail Address Policy so that the legacy information is there until I remove the last Exchange 2003 server?SnoBoy

Hi SnoBoy, For Exchange 2003 and 2007 co-existence environment, the Exchange 2003 RUS (Recipient Update Service) is responsible to update object attributes (such as legacyexchangedn, homemdb and so on) in a co-exist environment. Based on my research, the issue may occur if the purportedsearch attribute is not configured correctly of the Mail Enable Recipient system policy. The Recipient Update Service has three System Policies that are installed by default when you install Exchange 2003. They are Mail Enable Recipient, Mailbox Enable User and Hidden DL membership. All of them have the same purpose of update a few attributes on each entry under certain circumstances. Please understand if the recipient update service identifies than a new entry was added (or modified), and it does have the mailNickname to be considered mail-enabled. Therefore, by default, the purportedsearch attribute should be below: (|(&(objectCategory=person)(objectClass=user)(mailnickname=*)(targetAddress=*))(&(objectCategory=person)(objectClass=contact)(mailnickname=*)(targetAddress=*))(&(objectCategory=group)(mailnickname=*))(&(objectCategory=publicFolder)(mailnickname=*))) You can locate the"Mail Enable Recipient" object by using Adsiedit.msc tool: CN=Mail Enable Recipient, CN=System Policies, CN=ORG_NAME, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=DOMAIN_NAME,DC=com The user, contact and public folder object which have mailnickname and targetaddress (not for public folder) attributes. Mike

This fixes the issue with the typical contact. Thanks! That is a relief. This is not the first time that the purportedsearch Attribute has gotten munged requiring editing. It happened once before when there was no Exchange 2007 server in out site. This begs the question as to how it got messed up in the first place, but I am thankful to have it fixed.Here is a related issue:I am also working on mail-enabled folders on our SharePoint Sites with SMTP addresses of the form id@host.domain.eduadn with an STMP server running on the SharePoint server to allow incoming emails to go to the folder associated with the email address. According to one article,http://social.technet.microsoft.com/Forums/en-US/exchangesvrgeneral/thread/c4cf3b74-62a4-4228-abd4-5b2b28d69509/all contacts should have themAPIRecipient attribute set to FALSE. There are3 observations:1. External email address contacts created with either E2K3 or E2K7 do not have themAPIRecipient attribute set2. Contacts that go to our SharePoint server (address format is ID@host.domain)and created with E2K3 have themAPIRecipient attribute set to FALSE and send correctly3.Contacts that go to our SharePoint server (address format is ID@host.domain)and created with E2K7 have themAPIRecipient attribute not set and bouncewith the sameerror codeas the regular external contacts did without the legacyExchangeDN.Differences between the contacts include:E2K3E2K7not setcountryCode=0mAPIRecipient=FALSEnot setmsExchALObjectVersion=21not setnot setmsExchRecipientDisplayType=6not setmsExchVersion=4535486012416So the questions would be:Should themAPIRecipient attribute be set to FALSE on all contacts (I believe that since this stops email from being sent in Rich Text, the answer would be yes)?What controls that setting to force that on all contacts created?Do any of the other attribute differences rather than themAPIRecipient create the bounces that I am seeing with E2K7 created contacts that go to SharePoint?SnoBoy

Hi SnoBoy, As the new report issue you mentioned is different from the one discussed in this current thread, we'd recommend that you start up a new thread for it. We generally focus on one topic in one thread because in this way it will be better for other community members to participate in the discussion, and to search/find specific answers more efficiently in the future. Thanks for your understanding. Mike