Lesson 3: Dedicated Servers in an Exchange 2000 Organization | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Exchange 2000 Server, as it comes out of the box, is a universal messaging and groupware platform. By default, every machine is a mailbox, public folder, and a connector server, hosting several Internet virtual servers and possibly Instant Messaging (IM) and Chat services. With so many services in one unit, you need a very powerful machine to achieve top performance. As the number of users per system increases, splitting the roles across several servers becomes an interesting alternative. It gives you the ability to dedicate the server hardware to specific tasks, and it allows you to structure the administration according to individual server roles. For instance, you could place all connector servers in a separate administrative group and delegate full control permissions to routing administrators only.

This lesson discusses the advantages of splitting server roles and distributing them across separate Exchange 2000 servers. Following a brief introduction to the various roles a server is able to assume, you will read about how to design the server infrastructure of an Exchange 2000 organization.

After this lesson, you will be able to

Describe the roles an Exchange 2000 server can assume
Determine whether to separate server roles to best satisfy the users in the various routing groups of an Exchange 2000 organization

Estimated time to complete this lesson: 45 minutes

Possible Roles of an Exchange 2000 Server in a Routing Group

Recall from Chapter 4, "Assessing the Current Messaging Infrastructure," that a messaging structure typically consists of private, public, and bridgehead hosts. In an Exchange 2000 organization these correspond to mailbox, public folder, and connector servers.

Dedicated Mailbox Servers

Mailbox servers, as their name implies, are dedicated to holding user mailboxes. In more complicated language, a dedicated mailbox server is a server where all public stores are removed and only mailbox stores exist. Figure 5.13 illustrates the configuration of a dedicated mailbox server. Users can work with a MAPI-based client or an Internet mail client (IMAP4 or POP3) to access mailbox resources. Every mailbox server is also accessible via the Web Storage System (WSS) and the Hypertext Transfer Protocol (HTTP)/Web Distributed Authoring and Versioning (WebDAV). You can read more about the configuration of mailbox stores for maximum fault tolerance and resilience in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server."

Figure 5.13 - A dedicated mailbox server configuration

Note

When configuring dedicated mailbox servers, keep in mind that at least one public store holding the MAPI-based public folder hierarchy must exist in the organization. It is not possible to remove the public stores from all servers in the organization.

Dedicated Public Folder Servers

Dedicated public folder servers, or short dedicated public servers, are those that do not have a mailbox store. Only public store databases are configured in the Information Store (Figure 5.14). Public servers are especially useful if you intend to implement mission-critical workgroup and workflow solutions. Users can access public folder forums using a variety of clients and protocols, including MAPI, HTTP/WebDAV, IMAP4, and the Network News Transfer Protocol (NNTP). Potentially, all users in an organization may access the same server. For this reason, it is usually a good idea to equip public servers with powerful hardware. Public folder access strategies are further discussed in Lesson 4.

Dedicated Connector Servers

Connector servers are dedicated to the task of running the various connector types in a routing group. They are commonly known as bridgeheads. Besides RGCs, bridgeheads may also host connectors to MS Mail, Lotus cc:Mail, Lotus Domino/Notes, or Novell GroupWise, and third-party gateways. It is important to note that bridgeheads require at least one mailbox store because the message queues of many connectors reside in the private information store. Many message queues are located in hidden system mailboxes, so to speak.

If you intend to build large routing groups with a significant number of users who communicate heavily with users in other routing groups and foreign messaging systems, bear in mind that there is a high risk of overwhelming a single connector server. Growing message queues and delays in message transfer are indicators of this problem. Bridgeheads can be very busy machines. Message routing requires the connector server to frequently retrieve routing information from Active Directory. Messages addressed to recipients in different routing groups must be split into separate copies (as explained in Lesson 2), and message transfer to foreign systems requires conversion of recipient information and message formats. If the sum of these activities represents a substantial workload, configure multiple servers to run the connectors. Very large organizations often opt to run no more than one connector per bridgehead.

Figure 5.14 - A dedicated public folder server configuration

Advanced Server Configurations

