11.2 Recipient policies

---

Recipient policies are organization-wide objects held in the "Recipient Policies" container, a subcontainer of "Recipients." The Exchange installation program creates a default policy and you can create as many policies as you want thereafter, although you must keep the default policy and cannot delete it. The major functions of recipient policies are as follows:

• Set the default value for the domain name used by Exchange to reference files via IFS (for example, hp.com). The default policy holds this value. Do not change this value.

• Control the generation of email proxy addresses: The Recipient Update Service (RUS) generates and sets email addresses on new mail-enabled objects, but you define the format for the addresses and the type of proxy addresses that the RUS generates through recipient policies.

• Control how the Mailbox Manager processes mailboxes.

• Enable SMTP virtual servers to accept incoming email for a domain. When you install Exchange, the SMTP virtual servers will accept email for the domain defined in the default policy, but you can add policies to cover additional domains if you want Exchange to accept incoming email for those domains.

Figure 11.4 shows a comprehensive set of recipient policies as viewed through ESM. In this case, a separate recipient policy exists for a number of country-level groups plus one for corporate users. You can have as many recipient policies as you like, providing that you can identify the target users with an LDAP search. Exchange uses the LDAP search when it applies the policy to the users. However, you can use the default recipient policy (or create another one) and apply that to every mail-enabled object in an organization, a situation that usually exists in small organizations. ESM groups recipient policies in priority order, and you can move the policies up and down in the order. In Exchange 2000, ESM allowed you to define multiple policies at the same priority, but Exchange 2003 now assigns a number to each policy to indicate its order of precedence.

Figure 11.4: Recipient policies.

Exchange applies policies in priority order, so it is possible to create a policy that Exchange cannot apply, simply because a higher-priority policy takes precedence. It is quite normal to give the default policy the lowest possible priority to ensure that Exchange always applies first any policy that you want to apply for specific administrative groups or other groupings.

You edit a recipient policy by selecting and then double-clicking through ESM, or create a new policy by clicking on the Recipient Policies root and then select the "New…Recipient Policy" option. Older policies created before the Mailbox Manager was available may display only the property pages that collect administrative data (Details), control email address generation (Email Addresses), and establish the name of the policy and the target objects (General). You can add the property page to control the Mailbox Manager by selecting the policy and then selecting the "Change Property Page" option from the context-sensitive menu. Figure 11.5 illustrates how you define email addresses in a recipient policy (left-hand screen) and how to identify target objects through an LDAP query (right-hand screen).

Figure 11.5: Email addresses and LDAP query in a recipient policy.

Administrators implement default values for email address proxies by creating policies, defining the properties of the policies, and then defining LDAP queries to identify the mailboxes, accounts, or groups that Exchange applies the policies to. A mail-enabled object may have many different email proxies, including multiple values for the same type. However, you always have a primary address for each address type, and Exchange puts the primary address type in a message envelope when it leaves the organization. For example, an account may have multiple SMTP address proxies, because an organization has changed its name through merger and acquisition and you want to "grandfather" the older SMTP addresses so that Exchange can still deliver messages sent to those addresses. Thus, while my current primary SMTP email address in HP's Exchange organization is [e-mail], the AD still holds [e-mail] and [e-mail] as alternate SMTP proxy addresses for my account. Storing multiple proxy addresses allows correspondents who may have the old addresses in their header to reply to messages from me; they can continue to use one of my old email addresses because that is how they know me. Because it is the current primary SMTP address, Exchange stamps [e-mail] on all my outgoing messages. Of course, there is no point in defining addresses for domains if you do not have the necessary MX records in place to allow external servers direct email to your servers.

For incoming email, Exchange checks every possible email address held for users in the AD before it concludes that it cannot deliver a message, and, since the AD indexes proxy addresses, the check is very fast. As long as the AD stores the grandfathered email addresses as secondary SMTP proxies, Exchange is able to deliver incoming messages sent to these old addresses. This is a very useful feature, because it is quite possible that correspondents will send email to an address that they have in their address book, or by reference to an old business card, or by simply replying to an old message of yours that they have in their mailboxes. If Exchange did not support multiple proxy addresses, you would have to ensure that everyone knew your new email address and used it each time that the organization's name changed.

Some companies allow their users to define "vanity" email addresses as secondary SMTP proxy addresses, much as you can buy vanity license plates for cars. If I wanted to, I could ask my administrator to set up a proxy address such as [e-mail] and Exchange would treat this address with the same importance and validity as any other address.

Given the importance of SMTP as the primary mail transport for Exchange, most attention is usually dedicated to getting the SMTP address right, although the X.400 address is also important for routing if any legacy servers or connectors are used inside the organization. From a historical perspective, Exchange 5.5 and earlier versions use Site Addressing Defaults to define the default format for email proxies.

The right-hand screen in Figure 11.5 shows the LDAP query that Exchange uses to identify the set of Active Directory objects when it applies the policy. In this case, the LDAP query searches for all mailboxes on a named server. LDAP query syntax is reasonably complex, but you do not have to build the query by hand. Instead, the "Modify" button invokes a dialog (Figure 11.6) to collect search parameters. You can test the query with the "Find Now" button to ensure that the search finds the correct objects, and when you are happy, you can save the LDAP query with the "OK" button and return to the recipient policy. Just as with any LDAP query, it is best to be as exact as possible in the way that you reference fields. For example, in the example shown, the query looks for any entry where the Country field starts with "Ireland." We know that Ireland is unlikely to change its name anytime in the future and the name of no other country begins with Ireland, so setting up a search like this will return the right results but in a much slower fashion than if we use a query such as "Country is exactly Ireland."

Figure 11.6: Building a search query.

While the example shows an LDAP query that selects mailboxes from a specific server, it is far more common to create recipient policies for specific administrative groups.

11.2.1 Generating SMTP addresses

Recipient policies control the generation of SMTP addresses for mail- enabled objects through a pattern of replacement strings plus the email domain as laid down in the policy. For example, Figure 11.5 defines a pattern of [e-mail]. In this case, "%g" means "insert given name," while "%s" means "insert surname," so the default SMTP address implemented by this policy is "first [e-mail]." Table 11.1 lists the set of valid replacement strings.

Table 11.1: Replacement Strings for SMTP Address Generation

Replacement String	Meaning
%s	Insert surname (last name)
%g	Insert given name (first name)
%i	Insert middle initial
%d	Insert display name
%m	Insert Exchange alias
%rxy	Replace all occurrences of character "x" with character "y"

In addition to the basic strings, you can instruct Windows to use a specific number of characters by prefixing the string with a numeric value. For example, %3g means take the first three characters of the given name, %6d means take the first six from the display name, and so on. Exchange ignores invalid characters (as defined in RFCs 821/822) when it generates an SMTP address.

In the case of John Doe (first name = John, last name = Doe, display name = John Doe), the following replacement strings generate the email addresses shown:

[e-mail]	[e-mail]
[e-mail]	[e-mail] (space removed as invalid character)
[e-mail]	[e-mail]
[e-mail]	[e-mail] (space removed by string)

The Recipient Update Service will apply the updated policy the next time it is active.

11.2.2 Changing display names

While you can define and apply different patterns for email addresses through recipient policies, you cannot do the same for display names. The default pattern for display names is %g %-in other words, first name <space> last name, or Tony Redmond. This is acceptable for small implementations, where everyone knows each other and it is easy to find the correct recipient by browsing the GAL, but problems occur as the number of directory entries increases. On balance, more variation occurs in surnames than given names and users are accustomed to look through telephone directories by surname, so it makes sense to organize the GAL by surname. Think of a common given name, such as "John" or "Mary," and imagine how many times they occur in a large GAL. If the GAL is sorted by given name, you might have to look through several hundred entries before you locate the right recipient. It is easier to search using a surname, even with common surnames, such as "Smith" or "Ng."

Exchange builds the GAL from AD data, including display names. You can change the pattern AD uses to create display names by altering the properties of the user-display attribute of the Display Specified object in the configuration naming context with the ADSIEDIT utility. Follow these steps to make the change:

• Log on to an Enterprise administrator's account.

• If not already loaded, install ADSIEDIT and load it into an MMC console.

• Select the "cn=DisplaySpecifiers" node and expand it. Underneath, you will find entries for the entire set of locale IDs installed in the forest. Each locale ID has a separate value. Id = 409 is the identifier for U.S. English. Computers in multilingual environments support multiple locales. For example, id = 412 is the locale for Korean.

• ADSIEDIT lists the properties of the locale ID in the right-hand pane. Find the cn=user-Display attribute and click on it to select, then select the Properties option from the context-sensitive menu to display the properties of the object.

• Select the createDialog property. This is an optional property.

• Set the attribute to be %<sn>, %<givenName> and then click OK to close the dialog and write the pattern into the directory. See Figure 11.7 for an example of how to input the pattern.

  
  Figure 11.7: Changing the user display name default format strings.

You can achieve similar results for new contacts by editing the create- Dialog property for the contact-display attribute for groups by editing the group-display attribute and for iNetOrgPerson objects by editing the iNet- OrgPerson-display attribute. Few organizations alter the pattern for groups, but if you alter the pattern for user objects, you should also change the pattern for contacts. Otherwise, you will end up with contacts that follow a different sort order interspersed with users in the GAL.

Test that the change is effective by creating a new user. Complete the surname and given name fields and check that AD builds the full name field according to the new pattern. As shown in Figure 11.8, the pattern works. If you made a mistake when you entered the pattern, such as omitting the leading % sign for a value, or not terminating a value with a closing ">", the error will be obvious, since AD will be unable to correctly create the full name field.

Figure 11.8: Ensuring that the new default format works.

Windows automatically replicates updates to the AD configuration naming context throughput the forest, so the new pattern will become active as soon as replication completes. You can create a pattern based on any LDAP attribute held for an object (e.g., %<initials>), but, clearly, you should only use attributes that are provided when a user object is initially created. Any change made to impose a new pattern for user display names will not affect previously created user objects, so you will either have to change these objects individually or use a tool such as HP's LDSU to extract details of the objects, impose the new pattern, and then apply the change to the AD. Similar tools can be used if you need to change SMTP addresses (such as in the case of a merger or acquisition project) or to add secondary SMTP addresses. If you change SMTP addresses for any reason, it is best practice to grandfather the old SMTP addresses for at least one year after the changeover so that messages sent to old addresses can still be delivered.

Note that the display name pattern only governs the creation of objects, and you can change the display name afterward to input any value you like. For example, you could include a department name, location, job title, or other identifier to help resolve users that share the same name:

Smith, John (Glasgow) Smith, John (Security Department) Smith, John (VP, Technology)

---