## MS BackOffice Unleashed

- System Requirements
  - Hardware and Software
  - Network Connectivity
  - Network Operating System
- Planning and Considerations
  - Establishing Your Corporate Needs
  - Network Planning
  - Domain Planning
  - Site Topology Planning
  - Establishing Naming Conventions
  - Server Planning
  - Inter-Site Connectivity
  - External Connectivity
- Installation Procedure, Step-by-Step
- Issues and Possible Obstacles
- Configuration Tasks After Setup Is Complete
- Verifying Successful Installation
- Summary

#
— 21 —

##
Installing Exchange Server and Mail

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!"

###
System Requirements

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?

####
Hardware and Software

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

- For Intel and compatible systems:
- System with a 486/66 or faster microprocessor (Intel Pentium 90 recommended)
- 24M of memory (32M recommended)
- 250M of available hard-disk space (500M recommended)
- For RISC-based systems:
- System with MIPS R4x00 or Alpha AXP processor
- 32M of memory (48M recommended)
- 300M of available hard-disk space (500M recommended)
- Windows NT Server Version 3.51 (with service pack #4) or later
- CD-ROM drive
- 3[1/2]-inch Macintosh disk drive for Microsoft Mail Connector for AppleTalk

Clients

- For Microsoft Windows Version 3.1, Windows for Workgroups Version 3.11, and Windows 95:
- 8M of memory (12M recommended); with Forms Designer, 12M of memory (16M recommended)
- 12–22M of available hard-disk space
- For Microsoft Windows NT Version 3.51 on Intel-based systems:
- 16M of memory (20M recommended); with Forms Designer, 20M of memory (24M recommended)
- 12–22M of available hard-disk space
- For Microsoft Windows NT Version 3.51 on RISC-based systems:
- 20M of memory (24M recommended)
- 15–22M of available hard-disk space
- For MS-DOS Version 5.0 or later:
- 1M of memory (460K of free conventional memory)
- 2–3M of available hard-disk space

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:

- Pentium, Alpha, or MIPS machine with dual processor option or SMP (Symmetric Multiprocessing) capabilities
- 64M of RAM minimum, with larger systems having 128M or more
- Fast network card(s), such as 100Tx, FDDI, or 100VG
- 1GB Mirrored Fast/Wide system drive, 500M–1GB dedicated drive for transaction logs, and 4–16GB of hardware RAID5 array for information store databases
- 4X speed CD-ROM or higher
- PCI or EISA bus with a fast backplane (no ISA bus machines or ISA cards recommended)

> > 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:

- Domain controller services, such as a primary or backup domain controller
- Remote Access Services (RAS)
- Application services such as SQL server, SMS, or SNA server
- DHCP and/or WINS
- File and/or printer sharing
- Network Traffic services such as Multi-Protocol Router (MPR) or catapult proxy server
- Third-party products for such things as faxing, paging or imaging

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.

####
Network Connectivity

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.

Table 21.1. Available bandwidth requirements for each connectivity option.

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:

- Directory replication
- Public folder replication
- Value-added services such as FAX or paging
- Site administration
- Windows NT security
- Protocols utilized

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.

####
Network Operating System

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

- Local RPC (protocol independent)
- TCP/IP Winsock 1.x
- IPX/SPX
- NetBIOS
- Named Pipes (transport independent)
- Banyan Vines Protocols

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.

###
Planning and Considerations

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.

####
Establishing Your Corporate Needs

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.

####
Network Planning

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:

- Message routing topology
- Number of mailboxes for each messaging server
- Average number of messages per day at the same location
- Average number of messages per day between different locations
- Average message size per day per route
- Average number of messages transferred by gateways

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.

####
Domain Planning

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.

####
Site Topology Planning

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:

- Synchronous RPC connectivity between all servers
- Continuous network connectivity
- Same security context for service accounts
- High-speed available network bandwidth

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.

####
Establishing Naming Conventions

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).

Table 21.2. The X.208 recommendation of allowable printable string types.

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.

####
Server Planning

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:

- System memory is used to cache the directory for user object queries, transferring data to and from users and the message stores and maintaining connection information for each user.
- The system CPUs process requests for data from users, gateways, and system processes according to the NT multiprocessing model.
- Network adapter cards handle all traffic from servers to users and between MTAs.
- The disk subsystem provides storage capacity for system files, the directory database, and the information stores.
- The system’s backplane handles all aggregate intercomponent data transfer and is determined by the bus and expansion slot architecture.

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.

####
Inter-Site Connectivity

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
- Dynamic RAS Connector
- X.400 Connector
- Internet Mail Connector

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?

####
External Connectivity

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.

###
Installation Procedure, Step-by-Step

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:

1. Run the program SETUP.EXE from the directory \setup\platform on the CD-ROM, in which platform refers to I386, Alpha, or MIPS. See Figure 21.3 for the directory contents on the Exchange CD.

   FIGURE 21.3. Directory contents of the Exchange CD-ROM.

2. Click OK at the welcome screen shown in Figure 21.4. This is the start of phase 1 in the install process.

   FIGURE 21.4. The Exchange Server Setup welcome screen.

3. You are presented with the different installation types pictured in Figure 21.5. The installation types install the following components:
   - Typical: Installs the Exchange Server and Administrator
   - Complete/Custom: Installs the Exchange Server, Administrator, and all connectors
   - Minimum: Installs only the Exchange Server
   It is suggested that you always select the Complete/Custom type.

   FIGURE 21.5. Exchange Server installation types.

4. If you click the Change Directory button, you can specify the drive and directory to install the Exchange components in. See Figure 21.6 for this selection.
   Confirm creation of the new directory by clicking YES.

FIGURE 21.6. The Change Directory selection.

***Start 5***

1. Because you should have selected Complete/Custom, you should see the options list pictured in Figure 21.7. Select the options you want to install.

   FIGURE 21.7. Complete/Custom options list.

2. If you click the Change Option button while the Exchange Server selection is highlighted, you can choose which connectors and sample applications to install, as shown in Figure 21.8. Click OK when you are done with your selections.

   FIGURE 21.8. Exchange Server options list.

3. Click OK from the Complete/Custom options list to proceed to phase 2 of the install.
4. The screen shown in Figure 21.9 prompts you to join an existing site or create a new site.

   FIGURE 21.9. Organization and site information.

5. If this is your first server in a site, you should choose to create a new site. The Organization and Site information are automatically filled in from the registry, but you should override this information with the names you established in the planning stage. After you click OK, you are prompted to confirm the creation of a new site, as shown in Figure 21.10.

   FIGURE 21.10. Confirmation of the creation of a new site.

6. When you choose to create a new site, the next step is to select the service account the Exchange services will run under. Click the Browse button and select an account you created in your planning sessions. You then need to supply the password for the account to continue, as shown in Figure 21.11. You might receive a message stating that the account has been granted the Log on as a Service and Restore Files and Directories rights if this is the first Exchange Server to use this service account in the current domain.

   FIGURE 21.11. Selecting the Site Service Account for the Exchange services.

7. If you are adding a server to an existing site, you need to select to join an existing site and enter the server name of an Exchange Server in that site, as pictured in Figure 21.12. You then need to confirm that you want to join the organization and site listed for the server, as shown in Figure 21.13.

   FIGURE 21.12. Joining an existing site via an existing server name.

   FIGURE 21.13. Confirmation to join an existing organization and site.

8. The install process now begins phase 3, which carries out the following actions:
   - Records setup settings to the registry
   - Creates the setup log file
   - Copies the files and creates the script for an uninstall
   - Configures Exchange registry keys
   - Launches Exchange services
   - Configures the directory
   - Installs the connectors
   - Creates the shares on the Exchange Server
   - Replicates the directory (for a new server in an existing site)
   - Creates program manager items
9. The phase 3 portion of the install ends at the screen shown in Figure 21.14. I suggest that you skip the optimizer for now, because it is covered in a following section, Configuration Tasks After Setup. Click the Exit Setup button to complete your Exchange Server install.

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.

###
Issues and Possible Obstacles

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.

###
Configuration Tasks After Setup Is Complete

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:

- Configuring the various connectors to link sites
- Configuring directory replication between the various sites
- Disabling circular logging for the Information Store
- Setting up nightly backups of the DS and IS
- Setting up and configuring the MS-Mail Connector for 3.x post office connectivity
- Configuring the directory synchronization server and each MS-Mail 3.x post office
- Configuring an Exchange Server to act as a directory synchronization requester to an existing MS-Mail dirsync server
- Configuring the IMC for Internet or SMTP connectivity
- Configuring the X.400 Connector to external systems
- Establishing the site addressing for SMTP and X.400 address spaces
- Importing or configuring replication of foreign addresses from other systems

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.

###
Verifying Successful Installation

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.

###
Summary

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.