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.)
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)
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.
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:
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 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.
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.
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). 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.
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.
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
Here is a
free tool to monitor your Exchange Server.
Download the utility, then inspect your mail queues, monitor Exchange server's
memory, confirm there is enough disk space and check the CPU utilization.
