3.6 Query-based distribution groups

---

Large companies such as HP use distribution groups (or lists) extensively to create email-addressable objects that reach many people who share a common need or interest. However, it is typical to find a proliferation of distribution groups in any large email deployment, leading to a situation where people spend a lot of time updating the groups to make sure that the right people receive the right data all the time. For example, the HP GAL includes over 57,000 distribution groups, all of which have different maintainers. Some maintainers are very conscientious about how they maintain membership and the group is always accurate; others are less so and you can never be sure that the group contains everyone that it should.

Good maintainers remove members who no longer want to receive messages sent to the group or those who have left the company. Others simply leave the groups to degrade gently until they are no longer wanted. At that point, system administrators have to clean up the directory by removing redundant groups. However, cleaning up the directory or maintaining group membership is a low-priority task for hard-pressed administrators, so they are easy tasks to overlook. The result is a directory cluttered with obsolete groups and groups that do not reach the right membership. Exchange 2003 introduces support for query-based distribution groups to help you automate list maintenance. However, only Exchange 2003 and Exchange 2000 (SP3 onward) servers running in native-mode organizations support query-based distribution groups, connected to the AD on Windows 2000 SP3 or Windows 2003 servers, that have the necessary schema extension to support these lists (object type ms-Exch-Dynamic-Distribution-List). You can use the LDIFDE utility to gain an insight into the information that the AD holds for query-based groups. Figure 3.32 shows an edited version of LDIFDE output for a query-based group.

C:> LDIFDE -v -d "cn=Exchange2003EMEA,cn=users,dc=xyz,dn=com" -f     dn: CN=ExchangeEMEA,CN=Users,DC=xyz,DC=com changetype: add objectClass: top objectClass: msExchDynamicDistributionList cn: ExchangeEMEA description: Exchange 2003 Users in EMEA distinguishedName:   CN=ExchangeEMEA,CN=Users,DC=xyz,DC=com instanceType: 4 displayName: Exchange 2003 Users - EMEA proxyAddresses: SMTP:[e-mail] proxyAddresses: X400:c=US;a= ;p=HP;o=Exchange;s=Exchange2003EMEA; mailNickname: Exchange2003EMEA name: ExchangeEMEA showInAddressBook:   CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Co   ntainer,CN=HP,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xyz,DC=   com legacyExchangeDN:   /o=HP/ou=First Administrative Group/cn=Recipients/cn=Exchange2003 objectCategory:   CN=ms-Exch-Dynamic-Distribution- List,CN=Schema,CN=Configuration,DC=xyz,DC=com msExchRequireAuthToSendTo: FALSE textEncodedORAddress: c=US;a= ;p=xyz;o=Exchange;s=Exchange2003EMEA; mail: [e-mail] msExchHideFromAddressLists: FALSE msExchDynamicDLBaseDN: DC=xyz, DC=com msExchDynamicDLFilter:   (&(!cn=SystemMailbox{*})(&(&(& (mailnickname=*) (| (&(objectCategory=person)(o  bjectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) )))))

Figure 3.32: LDIFDE output for a query-based group.

As you can see, many of the attributes that you expect for any other distribution group, including email addresses, exist for query-based lists. The big difference is the value of the msExchDynamicDLFilter attribute, which holds the LDAP filter that the AD resolves to determine the dynamic membership of the list. The use of new attributes to define a query-based distribution group means that you cannot use the Exchange 2000 version of AD Users and Computers to work with these groups.

When users submit messages addressed to query-based distribution groups, the categorizer (even on an Exchange 2000 server) identifies that the group requires a query and then resolves it by making an LDAP query against a GC. After the GC returns all the recipients, the categorizer builds the recipient list and decides how to route the message. The need to build a list before submission increases load on the GC and routing server and delays the message slightly, but this is a justifiable tradeoff between usefulness and overhead.

The only difference a user sees between a query-based group and a normal group is that you cannot view the membership of a query-based group from its GAL properties. This is quite logical, because the GAL has no way of resolving the LDAP query to determine group membership. From an administrative perspective, you cannot use query-based groups to control access to objects such as connectors, and you cannot nest these groups inside other distribution groups.

3.6.1 Creating new query-based groups

Before creating a new query-based group, you should know what purpose you want the group to serve as well as the attributes that you will use to query the AD and build the group. Some administrators like to create one or more AD organizational units (OU) to hold the query-based groups instead of holding them with other objects in "regular" OUs. For example, you might call this OU "Groups" to make its purpose obvious. This decision is a matter of taste and policy and is not a requirement to use these groups.

To create a new query-based group, open the AD Users and Computers console^[3] and select the OU where you want to create the new object; then select "Query-based Distribution Group" from the menu, as shown in Figure 3.33. The next stage is to determine group membership. The AD uses LDAP queries to build group membership any time an application requests this information. As shown in Figure 3.34, you have to decide:

• The AD level to apply the filter-for the forest or a particular domain and its subdomains

• Objects to include in the group-these can be users with Exchange mailboxes, users with external email addresses, other mail-enabled groups, contacts with external email addresses, and mail-enabled public folders. In this context, an external email address means an address that an external correspondent can use to send a message to an object.

• Whether to apply a customized filter to further refine the search

Figure 3.33: Creating a new query-based distribution group.

Figure 3.34: Setting query parameters.

You can use a wide range of AD attributes to build the query to collect a specific set of recipients. The AD supports different attribute sets for users, contacts, public folders, and distribution groups, but the most common examples across all object types include:

• Objects in a particular department or set of departments

• Users who have mailboxes on a specific Exchange server

• Users and contacts who have a specific title (e.g., all marketing managers)

• Users who are temporary employees or full-time employees, identified by using a customized attribute to locate the members of either set. You might like to combine the new security feature to restrict the ability to send to a group to certain users or groups (see Figure 3.31). For example, you could limit the ability to send messages to full-time employees to authenticated users so that someone outside the company cannot send a message to all employees.

• Objects in a particular country

• Queries that use values in the set of customized attributes reserved for your own deployment purposes. For example, you could store employee job codes in one of the customized attributes and search against these values.

After you select the type of objects to include in the query, you can set filters for the query by clicking on the "Customize" button. Select the "Advanced" page and begin adding the filters by selecting the available fields from the "Field" drop-down list and the conditions that the AD uses when it resolves the query. For example, the query shown in Figure 3.34 selects any Exchange recipient (someone with a mailbox on an Exchange server in this organization) whose Country field is "Ireland" and City field is "Dublin."

You can add as many criteria as you like to a query, but each criterion can slow the query. The AD always resolves exact matches against properties faster than it can resolve properties that start with a certain value. It can also resolve present/not present values quickly. In other words, you can look for users who have no value in a specific attribute or those who have something in the attribute. You will not notice any performance difference from inefficient or slow queries on small deployments, but creating efficient queries is critical when the AD contains more than a few thousand entries. The golden rule is to make queries as simple as possible and then test the query to make sure that you get the expected results. It is also best practice always to test a query-based group to ensure that the query actually works and will return some objects when the categorizer executes it to route messages. You can certainly address messages to a query-based group that resolves to no addressable recipients and you receive no indication that Exchange is unable to deliver the message. Behind the scenes, the message flows as normal until it reaches the categorizer, which executes the query, finds there are no addressees for the message, and then terminates processing because the message has (in fact) reached its final destination.

When you have defined the query parameters, you can test a query with the "Find Now" button on the dialog that you use to set filter criteria (Figure 3.34) or by selecting the query-based group from AD Users and Computers and viewing the preview property page (Figure 3.35). The preview page also shows the LDAP query that the AD executes to resolve the query.

Figure 3.35: Previewing the results of the query.

Executing the LDAP query to view the contents of a list gives an insight into the way that the Exchange Routing Engine expands a query-based list.

The process is simple: Find the AD entry for the list through its Distinguished Name (DN), then convert the DN to the Relative Distinguished Name (RDN), and then expand the contents of the list with an LDAP search. As with other searches, to ensure best performance the Routing Engine looks at the DSAccess cache first to see if the list exists there.

3.6.2 Using custom attributes in query-based groups

Exchange has always provided a set of custom attributes that you can use to store information about users in the directory. It is highly unlikely that the designer of any directory will ever incorporate a set of attributes that satisfies every possible customer, so the Exchange 5.5 Directory Store and the AD both have 15 custom attributes that you can populate according to your needs. The Exchange 5.5 Administration program user interface only reveals 10 attributes, but there are 15. You just have to populate the last five programmatically if you ever want to use them. Fortunately, the AD reveals everything, and you can fill in the attributes by first selecting the advanced view for AD Users and Computers and then viewing the "Exchange Advanced" property page (Figure 3.36).

Figure 3.36: Setting values for custom properties.

Before you begin to add values to the custom property set, you should clearly define what these values will hold and how to populate them. Otherwise, one administrator may think that custom attribute 1 holds an employee badge number, whereas everyone else uses custom attribute 2 for this purpose. Other common uses for these attributes include cost center identifiers, whether a user is a permanent or temporary employee, Social Security numbers (some countries bar you by law from holding personal information such as this in a general-purpose directory), job codes, and so on.

3.6.3 Using query-based distribution groups

If you use Outlook, query-based groups look and behave like any other distribution group, and you can address messages to the group in the normal manner. The only indication that the group is any different is a different icon displayed when you browse the GAL, as well as the fact that you cannot view the membership if you look at the properties of the group through Outlook's Address Book (Figure 3.37). The inability to see group membership frustrates some users who are then unwilling to send messages to the group simply because they do not know who will end up receiving copies. It is possible that an administrator will make a mistake with the query that results in a message going to people who should not receive it, a fact that also worries users (if they realize what is happening in the background).

Figure 3.37: Viewing a query-based distribution group from the GAL.

The Exchange 2003 version of OWA is also able to deal with query-based groups correctly, although you cannot view group membership through this client, since the OWA UI does not support it.

Outlook Express does not know about the query-based group object type, so it has some problems when you attempt to address or send email to these groups. For example, you cannot use the CTRL/K feature with Outlook Express to check the name of a query-based group against AD. In addition, the Outlook Express interface to AD (a straightforward LDAP search) cannot find these entries, so it is best to create personal contacts that include the query-based group's SMTP address if you want to use query-based groups often. You can then use the contact or type the SMTP address into a message header, and Exchange will safely deliver the message by expanding the group membership after the Routing Engine resolves the address on the incoming message against the AD.

Because a query-based group only "exists" when an application such as Exchange resolves its membership against the AD, it follows that you cannot maintain group membership in the same way as users can update membership of regular groups by selecting the list from the GAL and then modifying its properties using Outlook. You have to make any change to a query-based group through AD Users and Computers.

Query-based distribution groups do not hold Windows security principals, so you cannot use them to control access to public folders or other resources such as file shares. In a similar manner, you cannot use querybased groups to place restrictions on objects such as connectors. In addition, you cannot nest query-based groups or add them to global or universal distribution groups; they stand on their own. Finally, the data captured by Exchange to chart the progress of a message sent to a query-based group in a server's message tracking log is the same as for regular groups.

The success of query-based groups obviously depends on a high degree of consistency in directory data. For example, if you want to create a query group to address all users in a particular country, the group can only be successful if you identify every user in that country by updating the user objects with the necessary information in the directory.

Query-based distribution groups are a useful feature that enables administrators to create self-maintaining groups. As with anything that depends on a directory, the accuracy of directory information will dictate the effectiveness of query groups.

^[3] . The installation of Exchange 2003 updates the AD Users and Computers console to provide support for query-based lists.

---