See also :
What I am about to include in my blog post is not taken from Microsoft blog posts or any other source, but it is my own personal point of view.
When designing your Exchange environment, you most likely visit TechNet, read white papers, watch couple of online webcast or may be attend a training.
What you will get though is mostly how the product is working and how to do the deployment, operation and also disaster recovery.
In these two part blog series, I want to highlight my own important points when considering your Exchange Architecture.
Know your Mailbox Types
When reading about Exchange capacity planning white papers, you will find different approaches to plan the Exchange databases layout and hardware requirements for Exchange server participating in your DAG.
There is no correct and wrong answer here. Every deployment has its own conditions and requirements.
Suppose you have 5000 mailboxes, most of the mailboxes are user primary mailboxes that belongs to your employees. I always like to start querying mailbox types in my environment to get a quick overview about how should I plan my Exchange MBX and DB distribution. Here is a short list of what I see usually:
- Employee Mailboxes : This can be also divided to Managers and non-Managers mailboxes [Usually Managers will have different quotas, etc]
- Shard Mailboxes : This is a special Exchange type of mailboxes where multiple people will have access to the same mailbox and each one can see transactions occurring on it for better collaboration]
- Room / Equipment Mailboxes : those are resource mailboxes.
- Admin Mailboxes: Like Search Mailboxes.
- Non-Employee Mailboxes : In case you have mailboxes provisioned for partners and contractors.
- Service Mailboxes : Mailboxes needed for services and not mapped to humans. This is very important type of mailboxes. Examples are some implementations of Service Desks that requires a mailbox and address, so when you send email to ServiceDesk@contoso.com, the service desk service will pull emails from that mailbox using POP3 for example and present the case on the Service Desk dashboard.
- Archive Mailboxes : The new type of mailboxes used for archiving.
Analyze Mailbox Types
Now that you are aware of the number of mailboxes per mailbox type, and the size requirements and access methods/frequency for each category, it would be great to ask you self : What is the most important mailbox type that I need to recover in case of disaster and that should have high resiliency against failures?
Usually the answer is Employee Mailboxes, then maybe Shared Mailboxes and Service Mailboxes, perhaps Non-Employee Mailboxes comes third or fourth. The last type of mailboxes that you may care about is Archive Mailboxes, because if you recover the user primary mailbox, he can wait couple of days till you give him his archive.
Now that you are aware of this inside analysis of your mailbox types, I guess it is not fair to just distribute those mailboxes across equally treated and designed databases.
Also, mailbox size and accessibility is another factor. Archive Mailboxes for example are big in size and not frequently accessed. It is not fair to mix them with other mailboxes in the same DB. This makes it hard to design DB size, number of mailboxes in each DB, and number of DBs per server.
For example, if you mix all types of mailboxes in the same database, then the sentence “ MBX 1 has 5 databases while MBX2 has 8 databases” does not mean that MBX2 is loaded more than MBX1, since there is no way to tell what type of mailboxes are hosted on each server, as each type has its own characteristics.
Also when your operation teams notify you about performance issues on MBX1, then there is no way to tell directly who will be affected and what type of mailboxes are doing that performance damage.
Design with mailbox type in mind
What I usually do is that I create islands of impact according to mailbox types. I isolate most mailbox types into different databases, maybe different servers, and some case to different DAGs. Let me give you a small example.
Let us say that I have 3000 mailboxes that can be divided to the following types:
- Employee Mailboxes (80%): All employees has 1 GB mailbox quota.
- Non-Employee Mailboxes (5%): contractors and partners with 500 MB quota.
- Service Mailboxes (5%): mailboxes for non-humans, mainly used by services. Quota is 500 MB with prohibit send and receive after that, and retention policy to delete all items older than 3 months.
- Archive Mailboxes (10%): Archives are given to employees only, with quota 10 GB.
So we have 2400 Employees that we need to think about first. For 400 mailbox per database, we need 6 databases. Since we need good resiliency for employee databases, we will go with three copies. Usually three mailbox servers will be enough here (MBX1, MBX2, MBX3). And since those are mailboxes for employees only, I usually like to name the databases with “E” prefix like E-01.
Mailbox Servers MBX1, MBX2 and MBX3 will host only databases with Employee Mailboxes that have 1 GB quota each. Things are easy now, since you know that all those six databases E-01 till E-06 should have the same number of symmetric mailboxes with same quota. Each of those servers will have exactly similar hardware, similar number of databases, similar failure impact, and similar number of mailboxes.
I then tend to think of Service and Shared mailbox types. Since they represent 5% which is 150 mailbox, they can fit into one database with two database copies if you do not want them to have the same level of resiliency as Employee Mailboxes. I usually name those databases with “S” prefix. Saying that, we will create one database called S-01, with another additional copy.
Non Employees are treated the same as Service and Shared mailbox types, so we will have two databases “NE-01” and another copy. “NE” stands for Non-Employee.
Finally Archives. Since they are big in size, and with low recovery measures, usually I will have two copies of archive databases. So mainly the setup will look like this after all: