10.2 User access

---

Users are the most important part of any system, and perhaps especially so in the case of systems that automate common office tasks and enable better people interaction. Without users, there is simply no point in running an electronic messaging system. Actually, setting out with a goal of "managing" users is probably the wrong attitude for a system administrator to have. The people who connect to mail servers are consumers of a service. As with any other consumer, users have the right to expect that Exchange will deliver a service in a reasonably predictable manner and that they will not go through too much pain to access and employ the service. Anyone who has ever managed a mail server knows that you have to register people in some way before they can use the system. Exchange is no different in this respect. You have to set up users with a mailbox and allocate them some quota to hold their messages, establish the email addresses that they can use for external communication, and determine the protocols they can use to connect to Exchange. The AD holds the details of users, contacts, groups, and public folders (Figure 10.6), and you can manipulate these objects like any other AD object. The objects that are important to Exchange are:

• Mail-enabled users: This is the most common type of mail-enabled object. Everyone who wants to use Exchange to send and receive interpersonal messages must be able to access a mailbox. With the appropriate permissions, you can access multiple mailboxes as well as have people processing email on behalf of other users. Windows 2003 introduces support for the iNetOrgperson object, which you may need to create instead of user objects to interoperate with LDAP- enabled applications that depend on such objects. iNetOrgperson objects only exist in a full-function Windows 2003 forest and are a variation on the user object supported since Windows 2000, so you can think of it as a user object with some extra attributes. If you mail-enable an iNetOrgperson object, Exchange treats it in the same way as a user object.

• Mail-enabled groups (distribution lists): A group is a collection of recipients of any valid type. When you send a message to a distribution group, Exchange expands the group and sends a copy of the message to each recipient.

• Mail-enabled contacts: Recipients on other email systems that you can address from Exchange—for example, an Internet user who receives mail via SMTP, or someone who receives messages sent via an X.400 link between Exchange and another SMTP-compliant messaging system, such as America Online (AOL).

• Mail-enabled Public folders: You can mail-enable public folders to allow users to post information into the folders by sending them email.

Figure 10.6: Users, contacts, and groups in the Active Directory.

You can place mailboxes, groups, and contacts in any organizational unit within the AD, or use AD Users and Computers to move them between organizational units within the same domain by simply selecting the object and then selecting the Move option and the organizational unit to receive the object, as shown in Figure 10.7.

Figure 10.7: Moving to another organizational unit.

Organizational units are more than just a subdivision of the AD. They play an important role in how you implement security within a Windows environment, since you typically use group policy objects to apply security settings at the level of an organizational unit. It is important to have enough organizational units to be able to apply proper security at a sufficiently granular level, but it is also important not to have too many organizational units, since this will result in an overly complex structure within the directory. Best practice is to limit the depth of organizational units to no more than four from the domain root. Every company is different, and requirements vary greatly, but some good general recommendations for organizational unit design are:

• Base the top level of organizational units on something that makes sense for your company. If you organize the company on a geographical basis, then use location names. Figure 10.6 shows an example in which organizational units map countries as the basis for the hierarchy.

• You can then create subsequent levels to establish subgroupings within the major organizational units. Sometimes, the decision on how to do this is easy, since there already are well-established departments such as marketing, sales, HR, and so on. In Figure 10.7, we are moving an object into the "Marketing" organizational unit.

• Use names that make sense. The current set of administrators may understand code names for departments, locations, or buildings, but this is not necessarily going to be the case for new administrators who join the company in the future. There is no need to save a couple of bytes by shortening names to codes, so try not to do it. Users never see the organizational unit names.

Another point to remember is that organizational units provide a great basis to enforce standards through group policy objects.

10.2.1 Creating accounts and mailboxes

After you have the organizational unit structure designed, creating new user accounts is easy. The AD schema is extended with the necessary attributes to support Exchange when you install the first Exchange server in the forest or when you run the /ForestPrep option for the setup program. Afterward, the property pages required to add an Exchange mailbox and to define properties such as email addresses and mailbox quotas are automatically available whenever you work with accounts. Windows activates the Exchange property pages dynamically when you start AD Users and Computers.

