Navigating the Information Store

Storage groups allow you to group databases logically, giving you the option of managing an entire storage group (with all its databases) or managing databases individually. Each mailbox server has one storage group by default, and you can create additional storage groups as needed. One additional storage group, called the recovery storage group, is always reserved for database recovery operations.

Using Storage Groups and Databases

On the surface, storage groups and databases seem to be the most fundamental Exchange Server components. Yet, as you dig deeper, the reasons for creating additional storage groups and databases become clear. You use storage groups as containers for mailbox databases, which hold user mailboxes, and for public folder databases, which hold public folders.

When you install the first mailbox server in the organization, this server's information store has two default storage groups:

• First Storage Group, which contains the default mailbox database

• Second Storage Group, which contains the default public folder database

When you install additional mailbox servers in the organization, these servers have only one default storage group:

• First Storage Group, which contains the default mailbox database

Although mailbox databases continue to be the primary type of database used with Exchange Server, Exchange Server 2007 supports public folder databases primarily for backwards compatibility with Microsoft Outlook 2003 and other Messaging Application Programming Interface (MAPI) clients that use public folders. Outlook 2003 clients use public folders to access free/busy information and the Offline Address Book (OAB). If you have Outlook 2003 and other MAPI clients, these clients can continue to access public folders on mailbox servers running Exchange Server 2007. However, Exchange Server 2007 does not provide graphical user interface (GUI) management for public folders. You must manage public folder configuration using Exchange Management Shell.

Note 

Exchange Server 2007 does not support public folder access using Network News Transport Protocol (NNTP) or public folder access using Internet Mail Access Protocol 4 (IMAP4). Exchange Server 2007 also does not support non-MAPI toplevel folders in your public folder databases. The only way to maintain this functionality in an Exchange 2007 organization is to maintain a server running Exchange 2000 Server or Exchange Server 2003.

Exchange Server 2007 de-emphasizes public folders because Outlook 2007 does not use public folders for accessing free/busy data or the OAB. Instead, Outlook 2007 accesses this information from the organization's Client Access servers. How does this work? Client Access servers provide Outlook Web Access services, which in turn allow clients to access mail, free/busy data, OAB data, and other Exchange data using Hypertext Transfer Protocol (HTTP).

Tip For sharing information and collaboration, in an Exchange 2007 organization, you should configure Windows SharePoint Services Version 3 or later. With Share-Point Services, you can create shared team calendars, document libraries, discussion boards, and more.

Configuring Storage Groups and Databases for Availability

Storage groups have several types of files associated with them. As Table 11-1 shows, these files include one or more checkpoint files, a temporary working file, and one or more transaction log files. Depending on the state of Exchange Server, you might see other working files as well. When you create a storage group, you can specify separate folder locations to use for transaction logs and system files.

Table 11-1: System and Data Files Used by Storage Groups
Open table as spreadsheet

Type of File	File Name	Description
System Files
Temporary data	Tmp.edb	Temporary workspace for processing transactions
Checkpoint file	E##.chk	Checkpoint file that tracks the point up to which the transactions in the log file have been committed
Transaction Log Files
Primary log file	E##.log	Primary log file that contains a record of all changes that have yet to be committed
Secondary log files	E## 00000001.log E## 00000002.log, …	Additional log files used as needed
Reserve log files	E## Res00001.jrs, E## Res00002.jrs, …	Files used to reserve space for additional log files if the primary log file becomes full

You create mailbox and public folder databases within storage groups. Each storage group can have multiple databases associated with it. You use Exchange databases to ease the administrative burden that comes with managing large installations. For example, instead of having a single 800-gigabyte (GB) database for the entire organization, you can create eight 100-GB databases that you can manage more easily.

Tip As a best practice, 100 GB is, in fact, the largest recommended size for Exchange Server 2007 databases. If you enable Local Continuous Replication (LCR), as discussed later in this section, the largest recommended database size is 200 GB. When it comes to backup and recovery, you will find that these database sizes typically work well in helping you meet any Service Level Agreements (SLAs) you might have.

When you create a mailbox or public folder database, you specify the name for the database, and this name sets the name of the primary database file as well. For example, if you create a mailbox database called MarketingDept, the primary database file is set as MarketingDept.edb. With Exchange Server 2007, the default location for database files is the same as the log folder used by the storage group itself. If you want a database to be in a different location, you can specify the location you want to use.

The many files associated with storage groups and databases provide granular control over Exchange Server, and if you configure the data files properly, they can help you scale your Exchange organization efficiently while ensuring optimal performance. To see how, consider the scenarios listed in Table 11-2, which outline some ways that small, medium, and large organizations can configure mailbox servers based on performance needs.

