Planning and migrating a small organization from Exchange 2007 to 2013 (Part 6)

If you would like to read the other parts in this article series please go to:


In the last part in this series we began to plan our Exchange 2013 environment. We’ll use a lot of that information in the next two parts in the series as we look at the actual hardware we’ll be using, and then begin to feed both our planning information and discovery information into the Exchange 2013 Role Requirements Calculator.

Planning for Deployment Continued

Target Hardware

Our final input to Exchange Sizing is the hardware we’re going to be using in the target environment. As we’ve previously established, Exchange Labs will use Virtualization. Although that abstracts the physical hardware itself, it doesn’t change the underlying requirements – we’ll need to know what the physical CPUs are, how much memory we have available (primarily so we can ascertain if we’ll need to buy some more) and the physical disks that will support Exchange.

Once you’ve found out from your Virtualization admin what these details are (or checked it yourself, if that admin is also you) then we’ll need to find the SPECint_rate2006 score for the CPUs we’ll be using. This score gives a well-known baseline that we can use when sizing and is required when using the Exchange 2013 Role Requirements Calculator. Microsoft’s Processor Query Tool can assist with this so download it and open it within Excel.

For our example environment, we’re using HP ProLiant DL380e G8s, with two Intel Xeon E5-2420 CPUs which have 6 cores each. First, in the Processor Query tool, enter E5-2420 as shown below, then press Query:

Figure 1:
Entering the Processor to query in Step 2 of the tool

Next attempt to find the closest match for your hardware model. In the results below, we see a BL420c Gen 8 that uses the same CPU with a result of 370, which is pretty close, but to gain an average result enter the number of cores in Step 4 and record the Average Result highlighted below in the Yellow box:

Figure 2:
Examining the Processor Query Tool output

With our final piece of information about our target hardware established, we’ll record this information ready to use in the next section:

CPUs Cores SPECint_rate2006 score Host RAM Disks Available
2 x Intel Xeon 12 367 192GB 12 x 2TB 3.5” 7.2K RPM SAS

Table 1

Exchange Server Sizing

We’ve collected a lot of information about our existing environment – and made some decisions about the sizing for our new Exchange 2013 environment, and with that knowledge we’re finally ready to start putting together the specifications for what’s going to be needed to run Exchange 2013 for our organization.

Before we begin, remember that with each release of Exchange, the sizing from the previous versions is pretty much thrown out of the window. Improvements in the product are aimed at making it cheaper overall to run, and the trend in versions from Exchange 2007 onwards has led to use RAM to reduce IO. In Exchange 2013, we’ll also vary CPU dependant as there’s a lot going on under the hood that requires processor time. For example, if your Exchange 2013 doesn’t have enough CPU power to perform Content Indexing for items while they are still cached in RAM – i.e. in real time – then you’ll require more disk IO as the items to index must be read from disk to be indexed. You can read in detail about these requirements on the Exchange Team Blog’s post Sizing Exchange 2013 Deployments.

We won’t be performing these calculations by hand however, and as we’ve mentioned we will use the Exchange 2013 Role Requirements Calculator. This Excel-based tool will be familiar to those who have deployed Exchange 2007 and 2010’s Mailbox Role Requirements calculator. However this tool does more than just Mailbox sizing, as it will size for the entire set of requirements for your Exchange infrastructure. Remember – an Exchange 2013 Mailbox server is effectively a multi-role server as it always includes the Client Access rendering, Transport and Unified Messaging components too.

First download the calculator from the TechNet Gallery and open it in Excel. We’ll work through each section of the calculator, entering information we’ve established so far.

For Red values in the calculator we’ll select the appropriate value from a drop-down list and for Blue values we’ll manually enter the information. As this is a small environment, sections such as Site Resilience Configuration, Mailbox Database Copy Configuration and Lagged Database Copy Configuration are unavailable so we won’t cover them here.

Role Requirements Input Factors – Environment Configuration

The first section is the Exchange Environment Configuration. We’ll enter high-level details of our planned environment here. If you’re using 64-bit Global Catalog servers, make sure you choose this here. For our environment we’ll also be using a multi-role configuration – a single Exchange Server with all roles. Unless you’ve got a really good reason to (and there’s not many) stick with a multi-role configuration.

As we’re virtualizing, make sure you select this here. This makes sure that the Virtualization Overhead value is used to add the default 10% to CPU calculations. Finally, we’ll be choosing No for HA Deployment and setting the number of servers to 1:

Figure 3:
Exchange Environment Configuration Section

In the Exchange Data Configuration section, we’re going to leave the defaults as-is for our small environment. The Data Overhead Factor allows us to add extra database room to account for additional growth. We’ve already accounted for this within the Quota Limits and Number of Mailboxes section. The Mailbox Moves per Week is self-explanatory, and in a small environment we don’t expect to move many mailboxes around. The Dedicated Maintenance / Restore Volume will be required as because we’re using a single-server configuration, it’s more likely we’ll need to perform a database restore at some point – or create a temporary database to move users into to release database whitespace. The Volume Free Space Percentage adds additional capacity to ensure that in the event we reach our sizing calculations, we still have some free disk space available.

Figure 4:
Exchange Data Configuration Section

In Exchange I/O Configuration, we have the ability to specify how much additional disk IO performance we will factor in to account for unexpected activity. We’ll leave the I/O Overhead Factor at the default Microsoft recommendation of 20%. We haven’t found any clients that require additional I/O requirement within the environment, with the exception of BES users which will be accounted for later, so we’ll leave the Additional I/O Requirement per Server as 0:

Figure 5:
Exchange I/O Configuration Section

In the Database Configuration section, we don’t have to change the default value from Default, which means the calculator will determine these values for us. For our deployment we’ll look to make best use of the databases available with Exchange Standard Edition and use 4 mounted databases (remember, we might want another Database online at some point to serve as a temporary DB for maintenance). Therefore we’ll set the first value to Custom, then change the Maximum Database Size to 200GB. We’ll then choose not to automatically calculate the number of databases and set the Customer Number of Databases per Server to 4:

Figure 6:
Database Configuration Section

Finally for the environment configuration section, we’ll leave the Transport Configuration as the default – two days for the Message Queue Expiration. This means that messages that are in-transport, such as inbound messages that are attempting to deliver to an offline database, will expire after 2 days in the queue.

Figure 7:
Transport Configuration Section

Role Requirements Input Factors – Mailbox Configuration

Our next section draws from some of the key discovery we performed earlier in this series. First of all, we’ll need the Exchange Profile Analyser results recorded in Part 2 of this series. We’ll also use the Quota Limits and Number of Mailboxes information from earlier in Planning for Deployment and from Part 4 of this series, we use the information about the number of Blackberry Enterprise Server users to ensure we account for additional IO required by those users.

The Exchange Profile Analyser results told us that the organization’s Average Message Size is 147.61KB. We’ll round that up to 150KB for the calculations. Our combined Average Received and Average Sent was 30.19, so we’ll round that up to 31.

Our Quota Limits and Number of Mailboxes planning resulted in two distinct user tiers – 597 Standard Users with 825MB Mailboxes, and 6 VIP users with 30GB mailboxes. We also decided in Mailbox Databases that we’d define a value of 14 days for deleted item recovery.

The Blackberry Enterprise Server user information told us we had 73 users enabled, though not all of them used BES. Blackberry provide information about the capacity requirements for BES in the Performance Benchmarking Guide, available on the Blackberry Support website. The latest guidance, on page 37 of the guide, suggests that an IOPS Multiplication Factor of 2.0 should be used and a Megacycles Multiplication Factor of 1.5. As these only relate to a proportion of users – who will be distributed equally across our databases, we’ll use our Standard User tier and define that 12% of users (73 of 597) will require this figures factored in.

We’ll take a look at the Tier-1 User Mailbox Configuration table below. As you can see, we’ve entered the values for the Total Number of Tier-1 User Mailbox, Total Send/Receive Capability per Mailbox per day, Average Message Size and Delete Item Retention based on the figures above. As we’ve already factored in growth, we’ve left Projected Mailbox Number Growth blank. We’re not using Personal Archives either, so again we’ve left the value as 0. Single Item Recovery and Calendar Version Storage are two areas that are enabled by default. We’ll leave these enabled because in the event that an item is changed, for example, a desktop anti-virus program replaces the contents of messages with nothing or an errant mobile device makes erroneous calendar changes we can recover these during our 14-day deleted item window without needing to resort to backups.

We’ve changed the Multiplication Factor User Percentage to 12% to indicate that the following IOPS Multiplication Factor and Megacycles Multiplication Factor will only apply to our BES users, and entered the respective values in the two subsequent fields. We’ll leave Desktop Search Engines Enabled set to no to indicate we don’t use any third-party desktop search engines like Google Desktop Search and chosen to predict the IOPS value automatically.

Figure 8:
Tier-1 User Mailbox Configuration Section

In the Tier-2 User Mailbox Configuration, we’ll enter similar values, but choosing to input 6 mailboxes to represent our VIP Tier, and entered a mailbox limit of 30GB. In the Tier-2 section we’ll leave Multiplication Factor User Percentage at the default of 100%, and leave the IOPS Multiplication Factor and Megacycles Multiplication Factor both at the default, 1.00:

Figure 9:
Tier-2 User Mailbox Configuration Section

If you’ve defined more tiers, repeat the process for those as necessary.

At this point we’ve entered a lot of the complicated information into the calculator, leaving Backup Config, Primary Datacenter Server Disk Configuration and Processor Configuration, which we’ll cover at the beginning of the next section and use the results to determine our Exchange server specification.


In this part of our Exchange 2007 to 2013 upgrade series, we’ve nearly completed one of the most critical tasks in any Exchange deployment – getting the right information into the sizing calculations so we can determine the specifications required. In the next part we’ll complete our planning and Exchange sizing, then move onto making sure our environment is ready to deploy Exchange 2013 into.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top