XCON: Messages Sent to a Group Are Not Distributed to Users Who Are Members of Their Primary Group

If you send a message to either a security group or a distribution group, the message is delivered only to recipients that are explicitly stamped as members of that group. If the group is also a user's primary group, the user is not explicitly listed as a member of that group, and the message is not delivered to that user.

The categorizer is responsible for the expansion of group membership. After the categorizer obtains the list of working global catalogs, the categorizer uses Lightweight Directory Access Protocol (LDAP) to query the global catalog for the member attribute of the group. Group membership is enumerated and the message is sent to all of the recipients that are explicitly contained in the member attribute.

If you send messages to members of a distribution group and the member attribute for the group is "null" (which is a valid state), the message is not sent to any recipients. If the member attribute for the group does not contain a complete list of members, the message is sent to the incomplete list of members if a particular member attribute is missing.

If the LDAP lookup procedure to the global catalog finds the group object, a non-delivery report (NDR) is not generated for the message.

To support groups that have a very large number of members like the Domain Users group (or the Domain Computers group), Directory Service performs a type of optimization known as the primary group optimization. If a group is marked as a user object's primary group, the membership in the group is not stored explicitly; however, membership is considered implicit. Do not use the primary group of a user to send mail to that user because the primary group membership is not explicitly stamped as a member.

To work around this issue, use the primary group of a user for administrative purposes only. Use any group other than the primary group to distribute e-mail. It is recommended that you use universal distribution groups.

The behavior of the categorizer is by design.

WARNING: If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Exchange 2000 Server, or both. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

The following scenario demonstrates the behavior that is described in this article:

1. Create a special organizational unit for this scenario.
2. Create a global or a universal security group and call it "Group1."
3. Create a user and name it "User1."
4. Open the properties for User1, click the Member of tab, and then add this user to Group1.
5. Set Group1 as the user's primary group, remove the user from the Domain Users group, and then click OK.
6. Use the LDP tool to get the LDP dump of Group1.
   
   You notice that the member attribute does not exist on the group at this time. However, in the Active Directory Users and Computers snap in, User1 is displayed as a member of Group1.
7. Create another global security group and call it "Group2."
8. Open the properties for User1, add User1 to Group2, and then click OK.
9. Use LDP to view Group2.
   
   You notice that User1 is displayed in Group2 under the member attribute, but User1 is still not displayed in Group1.
10. Open the properties for User1, make Group2 the user's primary group, and then click OK.
11. Use LDP to view the groups.
    
    You notice that User1 is displayed in Group1 under the member attribute, and Group2 does not explicitly show the user as a member.

For additional information, click the article number below to view the article in the Microsoft Knowledge Base: