162 Chapter 4 • Managing the Exchange 2007 Mailbox Server Role
Moving a Storage Group
At times you might need to move a given storage group from one location to another. To do so you
need to perform the following steps:
1. In the Exchange Management Console, click the Server Confi guration work center node,
then select the Mailbox Server subnode.
2. Now click the storage group you want to move and select Move Storage Group in the
Action pane. Alternatively, you can right-click the respective storage group and select
Move Storage Group from the context menu.
3. In the Move Storage Files Wizard, click the Browse button and specify the new
location for the log and system fi les, then click Move (see Figure 4.5).
Figure 4.5 Moving a Storage Group
Managing the Exchange 2007 Mailbox Server Role • Chapter 4 163
Removing a Storage Group
Removing a storage group is perhaps the simplest task of all, but bear in mind that you’ll need to
delete any mailbox and/or Public Folder databases contained in the storage group before you do so.
When you’re ready, perform the following steps:
1. In the Exchange Management Console, click the Server Confi guration work center
node, then select the Mailbox Server subnode.
2. Now click the storage group you want to delete and select Remove in the Action
pane. Alternatively, you can right-click the respective storage group and select Remove
from the context menu.
3. You’ll now be asked whether you’re sure that you want to remove the storage group.
Click Ye s .
4. When the storage group has been removed, you will get a warning stating that you need
to manually remove the Storage Group folder and any log fi les beneath it (see Figure 4.6).
click OK.
Figure 4.6 Storage Group Removal Warning
164 Chapter 4 • Managing the Exchange 2007 Mailbox Server Role
Managing Exchange 2007 Mailbox
Databases

As is the case with previous versions of Exchange, databases in Exchange Server 2007 are still based
on the Extensible Storage Engine (ESE). The purpose of ESE is to provide an interface to the
underlying database structure, which is responsible for managing changes made to the database
(more specifi cally, the .EDB fi le). To do so, ESE uses transaction log fi les so that a database is kept in
a reliable state. It does so by writing any changes made to a database (for example, via an Outlook
MAPI client) fi rst to one or more transaction log fi les and only thereafter to the database itself.
NOTE
If you want to remove a storage group using the EMS, you can do so using the
Remove-StorageGroup CMDlet. To get a list of the available parameters, type
Get-Help Remove-StorageGroup in the EMS.
Saying Goodbye to the
Streaming Media File (.STM)
In Exchange Server 2000 and 2003 a database is made up of 2 fi les: an .EDB fi le and an .STM fi le.
The purpose of the streaming fi le (.STM) is, as many of you might be aware, to house raw Internet
content message streams as defi ned in Request for Comment (RFC) 822. Since the .EDB fi le isn’t
very suitable for storing raw Internet content message streams, the idea of introducing the .STM fi le
SOME INDEPENDENT ADVICE
During the early development stages of Exchange Server 2007 (which, back then,
was code-named Exchange 12 or simply E12) there were serious plans about moving
away from the ESE (which, formerly known as the Joint Engine Technology, or JET,
is nothing more than a heavily modifi ed Access database) to a new SQL database.
These plans were dropped relatively fast. So, why were the plans about moving to
a SQL database dropped in the fi rst place? The decision was based on many factors,
but the primary reason was customers. Staying with JET would mean that customers
would not be faced with the migration work associated with moving to a new
store, which is perhaps a good thing when you look at all the other architectural
changes that have been made to the product. Will the next version of Exchange
(code-named E14) use a SQL database? We don’t know, but there’s a good chance
ESE won’t be replaced with SQL before E15 (yes, that’s right, the version after E14!).
Managing the Exchange 2007 Mailbox Server Role • Chapter 4 165

was understandable, but with Exchange Server 2007 the .STM fi le has been removed, together with
the Exchange Installable File System (ExIFS). The reasoning behind this decision was to reduce the
overall I/O footprint for Exchange Server 2007.
What about Support for
Single-Instance Storage?
As is the case with previous versions of Exchange, Exchange Server 2007 maintains single-instance
storage (SIS) of messages. That means that if a message is sent to one recipient and it is copied to
20 other recipients residing in the same mailbox store, Exchange Server 2007 maintains only one
copy of the message in its database. Exchange Server 2007 will instead create pointers to the message,
and these pointers will link both the original recipient and the 20 additional recipients to the original
message. If the original recipient and the 20 additional recipients are moved to another mailbox store,
only one copy of the message is maintained in the new mailbox store. Since SIS hasn’t changed since
Exchange Server 2003, we won’t go into this technology in depth but instead refer you to MS KB
article 175481 ( if you want to learn more.
New Size for Transaction Log Files
Another improvement regarding storage changes in Exchange Server 2007 is that the transaction log
fi les now are 1MB instead of 5MB, as was the case in previous version of Exchange. What’s the reason
behind this decision? In previous versions of Exchange, if a crash destroyed the last few log fi les that
hadn’t yet been committed to the database, you would need to restore or repair the database to have
it mounted again. Exchange Server 2007 introduces a new feature called lost log resilience, or LLR for
short, which will hold the last few log fi les in memory until the database is shut down. This means
that you’ll never have a case where part of log fi le 5, for example, has been written to the database,
but part of log fi le 4 hasn’t. The benefi t of this feature is that if you don’t mind losing the last few
log fi les, you can tell Exchange to simply throw away the data and mount the database.
The reason that the log fi les have been reduced to 1MB is to reduce LLR exposure. Now if you
lose the last log, it costs up to 1MB of the most recent data instead of 5MB.
Another improvement worth mentioning in regard to transaction log fi les in Exchange Server
2007 is that the log fi le sequence numbers now can go above 1 million. As some of you might be
aware, previous versions of Exchange had a limit of 1 million, so if a database had been running long
enough to generate a million logs, you had to shut it down and start over from log #1 (“resetting the

log sequence”). This would happen every few years, for most databases. With the smaller log sizes and
the increasing number of messages passing through most databases, the Exchange Product group
decided that 4 billion would be a better maximum log number.
NOTE
It’s a best practice to separate database and transaction log fi les on different disk
spindles. This makes it easier to recover your data if there’s a disk failure and
provides the best overall performance (by optimizing disk I/O).
166 Chapter 4 • Managing the Exchange 2007 Mailbox Server Role
Creating a New Mailbox Database
Creating a new mailbox database is straightforward; you do so by performing the following steps:
1. In the EMC, click the Server Confi guration work center node, and then select the
Mailbox Server subnode.
2. Now select the storage group in which you want to create the new mailbox database.
3. Select New Mailbox Database in the Action pane. Alternatively, you can right-click the
respective mailbox database and select New Mailbox Database from the context menu.
4. Name the new mailbox database and specify the location where you want the .EDB fi le
to be created, then click New (see Figure 4.7).
Figure 4.7 Creating a New Mailbox Database