A session summary from the Microsoft Exchange Planning Workshop heldSeptember 19-21, 1995, in Bellevue, Washington.
Server Performance Issues and Recommendations
Software ConsiderationsSite Topology Issues
Hardware Considerations
Microsoft Exchange Server and Windows NT
Microsoft Exchange Sites and Windows NT-based Domains
The issue of how to scale servers properly is central to any discussion of Microsoft® Exchange Server planning. Many organizations may have the same question: "How many users can I put on each server?" Although it's impossible to state an answer that is appropriate for every organization, you can consider some important issues as you make your decision. For example, is your typical user someone who composes 40 messages a day, reads 60, and has 20 server-based rules running, or someone who receives 5 messages a day and sends 2? Likewise, what is a server in your organization? A 486 with 24 megabytes of RAM, or a 6-processor Sequent® with 120 megabytes of RAM hosting 5000 users?
Many other factors can also impact server scalability. These factors fall into two categories: software considerations and hardware considerations. Within software considerations, you should determine two distinct types of actions: client-initiated actions and background server actions. The following sections provide more details about each of these considerations.
Software considerations are associated with client and server actions.
You can think of synchronous client-initiated actions as things users actually see and do—for example, opening a public folder. These client actions are completely dictated by what the user does. A client workstation logged into a Microsoft Exchange Server computer, but sitting idle during lunch, is causing very little server load, while someone reading mail, posting to public folders, and actively using rules is causing a decent load on the server. The server performance goal is to minimize the user's response time by maximizing the server's ability to handle client-initiated actions.
The client interacts with the server through remote procedure calls (RPCs), and most of these RPCs are to the information store. At a lower level, the bulk of the actual "noise" on the wire is either client-server interactions or actual messages. These interactions can be significantly reduced if users place their personal information store (PST) on their local hard drive. This eliminates the need to access the server every time users want to read messages; therefore, it will reduce overall network traffic and reduce the server load.
The user's perception of performance is highly dependent on response time. If it takes the server five seconds to open a mail message, the user will feel that the system is slow. As a result, you should be sure to consider user response time when you determine server configurations.
You can think of server background actions as things that clients inadvertently cause and may never be aware of, such as sending a message to 1000 users. These actions are performed on the user's behalf using background cycles on the server. Generally, users are less sensitive to background response times than to slow client response. However, an excessive number of background actions will slow the client response, so be sure to properly balance the server for peak periods of background processing.
The largest consumer of background resources is message delivery. The cycles required for message delivery are directly proportional to the volume of mail generated by your users. So accurately determining what a "user" is within your organization is key to projecting your message delivery needs.
The cycles used in public folder replication are proportional to modifications in the public folder. Public folders that are constantly changing will utilize significantly more cycles than a static public folder. Careful placement of public folder servers within a site can prevent needless replication, and still provide users access to all public folders. More information on this can be found later in this document.
The impact of directory replication will probably be negligible, with distribution list modifications being the largest contributor. Bulk imports, typically performed when installing a new Microsoft Exchange Server computer, will cause an initial load on the servers. This load will be greatly reduced once this information has been successfully replicated.
Additional background tasks place loads on the server that are not related to user demands. In fact these tasks may even take place when no users are logged on. These would include tasks such as gateway processing, other server applications, and event/diagnostic tracking. Additionally, housekeeping tasks, such as garbage collection, consistency checking, and backup procedures, would also fall into this category.
Be aware that making a Microsoft Exchange Server computer function as a backup domain controller will place a significant background load on this server. Ideally, a Microsoft Exchange Server computer would function in a dedicated mode. However, this may not always be possible, or even desirable, in small sites.
Many hardware factors influence the performance of Microsoft Exchange Server. Among these is the hard disk random access I/Os per second, the number of CPUs and their speed, the amount of RAM, and the I/O subsystem speed.
The primary concern with hard disk drives is not the size but rather the number of random read/writes that can be done in a second. However, care should be taken in diagnosing an I/O bottleneck. For example, if the console on a Microsoft Windows NT™ server gets very slow, it will appear to be disk bound. Some investigation in Performance Monitor will even show a very high level of I/O. But this computer may not be lacking in I/O capabilities as it looks; it may be memory bound. This lack of needed RAM is causing paging, which is saturating the I/O subsystem. This process is generally referred to as balancing between I/O and RAM. The Windows NT Performance Monitor can be used to find these bottlenecks and balance the system by adding the appropriate additional resources.
Disk I/O can be maximized by utilizing the database architecture of Microsoft Exchange to its advantage. By default, two databases exist on each Microsoft Exchange Server computer: a public store and a private store. Each database has a transaction log in which transactions are written sequentially. Since these logs are written sequentially, placing them on a separate physical disk will allow for a seek time between transactions of zero milliseconds. This has been tested to be the fastest possible configuration on any size computer. For additional I/O improvements, strip the remaining drives together (increased random I/O capacity) and use a caching disk controller (significant overall speed improvement).
A useful utility in configuring your server for optimal performance is the Microsoft Exchange Server Optimizer. This utility asks a series of server usage questions, such as number of users on this server, total number of users, and total number of servers. The utility will then analyze the disk partitions for speed and size, and suggest moving the database log files if appropriate. It will then conclude by configuring the hardware-sensitive server parameters. It is suggested that the Server Optimizer be run every time a hardware modification is made.
Another useful utility on the Microsoft Exchange CD is the Microsoft Exchange Client Simulator. This allows the simulation of hundreds of users from one computer. It also allows different user types to be configured so that it can accurately simulate what load a given number of users will place on a server.
In summary, the recommendations for Microsoft Exchange Server performance are:
In the following sections, you'll learn about site topology issues concerning Microsoft Exchange Server and Windows NT, as well as Microsoft Exchange sites and Windows NT Server domains.
This section describes the issues related to Microsoft Exchange Server and Windows NT.
The server components of Microsoft Exchange Server include the directory service, information store, message transfer agent, and system attendant, all of which are hosted on a computer that runs Windows NT Server version 3.51 or later. This computer is referred to as the Microsoft Exchange Server computer.
Since the server components of Microsoft Exchange run on Windows NT Server, all of the Windows NT administration and service mechanisms can be used in conjunction with Microsoft Exchange. For example, the service control manager can be used to query and control the Microsoft Exchange services. Likewise, the Windows NT event log and performance monitors can be used for logging and tracking Microsoft Exchange processes.
Microsoft Exchange Server also leverages the Windows NT security infrastructure for authentication and control. Users are granted access to Microsoft Exchange based upon their Windows NT logon credentials. Additionally, enhancements have been made to the Windows NT user manager to allow for automatic creation of Microsoft Exchange mailboxes when a Windows NT Server account is created.
Users attempting to perform an action on a Microsoft Exchange Server computer must have the appropriate "security context" to do so. This security context must exist in a Windows NT Server-based domain that the server knows about. This can happen in one of two ways: users log into the Windows NT Server domain in which the Microsoft Exchange Server computer is located, or users log into a Windows NT Server domain that is trusted by the Microsoft Exchange Server computer's domain. Additionally, the security context must allow them the necessary privileges to carry out the requested action. For example, a user trying to delete a public folder on a Microsoft Exchange Server computer must have a security context in the domain or a trusted domain that allows him or her to delete this folder.
The client authentication process functions the same way on a Novell® NetWare® environment. Native NetWare clients will still establish a security context with a Windows NT Server domain. The only difference is that this will happen when users attempt to connect to the Microsoft Exchange Server computer instead of when they log on to the network (since they are logging into the NetWare network). To the users, it appears as if they have a separate password for Microsoft Exchange, not that they are logging into a separate network. In fact, the latest versions of NSUP from Novell allow users to "remember" these passwords so that users do not have to enter them every time. Microsoft Exchange Server handles any password change mechanisms, and users will be notified of these requests when they connect to the Microsoft Exchange Server computer.
Administrator authentication functions through the same mechanisms as user authentication. When an administrator runs the Microsoft Exchange Server Administration program, it will attempt to connect to the Microsoft Exchange Server computer with the currently logged in user's security context. If this user's security rights specify him or her as a Microsoft Exchange administrator, he or she will be allowed access with the administration tool. To the server, the administration tool is nothing more than another type of client.
Microsoft Exchange Server computers cannot be brought up on a domain without a machine account for that server. Authentication between Microsoft Exchange Server computers within a site is bi-directional. Therefore, it's not possible for a "renegade" server to impersonate a "known" server without the creation of the correct machine account. The creation of machine accounts within a domain is usually reserved for domain administrators, effectively prohibiting the creation of these renegade servers. Note that while authentication within a site is bi-directional, intersite message transfer authentication is dictated by the messaging system used to connect the sites together. This may be a deciding factor when determining which method to use in connecting your Microsoft Exchange Server sites.
You use the Microsoft Exchange Server Administration program to grant Windows NT Server accounts rights on Microsoft Exchange Server mailboxes. When granting rights, accounts can be picked from any Windows NT Server domain that is trusted by the domain in which the Microsoft Exchange Server computer is. Granting access rights on Microsoft Exchange Server mailboxes is very similar to granting access rights to a sharepoint on a file server: read/write access rights can be granted to some users, while other users may only be granted read rights. Microsoft Exchange Server does allow you to grant multiple users access to one mailbox. For example, executives might have read/write access to their mailboxes, while their assistants have read-only access.
Microsoft Exchange Server computers can be grouped into one or more "sites" for unified administration, security, and communication services. A site consists of one or more Microsoft Exchange Server computers working together to provide communication services to a set of users. From the Microsoft Exchange Server Administration program, you can manage everything that is associated with the site—from the users, distribution lists, and public folders to the connectors and gateways.
All connectivity between servers within a site is RPC-based and bi-directional. This implies a need for continuous LAN connectivity within that site, and that the connection be fairly high speed. Additionally, all servers within a site need to be in a common security authority, which implies that they're in the same Windows NT Server domain or in separate Windows NT Server domains that fully trust each other. In a multisite enterprise, you can only administrate a Microsoft Exchange Server computer within the site you're connected to. To administrate a server within another site, you must make an RPC connection to that site first by opening a connection to a server within that site.
All Microsoft Exchange Server sites in the enterprise are combined into a single Microsoft Exchange Server organization. Communication between sites is assumed to be through messaging. But sites can be configured to communicate through RPCs if there is a high-speed connection between them. There is no assumption of LAN connectivity or a shared security authority. In fact, intersite connections can be multihop, indirectly routed, intermittent, and scheduled.
Domains are logical groupings of one or more Windows NT Server computers that allow them to be managed and used as a single unit. They are the building blocks of the Windows NT Server directory services. Using domains, you create one user account for each user. That account includes user information, group memberships, and security policy information and is the central point of user administration. Since computers in a domain share security and user account information, users only need to log on once to the domain, not separately to the individual resources in the domain. Domain boundaries are dictated primarily by administrative needs.
The minimum requirement for a domain is one server running Windows NT Server 3.5/3.51, which acts as the primary domain controller (PDC) and stores the master copy of the domain's user and group security account manager (SAM). A domain has only one PDC. A domain may have any number of backup domain controllers (BDCs) running Windows NT Server. While not required, one or more BDCs in a domain provide load balancing and fault tolerance. A BDC contains a copy of the domain's or master domain's SAM and can be used to authenticate user logons to help spread the load of logon request processing. Each computer within a domain must have a machine account, which is created by a domain administrator.
A trust relationship is an administration and communications link between two Windows NT Server domains. Domains use established trust relationships to share account information and validate the rights and permissions of users and global groups residing in the trusted domain. It allows users to have a single account and password in a single domain and yet access resources in other "trusting" domains.
Windows NT Server domain models use trust relationships to facilitate:
The single master domain model consists of several domains, one of which acts as the central administrative unit for user accounts. All user and machine accounts are defined in this "master" domain, and all users log on to their accounts in the master domain. Resources, such as printers and file servers, are located in the other domains. Each resource domain establishes a one-way trust with the master (account) domain, enabling users with accounts in the master domain to use resources in all the other domains. The network administrator can manage the entire multidomain network, as well as its users and resources, by managing only a single domain.
The single master domain model is particularly suited for:
With the multiple master domain model, there are two or more single master domains. Like the single master domain model, the master domains serve as account domains, with every user and machine account created and maintained on one of these master domains. A company's MIS groups can centrally manage these master domains. Like the single master domain model, the other domains on the network are called resource domains; they don't store or manage user accounts, but they do provide resources such as shared file servers and printers to the network.
In this model, every master domain is connected to every other master domain by a two-way trust relationship. Each resource domain trusts every master domain with a one-way trust relationship. The resource domains can trust other resource domains, but they are not required to do so. Because every user account exists in one of the master domains, and since each resource domain trusts every master domain, every user account can be used on any of the master domains.
The multiple master domain model incorporates all the features of a single master domain. In addition, it accommodates:
For the purposes of Microsoft Exchange planning, there are two very simple things to remember about Microsoft Exchange sites and Windows NT Server domains. Microsoft Exchange sites are essentially islands of high-bandwidth synchronous LAN connectivity, which are determined primarily by the network and messaging topology, whereas Windows NT Server domains are basic units of security and administration for the network that are determined by administrative needs.
Multiple Microsoft Exchange sites can exist with a single Windows NT Server domain. Since having separate sites allows the custom configuration of intersite connections, this might be desirable if you have strict protocol or routing requirements. For example, every single Microsoft Exchange Server computer could be placed into its own site if you only wanted messages to travel via X.400 over TP4. The downside of this configuration is that for centralized administration, each server would have to be connected to individually. This is due to the fact that administration of a Microsoft Exchange Server computer requires an RPC to the server, and in our example the connections between sites are message-based.
Microsoft Exchange sites can span Windows NT Server domains; however, there must be a two-way trust between these domains. This is due to the fact that servers within a Microsoft Exchange site work on the assumption that they're in the same security context. Microsoft Exchange setup specifies the same service account for every Microsoft Exchange Server computer, by default. This allows an administrator to log on to the network once and administrate all of the Microsoft Exchange Server computers. It is also recommended that all user accounts be maintained in a single Windows NT Server domain, for ease of administration.
The Microsoft Exchange architecture model where the domain and site topologies are the same is the simplest of all the models. This model is highly effective in small and single location networks.
Another simple Microsoft Exchange architecture model is where the users are in a separate domain from the servers. In this case the server domain needs to trust the user domain.
Public folders are distributed, replicated repositories of "public" user data. Public folders may have rules, access control lists (ACLs), forms, and views associated with them. Public folders may exist on every Microsoft Exchange Server computer, but not every exchange server has to contain public folders.
The public folder hierarchy is replicated to every Microsoft Exchange Server computer that contains public folders. But the folder contents may be replicated on a per-folder basis to specific servers as needed. This allows for information that is pertinent to specific users to be replicated where it is most accessible to them. Microsoft Exchange utilizes a multimaster replication model and supports conflict resolution, which means that every replica is editable (subject to ACLs). Replication is performed via e-mail messages, even within sites.
Site affinity allows users to access public folder replicas outside their own site. This allows you to place public folder replicas where they make the most sense, not necessarily in every site.
Site affinity follows these rules in determining where to obtain public folder contents:
The descriptions of other companies' products in this document are provided only as a convenience to the reader. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult the respective manufacturers.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, this document should not be interpreted as a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of this publication.
This document is for informational purposes only and is subject to change without notice. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
©1995 Microsoft Corporation. All rights reserved. Microsoft is a registered trademark and Windows NT is a trademark of Microsoft Corporation.
Novell and NetWare are registered trademarks of Novell, Inc. Sequent is a registered trademark of Sequent Computer Systems, Inc.