Verifying the Required Active Directory Attributes

 

When you are troubleshooting an NDR, verify that all mail-enabled attributes that Message Categorizer requires exist for that recipient in Active Directory. In Exchange 2000, multiple attributes must be correct for messages to be categorized:

  • homeMDB

  • homeMTA

  • legacyExchangeDN

  • mail

  • mailNickname

  • msExchHomeServerName

  • msExchMailboxGuid

  • msExchMailboxSecurityDescriptor

  • proxyAddresses

This list of required attributes is valid only if the recipient is a mailbox-enabled object in Active Directory (for example, an Exchange 2003 recipient). However, if the recipient is an Exchange Server 5.5 recipient, the only attributes that have to be present are:

  • legacyExchangeDN

  • homeMDB

  • homeMTA

For mail-enabled objects (for example, a custom recipient) and alternate addresses, the targetAddress attribute is required. If the targetAddress attribute is not present, the fallback is to the mail attribute.

If an e-mail message is missing any of the required attributes or if they are incorrect, the message may remain in the categorizer, and no events are created in Event Viewer. If you track the message, it appears in Message Categorizer or it generates an NDR, depending on which attribute is missing. If you want to check these attributes for a user in Active Directory, use the LDP tool or ADSI Edit. For more information about the LDP tool or ADSI Edit, see the Windows online documentation.

Note

If you use the ADSI Edit snap-in, the LDP tool, or any other LDAP version3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall any of the following: Windows2000 Server or Windows Server2003, or Exchange Server2003. You may not be able to solve problems that occur if you incorrectly modify Active Directory object attributes. Modify these attributes at your own risk.

The following table shows examples of each of the attributes that Active Directory requires.

Mail-Enabled Exchange 2003 Active Directory attributes

Exchange 2003 mail-enabled attribute Example

homeMDB

CN=Mailbox Store (CONTOSO-MSG-01),CN=First Storage Group,CN=InformationStore,CN=CONTOSO-MSG-01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com

homeMTA

CN=Microsoft MTA,CN=CONTOSO-MSG-01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com

legacyDN

/o=First Organization/ou=First Administrative Group/cn=Recipients/cn=ted

mail

ted@contoso.com

mailNickname

ted

msExchHomeServerName

/o=First Organization/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=CONTOSO-MSG-01

msExchMailboxGuid

0x06 0x4f 0x69 0xcc 0x5e 0xfe 0x79 0x4f 0x8c 0x6e 0x7b 0x67 0x57 0x92 0x51 0xd2

msExchMailboxSecurityDescriptor

This attribute is a binary blob that does not display a value in ADSIEdit or LDP.

proxyAddresses

SMTP: scott@contoso.com X400:c=us;a= ;p=First Organizati;o=Exchange;s=Bremer;g=Ted;

The following example shows a dump file from the LDP tool with all the mail-enabled Exchange 2003 Active Directory attributes that the categorizer requires:

Expanding base 'CN=Ted Bremer,CN=Users,DC=contoso,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: CN=Ted Bremer,CN=Users,DC=contoso,DC=com

1> homeMDB: CN=Mailbox Store (CONTOSO-MSG-01),CN=First Storage Group,CN=InformationStore,CN=CONTOSO-MSG-01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com;

1> memberOf: CN=Sales Team,CN=Users,DC=contoso,DC=com;

1> accountExpires: 9223372036854775807;

1> badPasswordTime: 0;

1> badPwdCount: 0;

1> codePage: 0;

1> cn: Ted Bremer;

1> countryCode: 0;

1> displayName: Ted Bremer;

1> mail: ted@contoso.com;

1> givenName: Ted;

1> instanceType: 4;

1> lastLogoff: 0;

1> lastLogon: 126416003544864704;

1> legacyExchangeDN: /o=First Organization/ou=First Administrative Group/cn=Recipients/cn=ted;

1> logonCount: 19;

1> distinguishedName: CN=Ted Bremer,CN=Users,DC=contoso,DC=com;

1> objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=contoso,DC=com;

4> objectClass: top; person; organizationalPerson; user;

1> objectGUID: fdd08ce8-be92-4652-96db-f44785ef49e4;

1> objectSid: S-15-C2EF2A3A-4F67EE69-69068D04-64A;

1> primaryGroupID: 513;

2> proxyAddresses: SMTP:ted@contoso.com; X400:c=us;a= ;p=First Organizati;o=Exchange;s=Bremer;g=Ted;;

1> pwdLastSet: 126415962391597356;

1> name: Ted Bremer;

1> sAMAccountName: ted;

1> sAMAccountType: 805306368;

2> showInAddressBook: CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com; CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com;

1> sn: Bremer;

1> textEncodedORAddress: c=us;a= ;p=First Organizati;o=Exchange;s=Bremer;g=Ted;;

1> userAccountControl: 512;

1> userPrincipalName: ted@contoso.com;

1> uSNChanged: 16820;

1> uSNCreated: 16814;

1> whenChanged: 8/6/2001 11:31:17 Pacific Standard Time Pacific Daylight Time;

1> whenCreated: 8/6/2001 11:30:38 Pacific Standard Time Pacific Daylight Time;

1> homeMTA: CN=Microsoft MTA,CN=CONTOSO-MSG-01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com;

1> msExchMailboxGuid: <ldp: Binary blob>;

1> msExchMailboxSecurityDescriptor: <ldp: Binary blob>;

1> msExchALObjectVersion: 56;

1> msExchHomeServerName: /o=First Organization/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=CONTOSO-MSG-01;

1> mailNickname: ted;

1> mDBUseDefaults: TRUE;

1> msExchPoliciesIncluded: {E7B464D2-65EF-4B3E-8AF4-8EB84BA7088E},{26491CFC-9E50-4857-861B-0CB8DF22B5D7};

1> msExchUserAccountControl: 0;

How the Recipient Update Service Updates Attributes

The Recipient Update Service has three system policies for mail-enabled recipients, mailbox-enabled users, and hidden distribution group membership that are installed by default when you install Exchange 2003. All three policies have the same purpose: to update a few attributes for objects in Active Directory under certain circumstances.

When custom tools are used to create users, contacts, or distribution groups, the Recipient Update Service attempts to correct any omissions in cases where a tool does not create all the necessary attributes for an object. If a user, contact, or distribution group lacks required attributes, problems can occur.

For a mail-enabled recipient, a minimum set of attributes is required to make all Exchange components work properly. For example, a mail-enabled entry (a user, contact, group, or public folder) has to have at least these attributes: mailNickname, legacyExchangeDN, and displayName. Without the mailNickname attribute, an object is not considered mail-enabled. After an object has a mailNickname attribute, the other two attributes must be set.

Mail-Enabled Recipient Policy

If the Recipient Update Service identifies a new entry that was added or modified, and that entry has the mailNickname attribute, but does not have the legacyExchangeDN or displayName attributes, the Recipient Update Service tries to create those attributes.

The displayName attribute is copied from the mailNickname attribute as is. The legacyExchangeDN attribute goes through an algorithm that identifies the organization and administration group for the entry, and then creates a value in the following format:

/o=MyCompany/ou=MyAdminGroup/cn=Recipients/cn=MailNickname

Mailbox-Enabled User Policy

For a mailbox-enabled user, two attributes must be present. The first is the mailNickname attribute, and the second is one of the following attributes:

  • msExchHomeServerName

  • homeMDB

  • homeMTA

If any one of these attributes is present, and the user has a mailNickname attribute, the user is considered a mailbox-enabled user.

In this case, the Recipient Update Service attempts to populate some of the following attributes if they are not present:

  • msExchHomeServerName

  • homeMDB

  • homeMTA

  • legacyExchangeDN

  • displayName

  • msExchMailboxGuid

These attributes are populated in the following order:

  1. If the msExchHomeServerName attribute is not present, it is created based on the homeMDB or homeMTA attribute, depending on which one is present. If the msExchHomeServerName attribute cannot be created, the process stops.

  2. After the msExchHomeServerName attribute is set, the homeMDB and homeMTA attributes are populated if either one is missing. If you have multiple mailbox stores or message transfer agents (MTAs) on your server, the Recipient Update Service picks the first one that it finds when it does an Active Directory search. Therefore, this selection can be considered a random choice.

  3. To create the legacyExchangeDN and displayName attributes, the Recipient Update Service follows the same steps that are used for a mail-enabled recipient.

  4. Finally, if the msExchMailboxGuid attribute is not present, the Recipient Update Service creates the msExchMailboxGuid attribute by generating a GUID.

Hidden Distribution Group Membership Policy

For the hidden distribution group membership policy, the Recipient Update Service does not run only when a new entry is created (such as a security group or distribution group). The Recipient Update Service also runs when you modify the status of the hideDLMembership attribute.

If this attribute is set to TRUE, the Recipient Update Service adds a noncanonical part to the security descriptor, which prevents anyone from viewing the "member" attribute for that entry. This applies to any type of client that searches the directory by using MAPI or LDAP.

If the attribute is set to FALSE, the Recipient Update Service removes the noncanonical security descriptor, which exposes the member attribute again.

For additional information about hiding group membership, see Microsoft Knowledge Base article 253827, "XADM: How Exchange Hides Group Membership in Active Directory." Although this article is written for Exchange 2000, the same principles apply to Exchange 2003.