The Information Store is the heart of Microsoft Exchange Server. Without a
healthy Store, you don't have a successful Exchange deployment, and users are
unhappy because they can't access their mailboxes. Exchange Server 2003 and
Exchange 2000 Server introduced the concept of storage groups (SGs) and introduced
new Store components such as the streaming database. Although the biggest change
to the Store in Exchange 2007 is support for the Windows 64-bit platform, Microsoft
has made other fundamental changes to the Store that you should also know about
when planning your Exchange 2007 migration.
No SQL Server?
The biggest change that many expected to occur in Exchange 2007 was a transition
to Microsoft SQL Server as the database engine for the Store. However, when
the Exchange developers investigated the challenges of forcing a database engine
designed for structured transactions to handle the work generated by Exchange
and its clients, they decided they couldn't do it for Exchange 2007. This isn't
altogether surprising when you consider the vastly different types of messages
that flow through Exchange—everything from small 2KB messages to multimegabyte
messages containing several attachments sent to large distribution lists. Also,
users interact with Exchange in ways that affect the database. For instance,
Microsoft Outlook users can click a heading in their Inbox to sort messages
by that column. This action creates a new custom view in the database. If you
consider that a server supports thousands of clients and each client can create
many different views, you can sense why the transition to SQL Server could be
such an engineering challenge.
The net result is that Exchange 2007 continues to use the
Extensible Storage Engine (ESE) that it's used since 1996. Of
course, each release of Exchange has modified ESE in different
ways, and Exchange 2007 is no different; its major change is the
move from a 32-bit platform to a 64-bit platform.
What 64-Bit Means for Exchange
The move to 64-bit is a big plus for Exchange because it addresses some fundamental
Store problems in Exchange 2003 and Exchange 2000. For example, as Microsoft
releases new versions of the OS, Windows servers gradually use more kernel mode
memory to accommodate drivers, such as those used by antivirus and antispam
products, and to handle the demand for connections from clients. Five years
ago, users typically connected with just a desktop client, so administrators
could easily figure out how many concurrent clients a server had to handle based
on the number of users whose mailboxes the server hosted. Now, the proliferation
of mobile devices means that people use multiple ways to connect to their mailbox.
Research in Motion's (RIM's) BlackBerry is popular with many Exchange organizations,
but it requires the expense of an additional server infrastructure, so organizations
often restrict the use of BlackBerry devices. Microsoft's introduction of server-side
ActiveSync (which is less expensive because it uses the same server infrastructure)
and the growing popularity of Windows Mobile devices, especially the upgraded
functionality delivered by the combination of Exchange 2007 ActiveSync and Windows
Mobile 6.0, mean that Exchange 2007 will need to support even more mobile devices
in the future. Each concurrent client connection requires memory, so you can
see how demand increases.
Virtual memory fragmentation has been
a bugbear for Exchange for years, especially
in clustered systems. Applications request
memory from Windows, which allocates the
memory in chunks. Some applications require
contiguous chunks of virtual memory to perform operations; if enough contiguous memory
isn't available, the application fails. For example,
Exchange requires relatively large amounts of
contiguous virtual memory to load an SG and
mount its databases. When failures occur on a
cluster, the cluster attempts to transfer the SGs
from the failed node to the other nodes in the
cluster, but if enough virtual memory isn't available, the cluster can't transfer the SG, and users
lose access to their mailboxes.
The huge increase in available memory made possible by 64-bit Windows OSs relieves
the memory fragmentation problems that Exchange 2003 and Exchange 2000 have
while also letting Exchange cache much more data than before. The advantage
of caching more data is that Exchange 2007 trades expensive disk I/O for memory,
which addresses another major performance bottleneck that Exchange suffers on
the 32-bit platform. Microsoft predicts that the net effect reduces the I/O
operations per second generated by users from around the 1.0 level to about
0.4 (your mileage will vary depending on the exact workload, CPU, and storage
configuration). Reducing I/O demand lets you support more concurrent users,
but it also requires you to equip Exchange 2007 servers with far more memory
than you'd typically deploy with Exchange 2003. Exchange 2007 Mailbox servers
with 8GB or more memory will be common, so you'll have to pay attention to the
type and speed of memory DIMMs that you specify for servers as you deploy Exchange
2007.
Internally, Microsoft has made other
changes to make the Store more efficient.
Database pages are now 8KB instead of 4KB,
which lets Exchange stuff more data into each
page and so generate fewer I/O operations.
The Exchange 2007 Store is smarter at write
operations and groups transactions together
so that single writes occur instead of multiple
writes. Finally, the Store makes better use of
memory to cache commonly accessed folders
and information, such as calendars, to speed
user performance.
The change to the database page size and
other internal changes mean that you can't
mount an Exchange 2003 database on an
Exchange 2007 server and vice versa. Because
of the complexities involved in an upgrade,
Microsoft doesn't support upgrades from a
server running 32-bit Windows and Exchange
2003 or Exchange 2000 to 64-bit Windows
and Exchange 2007 (even on the same 64bit–capable hardware), so you won't find a
special mode of Eseutil or any other utility
to upgrade a database. To move mailbox
data from Exchange 2003 or Exchange 2000
to Exchange 2007, you'll have to use the
Move Mailbox wizard or the Move-Mailbox
cmdlet. Fortunately, you can now script mailbox moves by using Exchange Management
Shell to automate these operations. For more
information about moving mailboxes, see the
Exchange & Outlook Pro VIP article "Exchange
2007: Life Without ExMerge?" January 9, 2007,
InstantDoc ID 94629.
Although production Exchange 2007 servers can run only on 64-bit Windows, Microsoft
has made a 32-bit version of Exchange 2007 available for use just on test servers.
You can also deploy the Exchange 2007 management components, including Exchange
Management Shell, on 32-bit Windows XP SP1 workstations (you'll have to install
Windows PowerShell and the latest version of the Microsoft .NET framework first).
Support for Windows Vista workstations will be added in Exchange 2007 SP1, which
is currently in beta and expected to be available by the end of 2007.
Maximum Databases
Every previous Exchange version has imposed a maximum database size on Standard
Edition. Before Exchange 2003 SP2, the maximum database size was 16GB; SP2 increased
this to 75GB, a limit that was still too small given the pace of growth in message
volume and average message size. By comparison, Exchange 2003 Enterprise Edition
supports database sizes that are limited only by available disk space. Some
organizations run databases as large as 300GB, but the vast majority of Exchange
databases are less than 50GB, largely because of the time required for backup
and restore operations. Exchange 2007 doesn't restrict database sizes, so even
with Standard Edition you can grow databases as large as you need to. However,
Standard Edition is restricted to 5 mailbox databases and 5 SGs, whereas Enterprise
Edition can support up to 50 databases and SGs.
You can still deploy up to five databases in a single SG, but Microsoft recommends
that you deploy just one database per SG in Exchange 2007. This recommendation
is partly to accommodate easier management, partly to provide better performance,
and partly because you can only use log shipping to protect SGs that hold one
database.
Previous
Register
