Version 19.9 Updates

Enhancements

• Revised name of Offline Address Book in MailboxDatabases.csv file
• Integrated revised CreateMBDatabases.ps1 script that better handles database creation with large numbers of databases
• Integrated revised CreateMBDatabaseCopies.ps1 script that performs faster
• Added validation check to ensure message profile has a mailbox size limit
• Added 4TB disks as a disk selection option
• Included prompt for 2nd site GC for on DB Export Primary DB List dialog
• Included prompt for 1st and 2nd site GC on Export Copy DB List dialog
• Revised default for GC on Export Primary DB List dialog to use FQDN
• Revised default for Public Folder DB on Export Primary DB List dialog to clarify it is a DB name
• Added problem explanation text to Distribution tab status line to show why the Calculator considers a configuration invalid
• Updated CreateMBDatabaseCopies.ps1 to use GC1 and GC2 from export file
• Added status information to Diskpart.ps1 to show the state of disks before and after script execution

Bug Fixes

• Fixed issue with "Number of Active Databases / PDC (After Second PDC Server Failure)" formula to ensure that the PDC cannot have more active databases than possible
• Removed rounding on calculating number of active databases / server
• Fixed "DB and Log LUN Design / Server" to accurately calculate /DAG totals when 2 LUNs / Backup Set architecture is chosen
• Fixed conditional formatting issue with Number of Mailbox Servers when the design utilizes standalone Mailbox servers
• Fixed bug preventing running multiple StorageCalc instances from running concurrently
• Fixed bug when saving a workbook under a new name after making changes to the original workbook
• Fixed "Number of Mailbox Cores Required to Support Activated Databases in Secondary Datacenter" to accurately take into account the correct number of remaining servers
• Fixed diskpart.ps1 script to ensure it can be re-executed
• Fixed diskpart.ps1 script to cater for embedded spaces in mountpoints
• Fixed CreateMBDatabaseCopies.ps1 to read input for Primary site and Secondary site DC's
• Fixed Export Primary Databases List to use PF Database instead of PF Server

Version 18.9 Updates

Bug Fixes

• Fixed the Storage worksheet’s "RAID Storage Configuration" Table to exclude showing "Total Number of Disks Required" for designs that do not have lagged database copies and are deploying in a JBOD configuration.
• Added a notification to Role Requirements regarding scenarios that result in >2TB databases.
• Fixed an error notification to indicate when the input parameters have resulted in a design that has more HA copies than available Mailbox servers.
• Fixed the DAG LUN total space calculation to be based on the total number of database copies, not the total number of mailbox servers.
• Fixed the database copy validation formula to ensure there is at least 1 HA copy or lagged database copy in the secondary datacenter when site resilience is enabled.
• Fixed servers.csv to not add a space between the comma and drive letter.
• Fixed cells to have the correct color formatting.
• Updated BDM throughput requirements to stipulate 7.5MB/s per database as the worst case, which aligns with what can potentially be seen in Jetstress runs.

Version 18.2 Updates

Bug Fixes

• Fixed the calculator’s database copy validation check function to allow for a single DAG to be stretched between datacenters when the database copy count is even.
• Fixed the “Storage Design Results Pane - Total Disks Required” when leveraging the “As Calculated” results to not highlight RAID disks for a datacenter’s server when JBOD was the appropriate choice in the “RAID Storage Configuration” choice.  Likewise, the “JBOD Storage Configuration” table’s calculations were also fixed to not highlight the use of JBOD disks for a datacenter’s server when RAID was the appropriate choice.
• Fixed an error in Storage Results where the Secondary Datacenter storage architecture tables would report the Primary Datacenter disk type and capacity instead of Secondary Datacenter disk type for RAID architectures.
• Fixed an erroneous alert on the Input worksheet regarding not having enough IO capability for JBOD due to isolating logs from databases.
• Fixed the calculated maximum database size for JBOD scenarios to allow for 2TB databases when >2.5TB disk sizes are selected.

Version 17.8 Updates

Bug Fixes

• Fixed the “Recommended databases per DAG” calculation formula to take into account symmetrical design multiples when the “Calculated Number of Databases for Symmetrical Distribution” is greater than the maximum of databases that can be deployed within the DAG.
• Fixed the validation check for when you select more database copies than available servers.  As a result, when this scenario is presented, the calculator will no longer provide results.
• Fixed "Calculated Number of Supported Databases / DAG" formula to round down to nearest whole number.
• Fixed distribution calculation to allow more copies and servers.
• Fixed "RAID Storage Architecture / SDC Server" to show the optimal RAID configuration for the SDC servers as opposed to the PDC servers.
• Fixed formula issue for number of databases in the environment for standalone scenarios.

Enhancements

• Added RAID-6 types 4+2 and 8+2.
• Added 10, 20, and 40 processor core options.
• Added 3TB disk capacity.
• Script changes:
  • Removed option to remove first database
  • Revised Diskpart script to format using 64K unit size

Version 17.2 Updates

Bug Fixes

• Database Copy Distribution fixes:
  • Prevented distribution calculation when Input sheet values are invalid; added row in header for counters for databases assigned to a server.
  • Added conditional formatting to highlight error/problem status messages in white text on red background.
  • Corrected the issue where Non-English operating system locales could not execute the database copy distribution macro.
  • Increased the performance of the Server Failure buttons.
  • Corrected an issue that prevented the Diskpart.ps1 script from working when there was only one server line present.
• Updated comments for processor input section to help customers understand the correct value to enter for SPECInt2006 rate value when deploying Mailbox servers as guest machines.
• Fixed CPU percentage calculation formula for lagged database copy servers to use the available megacycles for the Lagged Copy servers as opposed to the primary datacenter Mailbox servers.
• Added 900GB capacity as an option for disk drives.       

Version 16.5 Updates

Bug Fixes

Version 16.4 Updates

Bug Fixes

Enhancements

• Added throughput requirements information for supporting Background Database Maintenance operations.

New Functionality – Virtualization Support

The calculator now includes support for virtualization.  When you enable virtualization, you must be sure to configure the processor architecture  correctly.

In particular, you must enter in the correct number of processor cores that the guest machine will support, as well as, the correct SPECInt2006 rating for these virtual processor cores.  To calculate the SPECInt2006 rate value, you can utilize the following formula:

X/(N*Y) = per virtual processor SPECInt2006 Rate value

Where X is the SPECInt2006 rate value for the hypervisor host server
Where N = the number of physical cores in the hypervisor host
Where Y = 1 if you will be deploying 1:1 virtual processor-to-physical processor on the hypervisor host
Where Y = 2 if you will be deploying up to 2:1 virtual processor-to-physical processor on the hypervisor host

For example, let’s say I am deploying an HP ProLiant DL580 G7 (2.27 GHz, Intel Xeon X7560) system which includes four sockets, each containing an 8-core processor, then the SPECInt2006 rate value for the system is 757. 

If I am deploying my Mailbox server role as a guest machine using Hyper-V, and following best practices where I do not oversubscribed the number of virtual CPUs to physical processors, then

757/(32*1) = 23.66

Since each Mailbox server will have a maximum of 4 virtual processors, this means the SPECInt2006 rate value I would enter into the calculator would be 23.66*4 = 95.

In addition, you must ensure that you enter the correct Hypervisor CPU Adjustment Factor to account for the CPU overhead associated guest machines.  Work with your hypervisor vendor to determine the correct value.

New Functionality – Database Copy Distribution

In September I released our guidance on how to lay out database copies to ensure symmetrical distribution of the active copies in the event of a failure. This guidance was further expanded and released as a TechNet article in November.

On the Input worksheet, within the Database Configuration table, you can now have a new option, “Calculate Number of Unique Databases / DAG for Symmetrical Distribution”. When this option is enabled, the calculator will use the permutation formula discussed in our guidance to deploy the correct number of databases based on the number of copies and server architecture such that you can potentially achieve a symmetrical distribution after a failure event.

The calculator includes a new worksheet, Distribution. Within the Distribution worksheet, you will find the layout we recommend based on the database copy layout principles.

 

The Distribution worksheet includes several new options to help you with designing and deploying your database copies:

• You can determine what the active copy distribution will be like as server failures occur within your environment.

  

• You can export a set of CSV and PowerShell scripts that perform the following actions:
  • Diskpart.ps1 (uses Servers.csv) - Formats the physical disks, and mounts them as mount points under an anchor directory on each server.
  • CreateMBDatabases.ps1 (uses MailboxDatabases.csv) - Creates the mailbox database copies with activation preference value of 1.
  • CreateMBDatabaseCopies.ps1 (uses MailboxDatabaseCopies.csv) - Creates the mailbox database copies with the appropriate activation preference values across the server infrastructure.

Important: The database copy layout the tool provides assumes that each server and its associated database copies are isolated from each other server/copies. It is important to take into account failure domain aspects when planning your database copy layout architecture so that you can avoid having multiple copy failures for the same database.

Version 14.4 Updates

Bug Fixes

• Fixed stretched DAG scenario that had one database copy in each datacenter not reporting results due to new copy validation check
• Fixed secondary datacenter log disk calculations to correctly calculate the formatted disk space
• Fixed Table headers in the Storage Design tab to show disk count / Secondary datacenter

Version 14.2 Updates

Bug Fixes

• Fixed two-node stretched DAG scenario that resulted in calculator not reporting results due to new copy validation check

Version 14.1 Updates

Bug Fixes

• Fixed the Activation Results Scenarios to no longer display #NAME when dealing with dedicated lagged copy servers.
• Fixed 2 LUNs / Backup Set formula for the 11th database grouping set in the DB and Log LUN Design / Server table to display the correct number of databases in the grouping set.
• Fixed "Number of Active Databases / SDC Server (After First PDC Server Failure)" calculations to take into account stretched Single DAG without dedicated DR servers.
• Fixed "Number of Required Mailbox Processor Cores (Primary Datacenter)" formula to respect when site resilience is disabled and A/A (Single DAG) is selected.
• Fixed formatting for scenario that resulted in more HA database copies being deployed in the secondary datacenter than in the primary datacenter and also improved validation checks.
• Updated "Custom Number of Databases" (Input Section) and "Number of Databases" (Role Requirements section) text to indicate in standalone situations that the "Custom Number of Databases" is per server and "Number of Databases" is for the environment.
• Fixed 2nd PDC failure formula to enable site resilient scenarios that have 3 copies in PDC to allow double server failure event.
• Optimized Number of Mailboxes per Database (I/O Driven) to not round up odd numbers to the next even number.
• Fixed text in various comment fields.

Enhancements

• Added conditional formatting for Exchange Native Data Protection input factor to alert when you are deploying with less than the recommended number of HA copies.
• The calculator now includes the ability to select different disk types and capacities for the storage architecture being deployed in the secondary datacenter.

Version 12.8 Updates

Bug Fixes

• 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

Version 12.3 Updates

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

Version 12.1 Updates

Bug Fixes

• 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.

Enhancements

• Incorporated Megacycle adjustment formula changes as documented in 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. To determine your SPECint 2006 Rate Value:

1.  
   1. Open a web browser and got to www.spec.org.
   2. Click on Results, highlight CPU2006 and then select Search CPU2006 Results.
   3. Under Available Configurations, select SPECint2006 Rates and click Go. Under Simple Request, enter the search criteria (e.g. Processor matches x5550).
   4. Find the server and processor you are planning to deploy and take note of the result value. For example, let's say you are deploying a Dell PowerEdge M710 8-core server with Intel x5550 2.67GHz processors (2670 Hertz); the SPECint_rate2006 results value is 240.

• 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. Yes, really! An Active/Active user distribution architecture has the user population dispersed across both datacenters (usually evenly) with each datacenter being the primary datacenter for its specific user population. In the event of a failure, the user population can be activated in the secondary datacenter (either via cross-datacenter single database *over or via full datacenter activation).
• 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.

The calculator offers two types of Active/Active user distribution models:

1. Active/Active (Single DAG) - This model stretches a DAG across the two datacenters and has active mailboxes located in each datacenter. A corresponding passive copy is located in the alternate datacenter. This scenario does have a single point of failure (potentially), the WAN connection. Loss of the WAN connection will result in the mailbox servers in one of the datacenters going into a failed state from a failover cluster perspective (due to loss of quorum). The Active/Active (Single DAG) scenario supports two deployment types, deploying with dedicated DR Mailbox servers in the alternate datacenter, or using the Active Mailbox Servers as the disaster recovery servers in the event that a datacenter is lost.

   ---DC1---	---DC2---
   DAG1	DAG1
   Active Copies	Passive Copies
   Passive Copies	Active Copies

   In other words:

   

2. Active/Active (Multiple DAGs) - This model leverages multiple DAGs to remove single points of failure (e.g., the WAN). In this model, there are least two DAGs, with each DAG having its active copies in the alternate datacenter:

   ---DC1---	---DC2---
   DAG-A (active/passive copies)	DAG-A (Passive Copies)
   DAG-B (Passive Copies	DAG-B (Active/Passive Copies)

   In other words:

   

Version 7.8 Updates

Bug Fixes

• Fixed Read IOPS / mbx calculation to take into account the four scenarios (no desktop search engine and no multiplication factor, no desktop search engine and multiplication factor, desktop search engine and no multiplication factor, desktop search engine and multiplication factor)

Version 7.7 Updates

Bug Fixes

• Fixed an issue in site resilient designs where the number of HA copies between datacenters was asymmetrical that resulted in a condition where the number of activated copies after a server failure was less than the number of copies during normal runtime.
• Fixed log and restore LUN disk formatted capacity calculation formulas to accurately calculate formatted capacity as opposed to estimating it.
• Fixed an issue to prevent a situation where the number of activated database copies per server in the primary datacenter was greater than the total number of copies per server.
• Improved the calculations for the number of required servers in the secondary datacenter, as well as, the number of lagged copy servers by rounding up, as opposed to simply rounding.
• Improved the number of active database calculations for 2-member DAGs deployed in a site resilient configuration.
• Improved the cross-site database failover calculations during double server failure events in the primary datacenter (where a portion of the databases are activated in the secondary datacenter).
• Fixed the Number of Required Mailbox Processor Cores (Secondary Datacenter) calculation to only consider solutions that have HA copies in the secondary Datacenter.
• Fixed and improved various comments throughout the calculator.

Enhancements

• Added two new columns to the primary datacenter "Active Database Configuration / DAG" table. These columns now expose the total number of databases activated in each site after server failure events. This change was added to expose cross-site database failover events.
• The calculator now includes an option to activation block secondary datacenter mailbox servers that host HA database copies. This allows you to design a solution where you can activate the secondary datacenter in the event of a primary datacenter failure mode, or choose to activate a copy in the secondary datacenter manually, but prohibits Active Manager from automatically activating a copy in the secondary datacenter. This may be useful in certain environments where WAN costs are high, or utilization of the WAN is high, and thus you want to control when users access data from the secondary datacenter. From a server planning perspective, enabling cross-site database failover has the potential to impact the primary datacenter server design (e.g., can increase the design to support double server failure events, which can impact memory and CPU sizing), while disabling cross-site database failover, can potentially increase your outage scenarios, but allows you to control the situation better.
• Over the years, many requests have come in asking to increase the number of mailbox tiers in the calculator. Well finally we did something about it. In this version, we've added a fourth mailbox tier.
• Added support for 32-cores.
• Originally, the IOPS Multiplication Factor calculations worked as follows:

  Base IOPS + (Base IOPS * IOPS Multiplication Factor

  This was often times confusing, especially with regards to third-party applications that had multiplication factors, so we've simplified the formula as follows:

  (Base IOPS * IOPS Multiplication Factor)

  which means that if previously you entered in a value of say .5 as the multiplication factor, you now need to enter into the calculator a value of 1.5.

Version 6.3 Updates

Bug Fixes

• Fixed the Secondary datacenter Active and Passive megacycle calculations to take into account the number of activated databases based on the failure mode the secondary datacenter can support.
• Fixed the number of Active Databases / Secondary Datacenter Server after a first primary datacenter server failure to not display #VALUE for 2-node site resilient DAG solutions.
• Improved the number of Active Databases after double server failure in the primary datacenter site resilient calculation to deal with 3 servers in the primary datacenters, as well as, when there are 2 copies in the primary datacenter.

Version 6.1 Updates

New Functionality

Previous versions of the calculator would sometimes result in a storage design output that required zero disks. This was due to the calculator determining based on the input factors (e.g. deploying a DAG with 3 HA copies in the primary datacenter) that a JBOD architecture would minimize the required number of disks. However, if the disk capacity and/or disk type did not meet the requirements to host a database, the calculator would output zero disks. As seen in the following example, notice only the disk requirements for the secondary datacenter are reported in the Total Disk Requirements table:

In order to rectify this logic issue, the calculator has been updated to allow you to choose the storage design you are interested in deploying. The calculator still shows you both the RAID architecture and JBOD architecture disk requirements:

What is new, however, is that within the Total Disk Requirements results pane, you now will have three options:

1. As Calculated - this is the default behavior where the calculator determines the most efficient design that ensures the least number of disks are deployed, while still ensuring you have minimized single points of failure by utilizing RAID and/or JBOD based on the decisions found in the "RAID Storage Architecture" and "JBOD Storage Architecture" tables.

   

2. Entirely on RAID - Selecting this option outputs the results with each server utilizing the RAID storage defined in the RAID Storage Architecture results section.

   

    

3. Entirely on JBOD - Selecting this option outputs the results with each server utilizing JBOD storage as defined in the JBOD Storage Architecture. There are two caveats worth mentioning here - first, if the design doesn't support JBOD, then JBOD isn't a viable option (e.g., you don't have 3 HA copies); second, choosing this option may result in a situation where you have a single point of failure (e.g., having only a single copy on JBOD in the secondary datacenter). Remember the following conditions when considering JBOD:
   1. In order to deploy on JBOD in the primary datacenter servers: You need a total of 3 or more HA copies within the DAG. If you are mixing lagged copies on the same server that is hosting your HA copies (i.e. not using dedicated lagged copy servers), then you need at least 2 lagged copies.
   2. For the secondary datacenter servers to use JBOD: You should have at least 2 HA copies in secondary datacenter. That way loss of a copy in the secondary datacenter doesn't result in requiring a reseed across the WAN or loss of data (in the datacenter activation case). If you are mixing lagged copies on the same server that is hosting your HA copies (i.e., not using dedicated lagged copy servers), then you need at least 2 lagged copies.
   3. For dedicated lagged copy servers: You should have at least 2 lagged copies within a datacenter in order to use JBOD. Otherwise loss of disk results in loss of your lagged copy (and whatever protection mechanism that was providing).

   

In addition to the new functionality described above, this version also provides the following enhancements to existing behavior, as well as, corrects several issues reported:

Enhancements

• Message profiles have been simplified in order to be more consistent with the rest of our documentation and partner tools. For example, instead of using "20 sent/80 received", the calculator now simply uses "100 messages". The individual breakdown isn't consequential to the overall design of the mailbox server IO and capacity planning algorithms.
• Added additional column to the "Active Database Configuration / DAG" table on the Role Requirements tab to expose configurations where you will have a portion of your databases activated in the secondary datacenter as a result of a failure event in the primary datacenter.
• Improved "Environment Configuration" table on the Role Requirements tab to indicate the Number of Mailbox Servers and Lagged Copy Servers / DAG in each datacenter.
• Re-ordered tables in the Role Requirements Results section.

Bug Fixes

• Fixed an issue for site resilience scenarios that resulted in #DIV/0 errors as a result of determining the number of copies that can be mounted in the event of a double server failure when the solution only has 2 servers in the primary datacenter.
• Fixed an issue for site resilience scenarios that ensures that double failure events don't result in more databases being activated on the remaining primary datacenter servers than possible when only 2 copies exist in the primary datacenter.
• Fixed CPU core calculations to take into account the total number of DAGs being deployed in the situation.
• Fixed active megacycle calculation to exclude database copy overhead for standalone deployments.
• Fixed Lagged Copy Storage Architecture formula to be HA aware.
• Fixed Secondary Datacenter Storage Architecture formula to ensure there is at least 1 HA copy being deployed in secondary datacenter.
• Updated storage design tab improvements based on user feedback and added "in primary datacenter" for input HA/lagged copy instances.
• Fixed formula for JBOD disk type to accurately reflect when there was insufficient database copies vs. requiring RAID.
• Updated comments on various cells.

Version 4.5 Updates

Enhancements

There are only three improvements to the calculator in this release:

• Added the calculations to help you determine the minimum number of global catalog cores you need to deploy with your architecture.
• Added the ability to define different RAID parity settings for your Restore LUN architecture.
• Improved the calculation of the formatted capacity of a disk drive.

Bug Fixes

• The following issues were identified and addressed in this release:
• For HA solutions that chose to deploy in JBOD configuration, two fixes were made:
  • In certain scenarios, the calculator would calculate the number of mailboxes per database to be higher than the total amount of random IO available on the disk. As a result the calculator couldn't recommend a JBOD configuration. This has been corrected by rounding down the number of mailboxes per disk from an IO perspective calculation.
  • In certain situations the JBOD disk configuration isn't applicable. In past versions, the calculator would simply tell you this was because of "Insufficient Disk Capacity". This has been corrected to tell you if the insufficiency is based on disk capacity or IO capacity.
• Addressed several CPU calculation related errors:
  • Fixed the issue where #VALUE was reported in the secondary datacenter processor core ratio table when you deployed only a lagged copy in the secondary datacenter.
  • Fixed the required mailbox CPU calculations to take into account certain site resilient scenarios where neither datacenter could support a single server failure (e.g. 2 member DAG).
• Fixed an issue with the total disk count calculations with dedicated lagged copy servers as a result of rounding error.
• Fixed an issue where /DAG LUN space totals didn't take into account the 2 LUNs / Backup Set architecture.

Version 3.5 Updates

Version 3.5 introduces the following fixes:

• Improved the text on the input tab with regards to the number of database copy instances you would like for both HA and lagged copies.
• Fixes an issue where in a high availability architecture the calculator may size the solution based on activating more database copies during a second server failure event than the total number of database copies deployed on the server.

Version 3.4 Updates

Version 3.4 corrects a memory and CPU utilization issue where you deploy a site resilient architecture with multiple mailbox servers and a single database copy in the primary datacenter. Specifically, the calculator would determine the active database copy configuration after a single server failure and then size the CPU and memory requirements. However, since there is only a single database copy in the primary datacenter, the solution cannot survive with all copies hosted in the primary datacenter. Therefore, the copies need to be activated in the secondary datacenter. Version 3.4 corrects this scenario by ensuring there are at least 2 database copies in the primary datacenter in order to calculate the active database count after a single server failure.

Version 3.2 Updates

It's been a while since we discussed the Exchange 2010 Mailbox Server Role Requirements Calculator. Well I am pleased to say that today we are launching version 3.2 of the calculator.

This version includes the following improvements and new features:

• Added processor core guidance for Hub Transport and Client Access server roles.
• Added the ability to define a custom number of databases that you would like to implement in the solution.
• Added support for 2-node site resilient Database Availability Groups.
• Added 1 and 6 processor cores as selectable options.
• Improved breakdown of the activation scenarios in a site resilient solution.
• Improved breakout of the role requirements section.
• The Storage Design tab now indicates that when you select a custom RAID configuration that the calculator ignores RAID-5 and RAID-6 for 5.xK and 7.2K spindles due to performance concerns.
• Updated processor utilization results to show the processor utilization even if it is above the recommended threshold.
• Made conditional formatting improvements throughout the calculator to warn you when you have a configuration that will not work.
• Improved various cell comments.

This version also corrects the following bugs:

• Fixed LUN Requirements tables to accurately reflect space requirements when database copies are deployed as each server may not host all database copies.
• Fixed conditions that resulted in -1 lagged copies.
• Improved the active database copies after first/second server failure calculations:
  • We now calculate and expose the worst case scenario (the server that has to host the most active databases) is used in sizing memory and CPU.
  • We now ensure that the secondary datacenter calculations only consider double server failures when there are 3+ HA copies located in the secondary datacenter.
• Removed maximum memory stipulation in the minimum ESE cache memory calculation.

Hey where is Active/Active?

And for those that I know will ask, this version of the calculator does not include the Active/Active user distribution site resiliency scenario. For those that need that scenario, what I recommend is the following:

1. Launch two versions of the calculator.
2. Populate the first version for the first DAG in your design. This DAG (DAG1) will utilize Datacenter 1 as its primary location (and thus its user population is based out of Datacenter 1). It has site resiliency by having servers and database copies located in Datacenter 2 that can be activated in the event Datacenter 1 is lost.
3. Populate the second version for the second DAG in your design. This DAG (DAG2) will utilize Datacenter 2 as its primary location (and thus its user population is based out of Datacenter 2). It has site resiliency by having servers and database copies located in Datacenter 1 that can be activated in the event Datacenter 2 is lost.

By implementing the architecture in this way, you can ensure that for the majority of scenarios except loss of datacenter, the users remain operational in their primary datacenter location.

Conclusion

Hopefully you will find this calculator invaluable in helping to determine your mailbox server role requirements for Exchange 2010 mailbox servers. If you have any questions or suggestions, please email strgcalc AT microsoft DOT com.

For the explanation of different tabs and how the calculator works, go here. Yup, we updated that too!

Finally, to get the new calculator - go here.

Ross Smith IV