The main factor in determining the number of users a Microsoft Exchange Server computer can support is the load each user places on the server. This dependency generally falls into two distinct categories: user-initiated actions and background actions.
Some users interact with the server for 12 hours at a time, while others connect to the server only once a week for a few minutes. Some users read hundreds of messages in dozens of public folders every day, while others read none at all. In a given user community, a small percentage of users can generate a disproportionate percentage of the total load on a server because they are the heavier, more aggressive users.
When a user interacts with the server directly, the actions performed place an immediate incremental load on the server for a duration of time. User-initiated actions are operations that the server performs as a direct result of a user's action, and are synchronous from the user's point of view. For example, opening an unread message in a private folder in the server information store entails processing time on the server to receive and interpret the open request. The server must evaluate access restrictions, retrieve the message from the database, mark the message as unread, update the unread count for the folder, return the requested message properties to the client, and generate a folder notification to the client. All of this happens in the time it takes for the remote procedure call (RPC) issued by the Microsoft Exchange Client to return control to the client. The actual time that the user perceives the operation takes is this time, plus the additional processing time needed by the client to draw the window, display the message properties, and so on.
User-initiated actions are the single most important factor in sizing a Microsoft Exchange Server computer. The performance of any given server is directly proportional to the number of users actively interacting with the server per unit time and the actions performed.
In addition to user-initiated actions, Microsoft Exchange Server performs asynchronous or background actions on behalf of users. Accepting, transferring and delivering messages, making routing decisions, expanding distribution lists, replicating changes to public folders and directory service information, executing rules, monitoring storage quotas, and performing background maintenance such as deleted messages collection and view index expiration, are all examples of the work a server can do asynchronously on behalf of users, whether or not they are currently connected to the server.
In general, the load on the server due to background actions such as user-initiated actions, is proportional to the number of users on the server. However, other factors such as whether the server acts as an intersite connector for messages on other servers or hosts a messaging gateway, can have a large impact. On Microsoft Exchange Server computers that act purely as gateways or backbone computers and do not directly host any users, the load due to user-initiated actions is essentially non-existent. In such cases, the load on the server is considered only as a background action.
Although it is often convenient for modeling purposes to think of every user-initiated or background action as being equivalent to every other in terms of the load that each places upon the server, this is not the case. For example, when a 500K message is copied to a user's personal information store, that action places more load on the server than if a 1K message were copied. Similarly, sending a message to a distribution list containing 100 members creates more background actions than sending the message to a single recipient.
You can make accurate predictions about how user-initiated actions will impact the server load if you base your predictions on aggregates over time. For example, if you review the set of actions a user performs during a certain time period, such as an 8-hour work day, you can sum up the user-initiated actions during that time period. You can also quantify some definitions of users by characterizing how many actions they perform per unit time, the set of actions and the individual action's load characteristics (such as estimating the size of messages) and arrive with sample user definitions that can be used for making rough performance predictions of actual user communities.
As an example, you can classify your users as having low, medium, and heavy usage.
A low-usage user could be someone who, on a daily average:
A medium-usage user, on a daily average:
A heavy-usage user, on a daily average: