Deciding to Consolidate Exchange Messaging Systems

 

The decision to consolidate messaging systems should be based on an assessment of an organization's existing infrastructure. This assessment should include a graphical representation of the environment that illustrates the various regions that are administered separately, as well as the servers within these regions that store mailboxes, run messaging connectors, manage incoming browser connections, or perform other tasks. The assessment should also include a basic network analysis because network reliability and available bandwidth significantly influence the consolidation strategy.

The following figure illustrates a recommended approach to identifying consolidation opportunities.

Determining server consolidation opportunities

You should address server consolidation strategy questions in the following order:

• Is it possible to implement a central administration model?   The administration of Microsoft® Exchange Server 2003 is not bound to the physical network structure, so an organization can implement a centralized administration model for Exchange Server 2003—even across multiple geographical locations. A centralized administration model is better suited to server consolidation than is a decentralized model, because it is usually impossible to consolidate servers across regions that require independent administration. If you cannot implement a completely centralized administration, consider implementing a hybrid model in which a different Information Technology department is responsible for each individual geographical region in the organization. Each department is then centrally responsible for all those remote locations that belong to its assigned region. It might then be possible to consolidate servers into regional data centers.

• Is it possible to consolidate remote locations into a data center?   Remote locations that fall under the same administrative authority are good candidates for site consolidation if sufficient network bandwidth is available to support client/server communication with acceptable response times. As mentioned previously, Outlook® 2003 in Exchange cached mode can work over slow or unreliable network connections. However, you should conduct performance tests and pilot projects to determine whether the existing bandwidth is sufficient. An organization might have to upgrade network connections that cannot accommodate the workload, or refrain from eliminating mailbox servers in regional offices.

  Note

  To estimate bandwidth requirements, consider the number of users that connect to Exchange 2003 over the network link, the client type used to access mailboxes (for example, Outlook 2003 in Exchange cached mode or Microsoft Office Outlook Web Access), and user habits (for example, e-mail users who communicate frequently compared with e-mail users who communicate infrequently). You must also take into consideration processes that do not relate to Exchange-based client/server communication; for example, file and printer sharing or Active Directory® replication.

• Is it possible to consolidate servers within each location?   To identify servers that can be consolidated within a data center or geographical location, you must analyze the various tasks that the existing servers currently manage. Some server types are more eligible for an actual physical consolidation than others. For example, some servers might be responsible only for storing mailboxes (mailbox servers), while others might serve only the purpose of message transfer (bridgehead servers). You should consolidate mailbox servers, but it is not necessarily a good idea to consolidate bridgehead servers or Web servers onto mailbox servers in large organizations. Bridgehead servers and Web servers, due to their need for high network bandwidth, are more suited for server farms that are based on load-balancing technologies, such as Microsoft Application Center 2000.

  Note

  Server consolidation is primarily a way to concentrate user data onto a small number of servers by using a sophisticated storage subsystem. Servers that hold mailboxes and public folders are most suited for server consolidation.

• Is it necessary to replace the existing server hardware in order to manage the expected workload?   After you identify the servers that can be consolidated, calculate the final number of users that each of these servers must support. Based on these figures, estimate each server's approximate workload to determine its hardware requirements.

  Consider whether the existing server hardware can accommodate future demands. Reusing existing hardware might help to reduce costs, but do not upgrade existing Pentium Pro or Pentium II multi-processor computers to Windows Server™ 2003 and Exchange 2003. Intel discovered that an upgrade to Windows Server 2003 on servers that have two or more Pentium Pro or Pentium II processors might cause instability, data corruption, or other unpredictable results. Upgrading these platforms will force Windows Server 2003 into single-processor mode, which is a supported configuration. However, a single processor that is operating at 200 MHz is not a good choice for server consolidation. When you consolidate onto fewer servers, consider replacing existing server hardware and storage technology. The following table lists basic processor and memory configuration recommendations for mailbox servers.

  Processor and memory configurations for mailbox servers

  Number of Users	CPUs	Memory
  Fewer than 500	1 - 2	512 MB – 1 GB
  500 – 1,000	2 - 4	1 GB – 2 GB
  1,000 – 2,500	4 - 8	2 GB – 4 GB
  2,500 or more	4 - 8	4 GB

  Note

  The figures in Table 1 are recommendations for an optimal configuration. It is possible to support a greater number of users and at the same time, use less hardware. Microsoft, for example, is currently operating a number of four-processor Exchange 2003 servers that have 4,500 mailboxes each. Server performance can be improved by using additional processors, but the four-processor configuration works.

  The following factors influence your Exchange server hardware design:

  • **Connected users versus total users   **When you design server hardware, estimate how many users will connect to the server concurrently. For example, performance requirements might be lower if not all users connect at the same time; for example, when users work in shifts. However, the server background activity increases as the number of mailboxes increases, even when users have not logged on to the system. For example, database defragmentation activity increases on a server storing thousands of mailboxes. Always consider background activities when you design server hardware.

  • Location and use of message stores   Exchange users can store their messages in server-based mailboxes or in personal folders (.pst files) on their local client computers or on a network drive. Users can reduce a server's storage and processing workload by setting their default delivery locations for messages to their personal folders. For example, when a user opens or saves an item in a personal folder, the Microsoft Exchange Information Store service on the server is not involved. However, when you decide whether to use personal folders in this way, consider the fact that storing all messages in personal folder stores on local client computers makes it impossible to back up messages centrally.

    Note

    To require users to store messages in .pst files on their client computers, configure mailbox quotas for the mailbox stores. If a mailbox exceeds its size limits, the user must reduce the amount of data by downloading messages to the .pst file or deleting them. Otherwise, the user cannot continue to receive and send e-mail messages.

  • User habits and messaging clients   When you design server hardware, consider the number of messages users send and receive per day. Also consider the types of clients that they use. Outlook 2003 and Outlook Web Access 2003 place different workloads on a server. If your users primarily use Outlook Web Access 2003, assume additional processing requirements for Internet Information Services (IIS).

  • Public folder usage and replication   Public folders can have a significant impact on server performance, depending on folder size, frequency of access, number of different views for each folder, number of replicas, replication schedule, and frequency of content changes. Place large public folder repositories on a dedicated Exchange server that does not store any user mailboxes. Exchange servers that store public folders are sometimes called public servers.

  • Connectors and gateways   Connectors and gateways are messaging components that can substantially increase a server's workload. Message transfer involves server-to-server communication and might require message conversion. As mentioned previously, do not configure connectors or gateways on large mailbox servers. An organization can benefit from servers that are dedicated to message transfer. Another option is to migrate all messaging systems to Exchange 2003, thereby eliminating the need for messaging gateways.

  • **Is the server hardware correctly designed according to service level agreements? **  You can use Exchange 2003 stress and performance tools on a test server to verify whether its hardware is designed to accommodate the number of mailboxes you want to place on the server. For example, you can use Load Simulator (LoadSim) (LoadSim.exe) to test how an Exchange 2003 server responds to a large number of Outlook 2003 clients. Another useful tool is Jetstress (JetStress.exe), which you can use to simulate disk input/output (I/O) load to verify the performance and stability of your disk subsystem. You can download these tools from the "Downloads for Exchange Server 2003" Web site. To determine how many mailboxes Exchange 2003 servers of a given class can support, you might also want to read the performance benchmark studies at the "Performance Benchmarks for Computers Running Exchange Server 2003" Web site. Another source of information on this topic is Troubleshooting Microsoft Exchange Server 2003 Performance.