Exchange deployment thoughts and tips
I want to share with you my personal exchange deployment thoughts and tips when it comes to planning your Exchange deployment. This is my personal tips, and it is not related to any Microsoft recommendations.
Moreover, these Exchange deployment thoughts may or may not apply to your environment. Nevertheless, it might help you learn about different perspective that might become handy.
Know your Mailbox Types
The first tip from my Exchange deployment thoughts is to understand your recipients. When reading about Exchange capacity planning white papers, you will find different approaches to plan Exchange databases layout and hardware requirements for Exchange servers 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 database layout and distribution. Here is a short list of what I see usually:
- Employee Mailboxes : Those can be also divided even more to managers [key people] and non-managers mailboxes [usually managers will have different quotas or SLA].
- Shard Mailboxes: Those are a special mailboxes where multiple people have access to the same mailbox].
- Room or Equipment Mailboxes: those are resource mailboxes.
- Admin Mailboxes: Like Search Mailboxes.
- Non-Employee Mailboxes: In case you have mailboxes provisioned to 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 desk system that requires a mailbox to receive request.
- Archive Mailboxes.
Analyze Mailbox Types
Now that you are aware of the number of mailboxes per mailbox type, you can go further and for each type, write down the mailbox quota requirement for each type, the SLA for each type, and what conditions or restriction each type might have.
For example, service mailboxes and resource mailboxes might have low size quota, while employee mailboxes might have larger one. You have also to think that in case of a disaster, which type of mailboxes you will recover first. If you have 3000 employee mailboxes, and 2000 other type mailboxes, then it might make sense to put all your effort initially to recover those 3000 mailboxes. This is how you can define different SLAs per mailbox type. You might say that employee mailboxes can be recovered in case of major disaster within 24 hours, while other mailbox types will be recovered in 3 days.
You might also order your mailbox types with SLA in mind. So, employee mailboxes will be recovered first, then non employee mailboxes, then service mailboxes, and so on and so forth. I sometimes see the people determine the number of mailbox database copies in mind. For exmaple, since archive mailboxes are usually huge in size, and has lower SLA, people might consider having two mailbox database copies for each database holding only archive mailboxes, while databases hosting employee mailboxes will have three database copies.
All these considerations require that you do not mix mailbox types inside the same database. This might become handy in terms of assigning quota sizes per database, and when choosing which databases to recover first in case of a disaster.
Let’s say that we have 3000 mailboxes that can be divided to the following mailbox types:
- Employee Mailboxes (80%): All employees have 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 100 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. If a single database will host 400 mailbox, then we need 6 databases. Since we need good resiliency for employee databases, we will go with three database 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 mailbox type. Things are easy now, since you know that all 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 two database copies.
Non employees are treated the same as service and shared mailbox types, so we will have two databases “NE-01” with two database copies each. “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.
Separate MBX for Recovery
Next tip from my Exchange deployment thoughts is to consider where to restore databases. So you have deployed Exchange in your environment, and everything is working fine. Now you want to perform a regular database recovery operation as part of a yearly routine, or may be you want to do actual recovery for a database to restore a mailbox.
The first you think of is the need to create recovery database somewhere and you start looking for a candidate server with enough storage to host the recovery database. When you find one, you will start the restoration, and after you are done, you need to some cleanup to delete all temp files and folders.
My recommendation is to have a separate Exchange server with mailbox role that is not member of any DAG. This server will be used only for hosting the recovery database and for restoration purposes. You need to have a large LUN or disk on this server to handle database restoration. Doing that means your production mailbox servers will not be involved or affected by any restore operations.
Dedicated scripting server
Next tip from my Exchange deployment thoughts is related to PowerShell scripts. As an Exchange administrator, you will find your self writing a lot of PowerShell scripts. Some of those scripts will notify you if certain things happen, or will generate a nicely formatted report on a weekly basis.
My recommendation is to deploy a separate server with Exchange management shell on it, and use that server to run all your scripts. There are a lot of advantages on doing that. Firs of all, when I want to perform any administration tasks on Exchange, I will do it from that server. I do not need to log on to any production server. Also, some of those scripts will collect extensive information and will require a lot of processing power and memory. I do not recommend running those scripts on a production Exchange server.