The Microsoft Exchange Team released an important update of the Exchange Mailbox Role Calculator, bringing it to version 12.8.

This version includes the following fixes since 12.3:

• Fixed total number of databases/server calculation to deal with Active/Active (Single DAG) scenario correctly with respect to dedicated DR servers
• Fixed storage design disk calculations formulas for Active/Active (Single DAG) scenario, i.e., don’t recommend JBOD in scenario where only single copy is deployed (e.g., lagged copy deployed in secondary datacenter without dedicated hardware)
• Fixed Number of Active Mailbox Servers in DC2 calculation to not double count lagged copies when deploying Active/Active (Single DAG) scenario and deploying lagged copy in both Primary and Secondary Datacenters
• Fixed # of Target Lagged Copy Log Stream calculations to not double count lagged copies when deploying Active/Active (Single DAG) scenario and deploying lagged copy in both Primary and Secondary Datacenters
• Fixed second DAG Member Layout Table to show number of servers for both Active/Active scenarios

Consult the changeblog here.You can download the calculator here. Usage instructions can be found here.

A week ago, the Exchange team updated guidance on calculating the megacycles required for sizing or validating your Exchange configuration. They blogged about the change, which is also incorporated in Exchange 2010 Mailbox Role Calculator 12.3, here.

In summary, the formula has changed to include the megacycles value of the baseline system for dimensioning the CPU requirement, thus from:

((New platform per core value) * (Hertz per core of new platform)) / (Baseline per core value) = Adjusted Megacycles per Core

to:

((New platform per core value) * (Hertz per core of baseline platform)) / (Baseline per core value) = Adjusted Megacycles per Core

The baseline system is an HP DL380 G5 with 2 quad core x5470 3.33GHz (3,333 megacycles) with a Specint_rate2006 rating of 150 meaning 18.75/core. This change was needed to make a better estimate of the requirements and to accommodate for faster clocked CPU’s. The old formula could lead to over or under dimensioning, depending on the megacycles of the new system compared to the baseline system. The EHLO blog mentioned not to “panic” when you used the old formula since your systems simply will have some extra megacycle capacity. And while the trend nowadays is to have slower clocked CPU’s with more cores, you could run into some megacycle shortage when you used the old formula with a (perhaps re-used) 3,33 GHz+ CPU configuration and little margin. Unfortunately, the EHLO blog doesn’t mention that.

For example, let’s assume we’re going to use a Dell PowerEdge T610 with 2 hexa core Intel Xeon L5640 clocked at 2.26 GHz (2,260 megacycles) with a Specint_rate2006 of 283 (22 per core). In the old formula, the adjusted megacycles per core value would be 22 * 2,260 / 18.75 = 2,652. Using the revised formula the result is 22 * 3,333 / 18.75 = 3,911. The difference of 1,259 not only means a 50% increase in the adjusted megacycles per core value, but the total of 12 * 1,259 = 15,108 also means room for hosting roughly 3,777 additional active mailboxes (200 message profile meaning 4 megacycles/mailbox). Having over dimensioned like this isn’t problematic, it might get when using CPU’s clocked over 3,33 GHz. Suppose you used the T610 with a 2 quad core 3.46 GHz Xeon x5677 configuration with a Specint_rate2006 of 299 (37.375/core). The old formula would say 37.375 * 3,460 / 18.75 = 6,896.93; the revised formula results in 37.375 * 3,333 / 18.75 = 6,643.78. For 8 cores this means you’re a total of 2,025.2 megacycles “short” or about 500 mailboxes with a 200 message profile.

Now, using the Specint_rate2006 is not only nice for comparing different CPU configurations, e.g. what are the implications of using more processors with less cores versus less processors with more cores, but also to compare the hardware configurations of different vendors. For example, while an HP ProLiant BL480c with a single quad core 3.33 GHz Intel Xeon X5470’s gives you a  baseline per core value of 20.28, adding an additional CPU to the same configuration drops the value to 18.75. In addition, while this dual quad core 3.33 GHz X5470 configuration in an HP ProLiant BL480c gives you 18.75 per core, the same CPU configuration in an Fujitsu Siemens Celcius R650 gives a baseline per core value of 17.5. That difference of almost 7% might not seem much, but it might mean having sufficient room for overhead or not having to add a bigger or second CPU.

Of course, all the information above is from a CPU perspective and doesn’t take into account other dimensioning elements like memory or storage. Note that since in the revised formula contains two fixed numbers, you could also multiply the Specint_rate2006 by 177.76 to get the adjusted megacycles per core value.

The Microsoft Exchange Team introduced some serious fixes and additions in the Exchange Mailbox Role Calculator version 12.3. This version includes the following fixes since 7.8:

Additional functionality:

• Incorporated Megacycle adjustment formula changes mentioned in the Exchange Team blog Guidance Change- Calculating the Megacycles for Different Processor Configurations Formula;
• The calculator no longer requires you to enter in the adjusted megacycles per core for the server architecture you are deploying.  Instead, you simply need to obtain the SPECint2006 Rate Value for your server platform (consult www.spec.org);
• Added Megacycle Multiplication Factor – this works exactly like the IOPS Multiplication Feature does and was added as a result of RIM providing E2010 guidance on megacycle impact due to Blackberry devices;
• Active/Active user distribution scenarios;
• Added a new worksheet/section that documents the Activation Scenarios for DAG deployments;
• Added error reporting validation logic if HA solution results in greater than 16 servers in a DAG to not show any results, since the design is invalid;
• Dumpster size calculations have been optimized as calendar versioning storage has been reduced from 5.8% impact to 3% impact in SP1;

Bug fixes:

• Fixed Total Number of Databases / Server calculation to deal with scenario where lagged copies are deployed in both datacenters for Active/Active (Single DAG) scenario;
• Optimized Number of Active Databases after First PDC Server Formula removing redundant bad code and enabling single database scenario;
• Fixed Number of Required Mailbox Processor Cores for both PDC and SDC calculations to take into account the situation where the required megacycles to support the active load is less than the number of megacycles per core;
• Optimized Number of Required Mailbox Processor Cores for both PDC and SDC calculations to not assume all required cores would be 100% utilized by changing how rounding works in the formula;
• Fixed Number of Active Databases / PDC Server (After Second PDC Server Failure) formula to only report a value for the following scenarios: HA Only 3+ HA copies, 4+ servers; HA, Site Resilience, No activation block, 3+ total HA copies, 4+ total servers; HA, Site Resilience, activation block, 3+ PDC HA copies, 4+ PDC servers;
• Fixed standalone scenario to expose the total number of databases being deployed in the results section when there are multiple servers;
• Fixed Number of Active database calculations (after first PDC server failure) to take into account activation block;
• Fixed the Number of active databases during normal runtime formula to round up;
• Various formatting and text cleanup across all sections;
• Fixed data error validation statement for IOPS and Megacycle Multiplication Factors to specify the supported value must be 1 or greater.

Consult the changeblog here, including information on the new user distribution models (single/multiple DAGs). You can download the calculator here. Updated usage instructions can be found here.