Exchange Team Blog : Announcements

Exchange Server 2013 Architecture Poster PDF Download Available

Scott Schnoll [MSFT] — Tue, 11 Jun 2013 02:34:00 GMT

We just released a downloadable PDF version of the Exchange Server 2013 Architecture Poster. This is the poster that we handed out at the Office booth and in various Exchange 2013 breakout sessions last week at TechEd North America 2013 in New Orleans, LA. We’ll also be handing out printed copies of the poster at TechEd Europe 2013 in Madrid, Spain in a couple of weeks.

While we cannot provide printed copies for everyone, you can download the PDF file and take it to your favorite printer/copy center, and have them print it for you. It is designed to be printed in 36” x 24” format.

This poster highlights the significantly updated and modernized architecture in Exchange 2013, and highlights the new technologies in Exchange 2013, such as Managed Availability, the new storage and high availability features, and integration with SharePoint and Lync. In addition, it illustrates the new transport architecture in Exchange 2013.

A zoom.it version of the poster can be found at http://zoom.it/BuoF.

We welcome your feedback on the poster. If you have any, please feel free to send it to eapf@microsoft.com.

Scott Schnoll

Per-Server Database Limits Explained

Ross Smith IV [MSFT] — Tue, 04 Jun 2013 14:45:24 GMT

Over the past year, we have discussed the architectural changes that have been introduced in Exchange Server 2013. I wrote about the reduction in complexity that the new server role architecture introduces, as well as, the one of the new capabilities introduced in Exchange 2013, Managed Availability’s recovery oriented computing. However, we haven’t been clear on other architectural changes that have shaped decisions we’ve made about the Exchange 2013 product. For example, the decision on reducing the number of databases supported per-server from 100 to 50. There were three main reasons for this:

Server architecture changes
Use of commodity hardware
Testing

Let me explain each of these in more detail.

Server Architecture

Exchange 2013 includes fundamental changes to the search and store components and data is processed and rendered.

The old content indexing service was replaced with Search Foundation. Search Foundation is an actively developed search platform that used across the Office Server products. Search Foundation allows us to have notification-driven content indexing which improves indexing performance; in addition, we now annotate during transport, reducing the number of times a message must be indexed significantly.

The monolithic store.exe process was re-written; store is now written in managed code and there are now at least three processes that make up the Information Store service: The Microsoft Exchange Replication service, the Information Store service process controller, and the Information store worker process. By utilizing the worker process model, each database is now isolated from every other database (e.g., a database crashing due to a malformed message will not bring down the rest of the databases on the server).

In addition, there is a core shift in the server role architecture such that the protocol responsible for servicing a user’s request is the protocol instance that is local to the user’s active mailbox database copy. This means that the Mailbox server role now performs more work when compared to its Exchange 2010 counterpart.

The end result is that with the server architecture changes we introduced in Exchange 2013, search, store, and the protocols typically can be CPU and memory bound, as opposed to disk IO or capacity bound.

Commodity Hardware

As discussed in our server sizing guidance, we are big fans of commodity server hardware. Office 365 is designed to run on commodity hardware that leverages 2 processor sockets and 12 disks – we do not leverage external storage chassis as this increases the operational complexity in the environment. Our Exchange 2013 Mailbox servers have less than 50 database copies per-server in Office 365.

Testing

The last reason as to why we limited support to 50 databases per-server is that we did not have actual deployments at any scale to validate that store, search, the protocols, and Managed Availability could handle 100 databases per-server. Automation and lab testing can only take you so far; the lack of real world usage was one of the key reasons why we chose to limit the database count.

Moving Forward

The Exchange Product Group takes pride in the feedback mechanisms we have invested in with the Exchange community. Since the release of Exchange 2013, we’ve received an inordinate amount of feedback regarding the reduction in supported databases per-server. The driving response has been “we currently deploy more than 50 databases per-server in Exchange 2010; with this change, this means we will need to deploy more servers, which increases our capital expenditures significantly.” Rest assured, that is not the message we want with Exchange 2013. It is true that Exchange 2013 utilizes more CPU and memory than its predecessors – this is due to the architecture changes we’ve made, as well as the changes we’ve made to reduce disk IO, so that you can deploy more mailboxes per disk. But we do not want to see architectures artificially limited by the supported databases per-server constraint.

Over the last several months, we’ve been working to resolve our concerns and improve our test matrices to validate supporting more databases/server.

As a result of the work done by the Mailbox Intelligence team and Operations teams, I am pleased to announce that when Exchange Server 2013 RTM Cumulative Update 2 (CU2) releases we are increasing the number of databases per-server back to 100. Both the Exchange 2013 Server Role Calculator and our sizing guidance will be updated to include this architectural change in tandem with CU2’s release. CU2 will release later this summer.

As always, we continue to identify ways to better serve your needs through our regular servicing releases. We hope you find this architectural change useful. Please keep the feedback coming, we are listening.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Released: Update Rollup 1 for Exchange Server 2010 SP3

The Exchange Team — Thu, 30 May 2013 05:00:00 GMT

Update 6/13/13: we added a known issue with transport rules to the blog post below.

Today the Exchange CXP team released Update Rollup 1 for Exchange Server 2010 SP3 to the Download Center.

Note: Some of the following KB articles may not be available at the time of publishing this post.

This update contains fixes for a number of customer-reported and internally found issues. For more details, including a list of fixes included in this update, see KB 2803727. We would like to specifically call out the following fixes which are included in this release:

2561346 Mailbox storage limit error when a delegate uses the manager's mailbox to send an email message in an Exchange Server 2010 environment
2756460 You cannot open a mailbox that is located in a different site by using Outlook Anywhere in an Exchange Server 2010 environment
2802569 Mailbox synchronization fails on an Exchange ActiveSync device in an Exchange Server 2010 environment
2814847 Rapid growth in transaction logs, CPU use, and memory consumption in Exchange Server 2010 when a user syncs a mailbox by using an iOS 6.1 or 6.1.1-based device
2822208 Unable to soft delete some messages after installing Exchange 2010 SP2 RU6 or SP3

For DST changes, see Daylight Saving Time Help and Support Center (microsoft.com/time).

A known issue with Exchange 2010 SP3 RU1 Setup

You cannot install or uninstall Update Rollup 1 for Exchange Server 2010 SP3 on the double-byte character set (DBCS) version of Windows Server 2012 if the language preference for non-Unicode programs is set to the default language. To work around this issue, you must first change this setting. To do this, follow these steps:

In Control Panel, open the Clock, Region and Language item, and then click Region.
Click the Administrative tab.
In the Language for non-Unicode programs area, click Change system locale.
On the Current system locale list, click English (United States), and then click OK.

After you successfully install or uninstall Update Rollup 1, revert this language setting, as appropriate.

We have identified the cause of this problem and plan to resolve it in a future rollup, but did not want to further delay the release of RU1 for customers who are not impacted by it.

A known issue with transport rules after E2010 SP3 RU1 is installed

We have an issue where the messages stick in poison queue and transport continually crashes after this rollup is applied.

We have gathered enough information and have determined the issue. Specifically, the issue is caused by a transport rule (disclaimer) attempting to append the disclaimer to the end of HTML formatted messages. When this occurs, messages will be placed in the poison queue and the transport service will crash with an exception. We are investing resources to develop a code fix. You can either disable or reconfigure the disclaimer transport rule.

Exchange Team

Released: Calculator Updates Galore!

Ross Smith IV [MSFT] — Fri, 24 May 2013 18:27:00 GMT

Today, we have released an updated version of the Exchange 2013 Server Role Requirements Calculator that addresses several issues found since its initial release. You can view what changes have been made, or download the update directly.

In addition, we are releasing an updated version of the Exchange 2010 Server Role Requirements Calculator as well. You can view what changes have been made, or download the update directly.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Released: Exchange Server 2013 Management Pack

Ross Smith IV [MSFT] — Wed, 15 May 2013 19:07:42 GMT

The Microsoft Exchange Server 2013 Management Pack (SCOM MP) is now live!

As I discussed in my Managed Availability article, the key difference between this management pack and previous releases, is that our health logic is now built into Exchange, as opposed to the management pack. This means updates to Exchange 2013 (like our cumulative updates), will include changes to the probes, monitors, and responders. Any issues that Managed Availability cannot solve are bubbled up to SCOM via an event monitor.

You can download the management pack via Microsoft Download Center at http://www.microsoft.com/en-us/download/details.aspx?id=39039.

You can also view the following documentation:

Exchange Server 2013 Management Pack Documentation provides detailed instructions and descriptions on how to import and use the Exchange Server 2013 Management Pack
Exchange Server 2013 Management Health Set documentation comprehensive list of healthsets and details

More information can be found at the SCOM team’s blog - http://blogs.technet.com/b/momteam/archive/2013/05/14/exchange-2013-management-pack-released.aspx.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Released: Exchange 2013 Server Role Requirements Calculator

Ross Smith IV [MSFT] — Tue, 14 May 2013 13:00:00 GMT

It’s been a long road, but the initial release of the Exchange 2013 Server Role Requirements Calculator is here. No, that isn’t a mistake, the calculator has been rebranded. Yes, this is no longer a Mailbox server role calculator; this calculator includes recommendations on sizing Client Access servers too! Originally, marketing wanted to brand it as the Microsoft Exchange Server 2013 Client Access and Mailbox Server Roles Theoretical Capacity Planning Calculator, On-Premises Edition. Wow, that’s a mouthful and reminds me of this branding parody. Thankfully, I vetoed that name (you’re welcome!).

The calculator supports the architectural changes made possible with Exchange 2013:

Client Access Servers

Like with Exchange 2010, the recommendation in Exchange 2013 is to deploy multi-role servers. There are very few reasons you would need to deploy dedicated Client Access servers (CAS); CPU constraints, use of Windows Network Load Balancing in small deployments (even with our architectural changes in client connectivity, we still do not recommend Windows NLB for any large deployments) and certificate management are a few examples that may justify dedicated CAS.

When deploying multi-role servers, the calculator will take into account the impact that the CAS role has and make recommendations for sizing the entire server’s memory and CPU. So when you see the CPU utilization value, this will include the impact both roles have!

When deploying dedicated server roles, the calculator will recommend the minimum number of Client Access processor cores and memory per server, as well as, the minimum number of CAS you should deploy in each datacenter.

Transport

Now that the Mailbox server role includes additional components like transport, it only makes sense to include transport sizing in the calculator. This release does just that and will factor in message queue expiration and Safety Net hold time when calculating the database size. The calculator even makes a recommendation on where to deploy the mail.que database, either the system disk, or on a dedicated disk!

Multiple Databases / JBOD Volume Support

Exchange 2010 introduced the concept of 1 database per JBOD volume when deploying multiple database copies. However, this architecture did not ensure that the drive was utilized effectively across all three dimensions – throughput, IO, and capacity. Typically, the system was balanced from an IO and capacity perspective, but throughput was where we saw an imbalance, because during reseeds only a portion of the target disk’s total capable throughput was utilized. In addition, capacity on the 7.2K disks continue to increase with 4TB disks now available, thus impacting our ability to remain balanced along that dimension. In addition, Exchange 2013 includes a 33% reduction in IO when compared to Exchange 2010. Naturally, the concept of 1 database / JBOD volume needed to evolve. As a result, Exchange 2013 made several architectural changes in the store process, ESE, and HA architecture to support multiple databases per JBOD volume. If you would like more information, please see Scott’s excellent TechEd session in a few weeks on Exchange 2013 High Availability and Site Resilience or the High Availability and Site Resilience topic on TechNet.

By default, the calculator will recommend multiple databases per JBOD volume. This architecture is supported for single datacenter deployments and multi-datacenter deployments when there is copy and/or server symmetry. The calculator supports highly available database copies and lagged database copies with this volume architecture type. The distribution algorithm will lay out the copies appropriately, as well as, generate the deployment scripts correctly to support AutoReseed.

High Availability Architecture Improvements

The calculator has been improved in several ways for high availability architectures:

You can now specify the Witness Server location, either primary, secondary, or tertiary datacenter.
The calculator allows you to simulate WAN failures, so that you can see how the databases are distributed during the worst failure mode.
The calculator allows you to name servers and define a database prefix which are then used in the deployment scripts.
The distribution algorithm supports single datacenter HA deployments, Active/Passive deployments, and Active/Active deployments.
The calculator includes a PowerShell script to automate DAG creation.
In the event you are deploying your high availability architecture with direct attached storage, you can now specify the maximum number of database volumes each server will support. For example, if you are deploying a server architecture that can support 24 disks, you can specify a maximum support of 20 database volumes (leaving 2 disks for system, 1 disk for Restore Volume, and 1 disks as a spare for AutoReseed).

Additional Mailbox Tiers (sort of!)

Over the years, a few, but vocal, members of the community have requested that I add more mailbox tiers to the calculator. As many of you know, I rarely recommend sizing multiple mailbox tiers, as that simply adds operational complexity and I am all about removing complexity in your messaging environments. While, I haven’t specifically added additional mailbox tiers, I have added the ability for you to define a percentage of the mailbox tier population that should have the IO and Megacycle Multiplication Factors applied. In a way, this allows you to define up to eight different mailbox tiers.

Processors

I’ve received a number of questions regarding processor sizing in the calculator. People are comparing the Exchange 2010 Mailbox Server Role Requirements Calculator output with the Exchange 2013 Server Role Requirements Calculator. As mentioned in our Exchange 2013 Performance Sizing article, the megacycle guidance in Exchange 2013 leverages a new server baseline, therefore, you cannot directly compare the output from the Exchange 2010 calculator with the Exchange 2013 calculator.

Conclusion

There are many other minor improvements sprinkled throughout the calculator. We hope you enjoy this initial release. All of this work wouldn’t have occurred without the efforts of Jeff Mealiffe (for without our sizing guidance there would be no calculator!), David Mosier (VBA scripting guru and the master of crafting the distribution worksheet), and Jon Gollogy (deployment scripting master).

As always we welcome feedback and please report any issues you may encounter while using the calculator by emailing strgcalc AT microsoft DOT com.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Ask the Perf Guy: Sizing Exchange 2013 Deployments

The Exchange Team — Mon, 06 May 2013 13:00:00 GMT

Since the release to manufacturing (RTM) of Exchange 2013, you have been waiting for our sizing and capacity planning guidance. This is the first official release of our guidance in this area, and updates to our TechNet content will follow in a future milestone.

As we continue to learn more from our own internal deployments of Exchange 2013, as well as from customer feedback, you will see further updates to our sizing and capacity planning guidance in two forms: changes to the numbers mentioned in this document, as well as further guidance on specific areas not covered here. Let us know what you think we are missing and we will do our best to respond with better information over time.

First, some context

Historically, the Exchange Server product group has used various sources of data to produce sizing guidance. Typically, this data would come from scale tests run early in the product development cycle, and we would then fine-tune that guidance with observations from production deployments closer to final release. Production deployments have included Exchange Dogfood (our internal pre-release deployment that hosts the Exchange team and various other groups at Microsoft), Microsoft IT’s corporate Exchange deployment, and various early adopter programs.

For Exchange 2013, our guidance is primarily based on observations from the Exchange Dogfood deployment. Dogfood hosts some of the most demanding Exchange users at Microsoft, with extreme messaging profiles and many client sessions per user across multiple client types. Many users in the Dogfood deployment send and receive more than 500 messages per day, and typically have multiple Outlook clients and multiple mobile devices simultaneously connected and active. This allows our guidance to be somewhat conservative, taking into account additional overhead from client types that we don’t regularly see in our internal deployments as well as client mixes that might be different from what's considered “normal” at Microsoft.

Does this mean that you should take this conservative guidance and adjust the recommendations such that you deploy less hardware? Absolutely not. One of the many things we have learned from operating our own very high-scale service is that availability and reliability are very dependent on having capacity available to deal with those unexpected peaks.

Sizing is both a science and an art form. Attempting to apply too much science to the process (trying to get too accurate) usually results in not having enough extra capacity available to deal with peaks, and in the end, results in a poor user experience and decreased system availability. On the other hand, there does need to be some science involved in the process, otherwise it’s very challenging to have a predictable and repeatable methodology for sizing deployments. We strive to achieve the right balance here.

Impact of the new architecture

From a sizing and performance perspective, there are a number of advantages with the new Exchange 2013 architecture. As many of you are aware, a couple of years ago we began recommending multi-role deployment for Exchange 2010 (combining the Mailbox, Hub Transport, and Client Access Server (CAS) roles on a single server) as a great way to take advantage of hardware resources on modern servers, as well as a way to simplify capacity planning and deployment. These same advantages apply to the Exchange 2013 Mailbox role as well. We like to think of the services running on the Mailbox role as providing a balanced utilization of resources rather than having a set of services on a role that are very disk intensive, and a set of services on another role that are very CPU intensive.

Another example to consider for the Mailbox role is cache effectiveness. Software developers use in-memory caching to prevent having to use higher-latency methods to retrieve data (like LDAP queries, RPCs, or disk reads). In the Exchange 2007/2010 architecture, processing for operations related to a particular user could occur on many servers throughout the topology. One CAS might be handling Outlook Web App for that user, while another (or more than one) CAS might be handling Exchange ActiveSync connections, and even more CAS might be processing Outlook Anywhere RPC proxy load for that same user. It’s even possible that the set of servers handling that load could be changing on a regular basis. Any data associated with that user stored in a cache would become useless (effectively a waste of memory) as soon as those connections moved to other servers. In the Exchange 2013 architecture, all workload processing for a given user occurs on the Mailbox server hosting the active copy of that user’s mailbox. Therefore, cache utilization is much more effective.

The new CAS role has some nice benefits as well. Given that the role is totally stateless from a user perspective, it becomes very easy to scale up and down as demands change by simply adding or removing servers from the topology. Compared to the CAS role in prior releases, hardware utilization is dramatically reduced meaning that fewer CAS role machines will be required. Additionally, it may make sense for many customers to consider a multi-role deployment in which CAS and Mailbox are co-located – this allows further simplification of capacity planning and deployment, and also increases the number of available CAS which has a positive effect on service availability. Look for a follow up post on the benefits of a multi-role deployment soon.

Start to finish, what’s the process?

Sizing an Exchange deployment has six major phases, and I will go through each of them in this post in some detail.

You begin the process by making sure you fully understand the available guidance on this topic. If you are reading this post, that’s a great start. There may have been updates posted either here on the Exchange team blog, or over on TechNet. Make sure you take a look before proceeding.
The second step is to gather any available data on the existing messaging deployment (if there is one) or estimate user profile requirements if this is a totally new solution.
The third step is perhaps the most difficult. At this point, you need to figure out all of the requirements for the Exchange solution that might impact the sizing process. This can include decisions like the desired mailbox size (mailbox quota), service level objectives, number of sites, number of mailbox database copies, storage architecture, growth plans, deployment of 3^rd party products or line-of-business applications, etc. Essentially, you need to understand any aspect of the design that could impact the number of servers, user count, and utilization of servers.
Once you have collected all of the requirements, constraints, and user profile data, it’s time to calculate Exchange requirements. The easiest way to do this is with the calculator tool, but it can also be done manually as I will describe in this post. Clearly the calculator makes the process much easier, so if the calculator is available, use it!
Once the Exchange requirements have been calculated, it’s time to consider various options that are available. For example, there may be a choice between scaling up (deploying fewer larger servers) and scaling out (deploying a larger number of smaller servers), and the options could have various implications on high availability, as well as the total number of hardware or software failures that the solution can sustain while remaining available to users. Another typical decision is around storage architecture, and this often comes down to cost. There are a range of costs and benefits to different storage choices, and the Exchange requirements can often be met by more than one of these options.
The last step is to finalize the design. At this point, it’s time to document all of the decisions that were made, order some hardware, use Jetstress to validate that the storage requirements can be met, and perform any other necessary pre-production lab testing to ensure that the production rollout and implementation will go smoothly.

Gather requirements and user data

The primary input to all of the calculations that you will perform later is the average user profile of the deployment, where the user profile is defined as the sum of total messages sent and total messages received per-user, per-workday (on average). Many organizations have quite a bit of variability in user profiles. For example, a segment of users might be considered “Information Workers” and spend a good part of their day in their mailbox sending and reading mail, while another segment of users might be more focused on other tasks and use email infrequently. Sizing for these segments of users can be accomplished by either looking at the entire system using weighted averages, or by breaking up the sizing process to align with the various segments of users. In general it’s certainly easier to size the whole system as a unit, but there may be specific requirements (like the use of certain 3^rd party tools or devices) which will significantly impact the sizing calculation for one or more of the user segments, and it can be very difficult to apply sizing factors to a user segment while attempting to size the entire solution as a unit.

The obvious question in your mind is how to go get this user profile information. If you are starting with an existing Exchange deployment, there are a number of options that can be used, assuming that you aren’t the elusive Exchange admin who actually tracks statistics like this on an ongoing basis. If you are using Exchange 2007 or earlier, you can utilize the Exchange Profile Analyzer (EPA) tool, which will provide overall user profile statistics for your Exchange organization as well as detailed per-user statistics if required. If you are on Exchange 2010, the EPA tool is not an option for you. One potential option is to evaluate message traffic using performance counters to come up with user profile averages on a per-server basis. This can be done by monitoring the MSExchangeIS\Messages Submitted/sec and MSExchangeIS\Messages Delivered/sec counters during peak average periods and extrapolating the recorded data to represent daily per-user averages. I will cover this methodology in a future blog post, as it will take a fair amount of explanation. Another option is to use message tracking logs to generate these statistics. This could be done via some crafty custom PowerShell scripting, or you could look for scripts that attempt to do this work for you already. One of our own consultants points to an example on his blog.

Typical user profiles range from 50-500 messages per-user/per-day, and we provide guidance for those profiles. When in doubt, round up.

The other important piece of profile information for sizing is the average message size seen in the deployment. This can be obtained from EPA, or from the other mentioned methods (via transport performance counters, or via message tracking logs). Within Microsoft, we typically see average message sizes of around 75KB, but we certainly have worked with customers that have much higher average message sizes. This can vary greatly by industry, and by region.

Start with the Mailbox servers

Just as we recommended for Exchange 2010, the right way to start with sizing calculations for Exchange 2013 is with the Mailbox role. In fact, those of you who have sized deployments for Exchange 2010 will find many similarities with the methodology discussed here.

Example scenario

Throughout this article, we will be referring to an example deployment. The deployment is for a relatively large organization with the following attributes:

100,000 mailboxes
200 message/day profile, with 75KB average message size
10GB mailbox quota
Single site
4 mailbox database copies, no lagged copies
2U commodity server hardware platform with internal drive bays and an external storage chassis will be used (total of 24 available large form-factor drive bays)
7200 RPM 4TB midline SAS disks are used
Mailbox databases are stored on JBOD direct attached storage, utilizing no RAID
Solution must survive double failure events

High availability model

The first thing you need to determine is your high availability model, e.g., how you will meet the availability requirements that you determined earlier. This likely includes multiple database copies in one or more Database Availability Groups, which will have an impact on storage capacity and IOPS requirements. The TechNet documentation on this topic provides some background on the capabilities of Exchange 2013 and should be reviewed as part of the sizing process.

At a minimum, you need to be able to answer the following questions:

Will you deploy multiple database copies?
How many database copies will you deploy?
Will you have an architecture that provides site resilience?
What kind of resiliency model will you deploy?
How will you distribute database copies?
What storage architecture will you use?

Capacity requirements

Once you have an understanding of how you will meet your high availability requirements, you should know the number of database copies and sites that will be deployed. Given this, you can begin to evaluate capacity requirements. At a basic level, you can think of capacity requirements as consisting of storage for mailbox data (primarily based on mailbox storage quotas), storage for database log files, storage for content indexing files, and overhead for growth. Every copy of a mailbox database is a multiplier on top of these basic storage requirements. As a simplistic example, if I was planning for 500 mailboxes of 1GB each, the storage for mailbox data would be 500GB, and then I would need to apply various factors to that value to determine the per-copy storage requirement. From there, if I needed 3 copies of the data for high availability, I would then need to multiply by 3 to obtain the overall capacity requirement for the solution (all servers). In reality, the storage requirements for Exchange are far more complex, as you will see below.

Mailbox size

To determine the actual size of a mailbox on disk, we must consider 3 factors: the mailbox storage quota, database white space, and recoverable items.

The mailbox storage quota is what most people think of as the “size of the mailbox” – it’s the user perceived size of their mailbox and represents the maximum amount of data that the user can store in their mailbox on the server. While this is certainly represents the majority of space utilization for Exchange databases, it’s not the only element by which we have to size.

Database whitespace is the amount of space in the mailbox database file that has been allocated on disk but doesn’t contain any in-use database pages. Think of it as available space to grow into. As content is deleted out of mailbox databases and eventually removed from the mailbox recoverable items, the database pages that contained that content become whitespace. We recommend planning for whitespace size equal to 1 day worth of messaging content.

Estimated Database Whitespace per Mailbox = per-user daily message profile x average message size

This means that a user with the 200 message/day profile and an average message size of 75KB would be expected to consume the following whitespace:

200 messages/day x 75KB = 14.65MB

When items are deleted from a mailbox, they are really “soft-deleted” and moved temporarily to the recoverable items folder for the duration of the deleted item retention period. Like Exchange 2010, Exchange 2013 has a feature known as single item recovery which will prevent purging data from the recoverable items folder prior to reaching the deleted item retention window. When this is enabled, we expect to see a 1.2 percent increase in mailbox size for a 14 day deleted item retention window. Additionally, we expect to see a 3 percent increase in the size of the mailbox for calendar item version logging which is enabled by default. Given that a mailbox will eventually reach a steady state where the amount of new content will be approximately equal to the amount of deleted content in order to remain under quota, we would expect the size of the items in the recoverable items folder to eventually equal the size of new content sent & received during the retention window. This means that the overall size of the recoverable items folder can be calculated as follows:

Recoverable Items Folder Size = (per-user daily message profile x average message size x deleted item retention window) + (mailbox quota size x 0.012) + (mailbox quota size x 0.03)

If we carry our example forward with the 200 message/day profile, a 75KB average message size, a deleted item retention window of 14 days, and a mailbox quota of 10GB, the expected recoverable items folder size would be:

(200 messages/day x 75KB x 14 days) + (10GB x 0.012) + (10GB x 0.03)
= 210,000KB + 125,819.12K + 314,572.8KB = 635.16MB

Given the results from these calculations, we can sum up the mailbox capacity factors to get our estimated mailbox size on disk:

Mailbox Size on disk = 10GB mailbox quota + 14.65MB database whitespace + 635.16MB Recoverable Items Folder = 10.63GB

Content indexing

The space required for files related to the content indexing process can be estimated as 20% of the database size.

Per-Database Content Indexing Space = database size x 0.20

In addition, you must additionally size for one additional content index (e.g. an additional 20% of one of the mailbox databases on the volume) in order to allow content indexing maintenance tasks (specifically the master merge process) to complete. The best way to express the need for the master merge space requirement would be to look at the average database file size across all databases on a volume and add 1 database worth of disk consumption to the calculation when determining the per-volume content indexing space requirement:

Per-Volume Content Indexing Space = (average database size x (databases on the volume + 1) x 0.20)

As a simple example, if we had 2 mailbox databases on a single volume and each database consumed 100GB of space, we would compute the per-volume content indexing space requirement like this:

100GB database size x (2 databases + 1) x 0.20 = 60GB

Log space

The amount of space required for ESE transaction log files can be computed using the same method as Exchange 2010. You can find details on the process in the Exchange 2010 TechNet guidance. To summarize the process, you must first determine the base guideline for number of transaction logs generated per-user, per-day, using the following table. As in Exchange 2010, log files are 1MB in size, making the math for log capacity quite straightforward.

Message profile (75 KB average message size)	Number of transaction logs generated per day
50	10
100	20
150	30
200	40
250	50
300	60
350	70
400	80
450	90
500	100

Once you have the appropriate value from the table which represents guidance for a 75KB average message size, you may need to adjust the value based on differences in the target average message size. Every time you double the average message size, you must increase the logs generated per day by an additional factor of 1.9. For example:

Transaction logs at 200 messages/day with 150KB average message size = 40 logs/day (at 75KB average message size) x 1.9 = 76

Transaction logs at 200 messages/day with 300KB average message size = 40 logs/day (at 75KB average message size) x (1.9 x 2) = 152

While daily log volume is interesting, it doesn’t represent the entire requirement for log capacity. If traditional backups are being used, logs will remain on disk for the interval between full backups. When mailboxes are moved, that volume of change to the target database will result in a significant increase in the amount of logs generated during the day. In a solution where Exchange native data protection is in use (e.g., you aren’t using traditional backups), logs will not be truncated if a mailbox database copy is failed or if an entire server is unreachable unless an administrator intervenes. There are many factors to consider when sizing for required log capacity, and it is certainly worth spending some time in the Exchange 2010 TechNet guidance mentioned earlier to fully understand these factors before proceeding. Thinking about our example scenario, we could consider log space required per database if we estimate the number of users per database at 65. We will also assume that 1% of our users are moved per week in a single day, and that we will allocate enough space to support 3 days of logs in the case of failed copies or servers.

Log Capacity to Support 3 Days of Truncation Failure = (65 mailboxes/database x 40 logs/day x 1MB log size) x 3 days = 7.62GB

Log Capacity to Support 1% mailbox moves per week = 65 mailboxes/database x 0.01 x 10.63GB mailbox size = 6.91GB

Total Local Capacity Required per Database = 7.62GB + 6.91GB = 14.53GB

Putting all of the capacity requirements together

The easiest way to think about sizing for storage capacity without having a calculator tool available is to make some assumptions up front about the servers and storage that will be used. Within the product group, we are big fans of 2U commodity server platforms with ~12 large form-factor drive bays in the chassis. This allows for a 2 drive RAID array for the operating system, Exchange install path, transport queue database, and other ancillary files, and ~10 remaining drives to use as mailbox database storage in a JBOD direct attached storage configuration with no RAID. Fill this server up with 4TB SATA or midline SAS drives, and you have a fantastic Exchange 2013 server. If you need even more storage, it’s quite easy to add an additional shelf of drives to the solution.

Using the large deployment example and thinking about how we might size this on the commodity server platform, we can consider a server scaling unit that has a total of 24 large form-factor drive bays containing 4TB midline SAS drives. We will use 2 of those drives for the OS & Exchange, and the remaining drive bays will be used for Exchange mailbox database capacity. Let’s use 12 of those drive bays for databases – that leaves 10 remaining drive bays that could contain spares or remain empty. For this sizing exercise, let’s also plan for 4 databases per drive. Each of those drives has a formatted capacity of ~3725GB. The first step in figuring out the number of mailboxes per database is to look at overall capacity requirements for the mailboxes, content indexes, and required free space (which we will set to 5%).

To calculate the maximum amount of space available for mailboxes, let’s apply a formula (note that this doesn’t consider space for logs – we will make sure that the volume will have enough space for logs later in the process). First, we can remove our required free space from the available storage on the drive:

Available Space (excluding required free space) = Formatted capacity of the drive x (1 – free space)

Then we can remove the space required for content indexing. As discussed above, the space required for content indexing will be 20% of the database size, with an additional 20% of one database for content indexing maintenance tasks. Given the additional 20% requirement, we can’t model the overall space requirement as a simple 20% of the remaining space on the volume. Instead we need to compute a new percentage that takes the number of databases per-volume into consideration.

Now we can remove the space for content indexing from our available space on the volume:

And we can then divide by the number of databases per-volume to get our maximum database size:

In our example scenario, we would obtain the following result:

Given this value, we can then calculate our maximum users per database (from a capacity perspective, as this may change when we evaluate the IO requirements):

Let’s see if that number is actually reasonable given our 4 copy configuration. We are going to use 16-node DAGs for this deployment to take full advantage of the scalability and high-availability benefits of large DAGs. While we have many drives available on our selected hardware platform, we will be limited by the maximum of 50 database copies per-server in Exchange 2013. Considering this maximum and our desire to have 4 databases per volume, we can calculate the maximum number of drives for mailbox database usage as:

With 12 database volumes and 4 database copies per-volume, we will have 48 total database copies per server.

With 66 users per database and 100,000 total users, we end up with the following required DAG count for the user population:

In this very large deployment, we are using a DAG as a unit of scale or “building block” (e.g. we perform capacity planning based on the number of DAGs required to meet demand, and we deploy an entire DAG when we need additional capacity), so we don’t intend to deploy a partial DAG. If we round up to 8 DAGs we can compute our final users per database count:

With 65 users per-database, that means we will expect to consume the following space for mailbox databases:

Estimated Database Size = 65 users x 10.63GB = 690.95GB
Database Consumption / Volume = 690.95GB x 4 databases = 2763.8GB

Using the formula mentioned earlier, we can compute our estimated content index consumption as well:

690.95GB database size x (4 databases + 1) x 0.20 = 690.95GB

You’ll recall that we computed transaction log space requirements earlier, and it turns out that we magically computed those values with the assumption that we would have 65 users per-database. What a pleasant coincidence! So we will need 14.53GB of space for transaction logs per-database, or to get a more useful result:

Log Space Required / Volume = 14.53GB x 4 databases = 58.12GB

To sum it up, we can estimate our total per-volume space utilization and make sure that we have plenty of room on our target 4TB drives:

Looks like our database volumes are sized perfectly!

IOPS requirements

To determine the IOPS requirements for a database, we look at the number of users hosted on the database and consider the guidance provided in the following table to compute total required IOPS when the database is active or passive.

Messages sent or received per mailbox per day	Estimated IOPS per mailbox (Active or Passive)
50	0.034
100	0.067
150	0.101
200	0.134
250	0.168
300	0.201
350	0.235
400	0.268
450	0.302
500	0.335

For example, with 50 users in a database, with an average message profile of 200, we would expect that database to require 50 x 0.134 = 6.7 transactional IOPS when the database is active, and 50 x 0.134 = 6.7 transactional IOPS when the database is passive. Don’t forget to consider database placement which will impact the number of databases with IOPS requirements on a given storage volume (which could be a single JBOD drive or might be a more complex storage configuration).

Going back to our example scenario, we can evaluate the IOPS requirement of the solution, recalling that the average user profile in that deployment is the 200 message/day profile. We have 65 users per database and 4 databases per JBOD drive, so we can estimate our IOPS requirement in worst-case (all databases active) as:

65 mailboxes x 4 databases per-drive x 0.134 IOPS/mailbox at 200 messages/day profile = ~34.84 IOPS per drive

Midline SAS drives typically provide ~57.5 random IOPS (based on our own internal observations and benchmark tests), so we are well within design constraints when thinking about IOPS requirements.

Storage bandwidth requirements

While IOPS requirements are usually the primary storage throughput concern when designing an Exchange solution, it is possible to run up against bandwidth limitations with various types of storage subsystems. The IOPS sizing guidance above is looking specifically at transactional (somewhat random) IOPS and is ignoring the sequential IO portion of the workload. One place that sequential IO becomes a concern is with storage solutions that are running a large amount of sequential IO through a common channel. A common example of this type of load is the ongoing background database maintenance (BDM) which runs continuously on Exchange mailbox databases. While this BDM workload might not be significant for a few databases stored on a JBOD drive, it may become a concern if all of the mailbox database volumes are presented through a common iSCSI or Fibre Channel interface. In that case, the bandwidth of that common channel must be considered to ensure that the solution doesn’t bottleneck due to these IO patterns.

In Exchange 2013, we expect to consume approximately 1MB/sec/database copy for BDM which is a significant reduction from Exchange 2010. This helps to enable the ability to store multiple mailbox databases on the same JBOD drive spindle, and will also help to avoid bottlenecks on networked storage deployments such as iSCSI. This bandwidth utilization is in addition to bandwidth consumed by the transactional IO activity associated with user and system workload processes, as well as storage bandwidth consumed by the log replication and replay process in a DAG.

Transport storage requirements

Since transport components (with the exception of the front-end transport component on the CAS role) are now part of the Mailbox role, we have included CPU and memory requirements for transport with the general Mailbox role requirements described later. Transport also has storage requirements associated with the queue database. These requirements, much like I described earlier for mailbox storage, consist of capacity factors and IO throughput factors.

Transport storage capacity is driven by two needs: queuing (including shadow queuing) and Safety Net (which is the replacement for transport dumpster in this release). You can think of the transport storage capacity requirement as the sum of message content on disk in a worst-case scenario, consisting of three elements:

The current day’s message traffic, along with messages which exist on disk longer than normal expiration settings (like poison queue messages)
Queued messages waiting for delivery
Messages persisted in Safety Net in case they are required for redelivery

Of course, all three of these factors are also impacted by shadow queuing in which a redundant copy of all messages is stored on another server. At this point, it would be a good idea to review the TechNet documentation on Transport High Availability if you aren’t familiar with the mechanics of shadow queuing and Safety Net.

In order to figure out the messages per day that you expect to run through the system, you can look at the user count and messaging profile. Simply multiplying these together will give you a total daily mail volume, but it will be a bit higher than necessary since it is double counting messages that are sent within the organization (i.e. a message sent to a coworker will count towards the profile of the sending user as well as the profile of the receiving user, but it’s really just one message traversing the system). The simplest way to deal with that would be to ignore this fact and oversize transport, which will provide additional capacity for unexpected peaks in message traffic. An alternative way to determine daily message flow would be to evaluate performance counters within your existing messaging system.

To determine the maximum size of the transport database, we can look at the entire system as a unit and then come up with a per-server value.

Overall Daily Messages Traffic = number of users x message profile

Overall Transport DB Size = average message size x overall daily message traffic x (1 + (percentage of messages queued x maximum queue days) + Safety Net hold days) x 2 copies for high availability

Let’s use the 100,000 user sizing example again and size the transport database using the simple method.

Overall Transport DB Size = 75KB x (100,000 users x 200 messages/day) x (1 + (50% x 2 maximum queue days) + 2 Safety Net hold days) x 2 copies = 11,444GB

In our example scenario, we have 8 DAGs, each containing 16-nodes, and we are designing to handle double node failures in each DAG. This means that in a worst-case failure event we would have 112 servers online with 2 failed servers in each DAG. We can use this value to determine a per-server transport DB size:

Sizing for transport IO throughput requirements is actually quite simple. Transport has taken advantage of many of the IO reduction changes to the ESE database that have been made in recent Exchange releases. As a result, the number of IOPS required to support transport is significantly lower. In the internal deployment we used to produce this sizing guidance, we see approximately 1 DB write IO per message and virtually no DB read IO, with an average message size of ~75KB. We expect that as average message size increases, the amount of transport IO required to support delivery and queuing would increase. We do not currently have specific guidance on what that curve looks like, but it is an area of active investigation. In the meantime, our best practices guidance for the transport database is to leave it in the Exchange install path (likely on the OS drive) and ensure that the drive supporting that directory path is using a protected write cache disk controller, set to 100% write cache if the controller allows optimization of read/write cache settings. The write cache allows transport database log IO to become effectively “free” and allows transport to handle a much higher level of throughput.

Processor requirements

Once we have our storage requirements figured out, we can move on to thinking about CPU. CPU sizing for the Mailbox role is done in terms of megacycles. A megacycle is a unit of processing work equal to one million CPU cycles. In very simplistic terms, you could think of a 1 MHz CPU performing a megacycle of work every second. Given the guidance provided below for megacycles required for active and passive users at peak, you can estimate the required processor configuration to meet the demands of an Exchange workload. Following are our recommendations on the estimated required megacycles for the various user profiles.

Messages sent or received per mailbox per day	Mcycles per User, Active DB Copy or Standalone (MBX only)	Mcycles per User, Active DB Copy or Standalone (Multi-Role)	Mcycles per User, Passive DB Copy
50	2.13	2.66	0.69
100	4.25	5.31	1.37
150	6.38	7.97	2.06
200	8.50	10.63	2.74
250	10.63	13.28	3.43
300	12.75	15.94	4.11
350	14.88	18.59	4.80
400	17.00	21.25	5.48
450	19.13	23.91	6.17
500	21.25	26.56	6.85

The second column represents the estimated megacycles required on the Mailbox role server hosting the active copy of a user’s mailbox database. In a DAG configuration, the required megacycles for the user on each server hosting passive copies of that database can be found in the fourth column. If the solution is going to include multi-role (Mailbox+CAS) servers, use the value in the third column rather than the second, as it includes the additional CPU requirements for the CAS role.

It is important to note that while many years ago you could make an assumption that a 500 MHz processor could perform roughly double the work per unit of time as a 250 MHz processor, clock speeds are no longer a reliable indicator of performance. The internal architecture of modern processors is different enough between manufacturers as well as within product lines of a single manufacturer that it requires an additional normalization step to determine the available processing power for a particular CPU. We recommend using the SPECint_rate2006 benchmark from the Standard Performance Evaluation Corporation.

The baseline system used to generate this guidance was a Hewlett-Packard DL380p Gen8 server containing Intel Xeon E5-2650 2 GHz processors. The baseline system SPECint_rate2006 score is 540, or 33.75 per-core, given that the benchmarked server was configured with a total of 16 physical processor cores. Please note that this is a different baseline system than what was used to generate our Exchange 2010 guidance, so any tools or calculators that make assumptions based on the 2010 baseline system would not provide accurate results for sizing an Exchange 2013 solution.

Using the same general methodology we have recommended in prior releases, you can determine the estimated available Exchange workload megacycles available on a different processor through the following process:

Find the SPECint_rate2006 score for the processor that you intend to use for your Exchange solution. You can do this the hard way (described below) or use Scott Alexander’s fantastic Processor Query Toolto get the per-server score and processor core count for your hardware platform.
1. On the website of the Standard Performance Evaluation Corporation, select Results, highlight CPU2006, and select Search all SPECint_rate2006 results.
2. Under Simple Request, enter the search criteria for your target processor, for example Processor Matches E5-2630.
3. Find the server and processor configuration you are interested in using (or if the exact combination is not available, find something as close as possible) and note the value in the Result column and the value in the # Cores column.
Obtain the per-core SPECint_rate2006 score by dividing the value in the Result column by the value in the # Cores column. For example, in the case of the Hewlett-Packard DL380p Gen8 server with Intel Xeon E5-2630 processors (2.30GHz), the Result is 430 and the # Cores is 12, so the per-core value would be 430 / 12 = 35.83.
To determine the estimated available Exchange workload megacycles on the target platform, use the following formula:

Using the example HP platform with E5-2630 processors mentioned previously, we would calculate the following result:

x 12 processors = 25,479 available megacycles per-server

Keep in mind that a good Exchange design should never plan to run servers at 100% of CPU capacity. In general, 80% CPU utilization in a failure scenario is a reasonable target for most customers. Given that caveat that the high CPU utilization occurs during a failure scenario, this means that servers in a highly available Exchange solution will often run with relatively low CPU utilization during normal operation. Additionally, there may be very good reasons to target a lower CPU utilization as maximum, particularly in cases where unanticipated spikes in load may result in acute capacity issues.

Going back to the example I used previously of 100,000 users with the 200 message/day profile, we can estimate the total required megacycles for the deployment. We know that there will be 4 database copies in the deployment, and that will help to calculate the passive megacycles required. We also know that this deployment will be using multi-role (Mailbox+CAS) servers. Given this information, we can calculate megacycle requirements as follows:

100,000 users ((10.63 mcycles per active mailbox) + (3 passive copies x 2.74 mcycles per passive mailbox)) = 1,885,000 total mcycles required

You could then take that number and attempt to come up with a required server count. I would argue that it’s actually a much better practice to come up with a server count based on high availability requirements (taking into account how many component failures your design can handle in order to meet business requirements) and then ensure that those servers can meet CPU requirements in a worst-case failure scenario. You will either meet CPU requirements without any additional changes (if your server count is bound on another aspect of the sizing process), or you will adjust the server count (scale out), or you will adjust the server specification (scale up).

Continuing with our hypothetical example, if we knew that the high availability requirements for the design of the 100,000 user example resulted in a maximum of 16 databases being active at any time out of 48 total database copies per server, and we know that there are 65 users per database, we can determine the per-server CPU requirements for the deployment.

(16 databases x 65 mailboxes x 10.63 mcycles per active mailbox) + (32 databases x 65 mailboxes x 2.74 mcycles per passive mailbox) = 11055.2 + 5699.2 = 16,754.4 mcycles per server

Using the processor configuration mentioned in the megacycle normalization section (E5-2630 2.3 GHz processors on an HP DL380p Gen8), we know that we have 25,479 available mcycles on the server, so we would estimate a peak average CPU in worst-case failure of:

That is below our guidance of 80% maximum CPU utilization (in a worst-case failure scenario), so we would not consider the servers to be CPU bound in the design. In fact, we could consider adjusting the CPU selection to a cheaper option with reduced performance getting us closer to a peak average CPU in worst-case failure of 80%, reducing the cost of the overall solution.

Memory requirements

To calculate memory per server, you will need to know the per-server user count (both active and passive users) as well as determine whether you will run the Mailbox role in isolation or deploy multi-role servers (Mailbox+CAS). Keep in mind that regardless of whether you deploy roles in isolation or deploy multi-role servers, the minimum amount of RAM on any Exchange 2013 server is 8GB.

Memory on the Mailbox role is used for many purposes. As in prior releases, a significant amount of memory is used for ESE database cache and plays a large part in the reduction of disk IO in Exchange 2013. The new content indexing technology in Exchange 2013 also uses a large amount of memory. The remaining large consumers of memory are the various Exchange services that provide either transactional services to end-users or handle background processing of data. While each of these individual services may not use a significant amount of memory, the combined footprint of all Exchange services can be quite large.

Following is our recommended amount of memory for the Mailbox role on a per mailbox basis that we expect to be used at peak.

Messages sent or received per mailbox per day	Mailbox role memory per active mailbox (MB)
50	12
100	24
150	36
200	48
250	60
300	72
350	84
400	96
450	108
500	120

To determine the amount of memory that should be provisioned on a server, take the number of active mailboxes per-server in a worst-case failure and multiply by the value associated with the expected user profile. From there, round up to a value that makes sense from a purchasing perspective (i.e. it may be cheaper to configure 128GB of RAM compared to a smaller amount of RAM depending on slot options and memory module costs).

Mailbox Memory per-server = (worst-case active database copies per-server x users per-database x memory per-active mailbox)

For example, on a server with 48 database copies (16 active in worst-case failure), 65 users per-database, expecting the 200 profile, we would recommend:

16 x 65 x 48MB = 48.75GB, round up to 64GB

It’s important to note that the content indexing technology included with Exchange 2013 uses a relatively large amount of memory to allow both indexing and query processing to occur very quickly. This memory usage scales with the number of items indexed, meaning that as the number of total items stored on a Mailbox role server increases (for both active and passive copies), memory requirements for the content indexing processes will increase as well. In general, the guidance on memory sizing presented here assumes approximately 15% of the memory on the system will be available for the content indexing processes which means that with a 75KB average message size, we can accommodate mailbox sizes of 3GB at 50 message profile up to 32GB at the 500 message profile without adjusting the memory sizing. If your deployment will have an extremely small average message size or an extremely large average mailbox size, you may need to add additional memory to accommodate the content indexing processes.

Multi-role server deployments will have an additional memory requirement beyond the amounts specified above. CAS memory is computed as a base memory requirement for the CAS components (2GB) plus additional memory that scales based on the expected workload. This overall CAS memory requirement on a multi-role server can be computed using the following formula:

Essentially this is 2GB of memory for the base requirement, plus 2GB of memory for each processor core (or fractional processor core) serving active load at peak in a worst-case failure scenario. Reusing the example scenario, if I have 16 active databases per-server in a worst-case failure and my processor is providing 2123 mcycles per-core, I would need:

If we add that to the memory requirement for the Mailbox role calculated above, our total memory requirement for the multi-role server would be:

48.75GB for Mailbox + 4.08GB for CAS = 52.83GB, round up to 64GB

Regardless of whether you are considering a multi-role or a split-role deployment, it is important to ensure that each server has a minimum amount of memory for efficient use of the database cache. There are some scenarios that will produce a relatively small memory requirement from the memory calculations described above. We recommend comparing the per-server memory requirement you have calculated with the following table to ensure you meet the minimum database cache requirements. The guidance is based on total database copies per-server (both active and passive). If the value shown in this table is higher than your calculated per-server memory requirement, adjust your per-server memory requirement to meet the minimum listed in the table.

Per-Server DB Copies	Minimum Physical Memory (GB)
1-10	8
11-20	10
21-30	12
31-40	14
41-50	16

In our example scenario, we are deploying 48 database copies per-server, so the minimum physical memory to provide necessary database cache would be 16GB. Since our computed memory requirement based on per-user guidance including memory for the CAS role (52.83GB) was higher than the minimum of 16GB, we don’t need to make any further adjustments to accommodate database cache needs.

Unified messaging

With the new architecture of Exchange, Unified Messaging is now installed and ready to be used on every Mailbox and CAS. The CPU and memory guidance provided here assumes some moderate UM utilization. In a deployment with significant UM utilization with very high call concurrency, additional sizing may need to be performed to provide the best possible user experience. As in Exchange 2010, we recommend using a 100 concurrent call per-server limit as the maximum possible UM concurrency, and scale out the deployment if the sizing of your deployment becomes bound on this limit. Additionally, voicemail transcription is a very CPU-intensive operation, and by design will only transcribe messages when there is enough available CPU on the machine. Each voicemail message requires 1 CPU core for the duration of the transcription operation, and if that amount of CPU cannot be obtained, transcription will be skipped. In deployments that anticipate a high amount of voicemail transcription concurrency, server configurations may need to be adjusted to increase CPU resources, or the number of users per server may need to be scaled back to allow for more available CPU for voicemail transcription operations.

Sizing and scaling the Client Access Server role

In the case where you are going to place the Mailbox and CAS roles on separate servers, the process of sizing CAS is relatively straightforward. CAS sizing is primarily focused on CPU and memory requirements. There is some disk IO for logging purposes, but it is not significant enough to warrant specific sizing guidance.

CAS CPU is sized as a ratio from Mailbox role CPU. Specifically, we need to get 25% of the megacycles used to support active users on the Mailbox role. You could think of this as a 1:4 ratio (CAS CPU to Mailbox CPU) compared to the 3:4 ratio we recommended in Exchange 2010. One way to compute this would be to look at the total active user megacycles required for the solution, take 25% of that, and then determine the required CAS server count based on high availability requirements and multi-site design constraints. For example, consider the 100,000 user example using the 200 message/day profile:

Total CAS Required Mcycles = 100,000 users x 8.5 mcycles x 0.25 = 212,500 mcycles

Assuming that we want to target a maximum CPU utilization of 80% and the servers we plan to deploy have 25,479 available megacycles, we can compute the required number of servers quite easily:

Obviously we would need to then consider whether the 11 required servers meet our high availability requirements considering the maximum CAS server failures that we must design for given business requirements, as well as the site configuration where some of the CAS servers may be in different sites handling different portions of the workload. Since we specified in our example scenario that we want to survive a double failure in the single site, we would increase our 11 CAS servers to 13 such that we could sustain 2 CAS server failures and still handle the workload.

To size memory, we will use the same formula that was used for Exchange 2010:

Per-Server CAS Memory = 2GB + 2GB per physical processor core

Using the example scenario we have been using, we can calculate the per-server CAS memory requirement as:

In this example, 20.20GB would be the guidance for required CAS memory, but obviously you would need to round-up to the next highest possible (or highest performing) memory configuration for the server platform: perhaps 24GB.

Active Directory capacity for Exchange 2013

Active Directory sizing remains the same as it was for Exchange 2010. As we gain more experience with production deployments we may adjust this in the future. For Exchange 2013, we recommend deploying a ratio of 1 Active Directory global catalog processor core for every 8 Mailbox role processor cores handling active load, assuming 64-bit global catalog servers:

If we revisit our example scenario, we can easily calculate the required number of GC cores required.

Assuming that my Active Directory GCs are also deployed on the same server hardware configuration as my CAS & Mailbox role servers in the example scenario with 12 processor cores, then my GC server count would be:

In order to sustain double failures, we would need to add 2 more GCs to this calculation, which would take us to 7 GC servers for the deployment.

As a best practice, we recommend sizing memory on the global catalog servers such that the entire NTDS.DIT database file can be contained in RAM. This will provide optimal query performance and a much better end-user experience for Exchange workloads.

Hyperthreading: Wow, free processors!

Turn it off. While modern implementations of simultaneous multithreading (SMT), also known as hyperthreading, can absolutely improve CPU throughput for most applications, the benefits to Exchange 2013 do not outweigh the negative impacts. It turns out that there can be a significant impact to memory utilization on Exchange servers when hyperthreading is enabled due to the way the .NET server garbage collector allocates heaps. The server garbage collector looks at the total number of logical processors when an application starts up and allocates a heap per logical processor. This means that the memory usage at startup for one of our services using the server garbage collector will be close to double with hyperthreading turned on vs. when it is turned off. This significant increase in memory, along with an analysis of the actual CPU throughput increase for Exchange 2013 workloads in internal lab tests has led us to a best practice recommendation that hyperthreading should be disabled for all Exchange 2013 servers. The benefits don’t outweigh the negative impact.

You are going to give me a calculator, right?

Now that you have digested all of this guidance, you are probably thinking about how much more of a pain it will be to size a deployment compared to using the Mailbox Role Requirements Calculator for Exchange 2010. You would be right, and we fully understand that. In fact, we are hard at work on a new calculator for Exchange 2013 and we plan to deliver it later this quarter. Stay tuned to the Exchange team blog for an announcement.

Hopefully that leaves you with enough information to begin to properly size your Exchange 2013 deployments. If you have further questions, you can obviously post comments here, but I’d also encourage you to consider attending one of the upcoming TechEd events. I’ll be at TechEd North America as well as TechEd Europe with a session specifically on this topic, and would be happy to answer your questions in person, either in the session or at the “Ask the Experts” event. Recordings of those sessions will also be posted to MSDN Channel9 after the events have concluded.

Jeff Mealiffe
Senior Program Manager Lead
Exchange Customer Experience

Introducing Message Analyzer, an SMTP header analysis tool in Microsoft Remote Connectivity Analyzer

The Exchange Team — Wed, 01 May 2013 21:40:00 GMT

Microsoft Remote Connectivity Analyzer is a web-based tool that provides administrators and end users with the ability to run connectivity diagnostics for our servers to test common issues with Microsoft Exchange, Lync and Office 365. The tool started as Microsoft Exchange Server Remote Connectivity Analyzer, and based on your feedback we've continued to add functionality to test connectivity with Lync and Office 365, and made other enhancements such as tests for Outlook Anywhere, Exchange Web Services, outbound SMTP, Office 365 Single Sign-On test, support for 10 additional languages and an improved captcha experience.

We're excited to announce Message Analyzer, a brand new addition to the Remote Connectivity Analyzer. Message Analyzer makes reading email headers less painful.

Figure 1: The new Message Analyzer tab in RCA

SMTP message headers contain a wealth of information which allows you to determine the origins of a message and how it made its way through one or more SMTP servers to its destination. To use Message Analyzer, all you need to do is copy message headers from a message and paste them in the Message Analyzer tab on the RCA web site.

Figure 2: Paste message headers in the Message Analyzer

Trying to locate message headers in Outlook 2010 and later? See Hey Outlook 2010, where are my message headers?

Features of the Message Analyzer

Here's a quick look at what you can do with Message Analyzer.

View the most important properties and total delivery time at a quick glance.

Figure 3: View the most important header properties and delivery time
Analyze the received headers and displays the longest delays quickly for easy discovery of sources of message transfer delays.

Figure 4: Quickly detect where the longest message transfer delays occurred
Sort all headers by header name or value.

Figure 5: Sort message headers
Quickly collapse the sections that you don’t need.
All processing is done in your browser, and no private information is shared with Microsoft.
Useful for any header, whether generated by Exchange, Office 365, or any other RFC standard SMTP server or agent.

Note, we consider this feature to be in beta for the moment. Please send us feedback and we’ll continue to make improvements.

Check out this update to the RCA at testconnectivity.microsoft.com (short URL: aka.ms/rca).

Stephen Griffin & Scott Landry
On behalf of the entire MCA/RCA team
Follow the team on Twitter - @ExRCA

Updated: Exchange Server 2013 Deployment Assistant

The Exchange Team — Mon, 22 Apr 2013 20:50:00 GMT

We’re happy to announce updates to the Exchange Server 2013 Deployment Assistant!

We’ve updated the Deployment Assistant to include the following new scenarios:

Upgrading from Exchange 2007 to Exchange 2013
Upgrading from Exchange 2010 to Exchange 2013
Configuring an Exchange 2013-based hybrid deployment for Exchange 2007 organizations

These new scenarios provide step-by-step guidance about how to upgrade your existing Exchange 2007 or Exchange 2010 organizations to benefit from the improvements and new features of Exchange 2013. Plus, Exchange 2007 organizations can now configure a hybrid deployment with Office 365 using Exchange 2013 instead of Exchange 2010 SP3 in their on-premises organization.

And, there’s more on the way! We’re also working hard on additional scenarios, such as upgrading from a mixed Exchange Server 2007/2010 organization to Exchange 2013 and configuring Exchange 2013-based hybrid for Exchange 2010 organizations. Keep checking back here for release announcements.

In case you're not familiar with it, the Exchange Server 2013 Deployment Assistant is a web-based tool that helps you deploy Exchange 2013 in your on-premises organization, configure a hybrid deployment between your on-premises organization and Office 365, or migrate to Office 365. The tool asks you a small set of simple questions and then, based on your answers, creates a customized checklist with instructions to deploy or configure Exchange 2013. Instead of trying to find what you need in the Exchange library, the Deployment Assistant gives you exactly the right information you need to complete your task. Supported on most major browsers, the Deployment Assistant is your one-stop shop for deploying Exchange 2013.

Figure 1: The updated Exchange 2013 Deployment Assistant (large screenshot)

And for those organizations that still need to deploy Exchange 2010 or are interested in configuring an Exchange 2010-based hybrid deployment with Office 365, you can continue to access the Exchange Server 2010 Deployment Assistant at http://technet.microsoft.com/exdeploy2010 (short URL: aka.ms/eda2010).

Do you have a deployment success story about the Deployment Assistant? Do you have suggestions on how to improve the tool? We would love your feedback and comments! Feel free to leave a comment here, or send an email to edafdbk@microsoft.com directly or via the 'Feedback' link located in the header of every page of the Deployment Assistant.

Happy deploying!

The Deployment Assistant Team

Released: Exchange Server 2013 RTM Cumulative Update 1

The Exchange Team — Tue, 02 Apr 2013 16:00:00 GMT

We know a lot of you have been waiting for this, and so it is with great excitement that we announce that Exchange Server 2013 RTM Cumulative Update 1 (CU1) has been released to the web and is available for immediate download! This is the first release using the new servicing model for Exchange Server 2013. In addition to this article, the Exchange 2013 RTM CU1 release notes are also available.

Note: Article links that may not have been available at the time of this post's publishing are now available. Updated Exchange 2013 documentation, including Release Notes, is now available on TechNet.

CU1 is the minimum version of Exchange 2013 required for on-premises coexistence with supported legacy Exchange Server versions. The final build number for CU1 is 15.0.620.29. For more information on coexistence, check out the Planning and Deployment documentation, and this Ignite webcast covering deployment of and coexistence with Exchange Server 2013.

Upgrading/Deploying Cumulative Update 1

Unlike previous versions, cumulative updates do not use the rollup infrastructure; cumulative updates are actually full builds of the product, meaning that when you want to deploy a new server, you simply use the latest cumulative update build available and do not necessarily need to apply additional Exchange Server updates.

Active Directory Preparation

Prior to upgrading or deploying the new build onto a server, you will need to update Active Directory. For those of you with a diverse Active Directory permissions model you will want to perform the following steps:

Exchange 2013 RTM CU1 includes schema changes. Therefore, you will need to execute setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms.
Exchange 2013 RTM CU1 includes enterprise Active Directory changes (e.g., RBAC roles have been updated to support new cmdlets and/or properties). Therefore, you will need to execute setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms.
Exchange 2013 RTM CU1 includes changes to the permissions within the domain partition (e.g., Exchange Servers have been granted the ability to modify msExchActiveSyncDevices class on inetOrgPerson objects). Therefore, you will need to execute setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms in each domain containing Exchange servers or mailboxes.

Note: If your environment contains only Exchange 2007, and you upgrade to Exchange 2013, keep in mind you cannot deploy Exchange 2010 in that environment at a later time. If you foresee a need to deploy Exchange 2010 servers into your environment, deploy an Exchange 2010 multi-role server (with all four servers roles) prior to executing Exchange 2013 setup.exe /PrepareAD. As long as you retain at least one role of each legacy server, you will continue to be able to install additional servers of that version into your coexistence environment. Once you remove the last server role of a legacy version, you will no longer be able to reintroduce that version into the environment.

Coexistence Pre-Deployment Step: OAB Verification

As mentioned in the Exchange Server 2013 CU1 release notes, when you deploy the first Exchange 2013 Mailbox server in an existing Exchange organization, a new default Offline Address Book is created.

Figure 1: The new OAB as shown in an Exchange Server 2010 SP3 & 2013 CU1 environment

All existing clients that rely on an OAB will see this new default OAB the next time they look for an OAB update. This will cause these clients to perform a full OAB download. To prevent this from happening, you can configure your existing mailbox databases to explicitly point to the current default OAB prior to introducing the first Exchange 2013 server. You can do this one of two ways:

Within the Exchange Management Console (EMC), navigate to Organization Configuration –> Mailbox –> Database Management –> Mailbox Database Properties –> Client Settings.

Figure 2: Modifying the default Offline Address Book at the database level in the EMC
Alternatively, if you have many mailbox databases to update, the following Exchange Management Shell command can be used to view all mailbox databases without a default OAB explicitly set on them. If you have both Exchange 2007 and Exchange 2010 deployed on-premises then you will have to run the following commands using the respective Exchange Management Shell version as the Get/Set-MailboxDatabase commands are version specific.
Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $Null} | FT Name,OfflineAddressBook -AutoSize

If no values are returned then you are already prepared. However, if you need to configure some databases, then this next command will find all mailbox databases in an Exchange 2007 or Exchange 2010 environment with no default OAB defined at the database level, and it will set it to the current default OAB in the org.

Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $Null} | Set-MailboxDatabase -OfflineAddressBook (Get-OfflineAddressBook | Where {$_.IsDefault -eq $True})

To confirm all Exchange 2007/2010 mailbox databases now have a defined default OAB, re-run the first command. This time it should return no entries.

Server Deployment

Once the preparatory steps are completed, you can then deploy CU1 and start your coexistence journey. If this is your first Exchange 2013 server deployment, you will need to deploy both an Exchange 2013 Client Access Server and an Exchange 2013 Mailbox Server into the organization. As explained in Exchange 2013 Client Access Server Role, CAS 2013 is simply an authentication and proxy/redirection server; all data processing (including the execution of remote PowerShell cmdlets) occurs on the Mailbox server. You can either deploy a multi-role server or each role separately (just remember if you deploy them separately, you cannot manage the Exchange 2013 environment until you install both roles).

If you already deployed Exchange 2013 RTM code and want to upgrade to CU1, you will run setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms from a command line after completing the Active Directory preparatory steps or run through the GUI installer. Deploying future cumulative updates will operate in the same manner.

Note: Unlike previous versions, in Exchange 2013, you cannot uninstall a single role from a multi-role server. For example, if you deploy the CAS and MBX roles on a single machine, you cannot later execute setup to remove the CAS role; you can only uninstall all server roles.

Mailbox Sizes in Exchange Server 2013

As you start migrating your mailboxes to Exchange 2013, one thing you may notice is that your mailboxes appear to be larger post move.

As you can imagine, with hosting millions of mailboxes in Office 365, accurate storage reporting is essential, just like in your on-premises deployments. One of the learnings that we accrued into the on-premises product is ensuring that the mailbox usage statistics are more closely aligned with the capacity usage within the Mailbox database. The impact of reporting space more accurately means that mailbox quota limits may need to be adjusted prior to the mailbox move so that users are not locked out of their mailbox during the migration process.

Our improved space calculations may result in a mailbox’s reported size increasing on average of 30% when the mailbox is moved from a legacy version of Exchange to Exchange 2013. For example, if a mailbox is reported as 10GB in size on Exchange Server 2010, then when the mailbox is moved to Exchange 2013, it may be reported as 13GB. This does not mean that migrating to Exchange 2013 will increase your capacity footprint by 30% per mailbox; it only means that the statistics are including more data about the space the mailbox consumes. 30% is an average value, based on what we have experienced in Exchange Online. Customers with pilot mailboxes should determine what their own average increase value may be as some environments may see higher or lower values depending on the most prevalent type of email within their mailboxes. Again, this does not mean there will be an increase in the size of the database file on disk; only the attribution of space to each mailbox will increase.

New Functionality Included in Cumulative Update 1

Exchange 2013 RTM CU1 includes a number of bug fixes and enhancements over the RTM release of Exchange 2013. Some of the more notable enhancements are identified below.

Address Book Policies

As discussed recently, an Address Book Policy Routing Agent has been included in Exchange 2013 RTM CU1. For all the juicy details, see Address Book Policies, Jamba Jokes and Secret Agents.

Groups can once again manage groups!

In Exchange 2010 you could not use a group as an owner for another group for membership management. Instead you had to deploy explicit permissions on groups or use a script as a workaround.

Since Exchange 2010’s release both Microsoft Support and the Exchange Product Group received resounding feedback on the need for this capability. The good news is that with Exchange 2013 RTM CU1 groups can once again be owners of groups for membership management.

Public Folder Favorites Access through Outlook Web App

In Exchange Server 2013 RTM there was no way to access Public Folder content through Outlook Web App. In CU1 you will now have access to Public Folders you have added as favorites via your favorites menu either in Outlook or Outlook Web App. However, this access is limited to Public Folders stored on Exchange Server 2013.

Figure 3: Adding a Public Folder as a favorite in Outlook Web App in Exchange Server 2013 RTM CU1

Remember, you cannot start creating Public Folders on Exchange Server 2013 until all users have been migrated to Exchange Server 2013. For how to migrate from legacy Public Folders to Exchange Server 2013 Public Folders, see Migrate Public Folders to Exchange 2013 From Previous Versions.

Exchange Admin Center Enhancements

The Exchange Admin Center (EAC) has been enhanced and now includes Unified Messaging management, improvements in the migration UI allowing more migration options reducing the gap between PowerShell and the UI, and general overall improvements in the user experience for consistency and simplification based on customer feedback.

High Availability and Monitoring Enhancements

There are have been several enhancements in the high availability and Managed Availability space. In particular:

The Best Copy Selection algorithm now honors MaximumActiveDatabases.
Auto-reseed now supports disks that have Bitlocker encryption.
Many probes, monitors, and responders have been updated and improved over the RTM release.
Get-HealthReport cmdlet has been streamlined and its performance has been optimized.
Exchange 2013 RTM CU1 will support the Exchange Server 2013 Management Pack for System Center Operations Manager (SCOM); this management pack will be available at a later date. This management pack is supported on SCOM 2007 R2 and SCOM 2012.

On behalf of the Exchange Product Group, thanks again for your continued support and patience, and please keep the feedback coming.

Exchange Team

Updates

4/2/2013: Added info about Exchange 2013 documentation updates for CU1, including Release Notes.
Also check out High Availability Changes in Exchange Server 2013 Cumulative Update 1 on Scott Schnoll's blog.
4/3/2013: Updated info about Exchange 2013 documentation (updated for CU1).