In this chapter, you learn
Microsoft Exchange Server 4.0 (called Exchange in this chapter) brings client/server messaging to the BackOffice suite of Windows NT Server-based applications. Microsoft's goal for Exchange was to create a scalable, enterprise-wide messaging system with a centralized administrative model. To support the need for forms and other custom enhancements, Microsoft added programmability to Exchange with a Forms Designer and support for the Visual Basic for Applications (VBA) programming language.
Exchange replaces or supplements current mail systems using the shared file system (SFS). SFS includes Microsoft Mail version 3.x and its support components, such as gateways and multi-postoffice interchange capabilities. By offering the option to replace or supplement an SFS, Microsoft provides a number of options for migrating your existing mail system(s) to Exchange.
This chapter describes the overall architecture of Exchange, how Exchange relates to current implementations of Microsoft Mail 3.x, and what you need to know about Exchange and its workings before installation. It's important to understand that Exchange is an especially intricate product that requires a great deal of forethought before you bring it online. The chapter takes you through a typical installation and also discusses selecting options from the custom installation. The chapter also explains what you can expect as you set up Exchange for use in messaging environments serving only a few users, or many thousands of users.
Exchange is the first enterprise-wide electronic mail system to take full advantage of the client/server messaging model. Most Exchange users are likely to run Microsoft Mail, Lotus cc:Mail, or another SFS mail application. Before you install Exchange, it's important to understand how Exchange works and how Exchange's client/server architecture varies from the SFS approach.
When you create a Microsoft Mail postoffice on a mail server, the Setup program generates a large number of individual subdirectories with names ranging from ATT to XTN. These subdirectories are the holding locations for messages as well as postoffice management information. Each Microsoft Mail user connected to the postoffice has read/write access to these subdirectories. The user's MS Mail client application works with the subdirectories to post and retrieve mail. Microsoft Mail 3.x also supports Schedule+ 1.x's sharing of schedule information and its capability to send and receive meeting-related messages. The mail server also stores shared schedules and meeting-related messages.
The terms directory and subdirectory, rather than folder and subfolder, are used in this book when discussing applications that predate the current version of Microsoft BackOffice, Windows NT 4.0, and Windows 95.
SFS has no active server-based processes to manipulate messages. The shared folders are limited to storing information for searching and retrieval by the client application. There is no concept of intelligent, server-side processing of messages and other requests of the mail system, other than transferring messages between postoffices.
Mail systems typically are divided into multiple postoffices, usually assigned to physical locations, departments, or other logical groupings of users of the system. Microsoft Mail's Message Transfer Agent (MTA), which usually resides on a dedicated machine, periodically polls each postoffice and transfers messages between the postoffices. Figure 23.1 illustrates how the MTA transfers messages between postoffices.
Using the Message Transfer Agent (MTA) to link local and remote postoffices.
Postoffices not physically on the same network as the MTA call in to other postoffices to deliver and pick up mail. The MTA receives and processes the call, making available the messages that are pertinent to the calling postoffice. The MTA can be configured to receive calls and deliver any outgoing mail during the incoming call. The MTA also can be configured to place calls automatically, delivering mail to remote postoffices either on a scheduled basis or when the mail arrives at the MTA.
When a user calls in from the field with a laptop PC and a modem, the MTA is the process responsible for answering the call and delivering the mail to the calling user. The MTA handles mail headers, message content, and management of the remote user's mailbox. If you have remote postoffice traffic with many remote users calling in for their mail and a large number of active postoffices, the MTA is likely to become a significant bottleneck. Some ingenious workarounds for the MTA bottleneck range from dedicated systems that handle specific types of traffic, to elaborate circular transfers of mail between several different MTAs.
Exchange supports multiple connectors, the software that connects external mail systems. Connectors serve the same purpose as the MTA of Microsoft Mail. Unlike Microsoft Mail 3.x's MTAs, you don't need a dedicated system to transfer mail through each Exchange connector you install.
An example of a challenge presented by the MTA approach to messaging is the number of phone lines required to support remote mail access and Remote Access Service (RAS) to connect to the LAN. With the MTA setup, you're required to have one line to support the remote mail and one line to support Remote Access Service. Microsoft Mail 3.x has a number of other encumbrances that are eliminated by the use of Exchange. Most of these encumbrances derive from the product's early development time frame and need for backward compatibility.
Exchange drastically changes the messaging process from Microsoft Mail's SFS and MTA implementation. It's very easy to underestimate the significance of these changes. The following list shows just a few of the changes and enhancements that Exchange introduces to the messaging model:
It's likely that you'll implement your system in a stepped fashion, one piece at a time. The combination of features that best serve your messaging environment may not be readily apparent when you first start up your Exchange system.
By introducing intelligent back-end (server) processes, Exchange greatly enhances users' experience with mail. When a message is submitted, the server works through the routing of the message and determines the recipients for the message. The server determines the connectors or gateways through which the message should be routed, and initiates the process of sending the message to the recipient or posting the message in a public folder.
Exchange lets you enable folders as valid recipients. You can post a message to a public folder, making it available to other people for their reference. You can include a folder in a distribution list. A typical application for public folders is managing phone messages. You can send a phone message to the intended recipient and have the system automatically post a copy of the message to a Phone Messages public folder for record-keeping.
If the mail message is to multiple recipients, Exchange parses each recipient's name and starts the correct routing process. If the message is to multiple recipients at a single physical site, only a single copy of the message is needed. Exchange, in essence, issues a pointer to the single message stored on the server. When the user opens the message, the pointer presents the original message.
If you issue a very large message to several people using SFS, you can take down an entire mail postoffice. SFS makes one copy of the message for each person on the distribution list. With Exchange, each user sees the same copy of the message.
Exchange lets you send messages using the BCC, or Blind Carbon Copy, field. By doing so, however, you prevent Exchange from issuing the same message to more than one person using the "pointer" approach outlined here. You effectively eliminate the single-copy-to-multiple-users feature of Exchange. If you're sending a message to many people, avoid using the BCC field when possible.
Client/server messaging introduces a very important feature to mail systems-the capability to have the server preprocess messages on behalf of the recipient. The Inbox Assistant of the Exchange client lets you establish rules that govern the processing of your incoming messages. Figure 23.2 shows how to establish a rule that causes any message from Steve Wynkoop to be deleted on receipt.
Setting up rules for incoming messages with the Exchange client's Inbox Assistant.
You can use the Inbox Assistant's rules even when you're not logged on to Exchange. The power of the Inbox Assistant is that your rules are server-based. The rules are implemented on and controlled by the server; when established, rules don't require further intervention by the client application. Figure 23.3 shows the Edit Rule dialog of the Exchange client in which you can specify one or more actions based on the message address, subject, or text in the body of the message.
Using the Exchange client's Edit Rule dialog to specify conditional message actions.
Traditional electronic mail systems require mail users to be defined separately and distinctly from network users. Exchange weaves the process of defining and working with users into the basic Windows NT 4.0 user administration process. You maintain all network and Exchange user information in one place. Integration with Windows NT Server 4.0's security system is the subject of the later section "Working with User Manager and Exchange Mailboxes."
When you install the Exchange client, you can select from a number of providers, which are the source of information for the client software. Providers range from the Exchange system to proprietary network providers, such as The Microsoft Network (MSN) and CompuServe. Figure 23.4 shows the Add Service to Profile dialog's list of mail providers for the Exchange client running on Windows 95. Only the Internet Mail, Microsoft Mail, Personal Address Book, and Personal Folders appear when installing the Exchange client on machines running Windows NT 4.0. (Microsoft Mail appears only if you're using Microsoft Mail 3.x.)
Adding providers to Exchange in the Add Service to Profile dialog.
The Exchange client fulfills the concept of Microsoft's universal inbox. You can add Microsoft or third-party providers to the client application so that you can direct all your electronic communication to a common location. Faxes, electronic mail from all sources, and various types of electronic documents can be managed by the server and organized through systems of Exchange folders.
Exchange folders aren't the same as disk folders (directories and subdirectories). Exchange folders have many of the same characteristics as disk folders, such as hierarchical structures, but reside as individual records in Exchange's message store, a database similar in structure to Microsoft Access's .mdb files.
The interface to the provider layer in Exchange is open, so it's possible to create a provider that queries a SQL Server or Access database, or to provide an interface to other less structured sources of information, such as stock-quotation services.
Exchange answers the demand for a robust mail server by adding functionality to the mail-processing environment. This includes Proxy Address Support, Replication Support, and Native Application Development Support. When you combine these features with the client/server environment provided by Exchange, you begin to see the reason that Exchange's implementation is so powerful. The following sections explain how each feature is used in your messaging environment.
Exchange lets you define multiple addresses per recipient. When users are initially set up in Exchange, they often are assigned a number of addresses, depending on where the users' accounts originated. You can establish addresses for each mail system in which the user previously had an account. By adding proxy addresses, Exchange automatically forwards mail for the prior account to the new Exchange mailbox.
One of the more important features of Exchange is the capability to replicate information across servers. Information is stored in folder structures on the server. When information is added, changed, or removed from these folders, Exchange automatically updates all servers that contain that folder. Exchange has a conflict-resolution plan that handles conflicting updates.
Exchange uses the messaging subsystem to update folder structures. When a change occurs in a replicated folder, only the changed information is mailed to all other servers with the same folder. When the updates are completed, the recipient server sends a confirmation back to the originating server. This store-and-forward process provides assurance that folder changes flow between servers, just as messages flow between the servers. If a server is down-perhaps due to a severed network connection-the Exchange messaging engine stores the messages until the server becomes available. At that time, the messages are transmitted and folder changes are applied, in the order in which they originated.
Exchange replication is a fully automatic background process. Replication is also a server-based process, so regardless of whether your client software is running, the server makes sure that all folders are synchronized by applying updates as soon as possible after a folder content change.
Mail isn't just for sending meeting requests, short notes, or other text-based messages. Mail is an excellent medium for managing the information flow between servers. You can count on the mail system to send not only your text messages, but also application information, such as expense account entries in Excel worksheets, database updates, and requests to run queries on a database server.
For sending information to other applications or performing operations on databases, you create custom Exchange forms to organize and, in some cases, validate the information before submission to a public folder. When you design an Exchange form, you're developing an Exchange application. The form resides in a folder on the server; you open a blank copy of the form to create a structured Exchange message. Only the information you supply, plus a pointer to the form you used, is stored, making forms a very efficient method of communication.
As mentioned earlier in this chapter, Exchange is a true client/server messaging environment, dividing the functionality of the mail system between server and client processes to optimize the combination of performance, functionality, and features. The client/server implementation makes possible automatic replication and rules that run even when you're not logged on.
Exchange servers communicate with Exchange clients using remote procedure calls (RPCs). An RPC opens a channel of network communication between the server and a client, allowing the two systems to converse. In this context, conversing means that the client or server can make and fulfill requests from the other. RPCs let a client run a process on the server as though the process were run on the client PC. Windows NT uses RPCs for various networking operations.
Exchange uses RPCs to maintain the updates between server-based information stores and the information stores on your local system. When you install the Exchange client, the following two new working files are created on the client PC:
You can have more than one PST on a system and even in a given profile. This can be helpful if you have multiple mail addresses, as may be the case if you're the Exchange administrator or the administrator for a Web site.
Exchange clients use RPCs to converse with the server in order to make sure that local information stores are synchronized with the corresponding server store. By storing a local copy of e-forms that are used, users have ready access to the mail messages and attachments relating to those messages.
You may recall that the electronic forms are installed at the folder level. This has some real advantages over past implementations that were more server-based installations.
When you install Exchange, you find many new steps, terms, and approaches to the mail system that vary from Microsoft Mail's setup. It's important to understand how these terms affect your installation of the system. Exchange uses four terms to define the topology of the mail system, as listed in table 23.1 in order of increasing scope.
Table 23.1 Exchange Topology Terminology
Term | Definition |
Client | Any machine running the Exchange 4.0 client software that isn't a Server. |
Server | The system that's performing the task of managing the folders, messages, and tasks associated with the clients for which it's responsible. A Server runs the Exchange Server 4.0 software and participates in replication with other servers in your Exchange network. |
Site | Consists of one or more Servers. |
Organization | Consists of one or more Sites. |
Figure 23.5 illustrates the relationship between Servers, Sites, and Organizations.
The hierarchical organization of Servers, Sites, and Organizations.
The key to establishing a solid Exchange site is planning. You must take the time to plan for and name the servers, sites, and organizations that comprise your messaging system. You can relate sites and organizations in this context to domains in the Windows NT Server model. Sites can replicate folders and messages between themselves and, of course, can process electronic mail to and from other sites.
Choose organization, site, and server names carefully before you install Exchange. After you install Exchange, changing fundamental implementation details, such as the site name or organization name, requires you to reinstall Exchange Server 4.0.
On the Exchange CD-ROM, you can find planning materials in the \Migrate folder, which contains tools and planning guides to aid your e-mail conversion effort. Microsoft's Web site provides white papers that cover Exchange planning, migration, and deployment at http://www.microsoft.com/exchange/plan.htm. Most of the white papers are session summaries from the Microsoft Exchange Planning Workshop held in September 1995, when Exchange was in the final beta-testing stage.
To ensure the best possible performance, install Exchange Server 4.0 on a dedicated Windows NT 4.0 server that's neither a Primary or a Backup Domain Controller. As a point of compromise, if this isn't feasible, you can use the Exchange server as a temporary Backup Domain Controller until the server's domain duties affect Exchange's performance.
See "Roles of Domain Controllers," (Ch 16)
Running SQL Server 6.5 on the same server as Exchange isn't a recommended practice, because Exchange and SQL Server each require a substantial amount of memory resources and are disk-intensive applications.
As a point of reference, if you have users that employ the e-mail system in a typical manner, sending and receiving approximately 50 messages a day, count on needing as much as 50M of disk space per user on your system. To some extent, the server's disk space requirement can be alleviated by moving the users' mail databases (.pst files) to their local machines.
Additional requirements for good performance include an absolute minimum of 32M of RAM, disk drives that are as fast as possible, and as few additional server processes active as possible. Of course, in an ideal world, this would be a dedicated server with multiple processors and lots of RAM. Reality usually dictates that you scale the server as your mail system grows, starting small and later increasing the performance on the system.
The best indication of server performance is the length of time it takes from the time a message leaves a user's outbox to the time it arrives in the recipients' inbox within a common mailbox. If this time lag is excessive compared with the same timing when you initially install your system, consider the following options:
See "Using Performance Monitor," (Ch 14)
See "Small Computer System Interface (SCSI)," (Ch 5)
One of the most important considerations in planning your Exchange installation is the creation of Exchange accounts. Following are three recommendations to reduce the time and effort needed to establish mail accounts for Exchange users:
The process of installing Exchange comprises the following basic steps:
The Exchange client included with Windows 95 and Windows NT 4.0, now called Windows Messaging, isn't the Exchange client for Exchange Server 4.0. This issue created considerable confusion during the early days of Windows 95. You must install the Exchange client from the CD-ROM on each PC that you want to connect to Exchange Server; the new, licensed client replaces the existing Windows 95 Exchange client.
Before running the Exchange setup application, be sure to set the maximum size of your server's paging file to 100M plus the amount of RAM on your computer using the Performance page of Control Panel's System tool. Installation of Exchange 4.00a (released in August 1996) may fail if you don't have a sufficiently large Pagefile.sys.
To install Exchange from the Exchange Server distribution CD-ROM, follow these steps:
Selecting Exchange installation options and the default installation folder.
Selecting the Exchange components to install.
Selecting the e-mail connector and specifying installation of the Sample Applications.
Choosing between Per Server and Per Seat Exchange licensing.
Adding client licenses in accordance with your purchase.
Providing the organization and site names for a new Exchange installation.
Specifying the Windows NT account (domain and user ID) and password for the Exchange Administrator account.
Exchange now has the information it needs to install the files onto your server. The actual process of moving the files to the server can be quite lengthy; the footprint for Exchange is more than 100M, and setting up Exchange objects takes a considerable period of time. Consider taking a coffee break while the installation process completes.
When completed, the installation process offers you the opportunity to run the Optimizer utility (see fig. 23.13). It's strongly recommended that you run this utility to optimize your hardware and software configuration for the number and types of users of Exchange. Run the Optimizer utility immediately after you set up the Exchange server. Although you can skip the optimization step during installation and run the utility later, starting with the optimum configuration assures that users will gain the maximum performance available from the messaging system.
The final Exchange Server Setup dialog that offers the option of running the Exchange Server Optimizer.
The Optimizer performs the following basic operations:
The Optimizer offers suggestions; you have the opportunity to override these suggestions as the Optimizer completes each step. Running the Optimizer is a non-destructive process; you can rerun the Optimizer whenever you change your system configuration or the number of users changes significantly.
To maximize your server's performance for Exchange, follow these steps:
Configuring the Optimizer.
The Optimizer's suggestions for relocating Exchange files.
The final dialog of the Exchange Optimizer, offering the option to restart Exchange services.
You can run the Optimizer at any time from the Microsoft Exchange Optimizer choice that's installed in the Microsoft Exchange program menu. You have the same options as when running Optimizer during installation, and you can upsize your server configuration whenever necessary. It's a good idea to run the Optimizer whenever you have a significant change in the configuration of your server. Such changes include adding a large number of users to the system, adding memory, and adding services to or removing services from the server.
The Client Load Simulator (LoadSim) is a complex, intricate tool that lets you load-test your Exchange configuration. Microsoft developed LoadSim to evaluate the performance of Exchange in a wide range of configurations. Using LoadSim effectively requires a thorough knowledge of Exchange features and topology. A complete description of the use of LoadSim is beyond the scope of this book; thus, only a brief description of how to install and start LoadSim is provided here. LoadSim places a controllable user load on the server to provide the following information:
By using the Load Simulator periodically after you implement Exchange, you can project how your system will respond as its workload increases. You can use this information to justify the acquisition of new equipment, memory, or other resources that may be required to optimize your system. LoadSim uses a significant percentage of your server's resources, so it's best to run LoadSim overnight or on weekends, if your Exchange server is in production.
Running LoadSim creates an Exchange profile (Servername-##) for every simulated user. If you specify a load test with 100 users, LoadSim creates 100 exchange users and user profiles. The test profiles ordinarily don't present a problem, because it's uncommon to run a production Exchange client on the server. You can use the Exchange client to delete the test profiles, if necessary.
To install and run the Client Load Simulator, follow these steps:
Adding an Exchange server and basic test parameters for LoadSim.
Setting the basic test user parameters in the LoadSim User Profile Properties sheet.
LoadSim's progress report for a test simulation.
Displaying the result from the Loadsim.log file with the Lslog.exe utility.
The Loadsim.doc file describes in more detail user parameters and how to analyze data to forecast Exchange performance with additional users. Users are divided into Light, Medium, and Heavy usage categories by the utility, and these categories are used to stress the server based on the profile of your users. Before running the utility, it's important to have a profile of your users' mail usage patterns so that the utility reports data from a realistic loading of your system.
In an ideal situation, you install your Exchange server at the same time you install and configure your Windows NT domain and its associated users. The ideal is likely to be the exception rather than the rule when installing Exchange, because most Exchange installations are upgrades to existing mail systems.
If you're now using one or more popular mail systems supported by Exchange, you use the Migration Wizard to transfer user accounts, mailboxes, and shared folders. The Wizard supports migration of the following mail systems:
In each case, the users' mailboxes are converted and placed into the Exchange system.
Most new Exchange installations now occur within organizations using Microsoft Mail 3.x; as a result, Microsoft Mail migration receives the most detailed explanation in this chapter. The process for migrating from Lotus cc:Mail is almost identical to that for Microsoft Mail. Using the Migration Wizard to convert an existing Microsoft Mail system involves these basic steps:
The Migration Wizard offers the following two options for converting your MS Mail postoffice to Exchange:
Consider the following approach for your transition from Microsoft Mail 3.x to Exchange:
The following sections describe how to use the Migration Wizard with the recommended two-step scenario and the more drastic one-step method.
Before proceeding with the two-step or one-step conversion, back up at least your MS Mail postoffice folder. Although migration doesn't remove user information or other files from the MS Mail postoffice, there's always the possibility of file corruption during the process.
If your prospective Exchange users don't have Windows NT user accounts, it's a good idea to create a template account for use in the installation process. Perhaps the easiest way to ensure the best security is to create a template account with the group memberships and other rights you desire, and with the Must Change Password option selected. By combining this with the ability to create accounts and use the account name as the password, you can ensure that the account is secured after the user signs on the first time.
Implementing the template option may require experimentation. If some of your clients are running network or operating system software that doesn't support changing of passwords during the sign-on process, the user may be locked out of the system. Be sure to test the template account on all operating system and network operating system combinations that are the target of your conversion efforts.
To preview the migration process, you can create a new MS Mail postoffice on the server, add a few test users and messages, and then run the Migration Wizard on the test postoffice. You can quickly create a workgroup postoffice from a Windows 95 client by using the Microsoft Mail Postoffice tool of Windows 95's Control Panel. Add a few users, and then use the Migration Wizard to create test Exchange mailboxes and user accounts.
Have all users log out of MS Mail until the production conversion process is complete. Operations on the MS Mail postoffice during conversion can cause unexpected events, such as loss of messages.
The first step of two-step migration creates users on the Exchange server that match the mailboxes on the MS Mail system. This process creates the necessary user accounts on Exchange and Windows NT. The user names for the new Windows NT accounts are the same as the e-mail alias; new accounts aren't created for users whose Windows NT account uses their e-mail alias as the user name. The two-step process allows the users access to Exchange, but their existing mail, folders, and shared folders aren't converted from MS Mail.
After you complete your test phase, you use the second step of the two-step option to extract and import the message files, folders, and shared folders from the MS Mail system into the Exchange server's message store. Users have been created, as necessary, so you move only existing MS Mail messages to the Exchange message store.
It's important to understand the enhanced benefits you have when you move to public folders from shared folders. With public folders, you can enable rules, filters, and smart, server-based processing on the posted objects. Public folders are similar to Usenet newsgroups or Lotus Notes databases, because public folders support conversation threading and can present views based on the conversation threads.
The two-step process is a simple variation of the one-step method described in the next section.
If you select the one-step approach, the entire MS Mail postoffice is converted to the Exchange environment, carrying with it the address books, groups, folders, and mail for the users of the system. The conversion process involves the following basic steps:
When the conversion is completed, you shut down the MS Mail postoffice; users then connect only to the new Exchange server.
To run the Migration Wizard in the one-step process, follow this procedure:
Choosing the mail system to convert to Exchange in the Migration Wizard's opening dialog.
Specifying the MS Mail postoffice location and Administrator account name and password.
Selecting one-step or two-step migration.
Selecting the MS Mail information to migrate to Exchange.
Specifying the user accounts to convert to Exchange.
Providing the Exchange server name for MS Mail migration
Setting permissions for shared MS Mail folders converted to Exchange Public Folders.
Specifying the recipient container for Exchange accounts and a template file for creating Windows NT accounts.
Selecting the type of password to create for new Windows NT accounts and specifying the domain for the accounts.
The status dialog during an early part of the conversion process.
The message box indicating that migration is complete.
When migration completes, your users sign on to the new Exchange server from the Exchange client and see all their existing mail.
When you convert a postoffice using migration files, you be use a fixed-format file, created by an Exchange extractor application, as the source for the import process. The extractor programs included on the Exchange Server CD-ROM are located in the following folders:
The Readme.txt file in the folder details the use of the extractor with the Migration Wizard. In general, you follow these steps to create and use the extractor files:
The extractor options vary according to the features of your existing mail system. The extractor exports the messages stored in the system, private, and shared message storage locations (called folders in Exchange). After you create the migration source file, the Migration Wizard prompts you through the steps necessary to import the information into Exchange.
Installing the client software for Exchange is a requirement for your users, even if they have the Exchange client shipped with Windows 95 or the newer Microsoft Windows Messaging client. The installation of the client software adds the messaging subsystem drivers necessary to connect to the server, use Exchange's advanced features, and provide access to the public folders on the server.
The following basic steps are required to install the client software for your users:
The client software isn't included on the Exchange Server CD-ROM; instead, use the Exchange Clients CD-ROM, which also may include other BackOffice applications. Complete the following steps for each platform you want to support for a given server:
Review the Readme.wri document in the \Exchange\Clients\Eng folder before having users install the client software. The Readme.wri file contains a substantial amount of information regarding potential installation problems and how to tune clients for optimum performance.
To set up the share to the different directories, you have the following options:
You can customize the client setup program from the Start menu by choosing Microsoft Exchange and then Microsoft Exchange Setup Editor. The Setup Editor lets you preset some user options, as well as specify the services to install. The Setup Editor doesn't let you automatically install the Internet Mail, Microsoft Fax, Microsoft Network, or CompuServe mail providers for Windows 95 clients, so Setup Editor is of limited use for Windows 95 clients. The client software files you copy from the CD-ROM have the read-only attribute set. You must remove the read-only attribute from the Exchng.stf setup file in the setup folder before saving a modified setup file.
It's likely that most Exchange users run Windows 95 and already have the Windows 95 version of Exchange on their PCs. Follow these steps to install the full Exchange client software on a Windows 95 machine:
Selecting Exchange components for installation.
Adding the Microsoft Mail MAPI service provider to the Information Services installed.
Specifying required options for Schedule+.
Steps 3 through 10 also apply to installing the client software on the server, which is required to run the LoadSim utility described earlier in the "Using the Client Load Simulator Utility" section. You need to install only the Exchange provider to run LoadSim.
After the Exchange software is installed on the client system, you can establish multiple client profiles that each specify the set of information providers. To view client profiles, double-click Windows 95's Control Panel's Mail and Fax tool or Windows NT's Mail tool; then click Show Profiles in the Services page of the Microsoft Exchange Properties sheet to open the Mail and Fax property sheet. When you install the client software, the existing Exchange profile, if any, is saved and a new profile is created (see fig. 23.35). After you verify that the current MS Exchange Settings profile works, you can delete the MS Exchange Settings (old) profile.
Exchange profiles created by the Exchange client during replacement of the Windows 95 Inbox.
You add new profiles by clicking the Add button to start the Windows 95 Inbox Setup Wizard or the Windows NT Microsoft Exchange Setup Wizard. The following steps describe how to set up a new profile using the Inbox Setup Wizard:
Selecting the information services (MAPI service providers) for the client.
Specifying a descriptive name for the new profile.
Entering the name of the Exchange server and the user's mailbox name.
Choosing between installation for a laptop or a desktop PC.
Specifying the location of the existing Microsoft Mail postoffice.
Verifying the user's MS Mail account and entering the mailbox password.
Specifying the location of an existing Personal Address Book.
Use the existing .pab file for each profile you create. If you specify a new .pab file, the user must re-create all of his PAB entries.
Choosing whether to add the inbox to Windows 95's StartUp program group.
Confirming the information services to install before completing the new profile.
Making the new profile the default when starting Microsoft Exchange.
After installing the new Exchange client, test the connection to the Exchange server. If you used the Migration Wizard for MS Mail and specified conversion of shared folders, a Microsoft Mail Shared Folders item appears in the Explorer-like left pane (see fig. 23.46).
The Windows 95 version of the Exchange client, providing access to MS Mail shared folders.
Windows NT user accounts and Exchange mailboxes are closely integrated,
so User Manager for Domains provides simultaneous addition of new Windows
NT users and Exchange mailboxes. After you set up Exchange, a new menu
choice, Exchange, appears in User Manager's window. The
Exchange menu has Options and Properties
choices for setting up users and their mailboxes. Choosing Options
opens the General (only) page of the Options property sheet, in which you
specify the name of the default Exchange server and recipients container
for all new Exchange users (see fig. 23.47). Choosing Properties
opens the property sheet for the selected user.
Setting default options for adding new Exchange users.
When you create a new user, you follow the same steps as you did before
the installation of Exchange. After you choose New User
from the User menu and set up the account, however, you're
presented with a new property sheet containing several pages. The General
properties page lets you define the user's presence on the Exchange server
(see fig. 23.48). Table 23.2 summarizes the information you enter on each
page of the Username Properties sheet.
Setting General properties for a new Exchange mailbox.
Table 23.2 Summary of Property Pages for the Exchange User Property Sheet
Page | Description |
General | This page sets up the base account. You specify the alias, descriptive display name, and address information for the mailbox. This page also specifies the Windows NT user account that's associated with the mailbox. |
Organization | This page lets you specify the user's manager and subordinates. This information is useful for applications to query in resolving a relative reference. For example, if an application needs to send an e-mail message to the user's supervisor, the destination is looked up here. |
Phone/Notes | This page allows you to specify a number of phone numbers for this user. You can also enter a series of notes about the user. |
Distribution Lists | This page allows you to select from existing lists those lists to which this user should belong. |
E-mail Addresses | On this page, you establish proxy addresses (described earlier in the "Proxy Address Support" section) for accounts. More than one proxy address may be created, depending on the number of connectors installed on the server. A user may have one or more addresses associated with each connector that's running on the server and available to the user. |
Delivery Restrictions | This page lets you specify the individuals from whom you will or won't accept e-mail. This can be a helpful junk mail filter. The message originator is notified of refused mail if it's declined at your mailbox. |
Delivery Options | This page offers the option of setting up "Send on behalf of" privileges for users. This privilege allows users to, for example, send mail for a supervisor or co-worker. Another common use for this feature is to send mail on behalf of a shared mail account. For example, perhaps you have a technical support account, TechSupport, that's actually monitored by more than one individual. By using this feature, other users can originate mail from the TechSupport account. |
Custom Attributes | Custom attributes are simply fields in which you can place information pertinent to your operation. These are free-form fields. |
Advanced | Advanced options include several metering options that control system and disk space usage, mail display names, and others. This page may be helpful in managing users that tend to have a great deal of mail and require large amounts of disk space to store it. You can manage such users' disk space usage on this tab and help prevent storage outages. |
The property pages, connectors, and other objects in the Exchange environment are extensible by third parties. In some cases, when you install a product that works with Exchange, property sheets may be added to or changed from those of the default installation.
After you click OK to close the Username Properties sheet, you're returned to User Manager and are ready to add the next user to the system.
The Exchange Administrator application provides global access to the server and all of its components. With Exchange's object-oriented approach to the messaging environment, the Administrator displays a hierarchy of containers and objects to ease the administrative process. You add new mailboxes for users with existing Windows NT accounts with the Administrator. The primary use of the Administrator, however, is to set the properties of other objects, such as connectors, through a multitude of property pages. Publishing limitations preclude a complete description of the Administrator's capabilities; only a brief overview of the Exchange Administrator is presented here.
You launch the Administrator from the Start menu by choosing Programs, Microsoft Exchange, and Microsoft Exchange Administrator. When Administrator's window opens, much of the object hierarchy is collapsed. Click the + icon of the item you want to expand; a - icon indicates that the item is fully expanded (see fig. 23.49).
Exchange Administrator's window, with the first two object hierarchies expanded.
The Recipients container stores all mailbox accounts. Selecting the Recipients container, the default for new users, in the left pane displays all the container accounts in the right pane (refer to fig. 23.49). Double-clicking an individual recipient item displays the Username Properties sheet, as shown earlier in figure 23.48.
The Administrator is also where you install additional connectors for
your system and other Exchange objects. You install new objects by choosing
New Other from the File menu, which displays
the submenu shown in figure 23.50. You manage existing objects by double-clicking
the item at the lowest level (leaf node) of the hierarchy to display its
property sheet. Figure 23.51 shows the Internet Mail Connector Properties
sheet.
New object choices presented by the File menu's
New Other submenu.
The Internet Mail Connector Properties sheet.
You can create Custom Recipients for third-party connectors added to your Exchange server. For example, if you want to create a recipient that's accessible only through a third-party wireless or paging connector, you create a John Smith-Pager recipient. This recipient is associated only with the wireless or paging gateway, and messages sent to this user automatically are sent through the wireless or pager connector.
The Administrator is an effective tool for managing all Exchange objects. You can provide comprehensive distribution list management, user management, and connector support for your Exchange system. The specific options available depend on the services, transports, and connectors you install.
This chapter provided only a brief overview of Exchange Server's client/server messaging capabilities. A full exposition of the features of Exchange requires a book in itself. Step-by-step procedures were provided for installing Exchange Server, using the MS Mail Migration Wizard, and installing the Exchange client, along with the process of adding Exchange mailboxes for new user accounts with User Manager for Domains. The chapter closed with a short section on the Exchange Administrator application. For more information relating to topics covered in this chapter, refer to these chapters:
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.