Creating Exchange 2000 Mailboxes

In Exchange Server 5.5, account creation is straightforward: Exchange 5.5 controls its own directory, controls mailbox objects, and uses Windows only to authenticate users. But Exchange 2000 Server integrates tightly with the OS through Active Directory (AD), and the security model and mailboxes are logical extensions to user accounts. Thus, Exchange 2000 administrators need to understand the interaction between Exchange and Windows that creates a mail-enabled account complete with a mailbox in an Exchange store and a full set of email addresses.

Creating Exchange Mailboxes
In Exchange 2000, the simple rule is that you must mail-enable a Windows account before it can access an Exchange mailbox. Mail-enabling an account involves specifying which server will host the account's mailbox and configuring a set of optional attributes to let AD know that the account now has a mailbox and can receive email. These attributes include

To create a mailbox, you use the Exchange Task Wizard either when you're creating the new AD account or by selecting an existing account, then starting the wizard. The Exchange 2000 setup program installs the Exchange Task Wizard when it installs the Exchange System Manager (ESM) console; you need to install ESM separately on any other Windows 2000 servers or Win2K Professional workstations that you want to use it on. The version of ESM provided with Exchange 2000 doesn't run on Windows XP workstations; the release of Exchange Server 2003 (formerly code-named Titanium), scheduled for release in mid-2003, will resolve this problem.

To set up a mailbox when you create an account, select Create an Exchange mailbox in the New Object — User window, then specify the server and storage group (SG) that will hold the new mailbox. To create mailboxes programmatically, you use Active Directory Service Interfaces (ADSI) to create the basic structure in AD, and Collaboration Data Objects for Exchange Management (CDOEXM) or Exchange Management Objects (EMO) to populate basic mailbox attributes (e.g., the store in which the mailbox resides) through the IMailboxStore interface.

After you create a mailbox, the Recipient Update Service (RUS) completes the population of mailbox attributes by adding information such as the email proxy attributes (e.g., SMTP, X.400) to the account. A separate RUS job runs for each domain that supports Exchange 2000 servers. After RUS completes processing, the Exchange Routing Service can deliver to the proper server all incoming messages that are addressed to the mailbox and the mailbox can receive new email.

