Exchange 2000 and Server Consolidation

Updated : August 4, 2001

Contributors

Jens Trier Rasmussen, Senior Consultant, MCS EC3
Luis Caldeira, Consultant, MCS PT
Peter Nilsson, Principle Consultant, MCS UK
Jeremy Cowan, Consultant, MCS US

On This Page

1 Introduction
2 Exchange 5.5 Server Limitations
3 Large Messaging Database Size
4 Web Client Scalability
5 Exchange and Application Coexistence
6 Single-Purpose Exchange Servers
7 Conclusion

1 Introduction

With the release of Microsoft® Windows® 2000, you may be trying to decide whether Microsoft Exchange 2000 will fit into your current environment. Electronic messaging has become a mission-critical application for every major corporation in the world, and if your current Exchange system is stable, why should you upgrade simply because there's a newer version? You want to be sure that you are able to see a return on the resources you expend to upgrade your Microsoft Exchange 5.5 servers.

This document discusses how the consolidation of the services offered by multiple Exchange 5.5 servers onto a smaller number of Exchange 2000 servers helps in this situation. It also outlines how Exchange 2000 improves on your reliability, recoverability, and maintainability in the process.

In addition to server consolidation, there are many other reasons to upgrade to Exchange 2000, including video and data conferencing, instant messaging, streamlined routing protocols, more redundant routing in the Exchange 2000 organization, and synchronous event sinks. Therefore, even if you don't need to perform a server consolidation, it is recommended that you think about these other capabilities when you consider an upgrade to Exchange 2000.

2 Exchange 5.5 Server Limitations

Though Exchange 5.5 is a scalable application and has been proven to afford much greater reliability than other computer-based messaging systems, there are some inherent limitations in the product.

The following four sections discuss some of the limitations encountered during messaging-system deployment. They are followed by a discussion of how Exchange 5.5 has been used to meet these needs and a discussion of how Exchange 2000 and Windows 2000 can enhance the solution. These sections also discuss how Exchange 2000 and Windows 2000 can reduce the amount of hardware necessary for a messaging solution.

Keep in mind that these solutions won't be used by every organization that chooses to deploy Microsoft Exchange 2000. However, using one or more of these solutions will help you scale your messaging system much better than you could when using previous products.

3 Large Messaging Database Size

Exchange 4.0 had a 16-gigabyte (GB) database size limit. This limit was sufficient for the hardware at that time, which could handle only about 500 users adequately. However, as hardware became more advanced, newer systems required larger numbers of users. Microsoft's previous e-mail product, MS Mail, could host up to 500 users on a single post office.

However, 16 GB for 500 users (not taking single instance into account) provides approximately 32 megabytes (MB) per user. This means that, even when keeping the mailboxes fairly small (most customers run at 50 MB per mailbox), the Exchange 4.0 database became overloaded relatively fast.

Exchange 5.5 provided the unlimited store1, which allowed the single Exchange 5.5 mailbox database to grow well beyond the 16-GB limit. However, another problem arose. As customers began hosting more users, their stores grew, and occasionally a server had to be restored. These large stores took much longer to restore. Advancement in hardware technology, with backup speeds of approximately 40 GB per hour and restore rates of approximately 25 GB per hour, handled only part of the problem.

Therefore, due to the limit normally imposed by backup-and-restore technologies, few corporations installed large systems to host huge numbers of mailboxes.

3.1 Exchange 5.5 Mailbox Server Farms

Figure 1: Exchange 5.5 Mailbox Server Farms

The previous discussion explains why Exchange 5.5 has a low limit on how much data can be hosted on a single server. Because of this, many Exchange customers have deployed large farms of Exchange servers to host their user mailboxes. These server farms are normally hosted on 100-megabits per second (Mbps) or higher networks and can coexist with their other infrastructure servers. Although this allows extremely fast server-to-server communication, a large number of servers is more difficult to manage.

All Exchange 5.5 servers host a directory that is replicated directly to every other Exchange server in their site, which causes these servers to host much more network traffic than is necessary for the actual mailboxes.

Figure 2: VIP Exchange 5.5 Servers