Besides mailbox, public folder, and connector servers, an Exchange 2000 organization can also contain servers with very specialized purposes. Many of these advanced server configurations are particularly interesting for application service providers (ASPs) that plan to host a tremendous number of users. This includes front-end/back-end server configurations, IM servers, Chat hosts, and data and video conferencing servers. Another important type is the public-key infrastructure (PKI) server, which issues X.509 certificates to your users, if you want to enroll them with advanced security for message signing and sealing. You can read more about the design of advanced server features in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."

Designing the Server Hardware

It is difficult to make specific recommendations about server hardware, as the industry is quickly introducing new systems. "The more powerful, the better" may be a good slogan. In general, the CPUs of your Exchange 2000 servers should be as fast as possible. When planning to add new hardware in the future, such as additional processors, keep in mind that every upgrade requires downtime. Hence, estimate the full workload before purchasing the system and do not consider upgrading the hardware in stages over a time frame of more than a year.

For mailbox and public servers, consider one processor and 256 MB of RAM for every 500 users (so two processors and 512 MB of RAM for 1000 users), and for connector servers, two processors and 512 MB of RAM. Large organizations may even want to consider quad-processors with 1 GB of RAM for central (and very busy) bridgeheads. Do not forget to equip your servers with the fastest network interface cards (NICs) that your network can support. Typical system requirements for Exchange 2000 Server are discussed in Chapter 3, "Assessing the Current Network Environment."

Also important is the configuration of the hard disk subsystems. Mailbox and public servers require a fault-tolerant disk system, such as a redundant array of independent disks (RAID) with parity. When selecting a disk subsystem, carefully match the I/O speed, RAID controller performance, and disk redundancy to your requirements.

Note

Microsoft provides a tool called Load Simulator to check the behavior of an Exchange 2000 server in a test lab under altering conditions. Performance tests allow you to reliably determine the required server hardware. Load Simulator is included in the Microsoft Exchange 2000 Server Resource Kit.

Designing the Server Infrastructure

As discussed in Chapter 3, "Assessing the Current Network Environment," you need to review the existing network infrastructure to determine appropriate locations for your mailbox and public servers, and the routing group topology determines the number of bridgehead servers required. In every routing group at least one server must assume the role of a bridgehead server. Otherwise, e-mail transfer cannot take place across routing group boundaries. Whether you need a single dedicated connector server or several depends on the number of users and the amount of e-mail they generate. Of course, the actual number of connector servers also depends on the number of RGCs that you plan to deploy. You should design the server infrastructure for each routing group individually.

The most important design questions revolve around the project budget. Implementing dedicated servers will allow you to improve the overall performance of the messaging organization, but it may not be reasonable to split the tasks if the number of users is relatively small. For instance, in a routing group of 250 users, you do not need to implement dedicated mailbox and public folder servers, but it may still be within budget to give this routing group a dedicated bridgehead. The users may have to communicate heavily with users in other routing groups. On the other hand, in a routing group with 2500 users, you may want to place all mailboxes on a quad-processor machine with a highly sophisticated disk subsystem and 1 GB of RAM. In this situation, your users would benefit if you added a dedicated public server and connector servers because the mailbox server will be a very busy machine anyway. Exchange 2000 Server is able to balance the workload between multiple bridgeheads, and redundant RGCs between the same routing groups can improve fault tolerance if they rely on different physical network links, as explained in Lesson 2.

Note

Routing Group connectors allow you to specify multiple bridgeheads in the connector configuration, but this does not imply that load balancing is performed. Exchange 2000 Server always uses the bridgehead on the top of the list unless this server is unavailable, in which case the next bridgehead is contacted, and so forth. To achieve load balancing between routing groups, configure multiple connectors and assign them the same cost value.

Designing a Server Infrastructure for Adventure Works

Adventure Works decided to implement a separate routing group for each of its geographical locations (Canada, the United States, South Africa, and Australia), as outlined in Lesson 2. Each location has 500 users and John Y. Chen estimates that every user sends an average of 3 messages per day to recipients in other locations. Per routing group, that is 1500 daily messages or approximately 200 messages per hour. Chen does not expect the average message size to exceed a few kilobytes.

