Article ID: 318774 - View products that this article applies to.
This article was previously published under Q318774
This article is a consolidation of the following previously available articles: 318774, 329617
If you are an administrator, you can use Microsoft Exchange recipient policies to automatically configure and customize e-mail addresses for all Exchange recipients by using address generation rules. The Recipient Update Service applies addresses in bulk to new and existing users according to the specified rules. To configure these rules, use Exchange System Manager to access the properties of recipient policy objects.
However, in some situations, you may use a rule that causes duplicate or that causes multiple addresses to be applied across the Exchange organization. When duplicate e-mail addresses are detected during an ordinary Exchange operation, non-delivery reports (NDRs) with a 5.1.4 error code may be sent by the server, and you may experience other unexpected behavior. Additionally, the following event ID message may be logged in the Application Event log:
This article describes a situation where duplicate addresses are applied and how to remove these duplicate addresses.
The following rule is a typical rule for an SMTP (Internet) mail format address:
@domain.comWhen you use this rule, an e-mail address is added to each recipient object that is covered by the recipient policy of firstname.lastname@example.org. Therefore, if a user's Exchange e-mail alias is user1, the address email@example.com is applied to the user.
You can also use Exchange to define auto-naming rules. For example, you may want the Internet e-mail address for recipients to be configured as "FirstName_LastName@domain.com" instead of "firstname.lastname@example.org." You can use the following address generation rule to make this change:
%email@example.comFor additional information about available auto-naming specifiers and syntax, click the following article number to view the article in the Microsoft Knowledge Base:
285136If you are using auto-naming specifiers, you must make sure that the fields that you reference in the address generation rule actually exist for each of the recipients that are covered by the rule. If you do not do so, you may cause duplicate or multiple e-mail addresses to be generated on objects throughout the Exchange organization.
(http://support.microsoft.com/kb/285136/ )How to Customize the SMTP e-mail Address generators through recipient policies
The effects of this problem vary depending on what recipients are involved. Several Exchange system objects are mailbox-enabled. If the wrong address is applied to these system objects, problems may occur. For example, public folder replication may be unsuccessful or databases may not be able to mount. Additionally, the event ID message that is described in the "Summary" section of this article may be logged.
As an example of this behavior, suppose that you have defined the %firstname.lastname@example.org address generation rule. This rule takes the values for the givenName attribute and the sn attribute of an Active Directory object and uses these values to construct an e-mail address. If a user's givenName attribute value is Jeff and the sn attribute value is Smith, the e-mail address is Jeff_Smith@domain.com.
But the givenName attribute and the sn attribute are not mandatory, and mail-enabled objects such as distribution lists and system agents may lack these attributes. In this situation, the %email@example.com address generation rule devolves to the firstname.lastname@example.org address generation rule. For objects that do not have the givenName and the sn attribute value, the rule becomes the equivalent of a rule to hardcode the e-mail address as email@example.com.
When you apply new e-mail addresses, the Recipient Update Service checks to see if the same address already exists on any object in the forest. If it does, a numeric value is added to the new address to differentiate it. For example, if there are multiple users named Jeff Smith, an additional user account that is processed by the Recipient Update Service may receive an e-mail address of Jeff_Smith2@domain.com.
This means that objects without the givenName and the sn attribute values who are processed according to the %firstname.lastname@example.org address generation rule will receive e-mail addresses such as email@example.com, firstname.lastname@example.org, email@example.com, and other similar addresses.
Every time that the Recipient Update Service checks for new recipients who must have e-mail addresses, objects without the givenName and the sn attributes may receive an additional e-mail address. Consider an object that has the firstname.lastname@example.org address. This address does not match the email@example.com rule, and the Recipient Update Service may assume that the object still must have the "hardcoded" firstname.lastname@example.org address applied. Duplicate address checking finds that email@example.com address already belongs to a different object, and therefore, an address such as firstname.lastname@example.org may be assigned.
If none of the attributes of an object have been modified in Active Directory since the last time the Recipient Update Service ran, that object is not noticed by the Recipient Update Service. But if the object is changed in any way, the Recipient Update Service scans it again to determine if new e-mail addresses will be applied to it. This means that over time, a single object that lacks the specifier attributes can have dozens or hundreds of _NNNN@domain.com e-mail addresses.
Generally, the additional addresses are inert and do not affect ordinary mail flow; however, over time they can cause the Recipient Update Service to process items more and more inefficiently. The Recipient Update Service must check for duplicate addresses repeatedly when it assigns new addresses to objects. If the email@example.com address exists, the Recipient Update Service must perform over a thousand duplicate address checks before it can assign a new address based on the firstname.lastname@example.org generation rule.
Although Exchange checks for duplicate e-mail addresses, the check is not foolproof for the following two reasons:
Best Practices to Prevent Duplicate and Multiple AddressesThe character that is used most frequently in auto-naming rules is underscore character (_). This section refers to the address generation rule SMTP:%email@example.com as the base example.
A %firstname.lastname@example.org address generation rule does not cause the same problems as %email@example.com. If an object lacks the givenName and the sn attributes, the address generation rule devolves to @domain.com. This invokes the default Recipient Update Service behavior of stamping an e-mail address of mailNickname@domain.com
To prevent auto-naming specifiers from causing these problems if you are using auto-naming specifiers and you are using hard characters in the user part of the address generation rule, you must configure the filter on the recipient policy to explicitly test for the existence of the attributes that you specify.
Each Exchange recipient policy has an Lightweight Directory Access Protocol (LDAP) filter that defines the objects that the policy applies to. The simplest filter you can define on an object is (mailnickname=*). In LDAP filter syntax, attribute=* can be read as "attribute exists." Therefore, the (mailnickname=*) filter applies the policy to every object that has a mailNickname attribute (that is, every object that is mail-enabled). This filter is the filter for the default recipient policy.
If you create additional recipient policies, the filters may become much more complex as you restrict the objects that the policies apply to. Exchange provides a user interface that builds filters for the administrator based on common-sense criteria, instead of requiring you to construct filters manually.
For example, the following filter is automatically generated to capture all Exchange users, contacts, and groups:
To construct this filter on a policy:
(&(&(& (mailnickname=*) (|(&(objectCategory=person)(objectClass=user)(!(homeMDB=*)) (!(msExchHomeServerName=*)))(&(objectCategory=person) (objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) (&(objectCategory=person)(objectClass=contact)) (objectCategory=group)(objectCategory=publicFolder) ))))
Notice that (objectCategory=user)(givenName=*)(sn=*) has been added near the end of the filter. This filter now captures only users who have both a givenName and an sn attribute. This filter ignores distribution lists, contacts, and Exchange system objects.
(&(&(&(& (mailnickname=*) (| (&(objectCategory=person) (objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*))) (&(objectCategory=person)(objectClass=user)(|(homeMDB=*) (msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact)) (objectCategory=group)(objectCategory=publicFolder)))) (objectCategory=user)(givenName=*)(sn=*)))
Finding and Removing Duplicate AddressesDuplicate addresses that are created by auto-naming specifiers typically follow a predictable pattern (for example, firstname.lastname@example.org, email@example.com, and similar addresses). Therefore, you can perform an automated search for these addresses and perform automated cleanup.
You can use the Ldifde.exe utility that is included in Windows 2000 to export and import Active Directory information as plain text in the LDIF format. Ldifde uses the same standard LDAP search syntax as the Exchange recipient policy filters. You can paste a recipient policy filter into an Ldifde command line and create a text file that lists every object in a container that is captured by the filter. The following command is an example of the general syntax to create a text file:
ldifde -f file.txt -d "dc=subdomain,dc=domain,dc=com" -l [attribute list] -r "[ldap filter]"In this command, all objects in Subdomain that fit the filter are written to File.txt. To capture objects from the Configuration container, you must specify the container and the first domain that is installed in the forest, for example:
ldifde -f file.txt -d "cn=configuration,dc=firstdomain,dc=com" -l [attribute list] -r "[ldap filter]"The -l parameter restricts the attributes for the object that are written to File.txt. If you omit -l, all attributes for each object are listed. To list none of the attributes, use -l nothing. If you do so, the command exports only the distinguished name of each object to File.txt.
To find all duplicate or multiple proxy addresses, you can run Ldifde against every domain in your organization and against the Configuration container for your forest. To do so, you must define a unique search pattern that matches only the unwanted addresses.
For this example, the search pattern is *SMTP:_*@*. This search pattern captures every SMTP (Internet Mail) Exchange e-mail proxy address that starts with an underscore. For example, run the following command:
ldifde -f badproxies.txt -d "dc=domain,dc=com" -l proxyaddresses -r "(proxyaddresses=*smtp:_*@*)"This command exports data to Badproxies.txt that is similar to the following data:
The Badproxies.txt file contains records for objects whose proxy addresses include an SMTP address that begins with an underscore. All other addresses for these objects are also exported. You can filter out these extra addresses later.
dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=InformationStore,CN=EXCHANGE1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com changetype: add proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: SMTP:email@example.com proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: smtp:EXCHANGE1-PubIS@domain.com proxyAddresses: X400:c=US;a= ;p=Organization;o=First Administrative Group;s=EXCHANGE1-Pub IS; dn: CN=Microsoft DSA,CN=EXCHANGE1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com changetype: add proxyAddresses: smtp:email@example.com proxyAddresses: SMTP:firstname.lastname@example.org proxyAddresses: smtp:email@example.com proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: smtp:email@example.com proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: smtp:email@example.com proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: smtp:email@example.com proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: smtp:email@example.com proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: smtp:email@example.com proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: smtp:email@example.com proxyAddresses: smtp:firstname.lastname@example.org proxyAddresses: smtp:EXCHANGE1-SRS@domain.com proxyAddresses: X400:c=US;a= ;p=Microsoft;o=Desperation;s=JESSICA-SRS;
Some addresses that begin with underscores may be legitimate. If this condition is true, you must remove those objects from the Badproxies.txt file before you continue. Run the following Ldifde command to identify these objects:
ldifde -f file.txt -d "dc=domain,dc=com" -l givenname,sn,samaccountname,mailnickname,displayname -r "(|(givenname=_*)(sn=_*)(samaccountname=_*)(mailnickname=_*)(displayname=_*))"This command searches for objects whose first name, last name, Windows logon name, Exchange alias, or display name starts with an underscore. You can adapt the search filter to the pattern that is appropriate for your particular environment.
Note If the syntax of your Ldifde command is incorrect, Ldifde may not return an error. Instead, you may not see any search results at all. If your search returns no objects, test the Ldifde command by altering the search filter in a minor way to return results. For example, replace the underscore with the letter A.
Also, if you do not have permissions to view objects or attributes, these items are not returned by the search and you do not receive an error that states that you do not have permissions for certain object. When you search a domain container, Microsoft recommends that you log on as a domain administrator. When you search the Configuration container, Microsoft recommends that you log on as an enterprise administrator.
After you verify that Badproxies.txt contains only objects that have e-mail addresses that you want to remove, you must filter and re-format the LDIF file so that you can import it again. The LDIF import file format and the export file format differ significantly.
You can use the following sample script to convert and filter the import file. This script is provided as a sample only; use or modify this script at your own risk. This script in itself cannot change Active Directory information. You must manually import the output file from the script to Active Directory to make changes. Each line in the script is double-spaced to make it easier to detect improper line wrapping. To run the script, copy and paste the following text to a plain text file, and then name this file Proxyfix.bat.
ldifde -i -f delproxies.txt
Article ID: 318774 - Last Review: December 3, 2007 - Revision: 5.6