Chapter 2: Understanding Exchange Server Storage Architecture

This chapter describes the storage architecture in Microsoft Exchange Server 2003. We’ll cover the database file structure, the Extensible Storage Engine (ESE), the change made to the Installable File System (IFS), and the way Exchange Server 2003 handles public folders. Finally, we’ll look at indexing and how clients access Exchange Server 2003 stores, as well as the front-end/ back-end server architecture.

Storage Design Goals in Exchange Server 2003

The storage architecture of Exchange Server 2003 has three goals. The first is to minimize loss of productivity when a database goes offline. Exchange Server 2003 achieves this goal by spreading users across multiple databases that can each be mounted (started) or dismounted (stopped) individually. If one database in a storage group goes offline for some reason, the other databases continue to run, minimizing the number of users who are affected by the downtime.

The second goal is to allow a single server to host more users than is pragmatically possible in Microsoft Exchange 5.5. Spreading the users across multiple databases on a single server accomplishes this goal as well. Since the databases are smaller, creating more databases on each server allows each server to host more users. For instance, it is easier to manage six databases with 1000 users per database than it is to manage one database of 6000 users. Not only can backup and restore times be scheduled individually and run faster, but if one database becomes corrupted, only 1000 users are affected instead of 6000 users. In addition, Exchange Server 2003 can group multiple databases into a single storage group and host multiple storage groups on a single server.

The third goal, better recoverability in the event of a disaster, was a major concern of the design team and is also achieved by spreading users across databases, allowing individual databases to be restored while other databases are running. The result is shorter downtimes and greater productivity for users because only a subset of the organization’s users is affected when a database goes offline.