You can add new mailboxes by connecting to any domain controller (DC) in the domain to hold the account. The three most important properties given to a new account when you create it are:

• The account name:   This includes the down-level Windows NT account name and the UPN, or User Principal Name. For example, my NT account name is TRedmond, while my UPN is [e-mail].

• The SMTP email address:   This can be the same value as the UPN, and it is most convenient for users when it is. The Recipient Update Service generates the SMTP address and any other proxy addresses according to policies that you establish. The AD validates any email address against the directory to ensure that it is unique within the organization. Some companies generate user records as the result of automated HR processes and synchronize information into the AD to add the account. These procedures can cause email clashes if the code does not check for duplicates.

• The display name:   Users see this name most often, because it is the name shown in the GAL and other address lists.

It is a good idea to determine a set of policies to set standards for account and email addresses before you add any accounts or mailboxes. Plunging forward to create accounts in an uncontrolled manner may be artistic, and indeed this approach will probably work for a small operation, but it is inappropriate for a corporate-style implementation. If administrators do not comply with standards, you will see increasing problems as you add more accounts, particularly with display names in the GAL. It is inevitable that different administrators will name accounts according to a variety of different styles, and no one will be quite sure how to find people in the directory.

Some companies have well-meaning but unworkable ideas for how to create account names. For example, if your organization allocates numbers to staff members, it may seem sensible to use the same staff numbers as the basis for allocating account names, or even SMTP addresses. In reality, such a scheme is not feasible, since the resulting addressing scheme is very hard to use when you want to find someone. In HP's HR systems, my badge number is 100150847, but I would hate anyone to think of me as a mere number or to have people be forced to address messages to me as [e-mail].

National Social Security or insurance numbers are unique and are sometimes proposed as the basis for an even more unfriendly account naming convention. Thankfully, it is illegal to use Social Security numbers in this way in many countries. Even worse naming conventions are in use, and, strange as it may seem, there are organizations that think it is a good idea to use cryptic, esoteric naming schemes. I have received messages from people forced to use addresses such as [e-mail],^[1] and wondered how the email administrators in that company dreamed up such a charming naming convention. Perhaps it is an attempt to keep corporate secrets or stop people from guessing what an email address might be. Even more bizarrely, there are companies that support logical addressing schemes for incoming mail, and then insist on putting esoteric reply addresses on outgoing messages. For example, you might be able to send mail to [e-mail], but get a response from [e-mail]! Mixing addresses in this manner does not deliver a consistent external presence for a company.

The most sensible principles to remember when considering the most appropriate account naming scheme for your organization are:

• Logical: Users should not have to go through mental contortions to remember their own email addresses. Equally, they should find the GAL easy to look through when they need to find someone. As we have just discussed, the naming convention for external addresses should also follow a logical structure. The Electronic Messaging Association (EMA) recommends "first name.last name@domain" as the preferred convention for external SMTP email addresses.

• Friendly: Some logical schemes are, well, too logical. Look for a compromise between logic and user friendliness.

• Straightforward: Avoid complexity at all costs.

Administrators often consider surnames as the first and most obvious basis for planning a naming scheme, and it is often possible to use this approach in small to medium email systems. However, the statistical fact is that the more users a system supports the more chance there will be that common surnames exist. In a small system supporting 50 users you might only have one "Smith" (or the equivalent most common name in a country or language), but I'll guarantee that in a system supporting more than 100 or so users there'll be more than one surname clash to contend with. Surnames are also a western convention that does not always apply well in international deployments. There are places in the world, including Malaysia, Iceland, and parts of India, where the concept of a surname is not universally observed, and others (China) where the surname is the primary name.

A good account naming policy covers:

• The naming convention used for new accounts, including the down- level NT account name, the UPN, and the alias used for the Exchange mailbox. The account names must be unique within the domain.

