Address lists provide a convenient method to present directory
objects in containers and can be combined in an address book policy
(ABP) to restrict users to the Active Directory information they can
see. By default, Exchange comes with a number of predefined containers
defined by address lists:
All Users. All the mailboxes known to the organization
All Groups. All the distribution groups and dynamic groups known to the organization
All Contacts. All the mail-enabled contacts known to the organization
All Rooms. All the room mailboxes known to the organization
Public Folders. All the public folders (both traditional and modern) known to the organization
These
address lists are available to all clients. In addition, the default
Global Address List (GAL) is defined to be the sum of all the
mail-enabled objects within the organization. EAC manages both normal
address lists and GALs through the Organization section. Behind the
scenes, the *-AddressList cmdlet set interacts with address lists, and
the *-GlobalAddressList cmdlet set manages GALs. Your account needs to
hold the RBAC Address Lists role before you can work with address
lists. The role is included in the Organization Management role group.
Address
lists are used to create virtual organizations through the framework of
an ABP. If you are not interested in address book policies, you might
never go near the standard set of address lists because they meet the
needs of the vast majority of Exchange deployments and, certainly,
those that support only up to a few thousand mail-enabled objects when
it is relatively easy to browse or search the directory for recipients.
Larger
Exchange deployments might consider it a good idea to break up the
directory into smaller chunks to help users navigate. For example, if
your GAL contains 100,000 objects, it might be more convenient to
provide users with address lists based on department, office, or
country to assist users to find recipients. Exchange certainly makes
this possible, and it is very easy to create a set of new address lists
based on a broad range of criteria, remembering that users will
continue to have access to the totality of the GAL unless this is
restricted by an ABP.
Imagine that you want to provide a
country-centric view into the GAL. To do this, you need a separate
address list for every country. (Note that clients have a limited
amount of UI space to display address lists, so it’s best to restrict
yourself to creating the most important five or six address lists.)
Like anything to do with queries against Active Directory, the
assumption is that the data in the directory is sufficiently populated
to generate reliable results. In the example shown in Figure 1,
an address list for Contoso France is created, and the query is based
on two major factors: all recipient types and the value of the Active
Directory StateOrProvince attribute set to France.
Notice
the Preview Recipients The Address List Includes option toward the
bottom of the screen. Like the preview feature supported for email
address policies, this enables you to validate that the query specified
for the address list will create the desired set of recipients when run
against the directory. You can use this option to check the query and
adjust as required until you are happy that the correct results are
displayed; then save the new address list. Looking at the saved object
with the Get-AddressList cmdlet, you see:
Path : \Contoso France
DisplayName : Contoso France
Name : Contoso France
RecipientFilter : ((StateOrProvince -eq 'France') -and (Alias -ne $null))
LdapRecipientFilter : (&(st=France)(mailNickname=*))
LastUpdatedRecipientFilter :
RecipientFilterApplied : False
IncludedRecipients : AllRecipients
RecipientContainer :
RecipientFilterType : Precanned
These
properties should be very familiar because they are similar to those
used by dynamic groups and email address policies. The critical pieces
are the RecipientFilter and the IncludedRecipients properties.
Tip
Make
sure of your display names. Like other Exchange objects, address lists
have both Name and DisplayName properties. The Name property identifies
the object; the DisplayName is what users see when the address list
appears when they browse in places such as the People section of
Outlook Web App. You don’t need to specify a display name when you
create an address list with EMS, but if you do, make sure that the
DisplayName property is suitable and conveys the intention and purpose
of the list.
As
soon as a new address list is created, it becomes visible to clients.
For example, in Outlook Web App, the new address list shows up under
Other Address Lists in the People section. However, just after
creation, the address list is an empty container, and it needs to be
populated before users will see anything after they select the list. If
you select the new address list and look at its properties, shown in
the rightmost property pane, you’ll see that EAC indicates that some
changes recently occurred in the address list and that it needs to be
regenerated. Click Update to proceed and ignore EAC’s warning that this
action could take some time to complete (minutes rather than hours) in
large organizations, where an address list might include tens of
thousands of objects. After the update completes, users see the
recipients identified by the query when they click the address list.