Table 11-2: Configuring Exchange Data Files for Small, Medium, and Large Organizations
Open table as spreadsheet

Organization Size	Performance Needs	Recommendation
Small	Low	Place all data files on the same drive. Consider using a redundant array of independent disks, such as RAID 1 or RAID 5, to protect the data.
	High	Place all databases on a single drive. Place all transaction logs and system files on a different drive. Consider using RAID 5 for databases and RAID 1 for transaction logs.
Medium	Low	Place all databases on a single drive, using RAID 5 to protect the drive in case of failure. Place all transaction logs and system files on a different drive, using RAID 1 to protect the drive in case of failure.
	High	Place all databases on a single drive, using RAID 5 to protect the drive in case of failure. Place all transaction logs on a different drive, using RAID 1 to protect the drive in case of failure. Place all system files on a third drive.
Large	Low	Organize data according to storage groups, placing all the data for each storage group on separate drives. Use RAID 1 or RAID 5 to protect the drives.
	Moderate	Each storage group should have its own database drive. Use RAID 5 to protect the database drives in case of failure. Place transaction logs and system files for each storage group on different drives, using RAID 1 to protect the drives in case of failure.
	High	Each database should have its own drive. Use RAID 5 to protect the drive in case of failure. Place the transaction logs for each storage group on separate drives, using RAID 1 to protect each drive in case of failure. Place system files for each storage group on separate drives.

Improving Availability

You can also use storage groups to manage Exchange Server 2007 backup and recovery more effectively. When you perform backup operations on Exchange Server, you can back up each storage group separately. If you have a problem with Exchange Server, you can restore a specific storage group to resolve the problem instead of having to restore all the Exchange data. Log files are also useful in recovery. Each transaction in a log file is marked with a database instance ID, which enables you to recover individual databases within a single storage group.

Before you create storage groups, mailbox databases, or public folder databases on mailbox servers, you should consider how you will back up and recover your server. Your backup and recovery plan should take into account the requirements of any SLAs for Exchange Server.

To improve availability for the information store, Exchange Server 2007 introduces Local Continuous Replication (LCR). LCR is designed for storage group replication. It is a single-server solution for asynchronous log shipping, replay, and recovery. You use LCR to create and maintain a copy of a storage group and its related database for disaster recovery. The copy, or replica, of the storage group is created and maintained on a separate set of disks than those used by the storage group being replicated. These disks-like the original disks used by the storage group-must be connected to the server and cannot be located on another server.

Tip From an overall performance perspective, it is important to keep in mind that LCR requires approximately 30 to 40 percent additional processor and memory resources to maintain. Because of this significant additional load, you may want to add processors and memory to your mailbox servers prior to enabling LCR.

Because you cannot combine storage group replication with public folder replication, and you cannot create multiple databases in an LCR-enabled storage group, there are some strict rules for mailbox and public folder databases. These rules are as follows:

• With mailbox databases, LCR is available only when each storage group has a single database. If a storage group has multiple databases, you cannot enable LCR and you will need to first delete or move the additional databases.

• With public folder databases, LCR is available only when the Exchange 2007 organization has one public folder database. If your organization has more than one public folder database, public folder replication is used instead of LCR replication. Public folder replication occurs automatically whenever there are two or more public folder databases, even if there are no public folders to replicate.

You enable and disable LCR on a per-storage group basis. When you enable LCR for a storage group with an existing database, the database it contains is enabled automatically to use LCR. For storage groups, LCR allows you to configure separate backup locations for transaction logs and system files. For databases, LCR allows you to configure a unique backup location for the passive copy of the database file. The best guideline to follow when determining whether to use separate storage locations is this: if you store transaction logs, system files, and databases separately for each storage group, you should strongly consider using separate backup locations as well. This will help ensure the server's drives can keep up with the expected read/write performance levels.

When you enable LCR, it becomes your first line of defense for disaster recovery. To recover a database, you can revert to the passive copy of the data, and do not have to restore from backup. After you revert to the passive copy, it becomes the active copy and you can replay transaction logs, if they are available, to fully restore the database. You can also make backups of the passive copy rather than the active copy, giving you an additional backup option that should reduce any downtime related to backups.

After you've enabled LCR, you'll need to manage your LCR-enabled storage groups and databases in a slightly different way than storage groups and databases without LCR. Moving a storage group or database with LCR requires that you:

1. Suspend LCR.

2. Move the storage group or database.

3. Resume LCR.

You'll also want to regularly verify the LCR copies to ensure that they are valid and usable. Typically, you'll schedule verification to run during off-peak usage hours. See "Verifying Your Local Continuous Replication Copies" for more information.