When you send a message to a mail-enabled group, the Exchange server sends a copy of the message to each mail-enabled user and contact in the group. The process of finding those mail-enabled group members is called expansion.
Description of group expansion process
Figure 5.8 shows a diagram of the expansion process. During this discussion, I'll use the term "ultimate recipients" to mean mailbox-enabled users, mail-enabled users, and mail-enabled contacts.
- User selects group from Global Address List (GAL). The process starts when an Outlook user selects a distribution list from the GAL to be the recipient of an email message. Outlook obtains the GAL via a Name Service Provider Interface (NSPI) request sent to a Global Catalog server. The user could also simply enter the distribution list name in the To field of the message.
- Name Server Provider Interface (NSPI) transaction. Outlook uses NSPI to verify the group name in the Global Catalog and,
if the verification succeeds, it bolds the name in the To field.
- MAPI Send. When the user clicks the Send button, Outlook uses MAPI to transmit the message to the user's home Exchange server.
- Group Expansion. The Exchange server sees that the recipient is a group, and it sends an LDAP query to a Global Catalog server asking for the ultimate recipients who are members of the group, along with a list of email attributes that it needs for each of those recipients.
The Global Catalog server obtains the names of the ultimate recipients from its copy of Active Directory, along with the requested email attributes. If the list includes any mail-enabled groups, the Global Catalog server expands the membership of each of those groups and repeats the process recursively until it has assembled a full list of all ultimate recipients in each of the nested groups. It returns this list to the Exchange server.
- Message Routing. The Exchange server then sends a copy of the message to each of the ultimate recipients. If multiple recipients have mailboxes on the same server, the Exchange server sends a single message tagged for delivery to the recipients. This "single instance messaging" complements the "single instance storage" for messages on the target server.
This process of expanding group membership lists and returning the results to an Exchange server happens hundreds, if not thousands, of times a day. You want to support Exchange with good-quality, high-powered Global Catalog servers, and you need enough of them to handle both expansion requests and the GAL requests coming from Outlook clients.
In production, start with a minimum of two Global Catalog servers for each Exchange server. To scale from there, Microsoft recommends a 4:1 ratio between the number of processors in your Exchange servers and the number of available Global Catalog servers. For example, if you have two 4-way Exchange servers in an office, you should have two Global Catalog servers in the same location.
Designating expansion servers
When an Outlook user sends a message to a group, the user's home Exchange server works with a local Global Catalog server to expand the group's membership. Under most circumstances, the user's home Exchange server does the expansion by working with a local Global Catalog server. The term "local," in this case, means local to the Exchange server, not necessarily local to the user. In some circumstances, you might want to specify a specific Exchange server to handle the group expansion. These circumstances include
- Mail -enabled global groups. If you have multiple domains in your forest, you want to use Universal groups for email distribution because the Global Catalog contains the membership list. If you use a Global group instead, you should target the expansion of that group to an Exchange server in the same domain. Otherwise, if a user in another domain sends a message to the Global group, the Exchange server in that user's domain cannot expand the group membership because the Global Catalog does not contain the membership list for Global groups.
- Localized mail delivery. If all members of a particular Universal group reside in the Asia Pacific region, it might make sense to specify an Exchange server in Taipei as the expansion server rather than letting an Exchange server in Phoenix or Amsterdam expand the membership and send the messages.
If you decide that you need to designate an expansion server for a group, do so using Active Directory Users and Computers (ADUC). Open the group's Exchange Advanced Properties window, shown in Figure 5.9. Notice that a group is assigned to an Administrative Group. The expansion server must reside in the same Administrative Group.
Single point of failure
If you designate an Exchange server as an expansion server for a group or groups, email sent to that group does not arrive when you take that server down for maintenance. The Exchange server will log a warning about the inability to find the expansion server, and messages queue up for delivery to the recipients. Keep this in mind as you schedule maintenance on your Exchange servers.
You might want to determine whether groups have been assigned to a single expansion server. The Active Directory Users and Computers console does not have a standard query to find groups with expansion servers. You can use the Saved Query option to create a custom LDAP search using the Active Directory attribute that stores the expansion server name. This attribute is called msExchangeExpansionServerName.
The msExchangeExpansionServerName attribute stores the distinguished name of the expansion server in X.521 format; for example, o=organization,ou=site,cn=configuration,cn=servers,cn=servername. You can't just match the first few letters, so the search must use a wildcard to represent the initial part of the name. Here's the LDAP filter syntax that searches for every group that uses W2K3-EX1 as an expansion server:
If you have thousands and thousands of mail-enabled groups, this search could take a while to run because it uses a wildcard at the start of the attribute string.
15 tips in 15 minutes: Managing recipients and distribution lists
Tip 1: Exchange security groups
Tip 2: Group membership expansion
Tip 3: Managing Exchange group email properties
Tip 4: Exchange 2003 Query-Based Distribution Groups
Tip 5: DSAccess for Exchange
Tip 6: DSProxy for Exchange
Tip 7: Managing Exchange recipient policies
Tip 8: Exchange Recipient Update Service and proxy addresses
Tip 9: Restricting mail storage on an Exchange server
Tip 10: The Exchange server mailbox management service
Tip 11: Blocking a user's email access
Tip 12: Accessing another user's mailbox in Outlook
Tip 13: Exchange mail retention
Tip 14: Managing recipients with system policies
Tip 15: Managing recipients with Global Settings
This chapter excerpt from Learning Exchange Server 2003 by William Boswell is printed with permission from Addison-Wesley Professional, Copyright 2004. Click here for the chapter download or to purchase the book.