3.4 Mailboxes and user accounts

---

You must mail enable an AD account before you can use it to access an Exchange mailbox. The process of mail enabling means that you complete the set of optional attributes to let the AD know that the account now owns a mailbox in a store on an Exchange server and can receive email, including the name of the server that hosts the mailbox and the store that the mailbox is in. Other important attributes include:

• The set of email addresses used to send and receive email (SMTP, X.400, and so on), including the primary address of each type

• The LegacyExchangeDN attribute for backward compatibility with older versions of Exchange

• The showInAddressBook attribute to ensure that other users can see the new mailbox in the GAL and other address lists. The Recipient Update Services updates this attribute.

• The MailNickname (alias) attribute used to identify the mailbox by IMAP and POP clients among others

• The msExchMailboxSecurityDescriptor attribute that controls access to the mailbox

We will meet these attributes in different situations throughout the book. Chapter 10 discusses many of the issues you will meet to design and apply consistent naming standards for attributes such as email addresses, display names, and so on.

Figure 3.17: Creating a new mailbox.

Creating a mailbox (Figure 3.17) is a multiphase process, which flows like this:

• The administrator creates a new AD account and creates the mailbox at the same time, or he or she selects an existing account and invokes the Exchange Tasks wizard to create the mailbox. The left-hand screen in Figure 3.17 shows the dialog that Windows displays when you set up a mailbox as part of the account creation process, while the right-hand screen is the Exchange Tasks wizard.^[1] If you select the wizard option to create a mailbox, you end up back to the left-hand screen to answer the fundamental question: Which server and storage group will hold the new mailbox? Note that you can create mailboxes programmatically using ADSI to set up the basic account structure and then populate the mailbox attributes through the IMailboxStore interface of CDOEXM.

• At this point, the AD account contains a subset of the full set of mailbox attributes and the user cannot yet use the account to send or receive email. The Recipient Update Service (RUS) runs on a scheduled basis and completes the population of mailbox attributes by adding information such as the email proxy attributes (SMTP, X.400, and so on) to the account. At least one RUS job runs for each domain that supports Exchange servers.

• After RUS completes processing, the mailbox can receive new email, because the Exchange Routing Service is able to take incoming messages addressed to the mailbox and deliver them to the correct place. Up to this point, Exchange will reject any attempt to deliver a message to the mailbox, because it cannot resolve the address against the directory.

• The RUS is also responsible for including the new mailbox in the GAL by setting the ShowInAddressBook attribute to add the mailbox to the set of default address lists (unless you have set the attribute to hide the mailbox from the GAL). Users will not see new mailboxes in the GAL until the RUS successfully completes processing, which should take less than 15 minutes after you create the account. If you do not see a mailbox appear in the GAL after an hour or so, consider invoking a manual run of the RUS for the domain where you create the account. See Microsoft Knowledge Base articles 253828 and 327347 for more information.

• In terms of data structures in the mailbox store, Exchange does not fully instantiate the mailbox until the first user access to the mailbox or the first time that Exchange delivers a message to the mailbox. At this point, Exchange sets the mailbox rights (based on the access control entries in the msExchMailboxSecurityDescriptor attribute) on the mailbox's security descriptor in the Store. You will not be able to see the mailbox through ESM or ExIFS until the Store instantiates it as a response to a user logon or the delivery of new mail.

To force the pace, some administrators send an automatic message to the account soon after they create it to force Exchange to create the mailbox in the Store. While you might not be able to send a message by selecting the mailbox from the GAL, you can certainly send the message to the mailbox's SMTP address, since the Routing Engine is able to resolve the address by looking up the account immediately after the RUS has processed the account. You can consider using command-line utilities such as BLAT to create and send simple one-line messages as part of an automated mailbox creation process. Because of the mismatch between client and server MAPI components, do not install Outlook on an Exchange server just to test user mailboxes after you create them. If you want to connect to a user mailbox, use Outlook Web Access or Outlook Express instead.