The RUS is also responsible for including the new mailbox in the GAL. Users won't see new mailboxes in the GAL until the RUS completes processing—typically within approximately 15 minutes of creating the account. If after an hour or so you don't see a mailbox, consider manually running the RUS for the domain in which you created the account. See the Microsoft articles "XADM: How the Recipient Update Service Populates Address Lists" (http://support.microsoft.com/?kbid=253828) and "XADM: Cannot Resolve New Mailbox Address" (http://support.microsoft.com/?kbid=327347) for more information about how the RUS works and why assigning every Exchange 2000 server to the right RUS is important.

In terms of adding rows and tables in the Store database, Exchange doesn't fully create the mailbox until the user attempts to access it or Exchange delivers a message to it, whichever occurs first. Then, the Store sets the mailbox rights (based on the access control entries—ACEs—in the msExchMailboxSecurityDescriptor attribute) on the mailbox's ACL. You can't see the mailbox through ESM or on the M drive (the drive the Exchange Installable File System—ExIFS—maps) until Exchange creates it.

To force Exchange to promptly set up the mailbox in the Store, some administrators send an automatic message to new accounts immediately after creating them. You might not be able to send a message by selecting the mailbox from the GAL, but you can send the message to the mailbox's SMTP address. The Exchange routing engine can resolve the SMTP address against AD as soon as the RUS has stamped the email addresses on the account. If you automate the mailbox-creation process, you can use a command-line utility such as Blat or Mapisend to create and send a simple one-line message as part of the process. (Blat is a command-line SMTP mail-sending tool that you can download from http://www.winsite.com/winnt/netutil/page2.html; Mapisend is available in the Microsoft Exchange 2000 Server Resource Kit.)

The first client to connect to the mailbox influences the names of the default folders that Exchange creates in the new mailbox (e.g., Inbox, Calendar, and Sent Items for an English-language client; Indbakke, Kalendar, and Sendt Post for a Danish-language client). Many international companies ensure that folders are created in the correct language immediately after a mailbox is set up. To complete the process, AD replicates details about the new mailbox to all Global Catalog (GC) servers in the forest.

Recipient Update Service
The RUS runs as part of the System Attendant process. Two types of RUS services operate in an Exchange organization. One service processes Exchange system objects (e.g., servers) in the Microsoft Exchange configuration container and permissions that the delegation wizard sets for the container. The other service handles recipients in each domain within the organization.

Because all servers across the organization share one configuration container, only one RUS service is required to process systemwide objects. However, you need at least one RUS service per domain to process recipients. For large or distributed domains, you might need to use multiple RUS services. If you create many mailboxes at once, consider spreading the processing load across several RUS threads by setting up multiple RUS services in the domains that host the mailboxes. Remember that a mailbox won't be fully enabled until a RUS thread has processed it. To execute a specific RUS thread immediately, you can right-click the RUS object in ESM and select Update Now.

Figure 1 shows the ESM window for an organization that has two RUS services in use. One service (HPQNET) is configured for the domain in which the Exchange servers are installed. The other service (Enterprise Configuration) stamps attributes on the system objects. If you right-click the RUS and select Properties, you can view the domain that the RUS service is responsible for, the name of the server that performs RUS processing, and the name of the domain controller (DC) that the RUS uses when it needs to read and write AD data.

RUS operates on a schedule, which the Update interval property on the RUS Properties page identifies. The default value, Always run, directs RUS to wake up every 15 minutes and look for items to process. Other values for this property range from running the service immediately to never running the service. Typically, you'll use the Never run option only if you need to move RUS processing from one server to another.

The Exchange installation procedure creates the RUS service for a domain when you install the first Exchange server in the domain. That server hosts RUS processing and maintains the address lists for mail-enabled objects in the domain. Exchange also selects a DC, which must be a GC server, to act as the source of AD data for the new RUS. You can use the Browse buttons on the RUS Properties page to move RUS processing to another Exchange server or to select another DC. The Exchange Help text recommends that you select an Exchange server running on a DC to minimize network overhead. However, best practice for enterprise installations is to avoid running Exchange on a DC, and especially on a GC server. A better alternative is to move RUS processing to a GC server that's in close network proximity to the Exchange server that hosts RUS for a domain.

If multiple DCs and Exchange servers exist in a domain, you can divide RUS processing by creating multiple RUS services for the domain. For example, if you operate one worldwide domain with Windows sites in Australia and the United States, you might create separate update services in both countries to avoid any possibility that RUS can't fully activate a new account because it can't communicate with a remote DC. However, don't rush to create multiple RUS services for a domain unless you must. AD replication is complex enough without increasing the number of contributors to the replication puzzle.

Accessing Exchange Mailbox Attributes
After RUS has fully activated mailboxes, you can see and update details about the mailboxes through the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. You can do everything for Exchange 5.5 through one administration program. But Exchange 2000 depends heavily on AD to hold information about users, so you need to use the ESM console to perform server-centric tasks and the Active Directory Users and Computers snap-in to perform user-centric tasks. Exchange 2000 mailboxes aren't distinct objects in a directory. Rather, they're represented by extended attributes for AD account objects that you've mail-enabled. Logically, both implementations point to the mailbox contents in the Store, so the difference between Exchange 2000 and Exchange 5.5 lies in where each version keeps information about mailboxes.

When you select a mail-enabled account in the Active Directory Users and Computers snap-in, Windows dynamically loads code that creates and displays on the Properties page additional tabs that show Exchange-specific attributes. If the account isn't mail-enabled, you won't see these tabs. Figure 2, page 10, shows the four additional tabs for mail-enabled accounts.

The properties on the Exchange General tab include the mailbox alias, the server and Store in which the mailbox resides (equivalent to Exchange 5.5's Home-MDB attribute), delivery restrictions and options, and storage limits. Exchange 2000 system policies let you define storage limits and deleted-item retention periods. When a policy is complete, you can apply it to as many mailbox stores as you want in one operation. You can override the effect of a system policy by giving different limits to individual accounts. For example, you can update your boss's account so that he or she has a much larger limit than other users do.

The E-mail Addresses tab shows all the email addresses that a mail-enabled object holds, including the proxy addresses that connectors use. As in Exchange 5.5, an object can hold multiple addresses of a specific type (e.g., SMTP, X.400), but only one address of each type is the primary address that's used for routing. Don't delete any addresses without understanding the consequences; you can easily block a mailbox from receiving any incoming email. For example, the routing engine uses X.500 addresses to process messages sent to old addresses, such as an address used to reply to a message that was generated when a server that you've moved was in its old site or organization. The routing engine can check the address on such a message against the X.500 addresses in the directory and reroute the message to its new destination. If you delete the X.500 address, the routing engine can't reroute messages sent to the old address.

The Exchange Features tab lets you control which of the advanced features installed in the organization (e.g., Exchange-based Instant Messaging—IM) a user can access. You must enable a feature before the user can access it. By default, optional features are disabled. Few companies deployed the Exchange 2000 version of IM and conferencing, so you're unlikely to use this page much. However, Exchange Server 2003 moves the protocol settings from the Exchange Advanced Properties page to Exchange Features and uses that tab to let you control the new wireless functionality for a user.

The Exchange Advanced tab is visible only if you select the Advanced Features option from the View menu on the Active Directory Users and Computers snap-in. As Figure 2 shows, the properties on this tab include Custom Attributes, Protocol Settings, Mailbox Rights, and a flag to hide an object from address lists.

You can find many of the other properties that you can set for Exchange 5.5 mailboxes, such as telephone numbers and organizational information, on other tabs (e.g., General, Telephones, Address). These properties aren't specific to Exchange, and you can set them on any user or contact that's stored in AD, even if the user or contact isn't mail-enabled.

Compared with Exchange 5.5, Exchange 2000 mailbox creation is more complex. Understanding the process will help you determine where problems are likely to occur, then resolve them.