by Wesley H. Peace III
Now that you've decided to install Microsoft Exchange Server, the fun starts; you need to develop an implementation plan. You shouldn't undertake any project without developing an implementation plan, and Exchange is no exception.
To help you develop this plan, Microsoft has released a set of templates outlining the basic steps required to implement Exchange Server. You can find this template on the Microsoft Back Office Deployment Templates CD, Part #098-63461, available from Microsoft Inside Sales.
An automated design tool is also available on the Microsoft Exchange Server Technical Resource CD, the "Microsoft Exchange Server Modeling Tool." This tools will help you define the Exchange Organization structure and the components required to support it.
When you develop a deployment plan, you must consider in detail the environment that will be supported. Exchange is designed to operate in most existing electronic mail environments, but you must be careful when you design the support infrastructure.
Consider both the client and the server, and determine where a specific service will be supported and how it will be supported. If a particular connector is not available from Microsoft, you need to identify sources of connectors and service providers. These third-party products must be not only identified, but tested for functionality.
Microsoft maintains a database of third-party connectors and service providers at its web site
http://www.microsoft.com/Exchange/EXISV
When you are planning the installation of Exchange Server, first consider local users. All administrators want to save themselves time; with Exchange, careful planning before the installation will greatly minimize the amount of running around that will be required . A key to installing these users is defining a standard installation method and consistency in client installation. Exchange ships with a Setup Editor to customize the installation scripts, setup program options, and user options (see Figure 7.1).
Figure 7.1. The Exchange Setup Editor.
The Setup Editor generates a default.prf file, which provides a set of defaults to the Exchange setup program. The administrator has the option of creating a custom version for each user or each operating system, or a single profile that can be customized as needed. In either case, the Setup Editor will provide answers to some of the questions asked during installation of the client software.
Exchange supports both Services Providers and Connectors; Service Providers on the clients and Connectors on the server. When you are designing the system, review the support requirements for each platform to identify the appropriate location in which to install the service.
One service to consider is the Exchange Server Service itself; Configuration information and total client count must be available to assist in determining server requirements.
A Microsoft Mail provider can be installed as either a client or server service. Determine the requirements for access to Microsoft mail. If you do a trial installation, consider installing the service on the client . As additional clients are added, and a full migration is undertaken, it might be more appropriate to use the Microsoft Mail Connector on the Exchange servers. Consider also the Microsoft Mail gateways that will remain in the site after the migration is underway.
Implementing Exchange Server into an existing Microsoft Mail network requires some thought. Is the Exchange Server meant to replace Microsoft Mail? If so, how will the migration be done?
Consider a phased approachinstall the Microsoft Mail service provider and the Exchange client to support the Microsoft Mail post offices as users are migrated to the Exchange Server.
Key issues to consider when using this approach include the following:
Windows Messaging (formerly the Exchange client), the inherent messaging client for both Windows 95 and Windows NT 4.0, is currently the only client that ships with the Internet Service Provider. The Exchange clientthe version that ships with the Exchange Serverdoes not need an Internet Service Provider; all Internet access is provided at the server through the Internet Mail Connector. As part of the planning process, think about the types of clients that will be supported and where Internet Services must be supported
Currently, the choice between Internet Service Provider and Internet Connector is restricted to Windows 95. Soon Windows NT 4.0 will be added. When you need to support other platforms, the choice is clear; use the Internet Mail Connector on the Exchange Server.
You can also use the Internet Service while you are migrating existing users to the Exchange Server. One advantage of the Internet Service with Windows 95 is its capability to access POP3 servers. With POP3 support installed, existing UNIX post offices can continue to be supported for the receipt of mail until the migration is complete.
The Windows Messaging clients also support access to SMTP servers to send Internet mail. They do not accept SMTP connections, so incoming Internet mail must be routed to a POP3 server.
While the migration is in progress these clients can be supported with a standard SMTP and POP3 server installation on a UNIX platform; you must have expertise with UNIX and, specifically, sendmail to assure that the entries in the DNS database permit the correct routing of mail to the appropriate destination. As Exchange is deployed, the sendmail database support required to keep routing accurate becomes less of a problem; Exchange can provide message routing both within and without the organization.
Configuring an Exchange organization is no easy effort. This is not because it is necessarily complex, but because of the many options available to the designer. For example, there are three possible message stores in an Exchange Server.
Each of these stores has a 16GB limitation, which can limit the Exchange Server to a maximum of 48GB of total storage per server. These limits are not as restrictive as they might seem because they apply only to messages stored in the server message stores. When you are designing the Exchange server, you must understand these limitations and user requirements, to implement an effective design. The following represent some things you must consider when you design the Exchange server:
As an administrator, concerns range from restricting server storage to enabling the users to manage their own storage (and possibly increasing administrative support requirements). Each of these has its advantages and disadvantages. Weigh the circumstances to determine what is appropriate for the Organization.
If you choose server-based storage, remember that the maximum size of a recipient container, the private message store is 16GB. As the administrator, review the current e-mail storage requirements for the installed base. By looking at the size of current user-message store, determining an average, and then performing some quick calculations, it should be relatively easy to determine the number of users that can be supported from a single server.
An easy way to determine Exchange Server user storage requirements is to determine the average mailbox size for each user and divide that by the maximum size of the Information Store (16GB). Using this method will yield the maximum number of users an Exchange Server can support with a single recipient container. For example, if users have a 20MB Message Store (mailbox), 16GB/20MB = 800 users/server.
There are three Information Stores managed by the Exchange Server: the Private, Public Information, and Directory Store. The Private Information Store also maintains information other than messagesuser rules and forms are also stored there. These calculations will only provide preliminary storage requirements. Other factors will affect server storage requirements as well.
In addition to the Private Information Store, both the Public and Directory Store also have a 16GB limit.
Aging is described as the amount of time messages reside in the Information Store. If a message is retained beyond a prescribed period of time, should it be deleted? What policies should be put in place to support management of mail messages? What type of age limit should be placed on the message Store?
Aging is a concern; how long should a user maintain archive mail? When is it appropriate to delete old mail? Aging is manageable with Exchange. You need to establish a plan for managing this process.
For those users who never purge their deleted mail, the administrator has the tools to force a purge. Be sure that the activation of this capability is included in the rollout plan.
Mailbox storage is not the only place mail can be delivered in Exchange. You can also use personal folders to store mail. Saving mail to personal folders will bypass the 16GB limitation of the private Message Store. In effect, a single Exchange server can now manage more users. The downside is that the management of user space is now relegated to the user.
When you use personal folders, .pst files, consider where they will be stored. Each user has been designated a home server in the organizational hierarchy; an acceptable practice might be to maintain a common directory on the home server for the personal folders. For backup purposes, this will permit the administrator to designate this directory in the backup strategy.
In contrast, users can maintain their personal folders on their computers. When this method is chosen, individual workstation storage requirements are the concern, and there is less need to reserve storage on the Exchange Server. It then becomes the user's responsibility to back up messages.
Personal folders (.pst files) can be an ideal way to store messages, but they can become unwieldy. To archive messages when using .pst files, select Tools | Service | Add | Personal Folder from the Exchange client main menu. Rename the new personal folder archive (or some other meaningful name). Move all the messages to be archived to this personal folder. When you have finished, remove the folder from the inbox and copy it to backup media. A suggested practice is to create an archive for each month.
The archive does not have to be removed from the client, and you can maintain it as a separate Information Store on a continuous basis.
You also need to think about instances of multiple users sharing a single workstation. When this occurs, some of the inherent security designed into the Exchange client is bypassed.
By default, the Exchange client uses NT network security to check the user ID and connect to the appropriate mailbox. It is not evident to the user, but NT Security validates the user based on the security credentials created by the logon process. These credentials are used internally by NT and have now been extended to support this application. When using this method, access to the mailbox occurs without further validation. When a user is accessing Exchange servers located in other domains, accessing mailboxes when logged in as a different person, or on a Novell network, additional validation is required. Network logon validation must be disabled to support these environments. When this is done, instead of the mailbox automatically opening, a dialog box appears asking for logon information.
Even more important, because logon security is disabled, profile configuration procedures should be reviewed. Profiles need to be created on each workstation a user accesses, or establish support for "roving users."
Roving User configuration setup differs depending on the operating system. Registry entries are used to point to the client-configuration information in Windows 95 and Windows NT; Windows 3.x uses a .INI file.
The Exchange client uses a built-in editor to read and send mail. Organizations that use the Microsoft Office 95 suite (and specifically Microsoft Word) have another editor option: WordMail. New installations of Microsoft Word offer an option to install WordMail. When it is installed, it becomes the default editor for Exchange. If messaging is internal, this is an excellent option to use; however, be careful when you send Rich Text to other mail systems and the Internet. Rich Text Format (RTF) is a standard advocated by Microsoft as a vendor independent method of sharing data between word processing systems. It preserves all formatting code and is understood by any word processor that understands RTF.
Exchange by default sends data in RTF, this preserves the formatting characters of the message; however, few electronic mail systems understand RTF data. When an Exchange RTF message is sent to a system that does not understand RTF, the received message has an attached file winmail.dat, which contains all the formatting. When you send mail to the Internet, you should not send Rich Text formatted messages. An option is available on the properties page of the Internet Mail Connector to turn this off.
If WordMail is installed and becomes the default editor, the default editor can be changed back to the Exchange default editor from the Exchange Inbox. This does not remove WordMail as an editor, so either editor can be used to compose, read, or send mail. If you want to remove WordMail entirely, you can do so from the Office Setup program.
How will remote users be supported in the Microsoft Exchange environment? There are a number of new considerations to be made here as well.
Exchange Remote Mail users require remote access; remote users of Microsoft Mail access the Microsoft Mail Server through a personal computer running the Microsoft Mail Eternal program. The added capabilities available with a Point-to-Point Protocol (PPP) connection and Remote Access Services will to many veteran Microsoft Mail administrators appear to be both cumbersome and overkill.
Many administrators feel the use of RAS Service is not warranted to support the delivery of remote mail; however, from a maintenance point of view, there are fewer hardware components to support. Although RAS provides a reliable method of remotely receiving the mail, it also supports connectivity to the LAN. Consequently, more overhead is required to support this added functionality. In reality, when you use the Microsoft Exchange Server Remote client, there is little difference between the functionality it provides and that supported by Microsoft Mail Remote.
When you are migrating from a Microsoft Mail Remote to Microsoft Exchange Remote with PPP, you know the traffic volumes because there is no change in the number of users supported, only in the method of access. No additional modems need to be added.
Expect to monitor the remote access connections as traffic increases for remote users. Also keep in mind that these lines will be used by users accessing other services on the LAN. When you install new RAS Services, sizing becomes more difficult and will require some experimentation and monitoring.
As communications expertise grows, there will be more demand for ISDN, Frame Relay, and X.25 services. Remote access for large corporations can be provided by any of these services; RAS configuration for other than default dial-up connections is beyond the scope of this book. If support for these telecommunications services is a consideration, consult your network provider for information on the adapters and software required to support this connectivity.
The Exchange Configuration editor provides great control over the installation of remote user software. The Editor is designed to build default client configurations that include supported Information Service Providers and also permit the modification of the binding order for the client protocol stack; this is critical to Exchange connectivity both for remote and local users, and will speed loading time for the client software when done correctly. Be sure it is understood what protocols will be used to support Exchange in the Organization before you make any changes to the protocol stack or binding order.
If the binding order must be changed after the client is installed, you must do so with the Registry Editor in Windows 95 and Windows NT. In Windows 3.1 and Windows for WorkGroups, the binding order is an entry in the System.ini file.
Remote users are users who access the Exchange Server from a dial-up connection. Exchange also supports mobile users. For both categories of users you must define how they will be using their workstations.
A remote user has a dial-up connection to the Exchange server, and will always use a dial-up connection. A remote user should maintain messages in personal folders to make sure that archived messages are readily available. The user can compose their messages offline upload them to the Exchange Server at designated times set by parameters in the client software.
A mobile user is occasionally on the road, and maintains a permanent connection via the LAN to the Exchange Server when he or she is back in the office. This user should be set up with an offline storage (.ost) file for sending and receiving messages. When using .ost files, the administrative team should configure the remote client before allowing the mobile user access to the software. Use of .ost files permits a user to compose messages offline and send and receive mail as needed. When the user returns to the office, the laptop will synchronize the user's mailbox with the laptop. This is an ideal method of ensuring consistency between workstations while traveling.
Critical to the deployment of Exchange is the establishment of a naming convention. Conventions need to be established for the following Exchange objects:
You must carefully assign the names because they collectively will be used to identify the Exchange server and recipients. As stated throughout this chapter, Exchange assigns both a display name and a directory name to each object in the Information Store. The display name can be easily changed, but the underlying directory is never changed. This is especially true of the first three of these objects; once named, they can not be changed without reinstalling the server.
Exchange uses the organization name at the top of the hierarchy to define the overall name for all sites and servers under its control. The Exchange Organization tree starts at this point. The name for the Organization is usually the company installing Exchange Server (for example, SAMS or NCR). The Organization name does not have to be a single word (you can use spaces); however, Exchange uses the Organization directory name to generate default e-mail addresses, so it must be unique. This is an X.500-like directory structure; the entries created are populating a database.
Site names must also be unique. A good choice for the site name is the site's geographic or physical location (for example, Philadelphia or Denver). If at all possible, the site name should be meaningful to the casual viewer. This will help not only the administrator but also the end user in identifying people and locations.
The server name is, by default, the Windows NT computer name. Plan these names carefully; once you establish them, they cannot be changed unless you reinstall the Exchange server.
The naming of servers has always been subjective; corporate policies can dictate machine name. When you are connecting to the Internet, though, be careful when you are naming a machine; assume it will be visible to the outside world. Naming the machine accounting, for example, is asking for trouble. Also, never use a name that defines the machine's role or location (for example, garage, sauna, or finance), you never know when you might have to move it.
RFC 1178, "Choosing a Name for your Computer," provides some guidelines for naming a computer.
A mailbox is assigned to every object in the Exchange server. Default addresses are built based on the alias names created when the NT account is added in the case of a user, or using the scheme defined in the autonaming tab of the Exchange Administrator Tools | Options dialog box.
When you are adding a large number of user accounts, use the header utility provided in the Exchange Technical Resource Kit to create the header file for a .csv (comma delimited) file. When this is done, import the headers into Excel and add the appropriate fields. Use this .csv file to import the users and create mailboxes.
Often, an Organization has several users who are not Exchange users. These users need to be accessed by existing Exchange users. The easiest way to do this is to add these users to the Exchange Global Address List. You do this by using custom recipients. A custom recipient can also be used as an alternative recipient for mail messages.
You should also create mailbox names with ease of identification in mind. Coordinate the naming scheme with the NT account names or previous e-mail addresses. Several names are created when a mailbox is created:
First Name |
The user's first name |
Last Name
|
The user's last name
|
Alias Name
|
The alias is the default name for the users directory. It is generated by the Exchange Server based on an algorithm defined by the administrator when setting the Exchange autonaming options.
|
Display Name
|
This entry is used for display in the address book and Administrator Window. The default is also defined from the Administrator autonaming options.
|
Directory Name
|
This name defaults to the first alias name, but it can be changed. Once defined, it cannot be changed. |
Multiple recipient containers can be created (and even nested within recipient container) in the Exchange Site; properly named, this hierarchical structure will resemble the departmental structure of many organizations. This creates an easy-to-use directory for users to access other addresses, inside and external.
These components define an addressing structure that builds the recipient addressing scheme. This is your most vulnerable point in the assignment of names. Exchange uses names in a number of waysaliases, display names, and proxies are a few. When the Exchange server is installed in a Windows NT Domain, and users are added to the existing domain, an Exchange user is also created. The alias for that user is the NT account name. A "friendly name" must be created based on display information the administrator provides. The method to be used should be determined before you start to add users (see Figure 7.2). After you determine the method, set the "auto-naming" option of the Exchange Server Administrator program to reflect the choice for all users added to the Exchange Server Site. This parameter is configured by choosing Tools | Options from the Exchange Administrator menu and then selecting the Auto-naming tab.
Figure 7.2. Assigning Exchange default naming conventions.
The alias name is used to define the Exchange mailbox, so by default this name conforms to the NT user; however, this is not always true, especially in the case of a custom recipient where there is no NT user account.
Two types of addresses exist within Exchange: custom recipients (addresses of users outside the Exchange Organization) and e-mail addresses (defining recipients in the Organization). When you configure the Exchange server, three default addresses are created for each object. These default addresses are created based on the directory name and site information of the object. They are critical for the operations of Exchange and should not be deleted; however, they can be modified (see Figure 7.3). You access the Site Addressing Object from the Exchange Administrator by selecting the Configuration Container in the Exchange Organization Site.
Deleting any of the default recipient addresses in Exchange could cause the server to stop functioning.
Figure 7.3. The Site Addressing property page showing the three default addresses.
The following are the three default addresses:
The root address for these protocols can be changed from the Site | Configuration | Site Addressing dialog box in the Exchange Administrator (see Figure 7.4); if recipients have been created, their addresses will be automatically updated.
Figure 7.4. Site Addressing Property page.
These three address types are provided as defaults; you can add additional addresses as needed. You can also create custom address types to support unique addressing requirements. As connectors are added supporting new protocols, additional addressing types are added.
When you use the Internet Mail Connect (IMC), you must consider several issuesamong them domain addressing and security. The first issue, domain addressing, has traditionally been relegated to UNIX servers and sendmail. Exchange provides some rudimentary domain-address resolution. This support makes it quite easy to use the domain name as the root for all user addresses, and leaves the resolution of the name to the appropriate server to Exchange. So instead of an Internet address such as username@servername.org.com, the addressable name can be username@org.com. This also hides the actual server name from the outside world. This change in root SMTP addressing is done at each site through site addressing. If you want to use multiple SMTP addresses for different situations, you can add an additional address instead of changing the default SMTP address. As currently implemented, there is no limit to the number of SMTP addresses that can be added to a recipient. Prudence is the only deterrent.
To enhance security further, consider changing the default username for SMTP mail to a friendlier name, such as firstname.lastname rather than the alias. In the case of John Jones, who has a mailbox on server zeus in the bozo domain, the SMTP address would be (assume the alias name is jjones) jjones@zeus.bozo.com. When this address is sent to the outside world, it advertises the user's NT account name and the Exchange Server on which the user's mailbox resides. Creating an alternative SMTP address and assigning it as Reply Address provides a much more secure architecture. To the Exchange Organization, messages to John.Jones@bozo.com will be routed to jjones regardless of where the server for his mailbox resides. This ensures security to the Organization.
The Exchange Server can be made to support multiple Internet domains with the add-on imcext.dll that is provided with the Exchange Server Technical Resource Kit.
When additional addresses of any class are created, a Reply address must be assigned. This is the address the connector uses when sending mail.
Each installation requires support for custom addressespostmaster, webmaster, support and so on. Exchange provides a number of methods to create these. The method you choose depends on your organizational needs.
Creating a new mailbox for these account ensures that they will appear in the Global Address book. An alternate recipient can be associated with this mailbox, and mail will be routed automatically to the appropriate destination. This works well if there is one person handling all support issues; however, if it is a support address, multiple people typically are associated with this address. This can be accomplished by defining an alternative recipient as a distribution list or making the support mailbox itself the distribution list. Either way, a custom recipient is created that will support the required needs.
Custom recipients can also be defined to support special circumstances. These recipients do not have a presence in the Organization, and only provide a placeholder for receipt of mail. When you choose this method, the requirements are to provide a central location for the receipt of support queries; for example, in an Organization in which multiple mail systems exist and the address being created supports the entire Organization and all mail systems.
As the Exchange server deployment begins, departments within the Organization will want to broadcast messages among themselves. The method to support this is distribution lists. The distribution list contains the names of all people within the department or group to be supported. The members of distribution lists can be hidden to ensure privacy (see Figure 7.5). The administrator can create a new distribution list by selecting File | New Distribution List from the Exchange Administrator menu.
Distribution lists can also be created by individuals, but they are available only to the creator; lists created in the Administration program can be made available to the entire Exchange Organization.
Figure 7.5. Distribution List properties.
You can also use distribution lists to propagate permissions. Rather than assign permissions to individuals, assigned them to a list. A person added to a list inherits the permissions of that list.
A distribution list can contain other distribution lists; creating a list including recipients from other distribution lists is as easy as adding the name of the distribution list.
The criteria for supporting a single-site installation are the same as those for a multiple site. Although a multiple-site installation requires site connectors, the core installation components are the same. To install Exchange Server you need a foundation that must be installed regardless of the type of organization structure that will ultimately be supported.
A solid NT Domain architecture must be in place first. This is key to developing the Exchange Server architecture. You also must understand the organization's messaging requirements and WAN backbone.
Look at each of these criterion before developing the Exchange architecture. The Domain architecture defines how the Exchange architecture will be used. Without this underlying structure, there is no foundation for deploying Exchange. Four key activities must be accomplished:
The NT Domain requires the existence of a Domain controller. If this is a new installation, conversations should be held between the systems designer and the client to determine the numbers of users in the NT Domain. The assumption at this stage is that users in the NT Domain correspond to the users in the Exchange Domain. The Domain controller should be the first server in the domain. After this is defined, review the services to be supported to identify the capacity and number of servers required.
A single site can have more than one server. If there is high bandwidth between servers, they can reside in the same site; however, administrative needs may dictate the use of multiple sites.
When the administrator is configuring the Exchange server, he or she is restricted to the capacities of the server: 16GB for the private, 16GB for the public, and 16GB for the Directory Store. This might seem restrictive until a review of the available storage options is made. When using strictly the Private Information Store, only 16GB of data can be saved in a single Private Information Store per server. When using a combination of .pst files and Private Information Store, or .pst files alone, this limitation disappears.
A detailed analysis of the user environment will help determine the actual requirements.
After the client storage requirements have been obtained, you can begin to size the servers. When you have finished sizing the server, some key factors can be taken into account:
Unless you will configure a network backup scheme, a high-speed reliable SCSI tape backup should be included in the design. A CD-ROM drive should also be included in each system.
In the Microsoft Exchange Server Concepts and Planning Guide, Microsoft has provided some configuration guidelines.
After the physical hardware is configured, the requirements to support the application on the server must be designed. Although this might seem to be the same as hardware configuration, this is not the case. Platform design entails the requirements not just for the client, but also all other applications and services that will run on the server. In addition, the platform design will review interaction between these applications and services.
The following sections detail the services that must be supported by the Exchange Domain.
The Exchange Server Private Folders are maintained as a central repository for private user data. This includes not only user mailboxes but rules as well. Data stored in the private folders is contained in the Private Information Store database structure of the Exchange Server.
Consider both Private and Public Information Stores. Measure user utilization of the existing e-mail system to determine whether separate public folder information servers need to be installed. If a single public folder server is used, consider processor speed, memory, and the amount of disk storage required to support the application. A SCSI subsystem should be used with a RAID 5 implementation to improve throughput for reads to the disks. If at all possible, consider installing multiple host adapters to spread reads/writes across the system. Additional RAM should be installed to improve search capabilities.
The requirements for supporting a public/private server are the same when you choose hardware.
The client installation point is an NT Server share that contains the Exchange client software. This share is used to install the Exchange client software. There will be a great deal of use of this share when Exchange is initially installed, but this should taper off after all clients are installed. The client install point can be located on the same NT Server as the Exchange Server or, depending on the size of the Organization, it can be installed on the Domain controller.
If the Exchange client is to run from the network, make sure that ample bandwidth, memory, processor, and disk are available to handle the load in addition to any other services.
Customers with existing mail systems must be connected to those systems. If you are installing the server in a single site Organization, connectivity to foreign mail systems must be considered. The typical foreign mail systems to be supported are SMTP- or X.400-based.
In the case of an SMTP server, no additional hardware is required to support communications; however, depending on the number of users in the site and the traffic volume, consider a fast processor or dedicate an Exchange server with no mailboxes to support the traffic. If POP3 and UUCP support are required in addition to SMTP, some UNIX integration will be needed. This could also mean, if one does not already exist, the installation of a DNS server to handle IP address resolution. In this environment, multiple DNS servers should be configured.
The Exchange IMC will not start if the DNS server is unavailable. Multiple DNS servers will minimize the need to restart the IMC.
X.400 is the other popular protocol supported with Exchange Server. When used with TCP/IP, there is no additional hardware required; however, when X.25 support is required, the complexity of the installation increases. Memory and processing power of the server are also critical for X.400 access.
Sites with users running Microsoft Mail require synchronization of the mail directories to ensure that the most current information is moving between the sites. As they migrate to Exchange Server, the directories can still be synchronized. Exchange uses the Microsoft Mail DirSync process. This places no additional load on the server because the process is typically done in off-peak hours.
Although relegated to smaller stand-alone servers, this service can coexist with existing NT services. Security is important for KMS functionality; this server will run a security database, which should not be accessible to everyone in the Organization.
It should do the following:
A single primary domain controller(PDC) must exist within the NT Domain. The PDC provides the security for the NT as well as the Exchange Domain. This computer is responsible for validating the Exchange users before they access any resources within the domain. This is true even in a Novell environment. Several backup Domain controllers can exist within the domain; it is a good idea to have at least one.
The Exchange Server can be installed on a PDC, but be careful when you do so because the PDC also has the job of validating users as they enter the domain. This will place an added load on the Exchange server.
If the Exchange Server must be installed on a PDC, it must be sized to support both the logon authentication function and the Exchange Server itself. Multiple hard disks should be used to balance the load.
Remote users require access to the network. Again, consider the load on the servers (see Figure 7.6). If a limited number of users will be accessing the network remotely, the RAS server can share the same hardware platform. RAS users are configured through the Remote Access Administration program accessible from the Remote Access Services Program Group in NT 3.51. The Permissions dialog is displayed when you select User | Permissions from the menu. The administration of RAS Services has been implemented slightly differently with NT 4.0 and does not follow this model.
Figure 7.6. Remote Access Services User Permissions administration.
RAS support requires hardware components in the server to support dial-up access. The hardware you select should also provide minimal load on the server and provide its own processing capability.
Several considerations have already been expressed about server hardware. These include the following:
Additional information is provided in Chapter 6, "System Requirements for Optimal Performance."
Detailed planning must be undertaken to obtain the answers to these questions. Review with the organizations the requirements to support the Exchange Server.
Plan for growth. Never size the server for today's needs; provide hardware that will permit growth in memory and disk, with a minimum of disruption to the Organization. Also consider processors that can be upgraded. If this is not feasible, consider installing multiple servers to support projected growth. When you are sizing the servers, consider the following:
Microsoft provides some guidelines for deciding the requirements for the server. Consider these when the Exchange server is being used only for e-mail, and no other functions are being supported. As additional functions are supported on the system, memory requirements will increase. When you are installing the Exchange server, make every attempt to use more than a single disk. Exchange will take advantage of a multiple disk configuration, spreading the system files across the disks and optimizing reads and writes. The following chart, from the Exchange Server Concepts and Planning Guide, provides some server configuration guidelines. These figures should be used only as guidelines because actual implementations of the Exchange Organization are based upon the actual implementation.
Server Type |
Processors |
RAM |
Disk |
Users |
Low end
|
1 Pentium
|
32 MB
|
22 GB
|
100300+
|
Middle
|
1 Pentium
|
64 MB
|
52 GB
|
250600+
|
High end
|
3 Pentium
|
256 MB
|
82 GB
|
5001,000+ |
When you are designing the Exchange Server, use common sense to minimize the traffic between servers in a site and reduce network bandwidth requirements. Consider the following:
Most Organizations have, or should have, network drawings. Obtain a copy of the network map to get a clear picture of the Organization structure both geographically and physically. If this is a single site, obtain building plans and departmental locations. Quite often, the Organization would prefer to divide the servers among departments rather than geography. If this can be done, take advantage of it.
Start by building a logical drawing of the Exchange architecture.
Microsoft has released two tools that you can use to design the Exchange Organization architecture: the Windows NT Domain Planner, which is available in the NT 3.51 Resource Kit, and the Microsoft Exchange Domain Planner, which is available in the Exchange Technical Resource Kit.
The NT Domain Planner must be used before you use the Exchange Planner; but after you have the domain plan, you can use this as input to the Exchange Design Tool.
When both the logical drawing and the domain design have been done, review the protocols to be used on the network. Keep them to a minimum; if you are unable to do so, there must be at least one protocol in common to all servers. This will allow them to communicate among themselves.
Although Exchange Server does not require NT Server to run, it will operate in any network operating system environment. Both of the two leading network operating systems, Novell and NT, are supported. Configuration and support requirements differ between the two, but when set up properly, the end user should see no perceivable difference. The following paragraphs describe Exchange Server operations in each environment.
Exchange will operate in both Novell NetWare and NT environments, but you need to consider the environment you are using.
When working in a Novell environment, Exchange must still operate on NT Servers. This means the NT Servers must support IPX/SPX protocols to communicate with the NetWare clients. Additionally, they should run Gateway Services for NetWare (GSNW) and, optionally, File and Print Services for NetWare (FPNW).
Regardless of the operating system, the Exchange users must exist in the NT Domain. The NT Domain provides login validation.
If the NetWare servers are not running bindery emulation, the user accounts must be migrated manually to the NT servers. Source extractors are supplied with Exchange to assist in moving the user account between the two platforms. Novell Servers prior to Novell 4.x ran in Bindary mode. The Bindary is a central repository for all NetWare objects that contain permission and access control information. With the release of NetWare 4.x, Novell changed this control structure; however, the 4.x servers can run in an emulation mode.
If Exchange is to be installed in an existing LAN manager Domain, the primary Domain controller for the domain will have to be converted to NT server. The NT server must be the primary Domain controller in this domain. The LAN manager Domain controller can continue as a backup. The user accounts can easily be exported from the existing domain and imported into Exchange.
When Exchange is installed, it modifies User Manager for Domains by adding a new entry to the main menu: Exchange. From this selection, the default behavior of User Manager can be modified and the Exchange client properties can be configured. When a client is created, the dialog boxes to create an Exchange client are now activated.
The UNIX operating system is the most prevalent OS to integrate. Passing messages between a UNIX platform and Exchange can be accomplished. A common point needs to be established between Exchange and any NOS or O/S for passing of mail. This is either X.400 or, most likely, SMTP.
Some platforms have been configured to support only UNIX-UNIX Copy, UUCP (for example, AT&T UNIX running StarMAIL). This is a configurable parameter and can be modified to accept SMTP connections from Exchange.
Other systems will require different methods of connectivity. Review the system requirements prior to committing.
User requirements are critical to the rollout of Exchange. Group users with common communications needs together. Review Organization charts and the LAN survey. Tally the number of users within these groups to see what size servers are required to support the group. Large groups might need to be split between multiple servers; however, this is also dependent on how the server is sized.
As always, monitor the load on the server and adjust as required.
High volumes of public folder traffic could indicate the need for a dedicated public folder server. When the servers are installed, monitor the traffic to the public folders to see if a dedicated public folder server is warranted.
When you are designing a new Microsoft Exchange Organization, review the needs of the users to determine what the mix of folder usage will be. The following criteria will suggest the need to use a public folder server:
Multiple-site installation is not too different from single-site installation. The differences center around connectivity. Review the requirements for a single site in the previous sections.
In many cases, the need to install multiple sites is based on geographic and sometimes divisional criteria. As previously mentioned, the determining criteria could also be administrative. The core installation is based on a single site; Microsoft Exchange is administered from a single Administrative view, which contains all servers within the Organization. To administer a particular site requires that the administrator connect to a server (see Figure 7.7) in the remote site. This is easily done from the Exchange Administrator. This dialog box is automatically displayed when the Exchange Administrator is started and no default server has been chosen. To connect to a different server when the Administrator has been started, chose File | Connect to Server from the menu.
Figure 7.7. Connect to a different server in the organization.
Site connectors are used to connect multiple locations. Although there is a Site Connector, this is not the only means of connecting sites. Both the X.400 and the Internet Mail Connector (IMC) can be used as site connectors. Depending on the requirements of the locations, one connector may be more appropriate than another.
Some general guidelines for use of the connectors follow:
Using Exchange to support connectivity to other sites requires that certain aspects of the Exchange Server be considered for replication. The information that moves between sites in the Organization depends on the administrator, his/her requirements, and time.
At least one site must be configured to talk over the connector. When using the Internet Mail Connector, first determine if the Bridgehead Server has been defined. If it has not, it must be before any communications can occur. All servers within the site can communicate directly with the remote site if this is a requirement; using the Bridgehead Server, however, provides a focused delivery point to the remote site. Chapter 15, "Configuring Directory Replication," provides a more detailed discussion on connecting Exchange Sites.
If you do chose to use the Bridgehead Server, consider the role and services the chosen server is taking in the Organization. As part of the planning process, review the Organization requirements and consider the following:
Connectivity to other messaging systems is a capability inherent in the Exchange Server; Microsoft has designed the Exchange Server to support existing Microsoft Mail server gateways in addition to native support for three connectivity options: a 1984 and 1988 X.400 MTA; the Microsoft Mail connector for communications between Microsoft Mail users and the Exchange Server; and the Internet mail connector, which connects Microsoft Exchange Server users to the Internet. Chapter 13, "Connecting to Other Mail Systems," contains additional information.
The scaleability of Microsoft Exchange provides a robust client/server messaging system that offers multiple methods for connecting to other systems. In addition to the connector technology, the gateway components of Microsoft Mail can be used while migrating. The following Microsoft Mail gateway services can be used with the Exchange Server to support connectivity to other mail systems:
As part of the planning process, a view of the Organization must be provided that includes
Most external mail systems can be supported by the existing Microsoft Exchange connectors, or MSMail gateways. Review the communications requirements for the remote e-mail system to help narrow the connectivity requirements.
The Microsoft Exchange Server architecture uses the NT Domain architecture extensively, relying on the NT Domain for administration and security support. A key criticism of LAN-based, e-mail programs has been the need to maintain a separate user ID and password. Exchange, because of the integration with the NT Domain, does not require a second logon when using NT as the primary operating system.
There is no requirement to coordinate the installation of sites with the domain, but efforts should be made to make the installation as simple as possible to maintain. In fact, Microsoft Exchange Server supports four domain models within the NT Domain architecture.
NT Domains are logical groupings of one or more Windows NT Server computers structured to be managed and used as a single unit. This unit provides the foundation for the Windows NT Server directory services. A single logon is supported for the domain; users need to log on only once to the domain, not separately to each server within the Domain. The Exchange server takes advantage of this structure and by default uses the logon security information provided by the NT Domain to validate users. This is the reason an NT Domain is required for Exchange Server, regardless of the underlying network operating system (NOS).
There is no requirement for the Exchange Server to run on the Domain controller, but it will install only on an NT Server.
There are four NT Domain models; each supports different numbers of users. Each can support a Microsoft Exchange server Organization based on the model.
In certain environments, such as with roving users, it is appropriate to request login information a second time. In these cases, an option is available from the Exchange client to disable network security.
The first phase of the Microsoft Exchange Server design is reviewing the NT Domain architecture. If one does not exist, all efforts should be focused on establishing one before you proceed. If one exists, review the architecture to be sure that it can support the Exchange server Organization structure and that the architecture will meet the organizational needs.
When installing in a Novell NetWare environment, you must install a new NT Domain. The sole purpose of this domain is to provide Exchange server logon validation. To the Exchange users, this functions just as the current Microsoft Mail product does today; a separate logon and password are required. In reality, this information is for the NT Domain. A number of the networking clients will cache this information, and the user will not see it.
Every NT Domain has a primary Domain controller (PDC). NT servers assume one of three roles in the domain; Domain controller, backup Domain controller, or server. In this architecture, there is a single primary Domain controller (PDC), which maintains the master copy of the security account manager (SAM) database; only one PDC is allowed per domain.
Depending on the size of the domain, the PDC can reside on the same machine as the Exchange server. This will reduce the number of servers required in the domain. When working in a Novell environment, this could be critical.
Be sure to size the server to meet the needs of the domain. When sizing a PDC, consider the following information:
The NT Domain can also have a backup to the PDC. This is the backup Domain controller (BDC). It also maintains a copy of the master SAM, authenticates users, and can be promoted to a PDC in case of PDC failure. There may be several BDCs; however, none are required.
The number of user accounts is a good guide for deciding how many BDCs to implement. The number of user accounts in the domain dictates the number of BDCs to use. A good estimate is approximately one BDC for every 2,000 users.
A final class of server exists in the NT Domain: the Domain server (or resource server). These function as file, print, application, or communications servers and do not authenticate users. The Exchange server must run on the NT server platform and can function in any of these roles. In large installations, it is suggested that the Exchange server be installed as a stand-alone server (Domain server) to minimize the amount of login services running. If this is not feasible, it can be installed on either a PDC or BDC.
After you define the Domain architecture and the Exchange Server architecture, you might need to link geographically separate sites. Sites can be configured to exchange directory information, public folders, and messages. The following sections discuss what you need to do when you connect these sites. It is critical to plan the number of sites and their boundaries carefully. After they have been created, it is difficult to split or move them.
There are several factors that determine where to draw site boundaries. Some are necessary conditions that all Microsoft Exchange Server computers must satisfy in order to be placed in the same site. Others should be considered when you are planning site boundaries. These include administration, cost, security, and performance. There are also less tangible organizational issues that you should consider, such as grouping users who should work together in a single site.
One or more connections can be configured between sites. This redundant routing strategy offers load balancing between sites and across the Organization. With each route, costs can be assigned; the Exchange Server connectors uses these costs to route information. The connectors will load balance routing over the remaining connections based on these assigned costs.
These routes cab be used to reroute messages if the primary routes become unavailable; this ensures that messages will continue to flow between sites and the outside world.
In order for the Microsoft Exchange Server to function, it must have at least one physical connection to the network. This statement might prove to be misleading, but without a network connection there can be no client access (except for a locally connected client). The Exchange Server can have multiple network adapter cards, 32-bit adapter cards, and/or PCI adapter cards. You can maximize network throughput by using multiple, high-speed network cards. SCSI disk subsystems and multiple adapters should be a major consideration for reducing I/O bottlenecks and optimizing performance.
E-mail could be new to the existing network structure. In many cases it is the first application that must be shared among multiple locations and systems. A typical network installation has grown over months and sometimes years, often without much planning; when installing the Exchange Server, there now becomes a need to plan the connectivity between these systems. The Exchange Server design requires careful planning to determine how best to incorporate these locations. Not all solutions will work; to support this effort and better understand the network requirements, a number of key factors must be reviewed:
Newer, faster, and more affordable methods for linking LANs, WANs, and MANs are being providing by carriers. Dedicated links are replacing dial-up connections and other types of services; however, there are still hurdles in making these connections. LANs are optimized for data transmission; WANs are not. Data throughput drops when you transmit LAN data over a WAN because WANs do not typically have the same bandwidth.
Carefully examine the underlying physical network to ensure the existing network connections are adequate for deployment of the solution. It is crucial to take into account not only the size of your links but the proposed utilization as well. Too often, all efforts are geared toward sizing for the current opportunity; this is a serious mistake. The focus should instead be placed on the plans for the links over a period of time for all applications.
The Exchange Server can represent a small portion of the utilization of bandwidth. Other applications will also be using these links. Interaction between these applications and the Exchange Server should be considered, as well as the impact of the added Exchange traffic on the links.
Overall bandwidth and response times will be affected by the selected site connector. Consider the impact on the existing applications. There may be very large, fast connections between the sitesbut they could already be inundated with other network traffic, which impedes overall performance of the network link. It might be necessary to increase bandwidth in areas of heavy network traffic, such as locations where large amounts of graphic, audio, and video data are being transmitted. Exchange performance can be simulated using the LoadSim utility that ships with the server. Appendix A, "Understanding and Using LoadSim," provides a detailed discussion.
Also to be considered when looking at the network links are traffic bursts. Traffic bursts utilize a majority of the bandwidth for short periods of time. Characteristic of this traffic is the appearance of low overall utilizationbut with bursts of traffic during certain periods, which severely impact performance. When working with these types of connections, there are two possible solutions: increasing the bandwidth, or selecting a connector that will support more granular control of the connections. This will permit scheduling of connections and better utilization of the bandwidth.
Network bandwidth is the amount of data per second that can be transmitted over a communication link. Define site boundaries so that sites are joined to each other by data connections that "stretch" and "shrink" on demand. Three types of data connections provide this flexibility:
Traffic between sites is divided between replication messages and other types of messages. Although it is difficult to plan for the precise amounts of each type of traffic, patterns can be tracked before you install the Exchange Server to help determine volumes and reduce traffic between sites. The number and size of messages users send between sites can also vary greatly. Although you can't limit the number of messages, the Exchange Server does provide a method to limit their sizes in order to prevent the sending of large enclosures.
Develop a diagram describing the types and flow of traffic both within the organization and to other systems. The drawing should identify both current and projected traffic patterns. Every effort should be taken to document these patterns and use them to group users with common messaging needs.
When you are designing the messaging system, identify the location of gateways and high-volume users. Remember to incorporate expected growth as users become familiar with the new services and added functionality. Not all groups will use the Exchange Services equally, so the patterns will need to be described in the context of groups. Is mail sent mostly within the group, to other groups, to other sites, or to specific gateways? Are there any major traffic trends? If there is an existing e-mail system, some of this information may be available.
Messages addressed only to local users require fewer resources to deliver. Understanding traffic between groups will assist in grouping users who share common messaging needs on the same server, and in reducing network and server load.
Replication is the process of copying new and updated information from one site to another. This includes directory information about mailboxes, distribution lists, public folder addresses and contents, and addresses of users in foreign systems. The first time replication occurs, all information is sent to other sites. After that, only modifications and new entries are exchanged.
The structure and distribution of users within the Exchange Organization can greatly affect how replication affects the messaging traffic. You can schedule the flow of messages between sites. This can be used to manage the use of bandwidth if it is limited; by adjusting directory updates to occur during off-hours, the impact of message flow can be reduced. Additional information on directory updates can found in Chapter 15, "Configuring Directory Replication."
The Exchange Server can use a number of transport protocols. Native to the implementation are TCP/IP, IPX/SPX, and NetBEUI; however, Exchange will support other transports for wide-area connectivity. Each of these transport protocols installs its own MTA for messaging. An overview of the supported Transports follows:
Unlike Microsoft Mail, Microsoft Exchange was designed from the ground up to support connectivity between different post offices and mail systems. The traditional method of connecting mail systems has been through gateways, a program or hardware that supports translation from one protocol to another. Microsoft Exchange offers another method; the connector, a program that not only does protocol translation, but supports routing between mail systems as well.
Exchange uses connectors in a number of ways, to connect sites as well as to support foreign mail systems such as Microsoft Mail, SMTP, and X.400. The architecture designed by Microsoft provides an open structure for the extension of the Exchange Server by supporting the development of connectors by Microsoft as well as third-party developers. The following paragraphs describe the currently available connectors.
The site connector is the most efficient way to connect two sites because it uses RPC for site-to-site communication. Site connectors require permanent connections with higher bandwidths (more than 128KB) than the other connectors. However, they are easy to configure (see Figure 7.8) because no network transport has to be configured because it uses RPC. Messages are routed in their native format with this connector, no translation is required. A new Site Connector is created from the Exchange Administrator by selecting File | New Other | Site Connector.
Figure 7.8. Creating a new site connector.
Site connectors are point-to-point; each connection from a local server is to a remote server in the distant site. This implies that the connection is between known servers in the site, and this is truethe Site connector maintains a target server list for the remote site. It uses this list to establish the connection. By using the target server list, the Exchange Server is less likely to encounter blocked connections because of server outages, and it can balance the messaging load among servers within the remote site.
If more control is required, bridgehead servers can be created within each site and targeted as the single source for the transfer of messages.
The simplicity of the site connector is not without its shortcomings; when active, the site connector will attempt to use all available bandwidth, and the message size cannot be controlled.
The Dynamic RAS Connector (DRAS) is a dial-up site connector. It uses the NT Server Remote Access Service asynchronous communications instead of a permanent network connection between sites. This connector supports dial-up connections over slow, nonpermanent lines, and it provides an inexpensive method of providing electronic-mail services to small remote locations. The RAS connector can be configured to connect at prescribed times (see Figure 7.9); after the configuration is set, the Microsoft Exchange Server will make the connection as required. To set up a new Dynamic RAS Connector you must first create a new RAS MTA by selecting File | New Other | New MTA Transport Stack | RAS MTA Transport Stack, and select the server on which stack is to run. When this is created, select File | New Other | Dynamic RAS Connector.
Figure 7.9. Schedule for DRAS connections.
X.400 is used with TP0/X.25, TP4/CLNP, or TCP/IP it is a more robust method of connecting sites, because it offers more control over the connection.
When it is used, the administrator can control the message size (which cannot be done with the site connector), providing a more effective use of network bandwidth. If there is an existing X.400 backbone, or when you want to access a public X.400 system, this connector provides the best functionality.
The Internet Mail Connector is used to communicate between the Exchange Server and other messaging systems supporting the SMTP protocol. The IMC conforms to the following Internet Engineering Task Force (IETF) Request for Comments:
RFC |
Description |
821
|
Simple Mail Transport Protocol
|
822
|
Standard for the format of ARPA Internet text messages
|
1123
|
Internet Host Requirements
|
1521,1522
|
Multipurpose Internet Mail Extensions (MIME) |
The Internet Mail Connector can be configured to support inbound mail, outbound mail, or both. It provides a highly configurable interface to Internet mail. When used in conjunction with DNS Services, the IMC can route messages to servers within the Exchange Organization. It will support the generation of friendly name for messages destined for the Internet.
The Mail Connector (PC) MTA is responsible for exchanging mail between Exchange users and Mail for PC Networks users.
The Mail Connector (PC) MTA is an MTA process for PC Mail post offices that runs as a Windows NT service and is designed to replace existing MS-DOS EXTERNAL.EXE MTAs and OS/2 and Windows NT MMTA MTAs. The Mail Connector (PC) MTA provides the same functionality as the existing MS-DOS, OS/2 and Windows NT MTAs but is also Exchange-aware.
The Microsoft Mail Connector consists of three components: the Microsoft Mail Connector Interchange, the Microsoft Mail Connector Postoffice, and the Microsoft Mail Connector MTA. The Microsoft Mail Connector Postoffice (a.k.a., Shadow Postoffice), provides an entry point for mail originating in the Microsoft Mail Network. Because it is an Microsoft Mail Postoffice, it is visible to other Microsoft Mail Postoffices in the network and can be addressed by them. Including this Postoffice in the DirSync process enables messages and directory information to be traded between the two systems.
The Shadow Postoffice does not support users, so it cannot be used in place of an existing Microsoft Mail Postoffice.
The Microsoft Mail Connector (AppleTalk) provides connectivity between the Exchange Server and Microsoft Mail for AppleTalk. It consists of two components: the Microsoft Mail Connector, a component to convert messages to Microsoft Mail format and provide connectivity to the Microsoft Mail Postoffice; and the Microsoft Exchange Connector, a gateway program for messages destined between the Exchange Server and the Microsoft Mail (AppleTalk) server.
This chapter should be used merely as a guideline for the successful installation of Microsoft Exchange Server. Some activities must be performed so that a successful installation can occur.
Take the time to develop a concise implementation plan that includes a well though out naming convention. A standard convention cannot be established for everyone; and must be determined based on a number of factors including corporate standards as well as previously implemented conventions.
The Exchange Server can be installed in either a single- or multisite environment. The design of the Exchange Organization, the supporting communications links, and administrative requirements will determine which will be used.
NT and Exchange can be tightly coupled. In an NT Domain installation, NT Logon Security can be used to eliminate a secondary logon. Additionally, the Exchange Server Organization model can, but does not have to, mimic the NT Domain model. Exchange Organizational models exist that complement the NT Domain models.
Sites are locations that support Exchange Servers. An Exchange Site was designed to support multiple servers and the Exchange Organization designed to support multiple sites. This hierarchy provides a flexible structure for the expansion of the Exchange Organization not only internally, but also externally with the use of connectors.
Exchange Server is a constantly evolving product and offers a great deal of flexibility in design and implementation. As additional components are developed to support the server, the methods described here will be replaced by newer ones. To keep abreast of the latest capabilities of the Server, a number of sources are available; these include: