IT tutorials
Applications Server

Microsoft Exchange Server 2013 : Designing a Successful Exchange Storage Solution (part 1) - Requirements Gathering

12/27/2014 3:42:36 AM
- Windows 10 Product Activation Keys Free 2019 (All Versions)
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

The fundamental design process for an Exchange storage solution normally follows these steps:

  1. 1. Define requirements (functional specification).
  2. 2. Perform user profile analysis.
  3. 3. Complete the Exchange 2013 Server Role Requirements Calculator.
  4. 4. Select appropriate storage hardware.
  5. 5. Validate with Jetstress.
  6. 6. Document proposed solution.

In the early days of Exchange design, it was rare to see anything other than step 4 and perhaps step 6 practiced, largely because the Exchange 2013 Server Role Requirements Calculator didn't exist and we didn't have a way to validate the solution. As Exchange has matured, so too has the design process. More recently, it is expected that a storage solution is designed to meet requirements and to avoid overdeploying and operating unnecessary storage hardware.

Over-deploying storage was a common practice with Exchange Server 2003 as design teams tried to make up for performance and architectural limitations within the product. Generally, this proved unsuccessful since Exchange 2003 was limited by its underlying 32-bit architecture and the resulting memory fragmentation that it caused. However, it didn't stop IT departments trying to make it go faster by using very expensive, high-performance storage.

Good quality user-profile analysis is vital to the design process. Attempting to perform Exchange storage design without having good quality user-profile data and clearly defined requirements is just costly guesswork.

Requirements Gathering

Service Level The service-level agreement (SLA) is a contract between two parties that sets out things like how a specific service will be operated, who is responsible for its maintenance, what level of performance it will provide, and what level of availability it will achieve.

From an Exchange storage design perspective, we are mainly interested in the service level because it drives our high-availability decisions. If the SLA dictates a high-availability solution, then it opens up some design choices for storage that we may not have had otherwise, such as JBOD. JBOD requires a high-availability deployment, since we must have multiple copies of each database to be able to recover in a timely fashion once a disk spindle fails. We may also consider running an Exchange native data protection (backupless) solution. Exchange native data protection makes use of native Exchange features, such as multiple database copies within a DAG and lagged copies, to provide resistance against corruption and component failure without needing to take point-in-time backups.

If the service level does not require a high-availability solution, and Exchange will be deployed without a DAG, then our storage is likely to be based on a RAID solution that can tolerate disk spindle failure. In addition, we will probably also need to consider a backup solution, since backupless solutions require multiple database copies.

The important thing to note here is that simply deploying a massive DAG with JBOD storage is not always the right thing to do. Consider the system requirements carefully, and be sure that you understand the impact of your storage design choices on the rest of the Exchange infrastructure.

User Profile Analysis User profile analysis is an area of developing design requirements that is too often rushed and completed poorly. Frequently, this leads to problems later on in the deployment phase. Fundamentally, user profile analysis is the way to quantify the system workload required for each mailbox user. Without good user profile data, you cannot complete any of the Exchange planning calculators effectively. The common phrase “Garbage in, Garbage out” fits well here. If you guess at the user profile values in the Exchange 2013 Server Role Requirements Calculator, then you might as well guess the predictions too.

Given that we now understand that user profile data is vital to a quality storage design, what exactly do we need and how can we get it? Following are the most commonly requested core user profile metrics for designing Exchange storage:

Average Message Size in KB This is the average size of items in the user's mailbox. It is used to predict storage capacity growth, transaction log file generation, dumpster size, DAG replication bandwidth, and so forth.

Messages Sent per Mailbox per Day This is an average value of the number of messages sent by an average user on a daily basis. This value is used to predict workload; that is, how much are end users actually doing within the Exchange service?

Messages Received per Mailbox per Day This is basically the same as the previous item, except it is for messages received. Typically, users will receive many more messages than they send.

Average Mailbox Size Normally, this is the anticipated average quota size of the deployment. It is used to determine storage capacity requirements.

Third-Party Devices The most common example of a third-party device that has an impact on Exchange storage is BlackBerry. These devices can have a significant impact on your Exchange database I/O, and so it is vital that you speak to your device vendor to understand the extent of this overhead. Make sure that you check this for each and every deployment because it changes from version to version. We often see designs based on the old 3.64 multiplier value for BlackBerry Enterprise Server (BES) that was specific to Exchange 2003. Exchange 2010 reduced this multiplier to 2; that is the same as another Outlook client. Exchange 2013 is anticipated to require roughly the same IOPS multiplier as Exchange 2010. However, at the time of this writing, there is no specific BES sizing data available for Exchange Server 2013.

It is also vital that you understand what percentage of your users will have BlackBerry devices and the percentage of expected growth. In many cases, the root cause of reduced performance is directly related to an increase in BlackBerry use, which can easily increase I/O requirements beyond original design targets.

Interestingly, you do not need to scale for most ActiveSync devices, such as Apple iOS and Windows Phone, since this IO workload is included in the Exchange 2013 Server Role Requirements Calculator prediction base formula.

When discussing Exchange storage design, we are often asked how to obtain user profile values. For Exchange Server 2003 and Exchange Server 2007, the Exchange Server Profile Analyzer (EPA) will provide most of this information. However, this tool requires WebDAV, which was dropped in Exchange Server 2010 and so it will not work in later versions. Fear not; there is an alternative that is addressed in this article:


This article explains how to use a script to parse message-tracking log data in Exchange Server 2010 and Exchange Server 2013 to derive the important user profile metrics. Nevertheless, for Exchange Server 2003 or Exchange Server 2007, we still prefer the data from the Exchange Server Profile Analyzer rather than the message-tracking log analysis script since experience shows that EPA provides more accurate user profile values.

The bottom line for user profile metrics is to understand exactly what the metric is and then figure out a way to obtain that information in the best and most practical way possible. This is particularly applicable when migrating from foreign messaging systems, such as Lotus Domino. There is no easy way to obtain user profile data from Domino, but it is possible to calculate most items by estimation. For example, you could use the following formula:


Where user profile data is concerned, anything is better than making a random guess; that is, never guess your user profile information without some evidence to back it up. Always base user profile information on observed data, and record the process you used to derive it in your design documentation. This is especially important when you wish to engage in a design review cycle with a third-party consulting organization, because any good consultant will want to understand where the numbers came from that you put into the calculator. If the original source of data for those numbers is not recorded, it becomes impossible to provide any form of performance validation for your design.

- Microsoft Exchange Server 2013 : Designing a Successful Exchange Storage Solution - Storage Improvements in Exchange Server 2013
- Microsoft Exchange Server 2013 : Designing a Successful Exchange Storage Solution - Storage Changes in Exchange 2013
- Microsoft Exchange Server 2013 : Designing a Successful Exchange Storage Solution - A Brief History of Exchange Storage
- Microsoft Sharepoint 2013 : Federated Authentication (part 4) - Active Directory Federated Services - Configuring a Relying Party in ADFS
- Microsoft Sharepoint 2013 : Federated Authentication (part 3) - Active Directory Federated Services - Installing ADFS
- Microsoft Sharepoint 2013 : Federated Authentication (part 2) - Active Directory Federated Services - Preparing for ADFS Installation
- Microsoft Sharepoint 2013 : Federated Authentication (part 1) - Active Directory Federated Services - Install Certificate Authority
- Microsoft Sharepoint 2013 Authentication (part 3) - Configuring a Claims Web Application - Configuring SSL for SharePoint
- Microsoft Sharepoint 2013 Authentication (part 2) - Configuring a Claims Web Application - Creating a New CBA Application, Configuring an Existing CBA Web Application
- Microsoft Sharepoint 2013 Authentication (part 1) - Legacy Approach—Classic Mode Authentication
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
Popular tags
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS