The Microsoft Exchange Server Recipient Update Service (RUS) is responsible for generating mail proxy addresses for mail-enabled objects inside an Exchange organization. Typically, this service requires little or no changes to its default settings. Still, there are situations in which a tweak or two might benefit your implementation, and if you know how the RUS does its magic, you'll be ready for action.
Getting the Mail Through
Exchange 2000 Server and later depend on Active Directory (AD). To mail-enable a user, contact, public folder, message store (i.e., database), or group (including Exchange Server 2003's query-based Distribution Groups—DGs), you must create new attributes for the corresponding AD object. Windows populates some of these attributes (e.g., the attribute that specifies the distinguished name—DN—of the mailbox store that houses the user's mailbox) when you create or edit a mail-enabled object through the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. But an object doesn't become a fully mail-enabled Exchange object until the RUS detects that you've created or updated the object in AD. The RUS examines the new or changed object and applies the appropriate recipient policy to populate any missing attributes and to ensure that the object has at least one valid email address.
Currently, the most basic email address for an Exchange object is the SMTP address, which the mailbox uses to communicate over the Internet. Users might need other addresses, called proxy addresses, to connect to IBM Lotus Notes or X.400 systems or to send and receive faxes. To generate proxy addresses for mail-enabled objects, the RUS refers to recipient policies, which determine the type and format of addresses that the mail-enabled object needs. In Exchange Server 5.5 and earlier, the closest functional component to the RUS was site addressing defaults. The big difference between these components is that site addressing defaults is limited to objects belonging to the site, whereas the RUS and the recipient policies that it processes apply throughout the organization and are much more flexible in terms of the objects to which the policies can apply.
AD holds a mail-enabled object's addresses in a multi-valued string attribute called proxyAddresses, in the format type:address (e.g., SMTP:Tony@Tony.Net). Figure 1 shows the properties of a mail-enabled AD object. Note that some entries in the Type column are in uppercase. When an address entry's Type is in uppercase, Exchange regards that address as the primary address for that type. There can only be one primary address per type; Exchange uses that address as the default reply address for outgoing messages. Entries with lowercase Type values are deemed to be secondary addresses, which Exchange checks when it resolves the header on an incoming message to determine whether the message can be delivered to a mailbox within the organization. You can create a secondary address only when the object already contains a primary address of the same type. In addition, every user object must have a primary SMTP address (similar to the Exchange 5.5 requirement that every object have an X.400 address).
Companies that have been through a merger or a renaming or rebranding process often need to preserve old email addresses as secondary SMTP addresses so that external correspondents can continue using the old addresses. Over time, you might end up removing these old addresses (if only to reduce spam), but leaving them in the AD object's properties does no harm. You might also see secondary addresses used for special purposes. Exchange Mailbox Manager uses the MBX address type to track the mailboxes that it processes; Exchange uses the X500 address type to track old email addresses that might still exist in user mailboxes but that are no longer used inside the organization. For example, the Exchange 5.5 Move Server Wizard changes the DN of mailboxes as servers move between sites or organizations. The AD (through the Active Directory Connector— ADC) preserves these addresses so that users can reply to old messages that hold old addresses in their headers.
Apart from generating the correct addresses for mail-enabled objects, the RUS also ensures that the objects appear in the correct address lists. You want user objects, contacts, and groups to appear in the Global Address List (GAL), but you probably don't want public folders or message stores to appear there. The RUS hides the latter objects unless you specifically mark their properties to instruct the RUS to include them in the GAL. (A hidden object's msExchHideFromAddressList attribute is set to TRUE.) The RUS also populates a certain set of AD attributes, which Table 1 lists, that must be set if mail-enabled objects are to function correctly. As I mentioned earlier, some of these attributes are populated automatically when you create a mail-enabled object through the Active Directory Users and Computers snap-in. The RUS fills in any missing or incomplete attributes to ensure that all the necessary data exists to allow mail to flow smoothly. In addition, when the RUS finds a group that has hidden membership, the RUS adds non-canonical access control entries (ACEs) to the group object's ACL. These entries let Exchange servers expand the group membership for mail delivery, while preventing users from viewing the expanded data.
Each email address must be unique across the entire Exchange organization. When you create an address through the Email Addresses tab of a user object's Properties dialog box, Active Directory Users and Computers calls the appropriate proxy-generation DLL for the address's type, to ensure that the address is properly formatted. At the same time, the DLL generates an LDAP query that determines whether the proposed address is unique. (This process accounts for why creating new user-object email addresses can sometimes be slow within large deployments.) The policies that the RUS applies ensure that the addresses that it generates are properly formatted. The RUS also performs checks for address uniqueness.
Prev. page
[1]
2
next page 