Because of the varied requirements for the recovery of some of these systems, some mailbox servers have very small databases (less than 5 GB). These small individual mailbox databases can be restored in minutes, rather than hours, at the cost of additional hardware to support these systems.

3.2 Exchange 2000 with Multiple Databases

Figure 3: Exchange 2000 Cluster Databases

For customers hosting large numbers of Exchange 5.5 servers in network farms, Exchange 2000 provides the ability to host all databases on a small number of Exchange 2000 clusters. Exchange 2000 can host up to 20 Exchange databases on a single cluster, grouped into four storage groups, each with five databases. If each database hosts as few as 400 mailboxes (which, coupled with a 50-MB mailbox size limit, keeps the database sizes under 20 GB), this cluster can host 8,000 mailboxes with a maximum of 400 GB of data. Backup might take a long time2, but remember that you need to restore only the databases that might be having problems. In addition, you can back up the store while clients are accessing the system.

This solution also provides relief to customers who want to host small databases for their most important users. Because the server can host 20 databases, one of these databases can be the smaller VIP database, and the recovery of any single database does not impact any of the other databases on the system. This allows for high availability for that VIP database, while still allowing an administrator to recover a failed database on the same system.3

With Exchange 5.5 clustering, Exchange services could not be active on both cluster members. An advantage of Exchange 2000 is that clusters are in an active-active configuration where each system hosts connections to mailboxes. This allows a customer to size their cluster servers for the number of mailboxes they would host during a failure, even though each server actually hosts only half that number during normal operations.

Another advantage of Exchange 2000 is that not every Exchange server is required to host the directory. This means that a single Windows 2000 domain controller can host directory access for large Exchange 5.5 server farms that can't be hosted on one or two Exchange mailbox servers. The current recommendation is to have one Windows 2000 domain controller for every four Exchange 2000 servers. This means that if the systems are configured as shown in Figure 3, domain controllers would be required for every 16,000 users. Therefore, it is possible for a few domain controllers to host huge user populations.4

4 Web Client Scalability

In Exchange 5.0, Microsoft introduced a Web front-end to access Exchange e-mail. In Exchange 5.5, this application is called Microsoft Outlook® Web Access (OWA). OWA consists of about 80,000 lines of Microsoft Internet Information Server (IIS) Active Server Pages (ASP) code that runs on either an Exchange server or on a Web server built specifically to access the Exchange servers. However, due to the architecture of these OWA servers, they can support only about 300 simultaneous users in an operational environment.

This means that organizations currently hosting 2,000 or more mailboxes per Exchange server require at least seven servers to host OWA access for each Exchange mailbox server. Each of these servers also requires as much RAM as the Exchange servers they support, because the front-end servers run the ASP for all the users in real time. This is one of the major shortcomings of ASP applications—they don't scale well for large applications.

4.1 Exchange 5.5 Web Server Farms

Figure 4: Exchange 5.5 OWA Server Farms for 2,400 Exchange 5.5 Mailboxes

Because Exchange Web servers have limited scalability, several OWA servers are required to access a small number of Exchange mailboxes. However, because it is easy to deploy the client, which is actually the Web browser on the workstations, and because there are fewer configuration issues, many corporations have decided to accept the number of systems this solution requires.

These corporations typically deploy OWA farms to host incoming Web clients, and they even place these farms behind a single namespace, by using Windows Load Balancing Service (WLBS) or similar products. This allows more simple client access than deploying the more complex Microsoft Outlook client to all the desktops, so that even though there is a large initial expenditure, some of this cost is relieved by simpler client configuration and deployment.

4.2 Exchange 2000 OWA Services

Figure 5: Exchange 2000 OWA Services for 16,000 Exchange 2000 Mailboxes

During development, the primary goal of the Exchange 2000 development team responsible for the Web client was to build scalability into the client. They sought to allow Exchange 2000 OWA services to run locally on the Exchange 2000 server and be able to support as many mailboxes as the server could host. If 2,000 mailboxes are hosted on an Exchange server, then that server should be able to support all of them for OWA access concurrently.

