Exchange 2007 Server – Mailbox Role 
The purpose of this page is to explain what happens on a mailbox server. I will emphasise the new features of Server 2007.
Topics for Exchange 2007 Server Mailbox Role
- Planning your Exchange 2007 Mailbox Server
- Getting to Know the Storage Group Files
- Database.edb
- Log Files
- PowerShell Enable-Mailbox
- Checkpoint Files
- Single Instance Storage (SIS)
- Lost Log Resilience (LLR)
- Exchange Mail Exchange Records
♠
Introduction to the Exchange 2007 Mailbox Role
Mailbox is one of five roles of Exchange 2007 Server. Typically you select this role when you install the server, else you call for the Control Panel, Add or Remove Programs and add the Mailbox Role. In truth this is the most important role and requires more powerful servers than the other Exchange server roles.
To configure this (or any other role), launch the Exchange Management Console. Click on the Server Configuration tab, and then select: Mailbox. (See mailbox screenshot to the right.)
Planning your Exchange 2007 Mailbox Server
- Calculate the total number of mailboxes in your organization. Breakdown by site/location. (1+ 1 Processor per 1,000 mailboxes is a good rule of thumb).
- Guestimate increase in email usage for next 2 years.
- Decide mailbox size limitations. (Suggest 5MB per user?)
- Where are you in the hardware refresh cycle? Will you be using clustering?
- Ask: ‘Is this a good time to change our storage technologies?’ Would storage area network (SAN) or directly attached storage (DAS) be a better solution compared with what you have at the moment?
- How many storage groups will you require? Implications for Standard Edition. (8GB of RAM would be good for 10 storage groups.)
- Review the types of Outlook clients that Exchange 2007 services.
- Any public folders?
- Think about message retention and Journaling requirements.
- Ponder what current requirements will change when you deploy Exchange Server 2007.
- Decide on whether to deploy dedicated server roles for mailboxes and public folder servers. Consider the other Exchange 2007 Server Roles, for instance, will the mailbox server have auxiliary roles such as Unified Messaging? Ratio of servers; 6 Mailbox : 1 Hub Transport. 4 Mailbox : 1 Client Access.
- Review your service level agreements (SLA), update the acceptable availability expectations and recovery times. Should we try CCR (Cluster Continuous Replication)?
Recommendations for up to 1,000 Mailboxes
- 64-bit hardware. Twin (quad) processor. Check the supplier on the Windows Server Catalog (HCL).
- 4 GB RAM.
- 4 Storage groups.
- 5 GB Disk space. RAID 1/0 Data striped across mirrored sets. (Avoid RAID 0/1)
- Standard edition of Exchange 2007 Server SP1 or later.
Guy Recommends: A Free Trial of the Network Performance Monitor (NPM)
v11.5
SolarWinds’ Network Performance Monitor will help you discover what’s happening on your network. This utility will also guide you through troubleshooting; the dashboard will indicate whether the root cause is a broken link, faulty equipment or resource overload.
What I like best is the way NPM suggests solutions to network problems. Its also has the ability to monitor the health of individual VMware virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you try NPM now.
Download a free trial of SolarWinds’ Network Performance Monitor
Getting to Know the Storage Group Files
The killer reason for understanding how the database files work is to create efficient backups which actually work, and also to understand what to do if you have to recover a mailbox store. As with Exchange 2003 it is the Extensible Storage Engine (ESE) that handles the transactions. Here is the path to check the files that I am going to discuss:
C: \Program Files\Microsoft\Exchange Server\Mailbox.
Database.edb
The key point is that each mailbox database is contained within a single file. Consequently, these .edb files can grow to be very large. As Exchange Server 2007 is a modern email system the database can store rich text and attachments, another reason why this file will be so big.
A typical size for a an .edb database would be 40-120 GB, much bigger and you should consider creating another mailstore. Another recommendation is to have each database in its own storage group until you hit the limit of 50 (5 on Standard Edition). The advantages of segregating the databases are: flexibility, performance if you have multiple disks, and for recovery. You can check mailbox statistics via the Exchange Management Console, Server Configuration, Mailbox.
.stm These stream files are no longer used. The MIME stuff is now stored in the .edb files, making them even larger!
Log Files
Log files store transaction information about what went on in the mailstores. The current log file with transactions waiting to be processed is usually E00.log, whereas logs that have already been processed have the format, Enn000000000x.log. The difference is that current logs have no more than three characters whereas processed logs have at least ten characters. The nn represent the log prefix and x is a hexadecimal number.
For better recoverability, these log files have been reduced from 5MB in Exchange 2003 to 1MB in Exchange 2007. Actually these completed log files are precisely 1,024 KB. Good news, the maximum number of log files has been raised two-thousand fold from 1 million to 2 billion. Microsoft increased the limit in response to problems with Exchange 2003 where heavy duty servers ran out of logs after 2 or 3 years.
It’s worth reminding ourselves that multiple database in the same Storage Group, all share the same transaction logs. To give a specific example, 1 Storage Group with 4 Databases equals 1 set of transaction logs. 4 Storage Groups each with 1 Database means 4 sets of transaction logs.
Best Practice for Transaction Logs
Raid 1, also know as disk mirroring, is better than Raid 5 because transaction logs do lots of writing to disk. I would not rush to incur the expense of Raid 1/0 until performance monitoring convinced me that there was a significant disk bottleneck.
One pleasant side-effect of a full backup is that it can safely truncate or delete old logs, because their transactions are contained in the backup.
Avoid circular logging, it’s just not worth the hassle for the saving in disk space; in particular, disaster recovery would be a nightmare if you tick the circular logging checkbox. Talking of saving disk space, compressed drives are counterproductive for Exchange logs. Therefore, it is better to buy a bigger disk, or use SAN instead of dabbling with drive compression.
To take your knowledge one-stage further, research the Exchange Server 2007 log files with eseutil switches, for example, examine headers with eseutil /mh. My point is that one day you may need to use eseutil for a recovery. That would be a pressure situation and previous experience of eseutil would help you make sound decisions.
Guy Recommends: The SolarWinds Exchange Monitor
Here is a free tool to monitor your Exchange Server. Download and install the utility, then inspect your mail queues, monitor the Exchange server’s memory, confirm there is enough disk space and check the CPU utilization.
This is the real deal – there is no catch. SolarWinds provides this fully-functioning freebie, as part of their commitment to supporting the network management community.
Free Download of SolarWinds Exchange Monitor
Checkpoint Files
If you take the time to research how checkpoint files work, then you truly understand, how the Extensible Storage Engine (ESE) that handles mailbox transactions.
E00.chk. I think of Exchange’s checkpoint file as a progress file. In Exchange, the logs are ‘write-ahead’, meaning transactions are saved into log files, then at some time later, the email data is committed to the database. The ESE engine reads the checkpoint file to see how far it has got with writing these transactions into the database .edb store.
Another way of looking at the checkpoint files is as a record of all completed transactions. Yet another way of thinking about checkpoint is to study a restore. If there was no checkpoint file, then a normal Exchange restart would force the ESE to read all the transaction logs from the beginning. Actually, this is precisely what happens once you restore a database from its backup. (Known as a hard recovery.)
There is one .chk file for each storage group. These checkpoint files are never large, each checkpoint file is in the kilobytes range, and does not grow appreciably.
tmp.edb and tmp.log
These temporary files are by design they are created automatically and are used for processing transactions. The ESE deletes the files when the Information Store is stopped. Typical example of temporary files: E00tmp.log and tmp.edb.
Reserved Files
Even thought this is a simple idea to cater for disk full problems, I take my hat off to whoever first thought of creating two special .jrs files at installation, just to prevent data loss when a lazy administrator forgot to check free disk space. When the disk is full Exchange 2007 could not write any more transactions to the logs, what happens when Exchange realizes the disk full problem is it saves the current transaction into E00res00001.jrs and dismounts the storage group. When the administrator frees up some disk space and restarts the Exchange Information Store, ESE reads these reserved files, thus no email is lost.
Single Instance Storage (SIS)
Single Instance Storage (SIS). Claimed we get better performance by removing the idea of storing just one instance of a file that was sent to multiple users. Classic trade off, more disk space better performance. What I had not realized, (because I had not thought the problem through) was that SIS only worked if all the recipients were in the same mailstore. Thus with the modern tendency of more storage groups, the saving was not quite as great as imagined.
Lost Log Resilience (LLR)
The idea behind LLR is to enables you to recover Exchange databases when the most recent transaction log files have been damaged. LLR is a new feature in Exchange Server 2007 which holds the last few log files in memory until the database is shut down. The benefit is to prevent scenarios where part of log file 3 has been written to the database, but part of log file 2 hasn’t. This explains the main reason why the log files have been reduced from 5MB in Exchange 2003 to 1MB in Exchange 2007. Thus if you lose the last log it only costs 1MB of data instead of 5MB.
Default Storage Groups
By default, Exchange Server 2007 creates a ‘First Storage Group’ with one mailbox store. It’s a straightforward task to create more mailbox stores. For reasons of performance and flexibility, favour creating a new mailbox database in its own Storage Group.
If you selected Outlook 2003 clients during install you get a Second Storage Group with a Public Folder database to support the Offline Address Book. Outlook 2003 clients need public folder to access their OAB.
Double-check permissions to ensure that your mailstore is usable but secure.
RAID Disk Configuration for Exchange 2007 Mailbox Servers
| Speed | Disk Failure | I/O | |
| RAID 1 | Good | Poor | Best |
| RAID 1/0 | Best | Poor | Best |
| RAID 5 | Good | Best | Poor |
Guy Recommends: SolarWinds’ Free Bulk Mailbox Import Tool
Import users from a spreadsheet, complete with their mailbox. Just provide a list of the users with the fields in the top row, and save as .csv file. Then launch this FREE utility, match your Exchange fields with AD’s attributes, click and import the users. Optionally, you can provide the name of the OU where the new mailboxes will be born.
There are also two bonus tools in the free download, and all 3 have been approved by Microsoft:
- Bulk-import new users and mailboxes into Active Directory.
- Seek and zap unwanted user accounts.
- Find inactive computers.
Download your FREE bulk mailbox import tool.
Two Exchange 2007 Editions – Standard and Enterprise
Exchange Server 2007 is available in two editions, Standard and Enterprise. The Enterprise Edition supports 50 storage groups (50 databases), whereas the Standard Edition supports only 5 storage groups (5 databases). However, in a departure from previous version, Exchange 2007 has no software limit on the database storage, each storage group database can be as big as you like. In Exchange 2003 Standard edition, the limit was 16Gb or 75Gb.
Other advantages of the Enterprise Edition of Exchange Server 2007 are:
Support for: Cluster Continuous Replication, Single Copy Clusters.
Both Enterprise and Standard editions support:
Local Continuous Replication and Standby Continuous Replication
Summary of Exchange 2007 Server’s Mailbox Role
This page emphasises the improvements from Exchange 2003 to Exchange 2007 for a mailbox server. I have also explained the roles of the various files to help you understand their significance for a backup or restore. Also included is a planning check list for this most important Exchange 2007 server role.
If you like this page then please share it with your friends
See more Microsoft Exchange Server 2007 topics:
• Exchange 2007 Home • Compatibility • Recipients • Eseutil • Edge • Free Syslog Analyser
• Install • Server Roles • CAS Role • Hub Transport • SMTP Connector • NDRs • Exchange CCR
• Solarwinds Exchange Monitor • Mailbox Role • Create Mailbox• OWA • GAL • Mailbox Stores