Note that the first connection influences the names of the default folders that Exchange creates in the new mailbox. For example, if an English-language client connects, Exchange creates folders such as Inbox, Calendar, Sent Items, and so on, whereas if a Danish client connects, Exchange creates folders called Indbakke, Kalendar, and Sendt post. Many international companies have procedures to ensure that they create folders in the correct language immediately after they set up a mailbox or have Visual BASIC or other utilities to change folder names to another language afterward.^[2] To complete the process, the AD replicates the attributes of the new mailbox, such as its set of email addresses, to all Global Catalog servers in the forest.

3.4.1 Accessing Exchange attributes for mail-enabled objects

You work with Exchange-specific attributes through a set of property pages that Windows dynamically loads from code distributed with Exchange whenever you create or edit a mail-enabled object using AD Users and Computers. Exchange 2003 extends ESM so that you can move or delete a mailbox or configure it for the Exchange options. However, to change other attributes, such as updating mailbox quotas, you have to access the set of Exchange-specific property pages through AD Users and Computers. The pages are:

• Exchange General: This property includes the mailbox alias, the store where the mailbox is located (equivalent to the Home-MDB attribute in Exchange 5.5), delivery restrictions and options, and storage limits. Exchange 2000 introduced the concept of system policies, a way to create and apply a consistent set of policies to multiple objects. For example, you can create a system policy to control storage quotas for mailboxes and deleted item retention periods. Afterward, you can apply the policy to as many mailbox stores as you wish-all in a single operation. If you want, you can then override the effect of the system policy by selecting individual accounts to give them different limits. For example, you can update your boss's account so that he or she has a much larger limit than the norm!

