One of the most challenging steps of any major undertaking is the planning process that precedes the actual implementation. Just think of all the planning that took place before the first stone was laid on the Great Wall of China. Installing an Exchange
Messaging system also requires a very structured planning cycle, with many decisions that must be made before you even crack the shrink-wrap.
Exchange Server is a very flexible, powerful, and robust enterprise messaging system. It can also be very unforgiving, ineffective, and unhealthy if improperly designed and deployed. Determining the hardware and software requirements for Exchange in
your environment is the first step. This task requires you to document what your current mail system looks like and the messaging load it is currently managing. A careful analysis of your network operating system infrastructure, and the physical network it
runs on, is necessary to properly design a routing topology. Because Exchange uses X.400/X.500 naming conventions, you must plan your naming conventions carefully.
The installation of the Exchange Server software is a very straightforward process, assuming that you are working from a solid deployment plan. This chapter describes some of the most common installation problems and how to get around them. Some pre-
and post-installation guidelines are also discussed in this chapter. Although tuning of the Exchange Sever is not covered in this chapter, some references to general optimization guidelines are offered. After you have the server installed, testing and
verifying full functionality will ensure that you won't be uttering that famous four-letter word, "oops!"
Software vendors are known for publishing the most basic system requirements for their software. Sure, their product might install, and even run, on the systems specifications recommended on the back of the box. But these requirements usually will not
meet the needs of the typical user community. Microsoft is guilty of doing this with many of its products, and Exchange is no exception.
The specific system requirements for running their software in your environment can be determined only by properly establishing your organization's needs and expectations. Remember, Exchange and NT are scaleable to the hardware they are running on, so
plan for at least one year of growth in the system. What I see at many new installations of Exchange is that users tend to "exercise" the new system in their learning process. I had one gentleman who decided to back up his entire hard drive to a
public folder. Other than taking a long time and eating hard drive space for lunch, it seemed to work fine for him. The system administrators were furious about what this user did, but could you blame him?
Microsoft Exchange Server currently comes in two flavors, Enterprise edition and Standard edition. The Enterprise edition includes all the available connectors, such as the Internet Mail Connector (IMC), X.400 connector, MS-Mail Connector, Site
Connector, and Dynamic RAS Connector. The standard edition includes the MS-Mail Connector only, with the other connectors being optional components. The system requirements for both editions should be the same because the overall system requirements are
based on what services you are running.
The hardware and software requirements for the Exchange Server and Client are published as shown here:
Server
Clients
As you look over this list, you are probably wondering, How do I figure out what the requirements are for my system? You might also be asking yourself that notorious question, How many users can that machine support if I buy
it? Both questions require you to be much more involved in answering the necessary questions to come to a meaningful conclusion. This section does not cover tuning, because that topic is covered in Chapter 25, "Exchange
Server Performance Tuning and Scaling."
Generally, I suggest that you start with an Exchange server that has no less than the following specifications:
I know that I am jumping the gun when it comes to tuning, but there is a reason for the dedicated transaction log drive. If you disable circular logging for the IS (Information Store) service and routinely back up at night, you should get excellent performance from a dedicated log drive with large numbers of concurrent users. Formatting the log drive with the FAT file system also gives a measurable performance gain, but only if the logging drive is less than 1GB.
You might look over these requirements and think they are overkill for your little 50-user LAN. Well, think ahead to when it will be a 250-user LAN with many critical business processes running on the system. The server will probably be working with
large voice and imaging files, exchanging live data to an Inter/intra net, and managing large numbers of public folders. My motto is "Plan for the worst, and you will never be disappointed." If you are really worried about justifying such a
system now, just have your boss take a look at the performance available from current desktops.
The actual memory requirements for your server can be higher if it is providing these additional Windows NT services:
You should include the additional memory requirements of these services to determine the actual amount of RAM your system requires. You can calculate the general requirements of each of the previously listed services by referring to Microsoft technote
#Q139100, available in the Microsoft knowledge base. Also, as a general rule, try not to run other application services such as SQL server or SMS on your exchange box, because they will compete for similar resources and could produce undesired application
bottlenecks.
Have you taken a long hard look at your network lately? This is one of the areas most system administrators overlook when establishing the needs for a new system. Exchange Server uses a more efficient means of connectivity, termed RPC (Remote Procedure
Calls), to communicate from a server to other servers and clients. This means that it generates less network traffic than SFS-based mail systems, but it does require a higher level of available bandwidth in certain situations.
The amount of available network bandwidth needed is different for each connectivity option available in Exchange. The term available bandwidth refers to the amount of network bandwidth available to Exchange after all other network requirements
are met. For instance, you might have a very fast T1 connection to one of your locations. If the accounting system is utilizing 80–90 percent of that connection's bandwidth, you would only have only 150–300K of available bandwidth for Exchange to
use. Refer to Table 21.1 to determine the minimum network bandwidth needs for the different connectivity options for Exchange.
| Connectivity Option | Available Bandwidth | Network Options |
| Intra Site | High-speed 1.5M or higher | T1 and T3 leased lines 10M or higher LAN |
| Site Connector | 256K or higher | T1 and T3 leased lines Frame Relay 256K |
| Dynamic RAS Connector | Asynchronous 14.4–28.8 baud | Modem X.25 ISDN |
| Internet Mail Connector | Asynchronous 14.4–28.8 baud | Modem X.25 ISDN Leased line |
| X.400 Connector | 128–256K | X.25 ISDN T1 and T3 leased lines |
As you can see, the available network bandwidth determines which connectivity options you should use to connect servers or Exchange sites. These requirements are for general message delivery and do not include any of the additional Exchange
services. These are the other services that will affect your selection of a network connectivity option:
Chapter 25 covers recommendations for tuning the Exchange Server system to allow for faster network access. It also describes how to design and modify your network to provide support for the services beyond standard messaging.
Understanding how the various components of Exchange will impact your network allows for modifications prior to any implementation. A proactive network analysis lowers the possibilities of unexpected network problems—and helps keep your blood pressure
lower.
Most critics of Exchange Server claim that it was designed and optimized exclusively for Windows NT Server networks. This is true only in the fact that the server runs solely on the Windows NT platform. Exchange supports many other Network Operating
System (NOS) clients, only requiring the appropriate protocols to be loaded at the client. The default protocol support included with the Exchange Client is for
Exchange includes tailored conversion and protocol support for Novell Networks, allowing it to support NetWare native clients. Novell userid extraction tools allow you to get lists of users from your Novell servers and use the lists to create NT userids
and Exchange mailboxes with the bulk import utility. The SAP agent, a service included in Windows NT Server, is required to allow the Exchange Server to register itself for access by the Novell clients. Native NetWare clients require the most recent
updates to the client ODI support drivers, and it is recommended that you plan accordingly for your deployment.
If you are planning to install an Exchange Server in a completely Novell environment, you can make use of a few tools to make the job of account management easier on you and your users. The Directory Service Manager for NetWare (DSMN) keeps the user group and account information replicated between the NT domain and Novell 3.x servers. This allows for a single userid and password for each NetWare client, with the added benefit of bringing a robust directory service to the Novell 3.x environment.
End-users of these other NOSs will be required to log on to the NT domain when starting the Exchange Client. This additional logon is needed to properly authenticate the user from NT for secure access to ther mailbox. This is also necessary if you are
not able to keep the passwords synchronized between the NT domain and the NOS your clients are logging onto. Many users are already familiar with separate passwords for their e-mail, so this should not be a major problem.
The amount of time you spend planning for your Exchange implementation is inversely proportional to the amount of time you'll spend for actual implementation. The more proactive planning time your organization does before installation, the less reactive
"down" time will be needed during the implementation phase. Many very important decisions are made in this planning stage, requiring approval from management and acceptance by the user community. Remember, it is better to have other people in the
boat with you to bail if the boat takes on water.
When planning for your Exchange implementation, take into account the reasons your company has decided to implement Exchange. You might be converting from an existing system that is not meeting the company's needs, or installing your company's first
messaging system. In both instances, not truly knowing why you are proceeding with the Exchange installation can spell trouble for the implementation phase. Write these reasons on poster board and display them prominently at every related meeting to keep
things in perspective.
In life, there is perception and then there is reality; they are mutually exclusive. If your management is proposing Exchange as the fix for all your messaging problems, be very apprehensive. Many managers and support professionals perceive all the problems with e-mail and messaging to be caused by the current system. In reality most of these difficulties are actually related to network issues, desktop resources, improper design, unrealistic expectations, or other non-messaging problems. The planning process should expose these obstacles so that they can be corrected before your Exchange implementation.
Humans have very basic needs such as food, water, and shelter. Corporations also have basic messaging needs such as composition, delivery, and storage of messages. If any of these needs go unfulfilled for an extended period, either one would suffer. A
corporation's extended messaging needs can be divided into those of the users, those of the support professionals, and those of managers.
Determining the end-user's needs might be the most challenging part of the planning stage. You must determine the different applications and services the users must have, such as public folders, e-mail, scheduling, and electronic forms. Establishing how
each of these services will be used can help to model the resource requirements for the servers. The best way to establish the end-users' needs is to involve the users in the pilot project, allowing them to provide feedback by using the survey form from
the Exchange sample applications.
Support professionals' messaging needs are not focused on the fluff, but are deeply rooted in the manageability and stability of the system. They want to make sure that the user's needs are fulfilled, and at the same time keep their beepers quiet. They
are looking for proactive analysis tools to alert them to system problems, as well as good reactive tools to assist in repairing those problems. You should plan for a dedicated system to run the link and server monitors, and be sure to have the support
tools and resource kit installed on all servers and administrative machines.
The messaging needs of management can be directly linked to those of the users and support professionals. The management wants to make sure that their users get value from the system and that the support professionals are able to keep it running. Their
goals are also tied to the strategic technological direction of the company, such as directory services or Internet commerce. Unfortunately management will sometimes include company politics in their requirements, so be careful not to allow your messaging
system design to be shaped by politics.
To properly visualize and modify the physical network topology, you must first develop a working map of the company's geographical locations. From this map, place the various links, link speeds, link utilization, and percentage of uptime for each
location and the connections between them. You can use software packages that have been specifically designed to help you with this task, or if you are currently using network management software, this information is at your fingertips. Take this map to
your Exchange kickoff meeting, and have everyone involved validate its accuracy.
After you have a working network topology map everyone agrees on, add the messaging data from your current system. Give it to your e-mail administrators, and have them overlay it with the following information from your current system, or estimates if
you don't currently have a system:
Your map might be getting pretty crowded by this time, so you will need to be creative with the way the information is presented. You might also be dreading the time necessary to develop this map, but it will definitely pay off in the long run. From
this map you can get a better picture of how your messaging system looks today and correctly plan for servers and connectors to match the underlying network needs.
Most messaging systems have a "fingerprint" that can be used to track message statistics. Figure out specific network traffic patterns or packet signatures with network sniffing software for messages sent, received, and transferred out for each post office. Set up a sniffer to monitor each post office with filters for these fingerprints, and you will soon have all the data you need. The Microsoft Network Monitor software included in Windows NT Server 4.0 or SMS 1.x can easily perform this function.
Because Exchange depends solely on NT domains to grant secure access to messaging resources, planning for your domain topology is a very important step. Regardless of whether you have a current domain topology or are looking at implementing one,
Exchange will interact under the same set of guidelines. NT domain security is used to grant permissions to messaging resources for users, administrators, and service accounts. The various connectors have specific security requirements, and allow you to
override the security information used for that connection.
Simply put, an NT domain is a grouping of one or more servers that share common security, policy, and account databases. Servers can be Primary Domain Controllers (PDCs), Backup Domain Controllers (BDCs), or member servers in the domain. Trust
relationships allow domains to communicate with each other to utilize accounts from another domain. Microsoft defines the four basic domain models as single, master, multiple master, and full trust. For our purposes, I will examine only how Exchange works
within the single domain model and the master domain model. The multiple master and full trust models are variants of the single and master domain models, and you should avoid them if possible due to their complexity and many design challenges.
Exchange's interaction with the single domain model is the easiest to explain but the most challenging when it comes to multiple site topology design. Exchange servers are members of the single account domain, and all permissions for messaging resources
are assigned to accounts and groups in the domain. The Exchange servers can be PDCs, BDCs, or servers in the domain, depending on your user authentication needs. This domain model is good for organizations with fewer than 10,000 users that have a limited
number of locations across WAN links. Figure 21.1 shows an example of a single domain model with two Exchange sites.
FIGURE 21.1. Exchange sites in a single domain model.
The master domain model is a better choice for organizations with fewer than 40,000 users at multiple locations separated by WAN links. Exchange servers are located in the resource domains with permissions being assigned to accounts and groups in the
master user account domain (MUD). The separation of accounts and resources at the domain level adds granularity in administration of Exchange servers and sites. The Exchange servers are usually PDCs or BDCs in the resource domain, reducing the overhead
involved in replicating the changes normally associated with a Master User Domain (MUD). BDCs for the MUD should be located at each location separated by a WAN link to provide user authentication services should the PDC go down. Figure 21.2 shows an
example of a master domain model with two Exchange sites.
FIGURE 21.2. Exchange sites in a master domain model.
Larger organizations can use variants or hybrids of the different domain models to tailor their domain topology to suit their needs. In Windows NT 3.51, Microsoft suggests that you not exceed 40,000 users in a single domain, but future versions of NT
(4.0) have performance enhancements to overcome this design restriction. If your organization is fairly large (more than 10,000 users) and widely distributed, it is suggested that you break out your domain planning and Exchange implementation into separate
projects. Using this technique, you can focus on designing the best domain topology for your organization, and then utilize the flexibility available in Exchange to operate under that topology.
Even though Microsoft suggests that one Exchange service account be used for all Exchange servers in the sites, I highly recommend that you not do this. If one of your site administrators accidentally resets the service account password or locks the service account out, all the Exchange services throughout your organization will suddenly stop. I suggest that you live with the added complexity of separate service accounts for each site and utilize the security override feature on the various connectors for inter-site connectivity that crosses domain boundaries.
In planning your Exchange sites, you are not required to map to your domain topology. Site planning is based on factors that are independent of the requirements of domain design. Defining the number of sites and the site boundaries is more dependent on
your company's messaging requirements, and how messaging resources are affected by your network topology. For you to properly plan your Exchange site topology, the following requirements must be met within a single site:
Your site planning will also include other factors such as administration, performance, link costs, data replication, and the structure of the organization. For example, you might want to create separate sites for two distinct corporate divisions at one
physical location to allow for separate administration and different SMTP e-mail domain names. On the other hand, you might want to plan for sites based on geographic location and assign servers to the different organizational units for administration of
messaging resources.
You cannot fully determine the number of sites your organization needs until other planning steps are completed. You will probably change the number and location of sites many times throughout the planning process as you discover additional
requirements. Because it is very time-consuming and nearly impossible to change site names after installation, the site planning process should run parallel with the entire planning process. You should begin to add proposed site configurations to your
organizational topology map as early as possible, because this step will help the team visualize the message routing and site relationships within the organization.
Are your current naming conventions loosely based on cartoon characters or popular names for dogs? How many servers on your network have the same name because that name "sounded good"? This section is specifically targeted at your
organization, because these unstructured naming conventions will create many problems if used in your Exchange messaging system. Determining meaningful names for the objects in the Exchange directory will help users and administrators find the messaging
resources they need. Establishing naming conventions that are not affected by the ever-changing business environment will also minimize the need to frequently rebuild resources.
Because Exchange is built on an X.400 engine with X.500 directory services, your naming conventions should follow the recommendations of these standards. The X.208 recommendation defines characters that are "printable string types," and the
Exchange directory objects conform to this standard. Table 21.2 lists the allowable characters according to the X.208 recommendation, "Abstract Syntax Notation One" (ASN.1).
| Characters | Printable String Type |
| A, B, . . . , Z | Capital letters |
| a, b, . . . , z | Small letters |
| 0, 1, . . . , 9 | Digits |
| (space) | Space |
| ' | Apostrophe |
| ( | Left parenthesis |
| ) | Right parenthesis |
| + | Plus sign |
| , | Comma |
| - | Hyphen |
| . | Full stop |
| / | Solidus |
| : | Colon |
| = | Equals sign |
| ? | Question mark |
The two most important names you must plan for before installing your first Exchange Server are the Organization and Site names. The Organization name should embrace the name of the entire company, must be unique, and cannot be changed. Site
names should be related to the site's location, building name, or a user-identifiable code. Site names must also be unique and cannot be changed without a complete reinstall of all servers within the site. Even though these names can be up to 64 characters
in length, you might want to limit them to 10 or fewer characters for interoperability with external legacy systems.
Windows NT naming standards define the allowable characters for the NT computer name. Because Exchange uses the NT computer name as the Exchange Server name, you should use meaningful computer names for your servers. You cannot change the Exchange
Server name without reinstalling, so use server names that are related to the site. Windows NT Server names are limited to 15 characters, and they cannot contain the following characters:
| Bullet | A round bullet character |
| Currency sign | $ |
| Broken vertical bar | ¦ |
| Section sign | § |
| Paragraph sign | ¶ |
| Space | A space (for login script support) |
Each object in the directory has a distinguished name, which is a concatenation of the organization name, site name, recipient container, and recipient mailbox. An example of a distinguished name for a user would be
o=Dataflex/ou=Clearwater/cn=Exchange Recipients/cn=GDodge. This name can also be abbreviated by removing the labels for the naming components such as the o= and cn=. Each object also has a valid X.400 address that allows for interoperability with other
X.400-based systems.
Because every organization will want to connect Exchange to the Internet, you should consider the limitations of SMTP-based systems. You can use alphanumeric characters such as upper- and lowercase letters a through z, the numbers 0
through 9, and hyphens. The Internet address generator will use these restrictions to generate appropriate SMTP-type addresses for all exchange recipients, and you should plan appropriately in your naming conventions.
When your boss asks you to estimate the number of servers needed in order for your organization to implement Exchange, keep a very straight face and answer, "Without the appropriate planning, I estimate we need one server for every twenty
users." After your boss regains his or her composure, explain that the worst-case ratio of users to server is 20 to 1 when imaging applications are used. You should then explain that a proper analysis of the user's messaging needs can help to
determine the optimal size and number of servers for your organization.
Planning your organization's server requirements is more of an art than a science. You need to be aware of the current messaging, scheduling, and Groupware needs of your users, and you should be able to determine these needs well into the future. You
also need to be up-to-date on current and future hardware designs, as you might be asked to predict the direction the hardware industry is taking. Determining the number of servers in a site, and the primary roles of each server, requires good
visualization techniques.
These are the factors you should consider for planning server hardware requirements:
Two schools of thought exist regarding planning for the size and number of servers. One method is to purchase many inexpensive servers and distribute them throughout the organization; the other is to acquire a few expensive high-performance servers with
one for each site. I suggest that you tailor your hardware resources with a combination of both, depending on the specific needs of each site. Select hardware that can be easily upgraded over time, giving you the flexibility of adding resources as your
messaging system grows.
Planning your site topology involves the selection of connectors to facilitate mail transfer, directory replication, and public folder replication between your sites. These selections will also determine how messaging data will route throughout your
organization based on the cost associated with the various message types. These are the connector options that can be used to link sites together:
Site Connector is the easiest connector to configure, but the most demanding on network bandwidth. When using the Site Connector, plan for net available bandwidth between the sites to be no less than 64K, and it must support permanent synchronous RPC
connections. Servers in the sites using this connector have a many-to-many relationship, which means that message transfer is from the source server directly to the destination server with no additional hops. Message transfer and replication are fast and
efficient, assuming that the network is capable of supporting this type of connection. Connections cannot be scheduled or controlled because servers are continuously connecting as needed.
Dynamic RAS Connector connects sites via asynchronous modem, X.25, or ISDN connections, and it is limited in the amount of data the pipe can handle. This connector is best used for organizations that do not have an established WAN, and need to provide
site connectivity for many remote locations. Routing should be designed to have a hub site that all remote sites connect to, with messages and replication happening at scheduled connect times. This connector is also a good solution for planning backup
connections for WAN or network outages.
The X.400 Connector is the most versatile of the connector options, and it allows a higher degree of control over the routing structure and message transfer properties. Bridgehead servers are configured at each site, and redundant routes for load
balancing and fault tolerance can be established by assigning costs to each connection. If you are planning to utilize a public X.400 network backbone, this option only requires that the appropriate network transports be loaded for each MTA. Connections
can be scheduled and message size controlled through this connector, giving you flexibility in planning how Exchange will utilize network bandwidth.
The Internet Mail Connector can also fit into your plan for connecting sites, but you should use it with caution due to its limitations. Connections can be scheduled and message size controlled, but data is transferred in plain-text format and has to be
converted to and from Exchange native format and SMTP between the sites. This option fits best into your routing plans as a higher-cost backup route in case another connector or route fails. You might also decide to use the IMC to connect your sites over
the Internet, but we all know how dangerous and unreliable the Internet can be when it comes to your mission-critical business data. Who would you call when the Internet is down?
Exchange connectivity to external systems is very robust, supporting connections to MS-Mail 3.x post offices, X.400 native systems, and SMTP-based systems. Exchange can also connect to other systems through MS-Mail gateways, enabling you to leverage
existing connections that might not be available in a native Exchange connection. You should plan to install these external connections only at sites that have direct connectivity to these systems. This method will enable you to develop a routing topology
that allows all Exchange sites to utilize these connections, eliminating the need to install the connectors at each site.
In the MS-Mail environment, the Microsoft Mail Connector uses a "shadow" post office and Exchange MMTAs to link to existing post offices. Your plan for connectivity to MS-Mail should also include switching to the directory synchronization
server built into Exchange to produce a more robust global address list. You can also set up Exchange to be both a dirsync server and a requester, creating a tiered design to the MS-Mail dirsync structure and thus solving many problems for large
organizations. If you have MS-Mail AppleTalk networks, the AppleTalk MTA and gateway component should replace existing 1.0 or 3.2 connection gateways to MS-Mail.
If you need to provide connectivity between existing MS-Mail for PC Networks and MS-Mail for AppleTalk networks, Exchange is your answer. When it's configured, you can replicate the AppleTalk mailbox addresses to the MS-Mail 3.x post offices without installing the gateway access component. Because each custom recipient for the Macintosh addresses contains a valid network/post office/mailbox (10/10/10) e-mail address, users on the MS-Mail 3.x post offices can mail to these addresses, and Exchange will route them to the appropriate AppleTalk server through the MS-Mail AppleTalk MTA.
Connections to legacy X.400 systems are made through the built-in X.400 Connector. If your routing plan calls for the use of X.400 Connectors to link sites, you can leverage this backbone for message transfer to external systems. Bridgehead servers can
be configured at one site or multiple sites to provide the lowest-cost routing to external systems. You should plan for at least one X.400 Connector for every external ADMD and determine whether you want those connectors to act as relay MTAs. This portion
of your planning should be straightforward, and it will easily provide the level of service your messaging system requires.
The Internet Mail Connector will fit into any organization's plan to provide mail connectivity with the Internet or local SMTP hosts. The number of IMCs needed for your organization will depend on your current network connections to the Internet and the
message volume you expect to support. You can use two Exchange Servers configured with IMCs to load-balance your SMTP mail, or you can configure one to handle outbound traffic and the other to handle the inbound traffic to divide the load. You even have
the option of allocating an IMC for each site and configuring it to only queue SMTP mail for that site for eventual delivery to a site that has an active IMC with Internet connectivity.
To use the IMC to transfer mail to a dial-up connection at an Internet Service Provider (ISP), you need to use the RASDIAL.EXE program and a custom batch file. You first must make arrangements with your ISP to hold mail at that server and to dial up at predetermined times for mail transfer. Also, your IMC should be configured to forward all mail to a specific IP address, the address of your ISP's mail server.
Configure a RAS phone book entry for scripted logon to your ISP, and test the connection. Then create the batch file imcdial.bat, with the following format:
@echo off
:top
rasdial RAS Phonebook Entry name here
net start msexchangeimc
REM Use sleep command from NT resource kit to stay connected for XX minutes
sleep 30
net stop msexchangeimc
rasdial /disconnect
REM Use sleep command to wait for XX minutes
sleep 60
goto top
Save the file in the \exchsrvr\bin directory, and create an icon in your StartUp group that points to this file. If you do not want to log on to your Exchange Server every time you want to start this process, use the Windows NT resource kit utilities INSTSRV.EXE and SRVANY.EXE to create a service to run this process. Be sure to assign the Exchange service account to your newly created service in Control Panel so that it has the proper rights. If you have installed service pack #2 on your Exchange servers, you can select the RAS connection to use in the IMC properties page. This eliminates the need for the batch file, but you should still test the RAS connection first.
Now that you have a well-defined plan for implementation of your Exchange messaging system, it's time to examine the process of installing the server software. This section begins with the assumption that you have successfully installed Windows NT
Server Version 3.51 on your system and applied service pack #4 from the exchange CD-ROM. The computer name of your NT Server should follow the naming convention you decided on in the planning process, and the appropriate amount of system resources such as
RAM and hard disks should already be configured. The installation steps for Exchange Server are as given here:
FIGURE 21.6. The Change Directory selection.
***Start 5***
FIGURE 21.11. Selecting the Site Service Account for the Exchange services.
FIGURE 21.12. Joining an existing site via an existing server name.
FIGURE 21.13. Confirmation to join an existing organization and site.
FIGURE 21.14. Exchange Server Setup complete dialog box.
You have now successfully installed an Exchange Server, unless you experienced problems during the install. If setup failed or you received any weird messages, you should find an answer in the next section. If the setup still fails after you have gone
through that section, verify that you have met all the requirements outlined earlier in this chapter. If you are still having problems, it is time to get on the phone with Microsoft Product Support Services (PSS), or contact your Microsoft solution
provider.
The actual install process for Exchange seems fairly easy until you encounter an error that halts or ends the setup process. The installation process can bring up a few known problems, but these have easy workarounds. If you experience a problem on your
first try at an installation, then I say try, try again.
If you attempt to install Exchange on a version of NT later than 3.51 (NT 4.0), you might experience many setup errors concerning files that cannot be copied because they are open. You might also see this error message if you are running any mail-aware
applications in the background during the install. In both instances note the name and location of the file, and click the Ignore button. After the install is complete, verify that the file on your local hard drive is newer than the one on the CD, and copy
it from the CD if necessary.
Another problem can arise if you select a group for the service account when prompted during the install. The setup process should not let you do this, and it is a known bug. You need to manually assign the proper service account to all the Exchange
services in control panel, as well as the appropriate permissions in the Exchange administrator.
If you receive the message The service did not start due to a logon failure, you might have typed the service account password incorrectly. It is more likely that you left the checkbox for "User must change password at next logon" checked when
you created the account in User Manager for Domains, and it needs to be unchecked. You might also see this message if your account replication pulse has not completed and you are installing from a BDC. Wait a few minutes for the user database to replicate,
or use the server manager to force a replication immediately.
In very rare instances, immediately on starting setup you might receive an error message advising you that you do not have the "teletex" code page installed from service pack #4, even though service pack #4 is installed. This is because the
file C_20261.NLS was not properly registered as a language support module when service pack #4 updated the system. You should copy this file to the %systemroot%\system32 directory of the NT Server and add the file value to the registry for the key
\HKLM\System\Current Control Set\Control\NLS. Setup should continue correctly after doing this procedure.
Immediately after finishing the setup, you will want to run the Exchange Performance Optimizer in verbose mode. To run it in verbose mode, modify the properties of the icon for the optimizer, and add the -v option to the command line. The performance
optimizer is a straightforward procedure that analyzes the system resources of your server, asks you some pertinent questions about the role of the server, and tests the hard-drive access speeds for performance-tuning purposes. You should run the Exchange
performance optimizer any time you modify hardware resources or your organizational needs change. You can override the file locations to better match where you want specific components to be stored.
Now that your Exchange Server is installed and tuned, it is ready for configuration of the various system components. This task includes, but is not limited to, the following actions:
When you are satisfied that the system components you defined in your planning process are properly configured, you can start moving actual users to the system. At this point, I highly recommend that you expand your pilot to include additional users
outside the initial pilot, which will allow you to really exercise the system.
Your deployment plan should be well-defined by this time. You should begin to test migrate groups of users to document the conversion process. Train the people who will be responsible for the actual desktop deployment, because they need to be
comfortable with the process. The more you test at this stage, the smoother your deployment will be.
The best way to verify that the system is installed correctly is to let the users tear into it. Users have the uncanny ability to discover those configuration issues you did not identify in your planning sessions. They have a vested interest in being
involved in testing the system because they will have to use it every day to perform their jobs. Don't allow your fears of supporting users in this "pilot" test keep you from getting them involved, or you might regret your actions later.
One very valuable tool for testing the capacity and stability of your newly installed Exchange Server is loadsim. Loadsim enables you to simulate the messaging patterns of many users from a few NT workstations. This tool gives you the ability to test
how well you planned your message routing and site topology, and to test the impact Exchange will have on your network bandwidth. After you run the loadsim tool a few times, you will have solid performance statistics concerning your network and server
hardware that will enable you to eliminate system bottlenecks.
As your site topology and message routing are established, you will want to configure server and link monitors to constantly test site connectivity and server uptime. This way, you can simulate network outages or slow response times to see how your
design will react. You can also modify the actions your monitors will take for various problems, and establish which administrators are alerted to different system outages.
While you are testing the validity of your system design, send as many test messages as you can. You should have test accounts on each of the systems to which Exchange is connected to verify that the connectors are working correctly. Send all types of
test messages, such as those with large attachments, many attachments, long subject lines, and very complex rich-text formatting. You might discover that messages that worked correctly on your previous system now will not transfer correctly within
Exchange. This technique gives you more time to work on fixing these problems early on instead of wrestling with them during your deployment project.
Exchange Server is a very complex messaging system that requires a structured planning process for proper implementation. Planning for adequate hardware resources to support the organization's messaging needs far into the future will allow for the
immediate growth associated with any conversion. The Exchange network requirements affect how your site and routing topology impact the network bandwidth. Careful consideration should be given to determining the needs of your organization's users, support
professionals, and management so that they can be matched to Exchange messaging services.
The connectivity options for inter-site connectivity need good planning to match the best connector to the link's support capabilities. Connections to external systems will affect how your message routing topology is determined, creating new challenges
for your planning team. The installation of the Exchange Server software is a simple process, assuming that you have done the necessary planning up to this point. After the software is installed, you should validate and verify that the design works as the
planning sessions specified to be able to meet the needs of the organization.
The next chapter covers the administration, maintenance, and troubleshooting of the Exchange messaging system. Topics covered include disaster recovery, troubleshooting, configuration of the connectors, assigning permissions, and managing user mailboxes.
