Recipe5.12.Creating Multiple Address Lists

Recipe 5.12. Creating Multiple Address Lists

Problem

You want to create separate address lists for subdivisions of your Exchange organization.

Solution

Using a graphical user interface

Open the Exchange System Manager (Exchange System Manager.msc).
Expand your Exchange organization object, then expand the Recipients container.
Right-click the All Global Address Lists node, then choose the New Global Address List command.
In the Create Exchange Address List dialog box, give the address list a name, then click the Filter Rules button to specify which objects should appear in the address list.
The Find Exchange Recipients dialog box (see Figure 5-4) will appear. By default, the Find field will be set to find Exchange recipients, so you can use the checkboxes to select specific types of objects, or the Storage tab to select only recipients on a particular server or storage group. The Advanced tab lets you filter by any defined attribute on directory objects; for example, you can filter by custom attributes if you're using them, or by city, manager name, first name, or anything else you like. You can also use the Find field to perform other types of queries; for example, by setting it to Users, Contacts, and Groups, then entering "Robichaux" into the Name field, we can easily build a list of family members who have accounts on my home Exchange server.
Once you've built a set of criteria, you can use the Find Now button to execute the query and verify that it finds the objects you want included in the address list. Adjust the query as necessary, then click OK.
Click Finish to save the address list.
Wait for the RUS to run, then inspect the contents of the new address list to make sure the filter you built in step 5 is working properly.

Figure 5-4. You can easily build a new global address list by finding selected combinations of contacts, users, public folders, and distribution groups

Using VBScript

' This code creates a new global address list ' ------ SCRIPT CONFIGURATION ------  strDCName = "<serverName>"    ' e.g., CONT-EXBE01      strContainer= "/CN=All Address Lists,CN=Address Lists Container,CN=<orgName>," &_    "CN=Microsoft Exchange,CN=Services,CN=Configuration, <ForestRootDN>"  strALName = "<addressListName>"    ' e.g., "Seattle Employees" strDomain = "<domainPath>"        ' e.g., "dc=robichaux, dc=net" ' ------ END CONFIGURATION --------- Set objContainer = GetObject("LDAP://" & strDCName & strContainer) Set objAddrList = objContainer.Create("AddressBookContainer", "cn=" & strALName) objAddrList.Put "displayName", strALName objAddrList.Put "PurportedSearch", "(&(mailNickname=*)(objectClass=user))" objAddrList.Put "systemFlags", 1610612736 objAddrList.SetInfo WScript.Echo " Created new GAL named " & strALName

Discussion

Address lists allow you to create flexible groupings of your users that are automatically updated. If you're familiar with recipient containers in Exchange 5.5, you'll recognize the underlying idea: define a rule that says which users should be grouped together, then let Exchange reassign users as necessary. Unlike 5.5 recipient containers (which didn't allow you to move users between them), address lists are based on LDAP queries, so the lists are dynamically assembled, and the original objects' attributes are mostly untouched. You can write arbitrarily complex LDAP filter expressions to define the contents of your address lists; ESM provides a fairly robust interface for creating canned queries, but you can plug in your own filter expression via the GUI or in a script. (Note that although LDAP queries are used to build the address lists, clients access them via the Name Services Provider Interface, or NSPI.)

Once the address list has been created, the RUS will update it whenever it runs (which means that you may experience short propagation delays). If you leave the RUS schedule set to its default of "always run," then the RUS will be run whenever a recipient policy changes, which in turn means that your address lists will be updated when you change recipient policies. The RUS actually updates the showInAddressBook attribute to reflect each address list in which the object should be visible. You can verify the address list's presence in two ways: within ESM (although it may not appear until you quit and relaunch the snap-in) or by creating a new message in Outlook and clicking the To button, then using the Show names from the combo box to pick the new address list.

When you create an address list via script, it is important that you create it in the correct container. The All Address Lists object is the immediate parent of all the address lists you define in the organization; in turn, that object lives in the Address Lists Container object, a child of the Exchange organization object. The value of the PurportedSearch attribute specifies your LDAP filter.

Global Versus "Regular" Address Lists

It can be hard to figure out what type of address list you should use to group recipients in Exchange, because there's more than one type. Global address lists (GALs) are intended to be the base-level address lists for all users in an organization, while address lists subdivide the address space according to whatever criteria you've specified. In most Exchange organizations, there will only be one GAL, but there may be many address lists. Unfortunately, this distinction is muddied because you can easily create more than one GAL within the same Exchange organization. This is a feature, not a bug; it's designed to allow you to use one Exchange organization to provide messaging services to more than one "real world" organization. For example, you could provide logically independent Exchange services to several partner companies without actually building separate Active Directory forests for each partner; instead, you'd set up a GAL for each company, then follow the steps in MS KB 822940 to set permissions on the GALs so that each company's users (which would, of course, have to be contained in their own separate OUs) could only see their own GAL.