UPDATE 2: Exchange 2007 Processor and Memory Recommendations

NOTE: This article has also been published in the official Exchange 2007 documentation. We recommend that you check the documentation for the most up-to-date version. Please see the following links:


When selecting hardware for your Exchange servers, there are many things that you must consider. Two of the most critical resources are processor and memory.

This article, an update to an article original posted on 3/13/2006 as well as updated article posted on 11/27/2006, provides processor & memory guidelines for minimum, recommended and maximum recommended configurations. There are several factors that go in to choosing the right hardware for an Exchange 2007 deployment. This article provides rule of thumb guidance on the primary factors which determine the proper memory and processor configuration for a given Exchange 2007 role. In separate articles we will cover other critical pieces to Exchange 2007 sizing such as storage and network hardware. Additional guidance will be provided as available throughout the Exchange Server 2007 development process.

Exchange 2007 server hardware requirements are different than previous versions of Exchange (2003)

The primary hardware difference between Exchange 2003 and Exchange 2007 is the move from a 32-bit platform (Exchange 2003) to a 64-bit platform (Exchange 2007). Exchange 2007 will only be supported in production environments when it is running on an x64 edition of Windows Server 2003 (Note: The Exchange 2007 Admin only installation is supported for production when using both the x64 and x86 versions of the software running on their respective processor platforms). The change from a 32-bit platform to a 64-bit platform requires a new approach to choosing server hardware for Exchange; especially processor and memory:

Processor types supported by Exchange 2007

Exchange 2007 is only supported in production when the following are true:

  • Running the x64 version of Exchange 2007
  • Running on Windows 2003 x64 Editions
  • Running on x64 compatible processors

The following processors support x64 versions of Windows 2003, thereby supporting Exchange 2007 deployments:

Each of these vendors also ship x64-capable desktop processors which can also run x64 versions of Windows 2003 (e.g. AMD Athlon64 and Intel Pentium D with EM64T) but for the sake of simplicity, this article will concentrate on processors designed for server deployments.

It's important to note that the Intel Itanium (IA64) processor will not work with Windows 2003 x64 Editions, and thus it will not work for Exchange 2007 deployments. Exchange 2007 is designed to run only on x64 capable processors such as those listed above; Exchange 2007 will not run on Itanium based systems.

Regardless of which server processor you select, it is necessary to have the server product pass the Designed for Windows test suite to ensure Microsoft support. Servers listed on the Windows Server Catalog meet these criteria. If your server is not listed, check with your vendor to see if either the "Designed for Windows" logo testing is in progress or the server has passed the testing and is pending a website update.

Multi-core processor considerations for Exchange 2007

Exchange 2007 benefits significantly when running on multi-core processors. The performance benefit for Exchange from dual-core technology depends upon the specific processor utilized. The findings from Exchange 2003 dual-core testing have been summarized in Microsoft Knowledge Base article 827281, CPU and memory scalability for Exchange Server 2003 and for Exchange 2000 Server.

Multi-core processors are an attractive option for Exchange 2007 servers based on price and performance. Please ask your server vendor about dual-core benefits for Exchange, specific to a given hardware architecture.

Hardware specific memory considerations for Exchange 2007

Exchange 2007 enables much better memory utilization than Exchange 2003 due to its 64-bit architecture. Because of the virtual address space limitations of a 32-bit platform, Exchange 2003 is limited to using 4 GB or less of physical memory. In contrast, customers running Exchange 2007 on Windows 2003 x64 Editions can efficiently utilize upwards of 32 GB of memory (Mailbox role). Note: 32 GB is not a physical limitation, rather the most cost-efficient current maximum memory configuration. Depending upon the number of memory slots in a server, this cost-efficient maximum memory configuration could be even less than 32GB (e.g. 16GB). This change needs to be factored in when choosing server hardware. The following factors should be considered:

  • Server Maximum Memory Configuration - Different server architectures have different memory limits. We recommend that you check the following technical specifications of the server to determine the criteria that affect the maximum memory configuration to ensure that the appropriate amount of RAM can be installed in to an Exchange 2007 server economically:
    • Memory Speed - Some server architectures require slower memory to scale up the memory to ten's of gigabytes in a given server (e.g., maximum server memory is limited to 16GB with PC3200 or 32GB using PC2700). You should check with the manufacturer to make sure that the memory configuration target for Exchange 2007 is compatible in terms of speed.
    • Memory Module Size - What is the largest memory module size the server will support? Generally, the larger the memory module, the more expensive it is; 2x1GB DDR SDRAM memory modules generally cost much less than 1x2GB DDR SDRAM memory modules. When planning for an Exchange 2007 server, make sure the maximum memory module size allows you to meet your target memory requirements.
    • Total Number of Memory Slots - How many memory modules will a given server support? The total number of slots multiplied by the maximum memory module size will provide the maximum memory configuration for the server. Also, keep in mind that memory modules must sometimes be installed in pairs.