Tests run on Exchange 2000 show that the Exchange OWA team has almost reached this goal. With an Exchange 2000 server, users can use either their Outlook client or the Exchange 2000 Web client to access their mailboxes. In addition, if an organization wants to remote the OWA access from the mailbox server, every front-end server can host all OWA mailbox access for every four back-end Exchange servers. In the example shown in Figure 5, the three OWA servers running behind WLBS each host more than 5,000 simultaneous connections (one third of the 16,000 mailboxes on the supported mailbox servers), and they host as many as 8,000 connections if one of the OWA servers is taken offline. In addition, these front-end servers can be relatively low-powered systems, and if additional response is required, another front-end server can easily be added to the infrastructure.

5 Exchange and Application Coexistence

Exchange uses all available resources, whether or not there is another application running on the same system. For this reason, many organizations have been cautious about running Exchange on the file-and-print server in a remote office, or even hosting responsibility for controlling Microsoft Windows NT® account domains on the same system they're using for Exchange.5

In addition, Exchange 5.5 alone does not enhance other applications, so there is little reason to run Exchange on the same system on which other applications are running. Specifically, Exchange 5.5 can be run from an intranet, but few organizations are hosting intranet applications on Exchange 5.5 systems.

The following sections discuss these two issues. The first two sections explain the small-office scenarios, and the last two sections discuss Exchange and Web application enhancement.

5.1 Exchange 5.5 in Small Offices

Figure 6: Small Office Server Configuration

Many customers have both large and small offices that require the same services. In many cases, this means that file and print services, messaging services, account validation services, databases, and so forth, must be deployed in these offices. Exchange resource requirements often dictate that a separate system be deployed for messaging services. In addition, because Exchange 5.5 doesn't enhance other applications, it is rarely combined with services such as Web services. This means that three or more servers might be required in those small offices.

Additional small office expenditures are seen in additional hardware for resource domains. These resource domains host file and print services or infrastructure services for these offices without impacting the administrative model used in the account domains. Because these resource domains are typically small, their domain controllers typically host these additional services.

5.2 Exchange 2000 in Small Offices

Figure 7: Small Offices with Exchange 2000

In small offices with Exchange 2000 servers, messaging services can coexist with account validation, database, and file-and-print services. The Exchange 5.5 Performance Analyzer functions are built into Exchange 2000, which enable an Exchange 2000 server to dynamically modify its operational parameters. This enables Exchange 2000 to coexist with other applications without requiring an administrator to stop the services to change memory allocation.

Because Windows 2000 allows resource domains to be incorporated into account domains by the use of organizational units, resource domains are no longer necessary. This means that the services (file and print resources, Exchange 2000, and domain controller services, in addition to network services such as Dynamic Host Configuration Protocol [DHCP], Windows Internet Name Service [WINS], and Domain Name System [DNS]) for an entire small remote office can be hosted on a single server, thereby reducing remote hardware and management requirements.

When using Windows 2000, an additional benefit is that Terminal Services can be loaded onto the same system that is running the services already mentioned (administrative mode only). This allows remote administration of the system, as long as someone is available to change backup tapes regularly.

5.3 Exchange 5.5 and Web Applications

Figure 8: Exchange 5.5 and Web Application Support Scenarios

Exchange 5.5 has not been used to host Web applications. While Exchange 5.5 can be accessed from Web browsers, the URLs required to access the Exchange system are not intuitive. Applications run on Exchange 5.5 aren't much more functional than those that are run in the file system. In addition, a Web server can't simply store and retrieve data from the Exchange server; it must use the same MAPI/CDO (Collaboration Data Objects) access that other native Exchange clients use.

5.4 Exchange 2000 and Web Applications

Figure 9: Exchange 2000 and Web Application Support Scenarios

Hosting applications on Exchange 2000 is a new idea. Exchange 2000 adds the Exchange Web Storage System, which can be accessed in the same way that the file system or current Web pages are accessed. When Exchange 2000 is installed on the system, a new virtual disk is added to the system. This drive corresponds to the Web Storage System. You can traverse it and perform functions just like you would in any file hierarchy—by using the DOS commands CD, MD, COPY, and XCOPY. Users can save documents to these folders in a way similar to saving documents to standard shares on file servers. One advantage to this is that in Windows Explorer, these shares expose all the information stored with the document. This includes the author, revision information, and so forth, which you can see by checking the properties of a document.

By default, you can also access the Web Storage System through a Web browser. The URL for the default Web Storage System public folders is https://<Exchange server name>/public. Folders off this root are addressable in the same format; for example, the URL for a folder called Corporate is https://<Exchange server name>/public/Corporate.

These added functions are augmented by the fact that the Exchange database allows faster Web access than the standard file system does because the file system has the added overhead associated with opening and closing the files. The Exchange database doesn't have this shortcoming – the database is open all the time; the data just needs to be read from it.

With these enhancements, Exchange 2000 can be used in conjunction with Web servers and Microsoft SQL Server™ to create more functional applications. In addition, Exchange 2000 can be installed with these applications (in fact, Exchange 2000 requires IIS on the same box to function), and you can build very robust single-server Web application servers that include Exchange 2000.

6 Single-Purpose Exchange Servers

Since the release of Exchange 4.0, administrators have installed several basic types of Exchange servers—servers for mailboxes, public folders, connectors, and various other specific needs. This allows a problem system or database to be isolated from the rest of the Exchange servers in the location or site. However, these multiple servers add to the complexity of an Exchange organization.

6.1 Single-Purpose Exchange Servers

Figure 10: Single Purpose Exchange Servers

In many Exchange 5.5 organizations, there is a need for multiple servers so that each server does not affect other servers in, or the functionality of, the Exchange organization. For example, most customers don't want the connection to the Internet or to other messaging systems running against the same database they're using at the same time for their mailboxes. This forces them to have multiple server configurations (smaller ones for connectors, larger ones for mailboxes or public folders) and specific server build instructions.

This adds complexity to the implementation and to the routing tables for the system. For instance, each mailbox server must send a message to the Internet connector server before the message can be sent to the Internet. In small organizations, this is an unnecessary hardware expenditure.

6.2 Multi-Purpose Exchange Servers

Figure 11: Multi-Purpose Exchange 2000 Servers

With Exchange 2000, you can build Exchange servers that can handle mailbox traffic and connectors, while keeping the two segregated. Figure 11 shows how to segregate the connectors by giving each its own database in a connector storage group, which provides these connectors with their own log and databases. This is an extreme case that ensures that connector traffic does not corrupt mailbox access. There are separate databases for applications and public folders.

In addition, any of the connector databases can be taken offline, deleted, and rebuilt without affecting access to the mailboxes hosted on the same server.

The routing for messages going to and from this system is simple—messages go out and come in. When one of the users in SG 2 or SG 4 sends to the Internet or to one of the applications in SG3, the messages go directly to the Internet.

7 Conclusion

This document shows several areas where the architecture of Windows 2000 and Exchange 2000 can reduce the number of servers an organization requires. The four main ideas mentioned are mailbox server consolidation, OWA server consolidation, application server consolidation, and the use of multifunction Exchange servers. If you have more than two Exchange 5.5 servers, or if you are hosting Web applications along with Exchange services, you should consider using Windows 2000 and Exchange 2000 to consolidate your systems.

1 Hardware limitations for hosting huge drive arrays make the practical limit for the size of an Exchange 5.5 database in the 1- to 5-terabyte range.

2 Backing up 400 GB of data takes about 10 hours with the highest speed hardware, if the databases are backed up sequentially. However, Exchange 2000 allows multiple databases to be backed up simultaneously.

3 Microsoft Corporation is working with hardware vendors to build backup capabilities that will allow much faster database backup and recovery. These capabilities will be built into later versions of the Exchange products.

4 In organizations with many sites, the location of domain controllers should be considered as part of any Exchange 2000 project. Microsoft Corporation recommends maintaining at least two central domain controllers, and each site can host a domain controller, depending on network reliability and network saturation. In addition, because access to a global catalog server is required when clients log on, each remote domain controller should be considered for the global catalog role.

5 Although it is possible to limit the amount of memory an Exchange 5.5 server uses, this is not a dynamic process. Because most customers cannot bring their Exchange server offline for fine-tuning its performance, they must limit memory usage before they know it is a problem.