• Email Addresses: These properties include all of the email addresses held by a mail-enabled object, including the proxy addresses used by SMTP and other connectors. As with Exchange 5.5, an object can hold multiple addresses of a specific type (such as Lotus Notes, X.400, or Exchange's own X.500 address type), but only one address of each type will be "primary" and used by the Routing Engine to direct messages across a connector. The other addresses of each type allow Exchange to accept and deliver messages sent to addresses that a user may have used in the past (otherwise known as "grandfathered" addresses). Do not delete any of these addresses without understanding the consequences, since you can easily disable a mailbox in this way. For example, if you have used the Move Server Wizard to move an Exchange 5.5 server to another site or organization in the past, you will find X.500 addresses. The Routing Engine uses X.500 addresses to process messages sent to old addresses, such as when it creates a reply to a message that someone originally generated when a server was in its old site or organization. The Routing Engine is able to check the address on these messages against the X.500 addresses in the directory and reroute the message to its new destination.

• Exchange Features: This property page is only available for Exchange 2000 servers running on Windows 2000. The properties allow the administrator to control which of the advanced features (e.g., the Exchange integrated version of Instant Messaging) a user is able to access. You must enable each one of the features before someone can use it. The default is to disable access to everything. Not many companies deployed the Exchange 2000 versions of Instant Messaging and Conferencing, so it is unlikely that you will do much work with this page. However, for Exchange 2003, Microsoft has moved the protocol settings from the Advanced Property page to the Exchange Features (Figure 3.18) page. In addition, this page allows you to control the new wireless functionality for a user, so the Exchange Features page is now far more useful.

  
  Figure 3.18: Exchange 2003 Features Property page.

• Exchange Advanced: These properties are only visible if you select the "Advanced Features" option from the view menu in the AD Users and Computers console. The properties include a flag to hide an object from address lists, custom attributes, protocol settings, and mailbox rights (Figure 3.19).

  
  Figure 3.19: Exchange 2000 Advanced Properties.

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 property pages (General, Telephone, Address, and so on). These properties are generic and can be set on any user or contact stored in the AD, even if they are not mail enabled. In mixed-mode environments, it is a best practice to use the Exchange 5.5 administrator program to work with Exchange 5.5 mail-enabled objects and ESM and AD Users and Computers to work with Exchange 2000/2003 equivalents.

Along with the property page extensions, Windows adds an entry for "Exchange Tasks" to the context-sensitive menu that is available when you work with user, contact, and group objects in AD Users and Computers (Figure 3.20). You can also work with mail-enabled accounts through the Exchange 2003 version of ESM.

Figure 3.20: Exchange Tasks added to the AD context-sensitive menu.

You can select multiple objects to work with, or just select one. When chosen, the "Exchange Tasks" option activates a wizard to present a set of tasks that you can execute. The tasks displayed depend on the type of mail-enabled object you select. If you select multiple objects of different types, the wizard will present you with a complete set of tasks that you could potentially execute against the type of objects you have selected, but you might select an inappropriate option for a certain object that the wizard cannot perform. Figure 3.21 shows the result of selecting a group, user, and contact together and then invoking the wizard. As you can see, some of the options presented here do not make much sense. For example, you cannot enable Instant Messaging for a mail-enabled contact or hide membership for a user.

Figure 3.21: The Exchange Tasks wizard.

Common tasks for a user include:

• Moving a mailbox to another store, including a store on a different server in the same or different administrative group

• Deleting a mailbox, which turns the user object into a non-mail-enabled user

• Enabling or disabling Exchange features, such as Instant Messaging (Exchange 2000) or Exchange Mobile Services (Exchange 2003)

Common tasks for a group include:

• Hiding or revealing group membership. This means that Exchange alters the security descriptors on the group to prevent users from seeing who is a member of the group. From an Outlook perspective, it prevents users from selecting the group from the GAL and seeing members listed when Outlook views the properties of the group, as shown in Figure 3.22.

  
  Figure 3.22: Hidden group membership.

• Deleting email addresses or designating a distribution list. The first option removes any existing email addresses that are set for the group, effectively stopping people from using the group to distribute messages. The second option adds an alias for the group, but you may need to add some specific address proxies for the group (such as an appropriate SMTP address) after you designate it as a distribution list before the list is fully effective.

Common tasks for a contact include:

• Deleting or enabling email addresses. Deleting email addresses removes contacts from the GAL, while enabling addresses will allow you to specify the types of address (X.400, SMTP, and so on) and their values for the contact.

3.4.2 Moving mailboxes

The Task Wizard usually performs actions instantaneously, assuming a fast connection between your workstation and the server. Moving a mailbox is the obvious exception, since it requires Exchange to transfer messages to another mailbox store, which might not be on the same server as the source. Depending on system load, moving large mailboxes (>100 MB) will take between five and ten minutes to perform if the two servers share the same LAN, up to approximately 500 MB an hour. Moving a mailbox is a binary operation-it either works or it does not. If a failure occurs somewhere along the process, you have to start again. Note that you need Exchange administrator permission for the administrative group for both the source and target server to be able to perform the move.

Figure 3.23: The Exchange 2003 Move Mailbox wizard.

Always make sure that you ask the mailbox owner to log off before commencing the move, and ensure that enough disk space is available to accommodate all the transaction logs that the move operation generates. Each transferred message is a transaction for both the source and target databases, so the disk that holds the transaction logs will handle a substantial I/O load during the transfer. Exchange 2003 improves move mailbox operations (Figure 3.23) as follows:

• You can now move mailboxes from both the ESM and AD Users and Computers consoles, whereas previously you could not move mailboxes from ESM. Because you can now run ESM on Windows XP workstations, you do not need to use servers to drive the migration process.

• The wizard can continue processing and move the mailbox even if it encounters some corrupt messages in the mailbox-the administrator is able to decide how many corrupt messages the wizard should skip, up to a hard-coded limit of 100. Clearly, if you meet a mailbox that has many corrupt messages, it is a sign that the underlying mailbox store is probably suffering from some sort of corruption that deserves your attention. Note that if the wizard skips any corrupt messages, it generates a report to show you what those messages are.

• You can move multiple mailboxes concurrently by selecting multiple mailboxes and then taking the "Move Mailbox" option. Exchange uses up to four threads per session to move mailbox content. As a guideline, expect to take approximately an hour to move a 500-MB mailbox, depending on system load and server capabilities.

• The Exchange 2003 version of Move Mailbox is much faster than Exchange 2000. According to Microsoft, because operations use up to four separate threads, things move about four times faster, but the actual results you achieve will vary according to environment. You can see the multithreaded nature of operations by selecting multiple mailboxes and moving them together (Figure 3.24). Of course, you can achieve further acceleration by using multiple workstations to move mailboxes.

  
  Figure 3.24: Moving mailboxes.

• You can schedule moves to occur at a particular time. The System Attendant tracks and performs scheduled jobs at the requesting time, allowing you to ensure that mailboxes move when users are asleep!

• If users run Outlook 2003 and have a cached-mode mailbox, it is possible to continue working while Exchange moves their mailboxes. Exchange will not deliver new messages to the mailbox and queues them on the source server while the move proceeds. When it has moved the mailbox, Exchange releases the messages and delivers them from the queue. Exchange notifies Outlook when the moved mailbox is ready to use, and Outlook then switches across (transparently) to access the new server and then transmits any messages that the user sent during the mailbox move. While it is possible to move Outlook 2003 users who work in cached Exchange mode, it might be tempting fate. Therefore, it is still a good idea to have users disconnect before the move starts and, if they use Outlook 2003, to have them set their connection status to "Work Offline." In addition, if a user attempts to log on during a mailbox move (as opposed to continue working during the move), the Store detects the connection attempt and logs event 9660, identifying the user name and distinguished name. The Store also flags an error to tell the user that a mailbox move is under way.

After a mailbox move, Exchange informs Outlook clients of the new server name to allow these clients to update their MAPI profile. Exchange redirects Outlook Web Access connects to the new server at the next connect, but you have to update settings manually for IMAP4 and POP3 clients.

In some cases, administrators report that newly moved mailboxes use larger quotas than the original. This is anecdotal evidence that is not consistent from server to server, but it is a good idea to check mailbox quotas before and after the move to ensure that users can keep working. Overall, the net impact of the changes to the move mailbox feature is that it is easier to move mailboxes between servers, but it is an activity that you have to plan carefully.

The Exchange Task wizard captures details of its processing in log files, which it saves automatically in the \My Documents\Exchange Task Wizard Logs folder for the account that you use to run the wizard. The log files are in XML format, which is fantastic for everyone who can read and visualize XML format but remains a challenge for most people. Fortunately, you can apply style sheets to interpret the XML content and display it in a more understandable format. You can do the work yourself or ask your local Microsoft contact to help. In either case, after you have the style sheet, you can edit the XML report and insert the reference to the style sheet immediately after the first line in the file. For example:

<?xml version="1.0" encoding="unicode"?> <?xml-stylesheet type="text/xsl" href="c:/exchsrvr/ TaskWizardReport.xslt"?>

In this case, we reference a style sheet called TaskWizardReport.xslt style in the indicated directory. You can see the effect of such a transformation by comparing the top and bottom screens in Figure 3.25. The top figure is the raw XML content generated by the Task wizard, while the bottom is the formatted result.

Figure 3.25: Viewing Task wizard reports.

^[1] . The Exchange setup program installs the Task wizard when it installs ESM. If you want to manage Exchange on another server or workstation, you need to install ESM there. The version of ESM provided with Exchange 2000 does not run on Windows XP workstations, but the version supplied with Exchange 2003 does.

^[2] . Although the original Exchange client included this feature, Outlook, Outlook Web Access, and Outlook Express do not allow you to change the names of the default folders.

---