by Liz Hookway
As an Exchange administrator, you are responsible for creating not only user mailboxes, but also similar objects such as distribution lists, custom recipients, public folders, and hidden recipients. These objects are collectively known as recipients. This chapter explores the types of recipients that exist in the Exchange subsystem, but focuses mainly on the mailbox recipient. It reviews some of the Exchange architectural concepts as they relate to mailbox creation and management techniques with regards to naming conventions, message size limitations, and storage limitations.
Next, the chapter steps through the wide range of methods that are available to create your Exchange mailboxes. Included are examples for creating a single mailbox or a batch of multiple mailboxes as well as for importing users from your NT domain or from your Novell server. Microsoft has provided some impressive timesaving tools to assist administrators in creating and migrating Exchange users. This chapter also reviews some of the administrative tasks you may undertake for your Exchange organization such as backing up and restoring mailboxes, updating user information, and moving users within and even between Exchange sites.
Exchange identifies a recipient as any object you can send a message to. The following are the five types of recipients that you can send messages to:
Figure 18.1 gives examples of each typenineteen recipients in allwith the exception of hidden recipients, which are not shown in the displayed listing. To look at hidden recipients, go into Exchange Administrator, select the View menu, and choose to view just the Hidden Recipients.
Figure 18.1. Different types of Exchange recipients.
Administrators usually create an Exchange mailbox for each user that sends and receives mail on the Exchange server. Figure 18.2 shows the nine mailbox recipients in the Corporate Division subcontainer.
Figure 18.2. Exchange mailbox recipients.
If you have 100 users that send and receive mail, you create 100 mailboxes. To create the appropriate mailbox in Exchange Administrator, highlight the Site/Recipients container, and choose File | New Mailbox. This method is best for adding a few users at a time. However, it is possible to create a batch file of a group of users and then import them into Exchange.
Both of these methods are discussed in the section "Creating Exchange Recipients," later in this chapter. If you want to manage your recipients by location within the site, you can structure your site's recipient container to have multiple recipient subcontainers, such as the Five Points Office and Wateree Office shown in Figure 18.3.
Figure 18.3. Exchange recipient subcontainers.
Figure 18.3 shows the Exchange site of ColumbiaSC. It depicts the configuration path for site configuration information, but the recipients container name has been renamed Corporate Division. Within the Corporate Division, two additional subcontainers called Five Points Office and Wateree Office have been created. Furthermore, a second recipients container of Road Warriors has also been created at the site level. This configuration helps structure the users by location and functionality.
It is possible to create non-user mailboxes as well. For example, if you have an Employee of the Month program, you can ask your employees to e-mail their nominations to the user EmployeeOTM. As administrator, you can assign RufseL from personnel the access rights to open EmployeeOTM's mailbox and review the nominations. Notice the icon remains the same because this is still a mailbox. Figure 18.4 shows this non-user's mailbox.
Figure 18.4. Exchange mailbox recipient for a non-user.
There are two types of distribution lists in Exchange; those that are created by users for their own personal address book (Mailbox.pab) and those that are created by administrators for the Exchange community at large. Distribution lists can have any or all of the five types of recipients as list members. These distribution lists can also be hidden or made visible to the Exchange community. Note the distribution list icon people are smaller than the recipients icon in Figure 18.5. There is more information on creating and managing distribution lists in Chapter 19, "Directories and Distribution Lists."
Figure 18.5. Exchange distribution list recipients.
As an Exchange administrator, you have to clearly understand the difference between a mailbox and a custom recipient. A custom recipient is a mailbox recipient in a foreign system. Think of a custom recipient as a forwarding address, as a pass-through medium or channel, not as an Exchange mailbox. Custom recipients do not have an Exchange mailbox account on the Exchange server, in the Exchange site, or in the Exchange organization. Figure 18.6 shows two custom recipients defined in the Corporate Division recipient container.
Figure 18.6. Exchange custom recipient recipients.
A user can create a recipient in his or her client Personal Address Book (mailbox.pab) or the administrator can create some custom recipients for all Exchange users in the site to utilize. The following describes both methods:
For example, if you implement an Exchange server in your ColumbiaSC site but also have a community of mobile users, you can create a recipient subcontainer called Road Warriors and then import your mobile user mailboxes as a batch into this container. The Exchange community will then see this subcontainer when they review their address book selections, such as in Figure 18.7.
Figure 18.7. Example of subcontainers for mobile user recipients.
Custom Recipient Problems
If you attempt to create a custom recipient that has the same e-mail address as an existing Exchange user or mailbox, Exchange Administrator gives you an error.
If you create a custom recipient with an address or name to reside on an Exchange server, and the mailbox does not exist, all users that e-mail to this custom recipient get an undeliverable message from the Exchange System Administrator.
The key concept to remember about public folders is that only Exchange clients can create them. Administrators are responsible for managing them and replicating them to other Exchange servers/sites but they cannot create them from the Exchange Administrator tool. Administrators must log in from the client interface if they are to create public folders.
A public folder is a container of messages and postings, as well as subcontainers of more public folders. Public folders are a central repository of information not only for the local Exchange environment but also for the Exchange site(s) within the Exchange organization. The integration of Web connectors and browsers makes Exchange folders a powerful tool for your organization's Intranet. Public folders can also be a member of a distribution list.
For example, you can create a distribution list named Visionary Team that contains all the technical marketing analysts that are responsible for the next generation of computers. If you create a public folder named Visionary Team Topics and include it on the distribution list, every e-mail to the distribution list is copied to the Visionary Team Topic public folder, which in turn can be viewed by those associates with access rights to the folder.
Hidden recipients are just thatthey are hidden from the address book. Every object this chapter reviewsmailboxes, distribution lists, custom recipients, and public folderscan be hidden, but only by the Exchange administrator. To hide an object, highlight the object and pull up the property page of the object. Normally, this is found on the Advanced tab, with a field Hide From Address Book. Put a check mark in the box and the object is hidden from the address book. For example, a good way to use this is to make your CEO's private e-mail address hidden from the global address book.
It is also possible to show a distribution list in the address book but you can then hide (or disable the viewing of) the actual members of the distribution list. If you are using the Exchange Administrator tool, look at the hidden recipients by selecting View | Hidden Recipients.
Before you get into the mechanics of creating mailboxes and managing them, a few key points on some of the Exchange architectural concepts must first be explored.
It is extremely important that you decide on naming conventions when you plan your Exchange topology. It is generally recommended to keep names under eight characters in length. Just as there are multiple ways of defining user names, Exchange Administrator gives you multiple options to customize their format in Exchange Administrator under Tools | Options (see Figure 18.8).
Figure 18.8. Naming convention customization.
In alias name generation, the administrator defines how the alias name is generated. As you can see in Figure 18.8, Exchange lets you decide the alias generation format. It can be a combination of initials, names, or characters within the name. The Custom field enables you to create your own specific algorithm if the given options are not appropriate.
You will find that the Exchange subsystem is an excellent repository for your organizational data. As you can see in Figures 18.9 through 18.13, the users in your Exchange organization who are running the Exchange client are able to view the property pages for
Figure 18.9. General information.
Figure 18.10. Company organization information.
Figure 18.11. Phone/notes information.
Figure 18.12. Distribution list membership.
Figure 18.13. E-mail addresses.
As Exchange administrator, you are responsible for defining the boundaries of your Exchange subsystem. Boundaries can be placed because of resource limitations as well as organizational philosophy. Administrators can set two types of limitations: message sizes and storage limits.
Exchange has given the administrator the ability to limit the size of messages going into and leaving the Exchange server. These limitations can be set at the Exchange connector level or at the user level. For example, if you have an MS Mail connector using a phone line, you can decide to prevent any messages greater than 10MB from being transmitted into or out of your system. Each connector has a set of property pages that defines limitations. This is normally found on the General tab or the Advanced tab. Figure 18.14 shows an Internet Mail Connector (IMC) that is limiting message sizes to less than 2000KB.
Figure 18.14. Message size limits for the IMC, BERTNRUFSE.
However, you can decide to set limits for each specific user. In this case, you change the mailbox property of this user to allow greater sizes of messages outgoing or incoming. This can be done on the Advanced tab of the user's mailbox property pages. Figure 18.15 shows that Rufse Labdo is designated to use the information store limits. However, specific mailbox limits can be designated if necessary.
Figure 18.15. User message size limits for Rufse Labdo.
Each Exchange user has a home server that is their repository for messages. These messages can be text, bitmaps, video files, sound files, and so on. An Exchange user's personal messages are stored in the Exchange private information store. This store is a large database (c:\exchsrvr\mdbdata\priv.edb) that has transaction logs of messaging activity applied to it. The private information store cannot grow beyond 16GB of storage, so if your users send large messages or don't delete e-mail, it might be necessary to apply storage limitations.
As Exchange administrator, only you know where you (or Performance Optimizer) has placed the priv.edb and pub.edb files (private and public information stores). Each of these stores has a 16GB limit, totaling 32GB, so depending on your user characterizations and storage availability, you might need to apply storage limitations. Storage limitations can be applied at the Server | Private Information Store Level | General tab. Storage limitations can also be applied at the user level (User Mailbox | Advanced tab). Figure 18.15 shows that specific mailbox limits are set for Rufse Labdo. Here, the information store's default storage limits are ignored.
Now that limits are set, the users are sent a warning when they exceed them. There are two types of storage warnings that you can set: an issue warning and a prohibit send warning. You can view this as a two-stage warning program.
Figure 18.16 is a warning sent to a user, Bert Labdo, who has exceeded his 1KB message limit.
Figure 18.16. Warning E-mail sent to user Bert Labdo.
Some Exchange administrators reading this might be saying, "Hey, because Exchange implements single-instance storage, and a lot of my users get the same e-mail, what does this storage limit apply to?" Well, a good question! A storage limit applies to each user regardless of what messages are on the store. So, the logical limitations of the information store can be greater than the physical limitations of the information store.
Single Instance Store: When a message comes into Exchange, there is only one copy of the message in the information store. Exchange gives each recipient mailbox a pointer to the message. So if a 1MB message is sent to 100 users on the same Exchange server, Exchange doesn't create 100 1MB messages using up 100MB of storage. It creates one message with 100 pointers to this message in the database. Here, Exchange charges 1MB of storage space to each user, although the messages are shared on the database. Thus, the sum of the logical storage limitations on the Exchange server can exceed the physical storage limitations. Which is the way Exchange is designed, so that's okay.
When a user modifies the original message, Exchange creates a modified copy and the user's pointer changes to the newer version.
Look at an example of this. Say there is a server-wide storage limit of 50MB for each user on a server. LesB and AllyK are in the same group so they get much of the same e-mail from their boss, say about 30MB worth. If LesB and AllyK are the only users on their Exchange server, the total size of the private store may be just 70MB. This can be the 30MB of shared, boss e-mail and 40MB of total e-mail (20 + 20) that is specific to each user. However, both AllyK and LesB are charged for 50 MB as they have a logical storage size of 50MB (30 MB + 20 MB).
Figure 18.17. Storage of messages in the Exchange Information Store.
Now that you know more about the side effects of message sizes and storage limits, you are ready to address the different methods of creating an Exchange mailbox. There are many ways to create Exchange recipients, and each method has its usefulness in the appropriate situation. This section covers methods the Exchange Administrator can utilize in creating recipients:
This section also covers using the NT User Manager for Domains, and then creating a single mailbox recipient for your new NT user accounts.
It is fairly easy to create an Exchange recipient object. Table 18.1. shows you what you need to do in Exchange Administrator.
Choose |
To Create |
Then |
File | New Mailbox
|
An Exchange Mailbox
|
Define User/Mailbox attributes
|
File | New Distribution List
|
An Exchange
|
Add Members to New Distribution List Dist List
|
File | New Custom Recipient
|
A Custom Recipient
|
Define User attributes
|
File | New Other
|
A New Recipient
|
Create Recipients subcontainer within the Container |
The key is to use these tools appropriately for each case.
When you add one or two Exchange mailboxes at a time, you create each user singularly. However, in the long run, you should create a few templates initially to describe generic company users. For example, by creating an engineering template, you can preset basic information about department name, location, assistants, and so on.
Figure 18.18. Duplicate mailbox property page.
If you want to create multiple mailboxes for your Exchange site and you don't want to enter each individually, it is easy to create a file that Exchange can import. The easiest way to do this is to start with a template, and then modify it as you go along.
Step 1
The first step is to create a Template Import file.
Figure 18.19. Directory export form.
Based on the values you input and select on this form, Exchange Administrator will perform the required tasks you've indicated. The export tool can and will do the following:
Step 2
The second step is to edit your Template Import file.
What Export produced for you is a file that you can view in Notepad, Edit, VI, or Excel. If you use Notepad, Edit, or VI, the fields are separated by commas or the specific separator you requested. Excel spreads the data out into distinct columns, so you might want to print it out in landscape mode to understand what goes where. I find a combination of Excel and VI the most useful when editing mass lines with separators.
The header, or top line of the file, defines the ordering of the user information. Each line after the top header line is specific to each new user. For example, you see something like this:
Obj-Class,First Name,Last name,Display Name,Alias Name,Directory Name, Primary Windows NT Account, Home-Server,E-mail address,E-mail ddresses,Members,Obj-Container,Hide from AB,Phone Number,Office Mailbox,Josie,VanDerKrogh, Josie VanDerKrogh,JosieV,JosieV, MICPDC\JosieV,BERTNRUFSE,,MS:MICROSTAFF/MICPDC/JOSIEV%SMTP:JosieV@MICPDC. .MicroStaffCorporation.com%X400:c=US;a= ;p=MicroStaff Corpo;o=MICPDC;s=VanDerKrogh;g=Josie;,, Recipients,,803-725-0000,MM999
However, deciphering this data in columns makes the editing task easier. The following separates this data into fields for easier viewing:
Field |
Value |
Obj-Class
|
Mailbox
|
First Name
|
Josie
|
Last Name
|
VanDerKrogh
|
Display Name
|
Josie VanDerKrogh
|
Alias Name
|
JosieK
|
Directory Name
|
JosieV
|
Primary Windows NT Account
|
MICPDC\JosieV
|
Home-Server
|
BERTNRUFSE
|
E-mail Address:
|
MS:MICROSTAFF/MICPDC/JOSIEV%
|
%X400:c=US;a= ;p=MicroStaff Corpo;o=MICPDC; s=VanDerKrogh; g=Josie
| |
Obj-Container
|
Recipients
|
Hide from AB
| |
Phone Number
|
803-725-0000
|
Office
|
MM999 |
An appendix in the Microsoft Exchange Administrator's Guide manual details the significance of each field. Note that because every property page field is not exported, you might need to add any additional fields if your organization requires them.
A trick to figure out what goes in each field is to first run the Exchange Administrator in raw mode.
c:\exchsrvr\bin\admin -r
After you get into Exchange Administrator, highlight a recipient's mailbox object, and choose File | Raw Properties. A Raw Property Page window pops up with object attributes on the left and values in grayed out boxes on the right. Not all of these object attributes correlate directly to field names that you can set and consequently import, so use this for a quick guide when you can't find the appendix.
Step 3
The third step is to import your new template file that now has an entry for every user
After you have hand-crafted your .csv file with the appropriate mailbox accounts and information, choose Tools | Directory Import, and you see a pop-up window as in Figure 18.20.
Figure 18.20. The Directory Import dialog box.
From this window, you specify the following:
After you import your .csv file, you see all the new mailboxes created in the specified container.
If you implement Exchange into an existing NT environment, it might make sense to create your .csv file by first extracting the NT accounts and then by modifying the .csv file with appropriate information. Microsoft has a tool in Exchange Administrator to help you extract these user accounts. The following steps show how to perform this extraction and subsequent import into Exchange.
Step 1
First, in Exchange Administrator, choose Tools | Extract Windows NT Account List, as shown in Figure 18.21. You should see a pop-up window similar to the one in Figure 18.22. From this window, choose the NT domain from which you want to extract the user names, the name of the NT domain controller in this NT domain, and finally browse/create an output file for the extraction. After you choose and validate these fields, choose OK to run the NT User Extractor tool. You see a resulting pop-up window explaining the number of errors, if any, that occur.
Figure 18.21. Extract Windows NT account list.
Figure 18.22. The Windows NT User Extraction dialog box.
Step 2
Next, you must modify the output.csv file. Your output file looks similar to this:
Obj-Class,Common-Name,Display-Name,Home-Server,Comment Mailbox,Administrator,,~SERVER,Built-in account for administering the computer/domain Mailbox,AnzieV,Anzie Vizza,~SERVER, Mailbox,AudreyC,Audrey Crawley,~SERVER, Mailbox,BertL,Bert Labdo,~SERVER, Mailbox,BrennaT,Brenna Teath,~SERVER, Mailbox,FelixA,Felix Aghan,~SERVER Mailbox,Guest,,~SERVER,Built-in account for guest access to the computer/domain Mailbox,MaddieV,Maddie VanDerKrogh,~SERVER,
Remove the user names that are not valid for receiving mail or that already have mailboxes. For example, remove the Administrator line and Guest. Next, add those fields to the first line that your organization requires, such as Phone or Office and then add the appropriate information for each user line. If your organization information is the same for each user, it might make sense for you to choose a recipient template in the import phase instead. It is up to you to determine the best way for your import.
The value for Home -Server: ~SERVER, is the name of the server from which you are running the import. If you run the import from a different system, you must change the ~SERVER value to the name of the Home Exchange Server with your favorite editor (Edit, VI, Excel, and so on).
Step 3
Next, you must import your modified .csv file. After you have hand-crafted your .csv file with the appropriate mailbox accounts and information, choose Tools | Directory Import, and follow the steps as discussed in the previous section.
If your Exchange implementation is to include Novell users who already exist, then Exchange Administrator provides another great extractor tool to handle this. Again, in Exchange Administrator, choose Tools | Extract NetWare Account List, and you see a pop-up similar to the one in Figure 18.23.
Figure 18.23. The Novell NetWare User Extraction dialog box.
You will need to complete this form with the necessary information:
Follow step 2 and step 3 from the previous section to finish editing and importing the .csv file.
You may decide to do away with the Exchange Administrator user interface (although it is very useful!), and decide to do everything from the command-line prompt. Use the online help if you need more specific information on how to do this.
To export information from the Exchange Server, execute the following, where /e is to export, and /d is the Exchange Server from which you want to export data:
c:\exchsrvr\bin\admin /e file.csv /d bertnrufse
The following are other options you can use:
To import information into the Exchange Server, execute the following, where /i is to import, /d is the Exchange Server into which you want to import data:
c:\exchsrvr\bin\admin /i file.csv /d bertnrufse
The following are other options you can use:
One of the great things about Exchange is that Exchange administration is partially integrated into the NT User Manager program. If you add a new NT user to the NT domain, it is now possible to create an Exchange Mailbox for the user at the same time. In NT User Manager for Domains, you can use the Exchange | Options menu to determine the following:
You must decide upon naming conventions when you plan your Exchange topology. When you use NT User Manager for Domains to create an Exchange mailbox, the user name is defined to be the Exchange mailbox name by default. However, you can change the name when you create the mailbox.
General tab:
|
Display Name, Alias Name, Primary Windows NT Account
|
Advanced tab:
|
Directory Name, Home Server and Container name (per predefined options)
|
E-Mail Addresses:
|
Appropriately generated e-mail addresses: |
You cannot use an Exchange mailbox template when you use NT User Manager to create the Exchange mailboxes. If it is normal in your administration process to use templates, then follow these steps:
As an Exchange administrator, you are responsible for adding users, deleting users, monitoring storage limitations, and changing user organization information as the users move around the company. You are also responsible for defining a backup and restore policy for the Exchange server and ensuring its implementation. Some of the user management details have already been covered earlier in the chapter. This section focuses on backup and restore policies and on moving users in the organization.
It is important to set user expectations with regards to restoring deleted mail because this turns out to be an Exchange administrator's most routine activity. As of the writing of this book, there is not a tool or utility that can back up or, most important, restore a single mailbox. Vendors are working on this functionality, but currently, restorations must be performed at the server level. The administrator has two basic options when determining how to restore a messages or a specific mailbox for a user. These options are discussed in the following sections.
Some organizations have a policy of not restoring users' e-mail. Users are on their own. As an Exchange administrator, you definitely set users' expectations and make them a bit fearful of their Delete key, and consequently you will see your Exchange store size grow. However, you will have to restore someone's e-mail one day, possibly yours, so the next section describes a more realistic approach.
Backup and restore is covered in Chapter 20, "Maintaining Exchange." Take time to look at this chapter before you continue. Assume that you have a valid backup of your Exchange server. Because you are looking for only one user's mailbox or a specific message, you are going to have restore the entire Exchange Server database first, find the mailbox, copy their messages to a dummy .pst, and then copy them from the dummy .pst back to their Exchange server. The following section guides you through these steps. You will have to do some work from the administrator menu, as well as some work from the client interface.
You will first log on as an administrator, use the NT Backup and Restore Admin tool, and then use Exchange Administrator.
Moving a user in the organization might be as simple as updating just their mailbox information to reflect new phone numbers and office numbers. However, you might also need to change the following:
If a user moves physically, you might need to move his or her Exchange mailbox from one Exchange server to another. However, many times users don't move physically from their office but move their communication paths to different organization members. Therefore, users will communicate with a different set of people. In this case, as an Exchange administrator, you will want to optimize storage use (single-instance store) and transmissions between Exchange servers. Therefore, it might make sense to move this user's mailbox to an Exchange server that hosts the new user's department members' mailboxes. This will utilize single-instance store more efficiently.
If your user remains in the same Exchange site, the Exchange Administrator has a tool that moves the user's mailbox from one Exchange server to another. An intra site move requires the administrator to move the mailbox to the new server, and then the user (client) must change their profile to reflect the new server path. The following steps detail what each person should do:
As Administrator
As the Exchange Client/User
If your users move from one Exchange site to another, then this requires more effort on both parties. The Move Mailbox tool is only for intra-site movement. As of the writing of this book, there isn't a tool for inter-site movement, nor for backing up and restoring single mailboxes. I'm sure tools will be developed in the near future, so look for updates from Microsoft.
How To Move Mailboxes From Site A to Site B
This requires both the user and the administrator to perform tasks in sequence. The tasks are detailed in the following list beginning at Site A, and then moving the data to Site B.
At Site A, on the client desktop, the user must add a personal folder to the user's profile to act as a backup copy of all their server mail.
At Site B, the administrator needs to create the user's new mailbox.
At Site B, the user will create a new user profile to access the new Exchange server and copy their backed-up mailbox to their new mailbox. The user should execute the following steps:
At Site A, the administrator can now delete the user's mailbox.
As discussed earlier in this chapter, you will want to monitor your users for storage usage in their mailboxes. In Exchange Administrator, by choosing the server name, and then the Private Information Store in the right pane, you see in the Mailbox Resources tab a status of mailbox usage for your server. Notice in Figure 18.24 that one user is prohibited from sending messages and another user has just gotten their warning message.
Figure 18.24. Private information store mailbox resource status.
One way to perform maintenance on mailboxes is by using the Clean Mailbox tool in the Exchange Administrator. At the time this book was written, there are vendors developing more administrative tools for Exchange so these may be available soon. To clean (or reduce the size) of a mailbox, run the Clean Mailbox tool as shown in Figure 18.25.
Figure 18.25. The Clean Mailbox dialog box.
Using this tool, you were able to clean up the delinquent user (Bert Labdo) in Figure 18.24. You reduced his resource usage from 159KB to only 9KB.
It is important to pre-determine the types of Exchange recipients you will have in your Exchange site and to place them in appropriate subcontainers at the beginning of your implementation. Take time to forecast the different messaging subsystems to which your users will connect, and then create subcontainers and custom recipients to assist them in sending to their associates.
When you are populating your Exchange server for the first time, use the tools that Exchange gives you. They are quite good. When your site is up and running, create templates to help you create subsequent mailbox. You might already know your clients' need for restoring deleted messages, but it will help to have a test or dummy server in your lab to help you in emergency restores. Most important, keep your eyes open for new Exchange administration tools. Single mailbox restore tools should be available soon for purchase or for beta use, as well as tools to assist you in monitoring individual mailbox usage and subsequent cleanup.