Managing Global Address Lists

The global address list, by its very definition, is a list of all mail-enabled objects in the entire directory (in our case, the Active Directory). You can create multiple global address lists for your organization, but your users see only one. They cannot pick and choose which GAL they see in Outlook or Outlook Web Access.

Most small and medium-sized businesses will never need more than the default global address list. In fact, organizations with tens of thousands of mailboxes often never need more than a single GAL. So why is there a feature that lets you create more than one GAL? An organization might need more than one GAL for a couple of reasons:

• The Exchange organization is hosting more than one company or subsidiary, but users only need to see a subset of the entire organization.

• The Exchange organization is a hosting environment that runs many companies, but users in each company should see only the other users in their companies.

Creating Global Address Lists

Creating multiple global addresses lists and defining the permissions for them is a little beyond the job scope for the typical reader of this book, but we want to cover some of the basics nonetheless. If you are sure you do not need custom GALs, then you can safely skip this section of the chapter.

So now you may be asking, If there are multiple global address lists in a single Exchange organization and if a user cannot select which one they are viewing, then how do you use them? The client (Outlook or Outlook Web Access) selects which GAL you see based on one of three criteria. The GAL is selected in this order:

1. The GAL to which the user has permissions is selected first.

2. If the user has permissions to more than one GAL, the GAL to which the user is a member is selected.

3. If the user has permissions to more than one GAL and is a member of more than one GAL, the largest GAL is selected.

You create and manage GALs entirely through the EMS. Therefore, you should be aware of the EMS cmdlets that manipulate GAL objects. If you have been studying the EMS cmdlets in much detail, then you probably already know the verb portion of the cmdlet and just need the noun. Table 11.1 shows the cmdlets that are used to manage GAL objects.

Table 11.1: Cmdlets Used to Manage Global Address List Objects
Open table as spreadsheet

Cmdlet	Explanation
New-GlobalAddressList	Creates a new global address list object
Get-GlobalAddressList	Retrieves a list of GAL objects or properties of a specific GAL
Set-GlobalAddressList	Sets properties of existing GAL objects
Update-GlobalAddressList	Updates recipients in the Active Directory so that they appear in this GAL if applicable
Remove-GlobalAddressList	Deletes a GAL object

If you want to retrieve a list of all the GAL objects, you can use Get-GlobalAddressList and see these results:

 Get-GlobalAddressList | Format-Table Name Name ---- Default Global Address List 