"Although we plan to implement sophisticated workgroup and workflow applications," says Mr. Chen, "our current budget does not include dedicated workgroup or workflow systems. We may be able to implement public folder servers in the future, but for now, our mailbox servers will have to sustain the workload of both mailbox and public folder access. For this reason, we will be purchasing dual-processor machines with 300 GB of disk space and 512 MB of RAM and expect no serious bottlenecks. Similar machines with significantly less disk space (27 GB mirrored disks) will be purchased and installed as bridgehead servers. Because of the expected message traffic, we plan to install a dedicated bridgehead in every routing group. Messages may be routed to the mailbox servers directly, just in case the bridgehead servers are down." The server infrastructure of Adventure Works is shown in Figure 5.15.

Activity: Designing Server Infrastructures

In this activity, you will design the server topology for Consolidated Messen- ger and Litware, Inc. Administrative and routing groups were designed in previous activities.

Figure 5.15 - The server infrastructure of Adventure Works’ Exchange 2000 organization

Tip

You can use Figure B.15 in Appendix B as a guide to accomplish this activity.

Scenario: Consolidated Messenger

Consolidated Messenger is planning to deploy an Exchange 2000 organization with one routing group and three administrative groups, structured as shown in Figure 5.16. The company has 1500 employees in Portland, Oregon. Five hundred of them work in the Video department. Consolidated Messenger does not plan to implement workgroup or workflow applications in the foreseeable future, but does require Internet connectivity.

"At Consolidated Messenger, we heavily use e-mail to communicate with our customers over the Internet. Our current SMTP gateway is constantly overstressed. We definitely need to solve this problem in our messaging environment. We have a 4-Mbps Internet connection in place. We also have the budget to purchase as many servers as necessary, but of course, we should spend our money wisely. Generally, I consider dual-processor machines with 512 MB of RAM appropriate," said Gregory J. Erickson, Senior IT Administrator.

Figure 5.16 - Administrative and routing groups in Consolidated Messenger’s Exchange 2000 organization

It is your task to decide how many servers Consolidated Messenger should install, for what purpose, and in which administrative group.

How many mailbox servers should you install in Consolidated Messenger’s Exchange 2000 organization, and to which administrative groups should they belong?
How many public folder servers should you install in Consolidated Messenger’s Exchange 2000 organization, and to which administrative groups should they belong?
How many connector servers should you install in Consolidated Messenger’s Exchange 2000 organization, and to which administrative groups should they belong?

Scenario: Litware, Inc.

Figure 5.17 illustrates the administrative and routing group topology of Litware, Inc. The company plans to implement one administrative group with two routing groups for their sites in Los Angeles and Washington, DC. Litware’s hardware standard for server platforms is a dual-processor machine with 512 MB of RAM. The company is considering the implementation of workgroup applications, but this is the objective of a follow-up project. "We will plan our public server infrastructure at a later time," said Nikki McCormick, Chief Information Officer at Litware, Inc. "For now we are focused on the implementation of a powerful and reliable messaging infrastructure."

It is your task to decide how many mailbox and connector servers Litware, Inc. should deploy in their routing groups.

How many mailbox servers should you install in the routing group RG Los Angeles?
How many mailbox servers should you install in the routing group RG Washington, DC?
How many connector servers should you install in Litware’s Exchange 2000 organization?

Figure 5.17 - Administrative and routing groups in the Exchange 2000 organization of Litware, Inc.

Lesson Summary

Exchange 2000 organizations consist primarily of mailbox, public folder, and connector servers. A single Exchange 2000 server can assume all these roles, but it is advantageous to split and distribute the responsibilities across multiple machines. Dedicating hardware to specific tasks can increase the overall performance of the messaging organization. Whether you can deploy multiple dedicated servers per routing group depends on the number of users and the project budget.

Mailbox and public servers should be equipped with one processor and 256 MB of RAM for every 500 users. Connector servers may require two processors and 512 MB or even more if they are very busy machines, such as central bridgeheads in a large organization. Of course, the servers require the fastest NIC your network supports. Also important is the configuration of the hard disk subsystems. Mailbox and public folder servers require fault-tolerant mass storage and the disks of connector servers must allow fast I/O operations.

You need to review the network infrastructure and routing group topology to determine appropriate locations for mailbox, public, and connector servers. Every routing group must contain at least one bridgehead server. This does not necessarily have to be a dedicated machine, but for a large number of users a dedicated bridgehead can measurably improve system response times, depending on the number of users and the amount of e-mail they send and receive.