• The email addresses allocated to the new mailbox and instructions about how to resolve duplicate addresses. The Recipient Update Service creates email addresses automatically, but you may want to differentiate addresses when two or more users with duplicate names exist. For example, if there are two Jane Smiths in a company, what SMTP addresses will you allocate? Most companies use a middle initial to split the two, resulting in names such as Jane.F.Smith and Jane.D.Smith. This is fine until you have two people with the same middle initial, so be prepared to be inventive. Whatever you do, do not add numbers to the ends of people's names. It is not nice to have an email address such as [e-mail]!

• The Mailbox Store to host the new mailbox.

As mentioned earlier, the natural choice for display names, and the one that is probably most used in the English-speaking world is: "Given Name Last Name," as in: Tony Redmond.

This convention is fine for small implementations, but it is not appropriate for very large deployments. The basic problem is that there is a smaller number of first names in use than last names, so if you create display names in this manner it can be very difficult to find users in the GAL. There are just too many people named "John," "Peter," or "Tom" in large companies. For this reason, large companies often use a naming convention of: "Surname, Given Name" as in: Redmond, Tony.

The resulting GAL is usually easier to search (if you know someone's surname). The naming convention also needs to specify how to identify users who share the same name. The usual approach is to append some unique information to help identify users, often their location or department. Some implementations use initials, but correspondents tend not to know someone else's initials, although they often have an idea where the person works or which department the person works for. Thus, the complete naming convention is: "Surname, Given Name (Identifier)."

Figure 10.8 shows an extract from the HP GAL, in which I searched for anyone who shares my surname. As you can see, the second from top entry is an example of how to use a location identifier to identify an individual. HP now places the surname first in display names. This was not always the case—the first implementation of Exchange at Digital in 1996 sorted the GAL by first names. Everything was fine until we had 10,000 mailboxes in the directory and people started to notice that it was not as easy to locate other users anymore, since there were just too many "Johns," "Janes," and "Joes" in the company. We reversed the naming convention quickly to put surnames first and this approach has been successful ever since, surviving even the upheaval within the directory caused by two very large corporate mergers. The HP GAL contains over 250,000 entries, including mailboxes, contacts, and distribution groups, so you can appreciate that it is important to use a good naming convention with such a large number of entries.

Figure 10.8: A well-organized GAL.

Note that groups and contacts also need a naming convention for display names, preferably a convention similar to the one selected for user accounts. Group names should convey the reason why the group exists and should not use a cryptic name. Figure 10.8 also includes an example of a group name (toward the bottom of the screen) that is totally esoteric and unmeaningful. Using a meaningful prefix (such as DL--) keeps all groups together in one place in the GAL and provides an obvious hint to users that they are sending to a group.

Policies will allocate a default set of email addresses to a new account. The policy will ensure that the default addresses comply with corporate standards, but you may need to adjust the automatically generated addresses if the policy cannot generate an appropriate address, because the default address will conflict with an address already held by an account elsewhere in the organization.

10.2.2 Maintaining mailbox details

Administrators can enter lots of information about user accounts into the AD, and users can access most of this information through the GAL. Some companies restrict the number of properties that they update, because they do not want the overhead of maintaining the data (perhaps because it is held in many other directories within the company) or they fear the replication traffic that might be created. Others go to extremes and try to use the AD as the definitive repository of information about user accounts, including updating details such as organizational data (managers and their direct reports), as shown in Figure 10.9. However, going to this amount of trouble to populate the directory is rare, largely because it is so difficult to first find the data and then ensure that it is valid.

Figure 10.9: You can populate AD with organizational information.

The AD Users and Computers snap-in requires only a user logon name and first name to be specified when you create a new account. Everything else, including a password, is optional. If you want the account to be able to use Exchange, you have to specify a minimum number of details—whether to create a mailbox, the server in which the mailbox is located, and the mailbox database to use—but aside from this, administrators often omit a lot of information when they create accounts. They might have to go back afterward and populate properties such as phone numbers, titles, addresses, department names, add the accounts to groups, and so on. You might update the accounts manually or through a directory synchronization process with something like an HR database that already holds these details. Left to their own devices, most administrators "forget" to complete the job. After all, once you create an account it is ready for its owner to use. Why should the administrator bother completing every possible attribute, assuming that he or she knows the value that should be in each attribute? The answer is that if you want to have a directory containing useful and consistent data, you have to populate and maintain the entries according to standards. These standards should define the properties (e.g., whether full department names are used or abbreviations, whether to include organizational detail such as the manager's name, what phone numbers are included, and so on).

Once you create accounts, it is a major challenge to keep the data in the directory accurate. All companies experience ongoing change. People take on new responsibilities, they change offices, get new phone numbers, and join new departments. Departments split and merge to form new entities. If you do not take care, the directory will quickly become outdated and stale. In this respect, Exchange suffers from the same flaw as all its predecessors. Users probably make a forgivable assumption that administrators or other privileged users will make all the necessary amendments. Because the AD is replicated everywhere through an organization, it is important to exert control over updates. However, it is silly to prevent users from being able to make changes to properties that are not very sensitive, such as their telephone numbers. In situations in which users cannot update their own directory information, it usually falls to help-desk staff to process update requests, which then leads to a need for tools to maintain directory information. Access to the AD Users and Computers snap-in is sufficient to maintain account and mailbox details, and you can impose suitable access control lists on an organizational unit basis to restrict update privileges to specific staff.

It is possible to avoid using the standard Windows administration tools, but you will have to build your own programs or buy a commercial directory maintenance program. On a programmatic basis, you can use either ADSI or LDAP calls to update the directory in a controlled manner, or generate an LDIF output file that contains the necessary commands to update the directory, which you then process through a batch run under the control of a privileged account. It is also possible to create LDIF output from other programs, such as an HR database, to update the AD with information. You can use a similar approach to allow users to update their own mailbox information. A program or Web browser can fetch information from the AD and display it to the user, who then updates whatever fields need to be changed. Ideally, the program will enforce standards for the entered data and make sure that it complies with standards. The program could write out an XML or other formatted file and email it to an administrator for verification and checking or simply update the directory using ADSI.

Other implementations of corporate messaging systems allow users to update their own directory details, so is this a competitive disadvantage for Exchange? Perhaps so, but allowing users to update their own directory data may affect the quality of the information in the directory. A lot depends on corporate culture and experience from previous messaging systems. If you have only ever used Exchange, then the fact that you cannot update your directory data will not come as a surprise. If people expect to be able to change their telephone numbers or make sure that their titles are correct, then Exchange can be a little frustrating. To deal with users' frustrations, it is best to explain why it is important that control is exerted over the directory, and then make sure that some mechanism is in place to allow users to update information in a controlled manner.

10.2.3 Restricting mailboxes

You do not have to reveal all mailboxes in the GAL. The "Hide from Exchange Address Lists" checkbox on a user account's Exchange Advanced property page controls whether a mailbox is included in address lists. You only see the Exchange Advanced property page (Figure 10.10) if you select the "View.Advanced Features" option for AD Users and Computers. Senior management or other individuals occupying sensitive posts are often excluded from directory listings, the email equivalent of an ex-directory telephone number. Exchange 2003 moves the "Protocol Settings" option from this property page to the Exchange Features property page.

Figure 10.10: Exchange Advanced options for user accounts.

The Delivery Restrictions button on the Exchange General Property page defines who is able to send messages to a mailbox. This is another common restriction requested by senior management, who sometimes do not want to have messages arriving from anyone outside their immediate staff or a selected group of users. In fact, many senior managers arrange to have two mailboxes. One appears in the GAL and is available for anyone to send messages to, while the second is hidden and known only by the set of people who can send messages to it. The second mailbox is used for business-critical email, while the first is usually monitored on a daily basis to see whether any staff complaints, suggestions, or other email has arrived and needs to be answered. As shown in Figure 10.11, distribution or security groups are an excellent way of managing those permitted to send messages to a mailbox, with exceptions made on an individual basis thereafter.

Figure 10.11: Defining who can send messages to a mailbox.

You can impose further restrictions on the mailbox quota and the size of messages that a user can send. Indeed, you can get even more restrictive by not letting particular users send messages via specific connectors. All of this may sound a little paranoid, since you might think that it is best to allow free and complete communication across the whole user community. The spirit of this sentiment is admirable, but there are always situations in large implementations where it is nice to be able to tighten the screw a little.

Consider the case of contract workers who arrive to help with a project for a couple of weeks. It is good to be able to give them a mailbox so that they can communicate with the rest of the project team, but it is even better to be able to provide them with a secure working environment that allows communication while denying users the chance to send confidential information out to the Internet via an SMTP connector.

10.2.4 Mailbox quotas

You set mailbox quotas either on an individual mailbox basis or through system policies that you apply to selected Mailbox Stores. System policies allow you to implement the same settings across a large user population in a single operation, so it is a very convenient mechanism for administrators. Users are more concerned with the quota that you allocate, and they are especially concerned when they run into the brick wall of no more available quota and are unable to send or receive messages. The behavior of mail clients differs when a mailbox exceeds its quota. Some simply refuse to send or receive messages, while Outlook detects the condition and lets user knows what they can do to clean up their mailboxes to free space (Figure 10.12). The easiest option is to empty the deleted items folder, but that may only free up a small amount of quota. The hardest and most time-consuming option is to go through your folders and figure out what you need to keep and discard everything else. Indeed, some companies believe that users waste so much valuable time on mailbox maintenance that it is easier and cheaper in the end to keep increasing quotas and adding disks to servers.

Figure 10.12: Actions Outlook users can take when they exceed quota.

Determining appropriate values for mailbox quotas has long been a vexing question for Exchange administrators. If you use too low a value, users complain because they constantly exceed quota and have to stop work. Set it too high, and you end up with very large databases and extended backup times—and you can never be sure that all the data kept by users in their large mailboxes is vital corporate information. In fact, most of the time it is not, except in the eyes of the user. Three further issues increase the management problem: increased user demand for more graphical documents (so they are larger), the ease of attaching documents to messages in a simple drag-and-drop operation, and the fondness of users for including graphics such as corporate logos in their auto-signature files. These factors have increased the average size of a message on many corporate servers from circa 4 KB at the start of the 1990s to well over 100 KB today. Looking forward to an era when notes composed in digital ink on Tablets and hand-held PCs may replace some of the typed memos sent today, it is safe to assume that the average size of a message will continue to increase. Certainly, one small digital ink note containing five or six lines of writing can easily occupy 200 KB, a good pointer to future demand. The larger the average message size, the fewer messages can be held in a set quota, and the more users complain. It is an ongoing battle that will continue, so a wise administrator might plan for 50 percent growth in mailbox space per year and be happy when actual growth dips under this amount.

Relatively speaking, disk storage is cheap today and continues to decline in price per GB, so the long-held argument that you need to restrict quotas to manage storage is not altogether accurate. When Exchange first shipped, it was common to find mailbox quotas of 20 MB or less. Now, even users of free email services can get this amount of space, and it is relatively uncommon to find such a low quota on a corporate Exchange server. Table 10.3 identifies mailbox quotas for different user types. Executive users justify their large mailbox sizes because they tend to receive more email than regular users and often have to keep email for legally defined periods. The largest single mailbox I have ever seen approached 3 GB, but I am sure that there are larger mailboxes in use.

Table 10.3: Mailbox Quota Allocation by User Type

User Type	Mailbox Quota Range
Hosted (ASP)	5–15 MB
Standard corporate mailbox	30–100 MB
Heavy corporate user	100–250 MB
Executive user	250 MB–2 GB
Other users	Anything past 2 GB

Note that the AD Users and Computers UI and ESM (for both Exchange 2000 and 2003) impose a 2-GB limit on the values that you can assign to the cut-off points for storage warning, restrict send, and restrict send and receive. If you attempt to set a value past 2,097,151 (KB), AD Users and Computers signals an error and will not accept the value. Some users will need a larger quota, so you can either set the mailbox store or an individual mailbox to have no limit (in effect, the mailbox can grow as large as it needs) or set higher values by editing the values of the account's mDBStorageQuota (storage warning), mDBOverQuotaLimit (prohibit send), and mDBOverHardQuota properties with ADSIEDIT. Exchange will respect changes made through ADSIEDIT, but you can only view the updated quotas through AD Users and Computers and will not be able to change them again except by using ADSIEDIT. Possibly, the logic behind the 2-GB limit here is due to the 2-GB limit for ANSI-format OSTs and PSTs, so you should be cautious about setting higher limits, especially if you use cached Exchange mode, unless you are sure that everyone uses Uni- code-format OSTs and PSTs.

After you apply quotas, it is a good idea to take a proactive attitude to quota management. It is much better to know that a quota is about to expire and ask a user whether he or she needs more quota than to have a help-desk call logged by a frantic user who has suddenly discovered that he or she has run out of quota. You can also ask Outlook users to check for themselves on a regular basis, assuming that you tell them what their quota is in the first place! The simplest way to check current consumption is the "Show Folder Sizes" option, which generates a display similar to that shown in Figure 10.13. The difference between the "size" and "total size" fields is that the first value represents the size of all items in the folder itself, while the second represents the size of the items in the folder and all its subfolders (if any exist). Note that if you use Outlook 2003 in cached Exchange mode, you see tabs for "Local Data" (in your OST file) and "Server Data" (in your mailbox on the server). Exchange determines your quota based on data held in your server mailbox.

Figure 10.13: Viewing folder sizes from Outlook.

The easiest way to review the status of user mailbox quotas is to expand the mailbox detail for a Store through ESM and use the "Export List" option to write the data to a CSV file, as shown in Figure 10.14. Unfortunately, you cannot export data from several stores or servers in one operation, so some manual intervention is necessary to combine data together for all users. If you are programmatically minded, you could dump this information into a database and perform ongoing analysis on quota use—an exercise that is always likely to result in a chart that shows a continued sharp upward rise in mailbox storage. (See Figure 10.14.)

Figure 10.14: Listing mailbox quotas used in ESM.

You can also implement the Mailbox Manager to automatically scan, identify, and delete obsolete messages from mailboxes. This approach has the advantage that it preserves quota by eliminating junk from mailboxes. It also has a disadvantage in that users do not like automated tools making decisions about what messages to keep and what to delete.

Despite frequent requests, Microsoft does not support the customization of the text in the messages that the System Attendant sends to users when they exceed their mailbox quotas. It is possible to change this text, but only if you are willing to play with fire. You need a program called rlquiked.exe, which Microsoft publishes as part of its localization toolkit at ftp://ftp.microsoft.com/softlib/mslfiles/rltools.exe. Engineers who generate language-specific versions of Exchange use this toolkit to replace English- language text with local versions, and you can use the same approach to generate your own text for system messages. To do this, proceed as follows:

• Note the text that you want to replace.

• Download rtltools.exe and extract rlquiked.exe.

• Take a copy of exchsrvr\bin\mdbsz.dll (the resource dll that contains all the strings) to make sure that you can go back to a starting point, just in case things go wrong.

• Run rlquiked.exe and open mdbsz.dll.

• Search for the text that you want to replace and make the change by double-clicking on the text string to open a text box where you can edit the content.

• Save the altered file to a temporary dll

• Stop the Information Store service and replace mdbsz.dll in exchsrvr\ bin\ with the customized dll.

• Restart the Information Store service and check that everything works and that messages contain the customized text.

This is not an exercise to practice on a production server, so try things out on a test server before you even attempt to put the customization into practice. In addition, Microsoft may overwrite mdbsz.dll in service packs, hot fixes, or new versions of Exchange, so it becomes another item to check before you bring new software into production. Finally, if you run into any problems with the Information Store, you will have to swap the original mdbsz.dll back before you can expect any help from PSS.

10.2.5 Mailbox surrogacy

Mailbox surrogacy or delegation means that users give permission to other users to take control of their mailboxes for specific purposes. The classic example is when managers grant access to a secretary or administrative assistant to process messages that arrive in their mailbox. Even today, some senior executives process their own electronic mail, but others are still at the stage where they demand that their assistants print out their messages each day for their perusal. They then mark the printed copies of the messages with their comments or replies and leave the marked-up messages with their assistants, who take care of sending the replies. Of course, you might think that these people are dinosaurs or belong to the "Pointy Haired Boss" class, but sometimes it is easier to read and understand printed copies of messages, especially for people who are uncomfortable with keyboard skills. Receiving email is great, but how often have you replied to a message after quickly browsing its contents only to realize shortly afterward that you completely misunderstood the point and have sent off some rubbish as a response?

In the early days of email, systems tended to be unsophisticated when compared with the systems we have today. The total feature set was limited to simple create, send, read, forward, and reply functions, and delegation was accomplished by telling other people your password. Your secretary could then log on and assume your identity, and as far as the system was concerned, it was you at the controls. System administrators rightly hated this method, because it totally compromised system security. Users do not tend to pay much attention to system administrators at the best of times, so they continued to do what was necessary to get through their work. Passwords have always been the bane of administrators' lives, especially when users keep passwords on convenient scraps of paper that they can store in desk drawers or paste underneath a keyboard for easy reference.

As email systems evolved, designers paid attention to eliminating security holes while they extended feature sets. Facilities to allow users to access other users' mailboxes in a controlled manner began to appear in the early 1990s, but even so, many users persist in these new-fangled ways and continue to exchange passwords quite happily. Exchange supports mailbox delegation, which means that a user is able to open more than one mailbox, subject to being granted the appropriate permission. MAPI clients are able to open multiple mailboxes concurrently by modifying the advanced properties of the Microsoft Exchange service provider (in the MAPI profile) to specify the names of the extra mailboxes they wish to open. Internet clients have to log on to each mailbox separately.

You can grant delegate access in two ways:

• Outlook users can grant access to their own mailboxes with the Tools | Options | Delegates option. Figure 10.15 shows the option in use from Outlook 2000. Note that you can exert a certain amount of control over the options that another user can take within the mailbox. In most cases, administrative assistants or secretaries need to process calendar appointments and incoming email, but they do not necessarily have to set up new contacts. If you grant access to the Inbox folder, it means that delegates can move items to other folders as required.

  
  Figure 10.15: Granting delegate permission to folders from Outlook.

• Administrators can grant the "Send on Behalf " access to a user's mailbox with the AD Users and Computers snap-in. Select the mailbox you want to grant access to, go to the Exchange General tab, and click the Delivery Options command button. Add the names of the accounts that will be allowed to access the mailbox and click OK (Figure 10.16). The degree of access control is much coarser, since you can't specify which folders a delegate has control over.

  
  Figure 10.16: Allowing "Send on Behalf " permission for a mailbox from AD Users and Computers.

As with everything else in Exchange, Windows access control lists control delegate access. The Delivery Options screen also allows you to set a limit on the maximum number of recipients a user can add to a message.

This is a feature intended to stop users from sending internal spam. The default value is "no limit," so in practical terms users can continue to add recipients to a message until they get bored. You can still send a message that exceeds a set limit, but the Routing Engine will reject the message when it examines the header to determine how to route the message. At this stage, the Routing Engine generates and sends a nondelivery notification to the originator.

Delegate access is a good example of a feature that is highly sensitive to local and company culture, and the attitude of users varies greatly, even after they have been trained on the use and benefit of the feature. Even busy executives sometimes resist allowing their assistants to have access to their mailbox. It may be that they wish to process incoming messages themselves, preferring to forward messages to be actioned when required. I certainly prefer this approach, mostly because my mailbox receives a mixture of confidential, personal, and normal business messages. Others are quite happy to allow their assistants to process all new messages and pass on those that require attention from the executive.

^[1] . Creating non-user-friendly email addresses is more common than you might imagine. Even Scott Adams's "Dilbert" cartoon strip has poked fun at people who come to computer conventions equipped with business cards that have very long and complex email addresses. Naturally, Dilbert and his friends laugh hysterically when they see these addresses.

---