The real meat and potatoes of the GAL is the query, or filter, that is used to construct the membership list. There are a couple of properties of GAL objects that allow you to define the query that is used to construct the list. You can define a custom LDAP query, a recipient filter, or address list conditional properties. One conditional property of a GAL is the ConditionalCompany property. Let's do the Get-GlobalAddressList query again, but this time include these properties in a formatted list:

 Get-GlobalAddressList | Format-List Name,RecipientFilter,LdapRecipientFilter, ConditionalCompany Name                : Default Global Address List RecipientFilter     : (Alias -ne $null -and (ObjectClass -eq 'user' -or    ObjectClass -eq 'contact' -or ObjectClass -eq 'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistributionList' -or ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder')) LdapRecipientFilter : (&(mailNickname=*)(|(objectClass=user)(objectClass=contact) (objectClass=msExchSystemMailbox)(objectClass=msExchDynamicDistributionList) (objectClass=group)(objectClass=publicFolder))) ConditionalCompany  : 

First notice that the ConditionalCompany property was empty for this particular GAL. The LdapRecipientFilter property contains the filter that would be used if this GAL was being used by an Exchange 2000/2003 Recipient Update Service and maps to the Active Directory attribute purportedSearch. The RecipientFilter property is used by Exchange 2007 to apply membership to address lists; for you Active Directory fanatics out there, this property maps to the msExchQueryFilter attribute of the GAL object.

Let's take apart that RecipientFilter before we go any further and see what listing it is really generating. Inside of the inner set of parentheses, notice that the filter applies to any type of ObjectClass that is equal to (-eq) user, contact, system mailbox, dynamic distribution list, group, or public folder. This is almost every type of object in the domain, right? The filter narrows it down a little further by saying that the Alias property (the Exchange alias) must not be null. This means that the objects in question must be mail-enabled. Got all of that? Don't worry if it is a little fuzzy; creating multiple GALs is a very advanced topic and requires some practice.

Let's use an example now to further illustrate the concepts and practices of implementing more than one GAL. In this example, our company has just purchased a new company (Scully Surfboards) and has moved all of their mailboxes over to our organization's Exchange servers. However, the users from the company we just purchased are a little finicky and don't like seeing anyone in their global address list but their own little branch of the company. Granted, we could just give them their own Active Directory and Exchange server, but that might be a waste of hardware, software, and human resources. So we will create a GAL called Scully Surfboards. Here is the command:

 New-GlobalAddressList -Name "Scully Surfboards" 

All this command does is create a new GAL called Scully Surfboards; we did not even use any of the RecipientFilter or conditional filter properties. Let's say that we want anyone whose company name attribute is equal to Scully Surfboards to be in this GAL. We need to modify this GAL using the Set-GlobalAddressList cmdlet. The cmdlet needs to set the -ConditionalCompany property and it needs to set the -IncludedRecipients property. Since this list will only contain mailbox-enabled users, the -IncludedRecipients property only needs to have MailboxUsers. The following command will accomplish this:

 Set-GlobalAddressList "Scully Surfboards" -ConditionalCompany "Scully Surfboards" -IncludedRecipients "MailboxUsers" 

Now let's take a look at some of the properties that were created for this new GAL object.

 Get-GlobalAddressList "Scully Surfboards" | Format-List    Name,RecipientFilter,LdapRecipientFilter,RecipientFilterApplied, IncludedRecipients,ConditionalCompany Name                   : Scully Surfboards RecipientFilter        : (RecipientType -eq 'UserMailbox' -and Company -eq Scully Surfboards') LdapRecipientFilter    : (&(objectClass=user)(objectCategory=person) (mailNickname=*)(msExchHomeServerName=*)(company=Scully Surfboards)) RecipientFilterApplied : False IncludedRecipients     : MailboxUsers ConditionalCompany     : {Scully Surfboards} 

Notice that the RecipientFilter and LdapRecipientFilter properties were automatically generated even though we used a "precanned" filter.

Applying Global Address Lists to Mail Objects

In the previous example, we created a new GAL called Scully Surfboards. In an Exchange 2000/2003 environment, eventually anyone whose company name was equal to Scully Surfboards appear in this GAL. That was because there was a process called the Recipient Update Service (RUS) that took care of little housekeeping tasks like adding recipients to addresses lists. Many people that are new to Exchange may think that this sort of thing just magically happens, but there has to be some "back end" process that actually handles this.

Anyone that has fought RUS problems with earlier versions of Exchange will be happy to know that the RUS is no longer responsible for this task. Actually, the RUS has been retired from Exchange active duty permanently. When a new mailbox-enabled user is created by the Exchange Management Console, the cmdlet that creates the user evaluates each of the address lists available. The RecipientFilter and LdapRecipientFilter properties of an address list are examined to determine if the user being created should be included in that that particular address list. If the user should be included in the address list, that user's showInAddressBook attribute in Active Directory will include that particular address list name.

Intuitively, you might think that each time an address list is displayed, the query or filter is simply executed once again. It turns out that enumerating members of an address list is much more efficient if the address list information is stored with the mail-enabled object. Figure 11.2 shows the showInAddressBook attribute for a newly created mailbox-enabled user whose company attribute contained Scully Surfboards; the object was viewed using the ADSIEdit utility.

Figure 11.2: Viewing an mail-enabled object's showInAddressBook attribute

The value was stored in this attribute as the distinguished name of the GAL; in this example that name is as follows:

 CN=Scully Surfboards,CN=All Global Address Lists,CN=Address Lists    Container,CN=Volcano Surfboards,CN=Microsoft Exchange,CN=Services, CN=Configuration,DC=volcanosurfboards,DC=com 

That takes care of mail-enabled recipients that are created after the GAL is created. But what about mail-enabled recipients that are already in the Active Directory or ones whose company name is changed after they are created? This is the job of the Update-GlobalAddressList cmdlet.

If you know that GAL is out-of-date or not showing everyone it should, here is how you could update this:

 Update-GlobalAddressList "Scully Surfboards" 

If you wanted to update all of your recipients and all of the GAL objects, you could run these two cmdlets:

 Get-GlobalAddressList | Update-GlobalAddressList 

In an earlier EMS cmdlet, we showed you the properties of the Scully Surfboards address list. This included a property called RecipientFilterApplied. This property was set to False. Once we actually use the Update-GlobalAddressList to apply this address list to recipients, this will change to True. Here is an example:

 Get-GlobalAddressList "Scully Surfboards" | FL Name,RecipientFilterApplied Name                   : Scully Surfboards RecipientFilterApplied : True 

However, RecipientFilterApplied automatically goes back to False if we make any changes to any of its properties.

Applying Permissions to Global Address Lists

Thus far we have created a global address list called Scully Surfboards and made sure that anyone whose company name attribute is equal to Scully Surfboards will be included in it. However, when a user who is included in that address list logs on to Outlook or Outlook Web Access, they are going to be sorely disappointed because they will still see the default global address list. Why is that? Well, we have not yet changed the permissions on the default global address list, so the client continues to choose that one because it is the largest.

We now need to expand our example just a bit so that we can restrict who has permissions to which address lists. We need to do this with Active Directory security groups, and to do it right we need to create two security groups. We will define a group called View the Big GAL and a group called View the Scully Surfboards GAL. We will add the appropriate users to each security group; if a user is a member of both security groups, they will see the largest of the two GALs when they use Outlook.

The easiest way to edit the permissions on the GAL objects is to use the ADSIEdit utility from the Windows 2003 Support Tools. You will need to open ADSIEdit, browse down through the Configuration partition to Services, Microsoft Exchange, *Organization Name*, Address Lists Container, and All Global Address Lists. This is shown in Figure 11.3.

Figure 11.3: Using ADSIEdit to manage the permissions on a global address list

In Figure 11.3, we are looking at the Security properties of the Scully Surfboards GAL object. Notice that Authenticated Users has the Read and Open Address List permissions. Clear the Read and Open Address List check boxes in the Allow column for Authenticated Users; don't check the Deny permissions since that will override the permissions you are about to assign. Now add the View the Scully Surfboards GAL group to this list and assign that group Read and Open Address List permissions in the Allow column.

Now we need to do the same thing to the default global address list group; we must add the View the Big GAL group and allow that group Read and Open Address List permissions and we must clear the Read and Open Address List permissions from the Authenticated Users group.

This may seem like a bit of hassle to set up, but once you have started down this configuration path, it is easy to add additional GALs and to assign them permissions in the same way. One potential stumbling block that you will have to cross when you are creating multiple global address lists is that the default global address list allows authenticated users to access it. You must clear the Allow permissions for the Authenticated Users group; this will ensure that users do not see the default GAL in Outlook.