Applying the processor and memory configuration factors to specific Exchange 2007 server roles

The following chart can be used to assist in purchasing server hardware destined to be used for Exchange 2007 server roles. The goal of this chart is to provide minimum, recommended and recommended maximum configurations.

Minimum: The minimum processor/memory configuration suitable for specific Exchange 2007 server roles (also defined in System Requirements). Minimum hardware requirements must be met to receive Microsoft Product Support Services.

Recommended: This is the recommended processor/memory configuration for specific Exchange 2007 server roles. Recommended can be defined as "the best configuration based on price and performance." The recommended configuration also provides a balance between processor and memory capacity. The goal is to match the memory configuration to the processor configuration so the system will effectively utilize the processors without becoming bottlenecked on memory and vice versa.

Maximum: This is the maximum recommended processor/memory configuration for specific Exchange 2007 server roles. Maximum is defined as "the upper bound of viable processor/memory configurations for Exchange 2007 based on price and performance." Maximum is a guideline and not a "support criteria" and does not take in to account the resource requirements of 3rd party applications. The recommended maximum may change over time based on price changes and technology advancements.

Processor Configuration Table for Exchange 2007





Edge Transport

1 x Processor Core

2 x Processor Cores

4 x Processor Cores

Hub Transport

1 x Processor Core

4 x Processor Cores

8 x Processor Cores

Client Access Server (CAS)

1 x Processor Core

4 x Processor Cores

4 x Processor Cores

Unified Messaging Server (UM)

1 x Processor Core

4 x Processor Cores

4 x Processor Cores

Mailbox Server

1 x Processor Core

4 x Processor Cores

8 x Processor Cores

Multi Role (Hub, CAS, UM, Mailbox)

1 x Processor Core

4 x Processor Cores

4 x Processor Cores

** Processor Core recommendations are based on the following processor revision: AMD Option 275 2.2GHZ dual-core

  • www.spec.org ratings may be used to rationalize unlike processors/server configurations.

Edge Transport Role

Edge transport is extremely efficient in design and thus requires moderate processing power. Also, fault tolerant Edge Transport deployments will utilize multiple servers to provide redundancy. The Recommended configuration on 2 x Processor Cores takes this fault tolerant deployment consideration in to account. Large enterprises, with a large volume of inbound/outbound SMTP traffic will be able to utilize 4 x Processor Core servers to reduce aggregate Edge Transport server count. Processor utilization is based on several factors such as: message rate, average message size, number of agents enabled, anti-virus configuration, 3rd party applications etc.

Hub Transport Role

The recommended configuration for Hub Transport is 4 x Processor Cores in deployments where Hub Transport is deployed along with several Mailbox servers and thousands of mailboxes. 8 x Processor Core servers can be efficiently utilized when message hygiene is configured on the Hub server (A/V, Anti-Spam). 1-2 x Processor Core configurations can be considered for deployments where there are not enough mailboxes (message traffic) to utilize a 4 x Processor Core configuration. Processor utilization is based on several factors such as: message rate, average message size, number of agents enabled, Forefront Mailbox Virus Scanning configuration, 3rd party applications etc.

Client Access Server Role (CAS)

Exchange 2007 architecture has moved significant client specific functions from the Microsoft Exchange Store to the Client Access Server. Messages are now converted on the CAS server when accessed with non-MAPI clients (e.g. POP3/IMAP4). Also, Outlook Web Access rendering is now performed on the CAS server as opposed to the Mailbox Store in previous versions of Exchange. These architectural changes allow CAS to offload significant processing from the Mailbox role and to allow it to effectively utilize 4 x Processor Cores. Similar to Hub Transport, servers with 1-2 x Processor Cores can be utilized for CAS in deployments where there are not enough mailboxes/non-MAPI client traffic to utilize 4 x Processor Core servers.

Unified Messaging Role (UM)

The recommended configuration for the Unified Messaging role is 4 x Processor Cores. Multiple Cores are well utilized on the UM server for several architectural functions such as Voicemail WAV to WMA conversions. Similar to previous roles, 1-2 x Processor Core configurations may be utilized when the mailbox count/UM utilization does not necessitate 4 x Processor Core configurations.

Mailbox Role

The recommended configuration for the Mailbox role is based predominantly on mailbox count and user profile. A 4 x Processor Core server provides a good balance between price and performance and should be able to host several thousand mailboxes. Rule of thumb sizing for the Mailbox server role requires an understanding of the average client user profile. This profile can be collected using the Microsoft Exchange Server Profile Analyzer or with 3rd Party tools/applications. The following table lists generic/common Outlook knowledge worker profiles:

User Type

Send/Receive per day (~50kb Message size)


5 sent/20 received


10 sent/40 received


20 sent/80 received

Very Heavy

30 sent/120 received

There are several factors that go in to doing Mailbox server sizing for Exchange 2007 which are above and beyond the user type listed above. These include Exchange 2007 features such as Local Continuous Replication (LCR), Forefront Mailbox Virus Scanning, 3rd Party applications, 3rd Party mobile devices, and Microsoft Outlook client version/mode (Online vs Cached Exchange Mode etc.). Rule of thumb sizing used primarily for budgeting purposes can be accomplished by calculating that 1000 Average profile mailboxes will require 1 x Processor Cores. E.g. A 4000 Mailbox server with an Average usage profile can be estimated to require 4 x Processor Cores. A Heavy usage profile will effectively double the required processor cycles (or halve the number of users per processor core;500 Mailboxes/Processor Core). On the other hand, a 2000 Mailbox server with an Average profile can be estimated to require a 2 x Processor Core server. The maximum number of processor cores the Exchange 2007 Mailbox role will efficiently utilize is eight. Deploying Exchange 2007 Mailbox on servers with greater than eight cores will not provide significant scalability improvements.

*** Concurrency: Concurrency is defined as the percentage of the total number of users on a server that are connected and using the server at a given peak period of time. Concurrency is difficult to measure since users may use multiple clients/devices and different versions of Outlook have various connection counts to the server. For a fully utilized server, concurrency is generally in the 75-80% range. The guidance in this article assumes this average concurrency profile.

Sizing additional processing capacity for Local Continuous Replication (LCR)

Local Continuous Replication (LCR) has all of the Exchange 2007 Mailbox role services as well as the Exchange 2007 Replication Service running on the same server. On an LCR Mailbox server, there is additional processing overhead generated from the Replication Service copying and playing in logs to the target database copy. This additional processing cost is roughly 20% and should be factored in when sizing LCR Mailbox servers.

Multi-Role (Mailbox, Hub, CAS)

The Multi-Role configuration has similar guidance and limitations as the Mailbox role. To accommodate CAS and Hub Transport utilization on a single server with the mailbox, reduce the 1000 Mailboxes/core calculation based on the Average client profile by 20% (800 Mailboxes/core) when performing rule of thumb sizing for Multi-Role servers. The maximum recommended processor core configuration is listed at 4 for the Multi-Role configuration to indirectly provide guidance on the maximum number of users recommended to be hosted in this scenario. Neither Clustered Continuous Replication (CCR) nor Single Copy Cluster (SCC) support hosting the Hub nor CAS server so a Multi-Role server has to be non-clustered by definition. It is a good idea to cluster Mailbox servers that host thousands of user to ensure patch management and server failures do not have a significant impact on up time. The more users hosted on a Mailbox server the more user "pain" is caused by server downtime. For this reason, the recommended maximum processor core configuration for the Multi-Role server is listed at 4. While the this configuration will perform well up to 8 processor cores, it is not recommended due to the availability concerns outlined above.

Memory Configuration Table for Exchange 2007

Once the number of processor cores have been estimated to be required per server role are understood; baseline memory recommendations can be applied. The following table illustrates the Minimum, Recommended and Maximum memory configurations for Exchange 2007 server roles.





Edge Transport



 (2GB minimum)


Hub Transport



 (2GB minimum)


Client Access Server (CAS)



 (2GB minimum)


Unified Messaging Server (UM)



 (2GB minimum)


Mailbox Server


Variable based on Storage Group Count.  See below

2GB +2MB to 5MB/mailbox:

Variable based on user profile, see Mailbox Memory Recommendation in table below


Multi Role (Hub, CAS, UM, Mailbox)

4 GB:

also depends on number of storage groups (For information, see later in this topic.)

8 GB plus from 2 MB to 5 MB per mailbox.

This is variable based on user profile. For more details, see "Mailbox Server Role" later in this topic.


Edge/Hub Transport Roles

The Edge and Hub Transport roles do not require substantial quantities of memory to perform well in optimal conditions. Generally, 1GB of RAM per processor core (2GB minimum total) is sufficient to handle all but the most demanding loads/scenarios. There is one significant memory factor that should be taken in to account for large deployments:

Large Queue Scenarios: Exchange 2007 Edge/Hub Transport servers are designed to handle scenarios where extremely large queues build up (e.g. 1 million messages in a single server queue). Edge/Hub Transport servers hold the queued message recipient information in memory to optimize the SMTP send and message retry operations. When sizing Edge/Hub Transport servers for large queue scenarios, use the following table to estimate the memory requirements:

Memory Factors/Queued Message

Memory Consumed

Per Message Overhead


Per Recipient Overhead


The recommended maximum memory configuration of 16GB is based on the Edge/Hub Transport servers handling 1 million messages with an average number of recipients each. Most deployments will be optimally configured with the "Recommended" memory configuration of 1GB per processor core (2GB minimum total).

Client Access Server Role (CAS)

In general, memory utilization on Client Access servers has a linear relationship with the number of client connections and the transaction rate. Based on the current recommendations for processor and memory configurations, a Client Access server will be balanced in terms of memory and processor utilization, and it will become processor bound at approximately the same time it becomes memory bound.

Mailbox Role

The memory configuration process for the Mailbox role is more involved than the other roles since the optimal memory configuration depends upon the mailbox count and the client profile (similar to estimating processor core requirements). Memory sizing for the Mailbox role is critical to reducing the I/O requirements of the server. The more memory you add to the Mailbox server, the less I/O will be generated by the Exchange databases. There is a point of diminishing returns; in which adding additional memory to the server may not be justified based on price/performance. Memory guidance outlined here takes this point of diminishing returns in to account based on current memory prices and performance metrics. Also, defining the memory configuration of the Exchange 2007 Mailbox server is required prior to defining the storage requirements/configuration. The following table can be used to assist in estimating the memory requirements of a given mailbox server with a given number of hosted mailboxes with a given profile type (taken from previous profile table).

User Type

Mailbox Memory Recommendation


2GB + 2MB/Mailbox


2GB + 3 ½MB/Mailbox


2GB + 5MB/Mailbox

Recommended Maximum Memory Configuration for Mailbox

Recent x64 based servers have the ability to scale up their memory configuration to 64GB and beyond. There are several reasons why Microsoft does not recommend maximum memory configurations for Mailbox that go beyond 32GB.

Cost: Based on current memory prices (specifically 4GB DIMMs), it is cost prohibitive to expand the physical memory capacity of a server beyond 32GB. Generally, the cost of physical RAM is linear up to 32GB; beyond this the cost trend is exponential. Beyond 32GB, for many configurations, it is less expensive to add disk drives as opposed to memory.

Non-Transactional I/O: The Mailbox server utilizes additional physical RAM by caching more data and thus reducing the database I/O footprint for transactional I/O (I/O that is generated by send/receive/client processing of email). There are several sources of non-transactional I/O generated on the Mailbox server. These include Online Maintenance (e.g. Online Defrag), Offline Maintenance (e.g. offline defrag, database repair operations), Backup/Restore operations, Mailbox Management Processes (e.g. Messaging Records Management (MRM)), All of these operations require database I/O to properly maintain and recover the server. Although Exchange 2007 has reduced transactional I/O significantly; adequate storage performance is still required for proper maintenance of the Mailbox server. For this reason, there is a point of diminishing returns when adding memory to the server. In general, the purpose of adding memory to the Exchange Mailbox server is to reduce the storage requirements (specifically performance) and thus storage cost. Due to non-transactional I/O requirements; the storage requirements of the system may not be significantly reduced by adding server memory beyond 32GB.

Cold State Operation: Cold state is defined as the state of the Mailbox server immediately following a server reboot or store.exe process restart. The Database Cache, which is used to cache database read/write operations, is small in size (or "cold") during this period so it has a significantly diminished ability to reduce read I/O operations. As the Mailbox server processes messages, the Database Cache Size grows which increases the effectiveness of the cache and subsequently reduces the I/O footprint of the server. The larger the physical memory size of the server the longer it takes the Database Cache size to reach its optimal size. If the storage is designed/sized for a server with a large amount of physical RAM (>32GB), and the I/O profile of the users assumes an optimal Database cache state (large/warm cache); then the client experience may be compromised due to insufficient disk performance during these "cold state" periods. Similar to the Non-Transactional I/O case; the storage subsystem requirement may be the same for a server that has been populated with 32GB of RAM as a server that has been populated with greater than 32GB of RAM.

While the Exchange 2007 Mailbox role will utilize memory greater than 32GB, for the reasons outlined above; 32GB is the maximum recommended memory config and is considered the point of diminishing returns in terms of both cost and performance.

Required Minimum Memory Configuration for Mailbox based on the number of Storage Groups

The maximum number of Storage Groups configurable in Exchange 2007 has been increased to 50 in the Enterprise Edition (up from 4 with Exchange 2003). This increase provides much greater flexibility in server/storage architecture, but the increase has a significant effect on the memory utilization of the Exchange 2007 Mailbox server so Storage Group count is now a factor in minimum memory configuration for Mailbox and Multi-Role servers. Increasing the number of Storage Groups primarily effects the Database Cache utilization of ESE (Extensible Storage Engine). The ESE Database Cache is used for both read and write activity. Due to the way Checkpointing works, adding a Storage Group effectively increases the amount of the Database Cache used for write activity. This has a positive impact of reducing database write I/O; but if too many Storage Groups are configured on a server with insufficient physical memory, the effectiveness of the database read cache may be reduced which may have an overall negative effect on the performance of the server. For this reason, minimum hardware requirements for Mailbox and Multi-Role uses the following table to provide specific minimum memory requirements based on Storage Group count configured on a per server basis.

Storage Group Count

Minimum Required Physical Memory



























*** This table includes the 2GB minimum memory requirement. Mailbox and Multi-Role Server configurations must meet the requirements outlined in the above table to receive Microsoft support.

The minimum physical memory requirements based on SG count closely match our recommendations on memory sizing based on mailbox count and profile (detailed above).

Example 1: A 4000 user Mailbox server with a heavy user profile would calculate out to 22GB of RAM (2048MB+ (4000*5MB)). Based on the above support requirements, the administrator will have the flexibility to use up to 44 Storage Groups. Additional RAM would be required to deploy greater than 44 Storage Groups based on the above supportability requirements.

Example 2: A 1000 user Mailbox server with a light user profile would calculate out to 4GB of RAM (2048MB+(1000*2MB)). Based on the above support requirements the administrator will have the flexibility to use up to 8 Storage Groups. Additional RAM would be required to deploy greater than 8 Storage Groups based on the above supportability requirements.

Memory Recommendations for Local Continuous Replication (LCR)

Local Continuous Replication (LCR) has all of the Exchange 2007 Mailbox role services as well as the Exchange 2007 Replication Service running on the same server. The Exchange 2007 Replication Service will work well on a LCR server based on the provided memory guidance but to ensure that the ESE Database Cache maintains optimal efficiency under LCR, it is recommended to provision an additional 1GB of physical RAM to Exchange Mailbox and Multi-Role servers (above and beyond the memory guidance listed above).

Multi-Role (Mailbox, Hub, CAS)

Guidance and limitations similar to the Mailbox server role apply to multiple server role configurations. To accommodate the Client Access and Hub Transport server roles on the same server as the Mailbox server role, the recommended base memory configuration is 8 GB. Memory guidance based on mailbox count and profile is the same as the Mailbox server role. The recommended maximum amount of memory is 32 GB.

Neither cluster continuous replication (CCR) nor single copy cluster (SCC) supports hosting the Hub Transport or Client Access server roles in a failover cluster. A multiple role server is non-clustered by definition. It is a good idea to cluster Mailbox servers that host thousands of mailboxes to ensure that server maintenance or failures do not have a significant impact on uptime or availability.

The minimum memory requirements based on the number of storage groups listed in the preceding table apply to multiple role server configurations, including configurations that contain the Mailbox server role.

Server Role "Rule of Thumb" Ratio Recommendations

Once optimal server role processor/memory configurations have been finalized, the next logical sizing task is to make a rough prediction of how many server roles of each type are required for your deployment. As with any sizing exercise, every environment is different; so these recommendations should be considered starting points that can then be tailored to specific environments. The recommendations are also based off of Microsoft's own Exchange 2007 deployment with the following characteristics:

User Profile

Heavy->Very Heavy

Primary Client  (Weekday working hours)

Outlook 2003/2007 Cached Mode (MAPI/RPC)

Primary After Hours/Weekend Clients

Outlook 2003/2007 Cached Mode (RPC/HTTPS) & OWA

Percentage of user base utilizing AirSync


The recommended "Rule of thumb" ratio for each role is based on processor cores (like our other guidance in this document), since it is common for roles to have vastly difference processor core counts. Also, the Mailbox server role is the basis for the process core ratios. Hub and CAS roles relate back the Mailbox role with regard to the rule of thumb recommendation.

Role Ratio

Processor Core Ratio Rule of Thumb


7:1 (no A/V on Hub)

5:1 (with A/V on Hub)



These recommendations have the following caveats:


  • Ratio is a "rule of thumb" and may not be valid for every topology (not a support requirement or hard and fast rule).
  • Ratios can change dramatically based on user profiles. E.g. A profile that creates correspondingly more load against the Mailbox role than the Hub role will increase the Mailbox:Hub ratio; and vice versa.
  • This guidance follows Microsoft's internal Exchange deployment for Mailbox servers which is based on the ~500 "Heavy" users per processor core.
  • Ratio assumes Mailbox role servers are +60% processor utilized during peak period with corresponding processor utilization on Hub or CAS.
  • Processors used on Mailbox role and Hub/CAS roles are of same type and speed.
    • www.spec.org ratings may be used to rationalize unlike processors/server configurations.
  • A minimum of two Hub and two CAS servers should be deployed for redundancy to ensure uninterrupted service in case of planned or unplanned server downtime.
  • The Exchange 2007 Management Pack for MOM 2005 SP1 combined with the Performance Troubleshooter, built in to the Exchange 2007 Management Console; can be used to determine when/if a given deployment requires additional Hub, Edge, CAS or Mailbox server roles based on performance. This method can be used to fine tune the server role ratios for a specific deployment.


  • Hub ratio rule of thumb where A/V is enabled assumes Forefront A/V with five engines scanning.


  • CAS ratio rule of thumb assumes SSL is enabled for all appropriate access protocols.

It is not possible to provide Edge and UM ratios since their utilization are not directly tied to the Mailbox server role. UM server sizing is covered in Determining the Number of Users an Exchange 2007 Unified Messaging Server Can Support. Edge server sizing is covered next.

Edge Server Sizing

Determining Edge server count is based off the following key factors during peak period:

  • Connections/sec
  • Messages/sec
  • Avg. Message Size

Sizing is based on the number of connections/messages processed with Avg. message size being a secondary factor. Since every SMTP connection does not translate in to an SMTP message and every message initially accepted does not make it passed IMF/Anti-Virus scanning; it is very difficult to provide a simple sizing methodology based on message rate. Edge utilization will depend on several factors that are very specific per individual deployment. The following table can be used, however, to get an understanding of Edge's performance characteristics based on Microsoft's own internal Exchange 2007 deployment:

SMTP Connections/Sec


% Connections Accepted


Avg. Recipients/Msg


Recipients Rejected/Sec


SMTP Messages IMF Scanned/Sec


% SMTP Messages passed IMF Scanning


SMTP Messages A/V Scanned/Sec


Avg. Message Size


CPU Utilization


** Based on a 2 socket, dual-core AMD Opteron 275 2.2 GHz based server.

  • A minimum of two Edge servers should be deployed for redundancy to ensure uninterrupted service in case of planned or unplanned server downtime.

In the above example, a significant percentage of the server processing can be associated with the overhead of analyzing connections and scanning accepted messages. For this reason, it is not possible to provide a sizing metric based solely on the number of messages sent/received per second since blocking spam/viruses is a significant processor utilization function of the Edge role.


With effective planning and an understanding of the basic processor and memory requirements for specific Exchange 2007 server roles, a balanced/cost effective topology can be easily attained.

- Matt Gossage

Share this post :

Comments (27)
  1. Matthew Wade says:

    So what exactly has been updated in this article?  Could you possibly add a small section for revision history.  This is the third time I’ve had to re-read the entire article and it’s getting harder to find the information that’s changed.  Thanks.

  2. Bright_911 says:

    Hello Team,  

    Can anyone lemme know guide me to a good documentation on Exchange 2007 Database Architecture?



  3. Matthew,

    In this update, we added the section "Server Role "Rule of Thumb" Ratio Recommendations" and cleaned up some verbiage in other parts of the article.

    In the previous update, we updated "Required Minimum Memory Configuration for Mailbox based on the number of Storage Groups" and the "Memory Recommendations for Local Continuous Replication (LCR)" sections.

    Hope this helps.


  4. SK,

    Database architecture is a broad topic.  For what specifically are you looking?


  5. robrfr says:

    It’s a shame the tables are not fully visible on the right

  6. Exchange says:


    This can happen depending on the resolution you run and/or the width of the browser window. There are a few things to do:

    – widen the browser window/up the resolution

    – use a RSS reader of some sort to get the post by subscribing to the RSS feed – it should show properly there or should at least give you a scroll bar to scroll and see everything

  7. Anonymous says:

    Apple iPhone for now ignoring synch to Exchange, other e-mail platforms Configuring, validating and monitoring

  8. yongmoney says:

    As per the previous comment. Does this mean that the conncurrency issue is gone?

    Can we now host 40,000 users on a clustered server environment and see hits of 4-5k users as long as the storage will handle?

    If I have 8 cores and 32GB of RAM and LCR, with a mixture of light medium and heavy users. (4000 staff, 40000 students. So Students would be light and the staff a mixture of medium and heavy). Running all this on multiple storage groups and databases on multiple sets of RAID 10 15,000RPM disk.

    Is this plausible, or is there something else here that I don’t know about?


  9. mattgos says:

    wrt concurrency…  Yes, concurrency needs to be factored in to to server/storage sizing.  It is especially important in scenarios where the concurrency is expected to be less than 50%.  The guidance in this blog assumes concurrency of +75% (e.g. 500 heavy profile mailboxes/core assumes +75% concurrency).  Our guidance is a starting point and can be tweaked for specific cases (like low concurrency cases).  The mailbox count/core can be increased in low concurrency scenarios but we do not have specific guidance as to how much.

  10. Anonymous says:

    I have been busy this past month hence hardly any posts… hardly an excuse, but the truth..! Yesterday

  11. Jonathan Amgar says:

    This is interesting, but do you have any sizing information on the unified messaging role when using speech recognition? Does this change with the number of names in the directory or the number of concurrent telephony calls over SIP using the system? What hardware is recommended in these cases?

  12. Jonathan,

    Take a look at this blog for UM scalability information.



  13. Anonymous says:

    Alright! I finally finished going through the Q&A Log for Part 3 of 24 in the Exchange Server 2007

  14. yongmoney says:

    OK, so there isn’t a specific number any longer? If during testing I put 10,000 connections onto an exchange server, it will take the load?

  15. Jonathan Amgar says:

    Thanks for the pointer Ross. I took a look at that page, and its very good for SIP provisioning (60-100 concurrent users) and erlang calculations. Does anyone know how this is affected by dtmf versus voice commands? Speech recognition is much more CPU intensive then simple dtmf processing, and I’m curious to know if the 60-100 concurrent users on a single box would stay the same if everyone was speech activated. It also says no accounting was done for automated attendants. I’d hate to deploy a UM solution and have to create a second UM server/dialing plan just because I didn’t have voice vs dtmf sized properly.

    Another open question is that since Ex2k7 now has inherent speech server functionality, has anyone seen accuracy numbers on corporate or personal contact dialing (the rate it recognizes the name properly). Part of sizing, since recognition is hurt by straining system resources.

  16. Anonymous says:

    To get started, let me take you on a trip down memory lane to dark ages of computing and e-mail. Journey…

  17. Anonymous says:

    There is an interesting posting on the MS Exchange team blog ( http://msexchangeteam.com/archive/2007/02/07/434523.aspx

  18. Anonymous says:

    In order to assist customers in designing their storage layout for Exchange 2007 (especially after publishing…

  19. basil says:

    OK, So I want to design a very large exchange 2007 solution and I am having a very heated debate with a well respected "Expert" who says exchange 2007 can’t do the following. In fact he thinks exchange 2007 caouls only handle 4000 concurrent sessions!!!

    50,000 mailboxes (average size 75mb), with a concurrency of 20% (10,000 users) on an 8 core box with 32GB ram and using CCR Users profiles are light to average use and 70% of users are OWA. CAS, HT and edge server roles will be deployed seperately to the Mailbox server.

    does anybody have any experience with such large deployments?


  20. Anonymous says:

    In order to assist customers in designing their storage layout for Exchange 2007, we have put together

  21. Anonymous says:

    This post focuses on two aspects of Active Directory (AD) design for Exchange 2007:   The recommended…

  22. stoneyh says:

    I was told by a Dell Server and Storage specialist that it would be better to use a dual core processor in an exchange 2007 server (MB role for example) because Quad Core processors were better suited to a multiple application or multiple VM box and Echange 2007 would not take advantage of that.  That a dual-core higher clock speed processor would provide better Echange server performance.  Other colleagues are insisting that Exchange 2007 was written to take advantage of mutiliple core processor technology and therefore quad core was the way to go. Anyone have any insights on this?

  23. mattgos says:

    Exchange 2007 has been developed and tested to use the core counts listed in the posting (based on server roles).  Quad core processors do not change this guidance by themselves.  Exhcange 2007 will work great on quad core processors. What depends is the number of sockets your server has.  Right now, quad core processors are only available for single and dual socket servers.  That means the max core count is 8 for Exchange 2007 which we will be happy to utilize.  When 4 socket servers are available with quad core processors; then you begin to exceed the max number of processor cores Exchange 2007 will effectively utilize. 8 processor cores is currently our recommended maximum and this will most likely not change with the advent of 4 socket, quad core server (16 cores).  When these 16 core servers are availble, they may not be a good choice for dedicated Exchange 2007 server roles (4 socket dual core or 2 socket quad core may be a better fit).  As this blog says, we recommend 8 cores max.

  24. Anonymous says:

    I am finished with the Q&A Log from Part 19 (Introduction to Disaster Recovery) of the 24 Part Exchange

  25. ComputerX says:

    I’m in the same place as stoneyh.

    As of 4/10/07 a Dual Core Xeon 5130 (2.00GHz, 1333MHz FSB) is the same price as a Quad Core Xeon E5310 (1.60GHz, 1066MHz FSB ).  Would I get more performance with the extra two cores or with the faster clock and bus?

    My initial thought was cores in a chip should talk to each other faster so the Quad would be better but I have vague recollections of reading that the current Quad core uses the FSB for interchip communication.

    Does cost/performance calculation change if virus scanning is happening on on the same box?  This is for a typical small business setup.  One server does all the Exchange tasks.



  26. Anonymous says:

    Here are the "Best Of" the questions and answers from today’s TechNet Webcast: "Exchange Server 2007

  27. Anonymous says:

    I’ve had a couple of conversations with customers lately, looking for advice in figuring how to plan

Comments are closed.

Skip to main content