Lesson 2: Configuring Information Stores | MCSA/MCSE Self-Paced Training Kit (Exam 70-284): Implementing and Managing MicrosoftВ® Exchange Server 2003 (Pro-Certification)

Mailbox stores are only a portion of what can be contained within a storage group. The information store service of Exchange Server 2003 manages all the storage groups on a server, which can contain public folder stores as well as mailbox stores. Storage groups are one of the most significant advantages Exchange Server 2003, Enterprise Edition, has over Exchange Server 2003, Standard Edition. Exchange Server 2003, Standard Edition, supports having only a single storage group per server, containing one mailbox store and one public folder store. Exchange Server 2003, Enterprise Edition, can support up to four storage groups per server, with each storage group containing up to five databases (combinations of mailbox stores and public folder stores).

After this lesson, you will be able to

Understand storage group architecture
Understand the use of multiple databases and storage groups
Add storage groups and databases
Move Exchange Server 2003 storage groups and databases

Estimated lesson time: 30 minutes

Understanding Storage Group Architecture

The Exchange Server 2003 storage architecture consists of databases (also known as information stores) that are grouped together within a storage group. Each database is comprised of two files: the rich text file (.edb file) and the streaming file (.stm file). These files are managed as a single unit by the Microsoft Exchange Information Store service. There are additional files, as well, that are common to the entire storage group.

E00.chk The checkpoint file, which is used to mark which transactions in the transaction log have been committed to the database. E00 indicates the first storage group on a server. When you create additional storage groups, the file name that is created will be incremented to E01, E02, and so on.
E00.log The current transaction log. Exchange Server 2003 first writes data to a transaction log rather than to the database itself, which allows for better performance and scalability.
Mailbox.edb The rich text file. While the extension will always be .edb, the name of the file is defined at the time the storage group is created. By default, it will be named the same as the storage group.
Mailbox.stm The streaming file. As with the rich text file, the name of the streaming file is defined at the time the storage group is created.
Res1.log The first of two reserved transaction logs. The reserved logs are used to reserve a portion of disk space for use by Exchange Server 2003 in case the hard disk runs out of space. This allows the Exchange Server 2003 services to shut down normally rather than crashing when the disk becomes full.
Res2.log The second reserved transaction log. Each transaction log is 5 mega-bytes (MB) in size.
Tmp.edb A temporary transaction log used by Exchange Server 2003.
E00tmp.log When the E00.log file reaches 5 MB in size, it is renamed, and another E00.log file is created. This E00tmp.log file is used to bridge the gap by storing transactions that occur while the process of renaming E00.log takes place.

There are .edb and .stm files for each database in a storage group but only one set of log files for all databases within a storage group.

Understanding the Use of Multiple Databases and Storage Groups

Multiple storage groups can be used for a number of purposes in an Exchange Server 2003 organization. One of the most common purposes is related to backup and restore. Even in small companies, it is not uncommon to have over 20 GB in e-mail, particularly if storage limits are not used. In large organizations, 100 GB or greater in e-mail is often stored on the e-mail servers. With Exchange Server 5.5 and earlier, only a single mailbox store (called the private information store) is possible. As a result, all the e-mail is stored in a single database file. That poses a significant problem when it comes to backing up and restoring data. The problem isn't so much with backing up the database as it is with restoring it. A restore typically takes twice as long as a backup, so if you have a 100-GB mailbox store that takes eight hours to back up to tape, you can expect it to take roughly 16 hours to restore the database in the event of a disaster. Because e-mail is such a vital corporate application, that length of downtime is unacceptable in most cases. That time frame doesn't even include the time it takes to replace any faulty hardware and reinstall or restore Windows prior to restoring Exchange.

By using multiple databases, you can reduce the individual mailbox store size, making backup and restore easier to manage. However, a limitation is that you cannot schedule backups for individual databases within a storage group if you want them to run at different times. Backup scheduling applies at the storage group level. So, to get around that, you would instead use multiple storage groups, which would allow you the flexibility of different backup schedules for each storage group.

In addition, you can restore mailbox stores individually, in the order you choose, in case of a disaster recovery. For example, while you are restoring Exchange Server 2003, the executive management group requests that getting their e-mail online be the highest priority. If you had the executives in their own mailbox store, you could restore that database first and get the executives' e-mail online, then work on restoring the rest of the company's e-mail. Using multiple databases also allows the flexibility of taking one database offline for maintenance, or restoring an individual database, without affecting the other databases. This results in limiting downtime to a subset of users rather than to all of them.

Another advantage to using multiple storage groups is that you can configure circular logging settings independent of each other. Circular logging is a process that saves disk space usage by reusing the same set of log files, overwriting older transactions with newer ones. This differs from the process described earlier where the transaction log is renamed when it reaches 5 MB in size and a new log is created. This is the default behavior and can result in significant disk usage if backups are not performed regularly. Naturally, backups should always be run on a regular basis, generally at least once a day. When a backup is run, transactions are committed to the database and the unnecessary log files are deleted. With circular logging, only full backups can be run. Incremental or differential backups cannot be used because of the way circular logging works. As a result, if you have to restore a database, you can restore only to your last full backup.

Caution

This characteristic of circular logging is a very important and significant limitation. Therefore, the use of circular logging is strongly discouraged unless you have no other choice, such as a short-term workaround with a failed tape backup drive and insufficient disk resources to hold the growing log files until the tape drive is replaced.

By default, circular logging is not enabled. However, if you do enable it, the setting applies to all databases in a storage group. So, if you want to have circular logging on a particular database but you don't want other databases to use circular logging, you would use a separate storage group to house the database that needs circular logging and configure it in the properties of the storage group.

Adding Storage Groups and Databases

Prior to adding more storage groups and databases, you should adequately plan for them because they increase the complexity of administering Exchange Server 2003. Planning involves determining the business needs for the storage group infrastructure, which usually relates to backup and restore needs and to administrative requirements.

To add a storage group, use Exchange System Manager. Each server running Exchange Server 2003 can host up to four storage groups. (However, remember that if you are using Exchange Server 2003 on a Cluster Service cluster, you need to ensure that a storage group can hold the databases from another node in the case of a failover.) Navigate to the server on which you want to create the new storage group. Then, right-click the server, point to New, and then click Storage Group. This opens a Properties page for the new storage group. The first task is to name the storage group. As soon as you start typing a name, Exchange Server 2003 will automatically fill in the paths to its installation directory and use the name for the location of the transaction logs and system path. This is shown in Figure 7-36.

click to expand
Figure 7-36: Storage group properties

You can change the paths, and you probably should. Exchange Server 2003, like previous versions of Exchange Server, performs best when the transaction logs and the databases are on separate physical drives. This approach is also highly recommended for improved recovery since, if a hard drive fails, it will not take out both the transaction logs and the databases.

Important

If the partition that the transaction logs are located on completely fills up, the Information Store service will stop in order to prevent data corruption. You can correct the problem by freeing up disk space and then restarting the service.

On the Properties page, the Transaction Log Location defines the path to the transaction log files. The System Path Location sets the location for the storage of temporary and recovered files. The Log File Prefix is not user-configurable, but after you create the storage group, you will be able to view the prefix, such as E01, E02, and so on. The Zero Out Deleted Database Pages setting clears deleted data from the hard drive, at the expense of system performance. The last configuration option, Enable Circular Logging, reduces disk usage by reusing a single transaction log rather than creating a new one each time the 5 MB size limit is reached.

Exam Tip

Transaction log files are always 5 MB in size. Exchange Server 2003 creates an empty 5 MB file and then fills it with data. When the 5 MB size limit is reached, a new file is created. A transaction log file that is not 5 MB in size is almost certainly corrupted.

Real World: Disk Configuration

Because of the critical nature of the messaging system within a corporation, planning a server configuration for optimal performance and reliability is crucial. This includes not only planning for Exchange Server 2003 but also for the Windows operating system. The following hard disk configuration is considered the best practice for a server running Exchange Server 2003 in the real world:

Mirrored system disk (RAID-1) Contains the operating system and Exchange Server 2003 binaries (the application itself).
Mirrored transaction log disk (RAID-1) Contains the transaction logs for Exchange Server 2003. The transaction logs are arguably more import-ant than the databases themselves when it comes to disaster recovery, and RAID-1 is ideal because data is mirrored automatically as it is written. RAID1 should be implemented with the two drives on different controllers so as to avoid a bottleneck during disk write procedures. RAID-1 performs better than RAID-5, which is better suited to write-once and read-many type of operations.
RAID-5 database disk partition Contains the storage group and its database. RAID-5, which provides disk striping with parity, scales well (requires a minimum of three disks and can have up to 32) and, with the use of a hot spare (another powered drive that isn't presently part of the RAID set), up to two drives can fail before data is lost. RAID-5 is well suited for storing the databases because it is reliable and performs best when data is read more often than it is written. Another good option is RAID-0+1, which is a combination of disk striping (without parity) and disk mirroring. A RAID-0 stripe set is created, and then the stripe set is mirrored. This overcomes the primary limitation of RAID-1, which is that it can utilize only two drives. However, RAID-0+1 is costly in terms of disk hardware because even though it scales well, the mirroring function results in only half of the total disk space being available for data.

This type of configuration should be scaled as the number of storage groups and databases grows. For each storage group, which contains its own set of transaction logs, you should have a separate mirrored disk set for the logs. Likewise, each database should go on its own RAID-5 disk partition, or RAID-0+1 if cost is not a concern. This ensures the optimal level of server performance and the greatest level of reliability. In addition, if there is a performance difference between hard disks in your server, you will want to place the transaction logs on the fastest disks.

It may not be practical from a cost standpoint to have such an extensive disk configuration in all environments, but the goal is to provide the best possible performance and reliability.

Once you create a storage group, you will likely want to add a database to it. Databases can be either mailbox stores or public stores. To add a database, right-click the storage group in Exchange System Manager and point to New, and then click Mailbox Store. As you can see in Figure 7-37, Exchange Server 2003 displays a Properties dialog box.

click to expand
Figure 7-37: Configuring a new mailbox store

Moving Exchange Server 2003 Storage Groups and Databases

When Exchange Server 2003 is first installed, it places the first storage group and databases it creates in the Mdbdata folder underneath the installation path (for example, C:\Program files\Exchsrvr\Mdbdata). While this works, it does not allow for the optimal level of performance and reliability. Exchange Server 2003 performs best when its transaction logs and database files are on separate physical disks (or disk arrays). With Exchange Server 5.5 and earlier, there was a utility called Performance Optimizer that analyzed your server and made recommendations as to where to place the transaction logs and database files (storage groups did not exist, so that wasn't an option). You had the option to accept the recommendations, to override them by choosing the locations yourself, or to do nothing at all. Performance Optimizer is not included with Exchange Server 2003, but you can still move databases.

Exchange System Manager is used to move both storage groups and databases. To move a storage group, right-click it and then click Properties. Click the Database tab to open a dialog box like that shown in Figure 7-38. You can click the Browse button next to Transaction Log Location and select a new folder. You can also change the System Path Location in the same way. Remember that if you change the location of the transaction logs, it affects every database in the storage group. As a result, all databases will be dismounted (taken offline) while the process completes. Dismounting a database makes it unavailable for users to access. When you click OK, Exchange System Manager will prompt you with a message box, warning you of what tasks you are about to perform and that all databases in the storage group will be temporarily dismounted. You are prompted to click Yes to continue (which will move the files) or No to return to the Properties dialog box.

click to expand
Figure 7-38: Database properties

Moving a database is similar to moving a storage group. Using Exchange System Manager, right-click the database that you want to move and click Properties. Next, click the Database tab. For a database, you have the option of moving the Exchange Database (.edb file) and the Exchange Streaming Database (.stm file). Generally, there is no advantage in separating these files, so it makes sense to keep them located in the same folder. After choosing new folder locations and clicking OK, Exchange System Manager will prompt you to confirm, as shown in Figure 7-39.

click to expand
Figure 7-39: Confirming the database move

When moving a storage group or database, you can move the log files and database files to any folder that you want to create. When you move log and database files, it is recommended that you create the \Exchsrvr\Mdbdata file structure on the destination disk partition for consistency, but you are not required to do so.

If you move data to another partition, you must grant the following default permissions to the new Mdbdata folder that contains the log files and database files:

Administrators: Full Control
Authenticated Users: Read and Execute, List Folder Contents, Read
Creator Owner: None
Server Operators: Modify, Read and Execute, List Folder Contents, Read, Write
System: Full Control

Moving log files or database files invalidates all existing incremental and differential backups, so it is recommended that you perform a full backup after the move.

Practice: Configuring Information Stores

In this practice, you will create a new storage group and mailbox stores. You will then move the storage group to a new location, observing how the change affects the databases within the storage group and the creation of new databases.

Exercise 1: Create a Storage Group

To start Exchange System Manager, from the Start menu, point to All Programs, then point to Microsoft Exchange, and then click Exchange System Manager.
Navigate to the Exchange Server 2003 server that you will be adding the storage group to. Right-click the server, point to New, and then click Storage Group.
Type MIS for the name. Leave all settings at their default for now, but observe that the paths for the transaction logs are the installation root of Exchange Server 2003 plus the name of the storage group, such as C:\Program files\Exchsrvr\Mis. Click OK.
The new storage group should have been created on the server.

Exercise 2: Add Mailbox Stores

Right-click the MIS storage group, point to New, and then click Mailbox Store.
Type HelpDesk for the name. Leave all other settings at their default for now and click OK.
Repeat the process and create mailbox stores for SysAdm and Engineering.
Observe the new mailbox stores in the MIS storage group.

Exercise 3: Move a Storage Group

If you have a D hard disk partition, create a folder structure for D:\Exchsrvr\Mis. If you have only a C partition, create a folder structure such as C:\Exchsrvr\Mis to complete this exercise. This exercise assumes two physical disk drives configured as C and D.
Right-click on the MIS storage group in Exchange System Manager and click Properties.
Because the transaction logs and database files should be on separate physical disks, you will only need to move one or the other. The databases tend to consume more disk space than the transaction logs, so change the System Path Location. To do this, click Browse and select D:\Exchsrvr\Mis, and then click OK twice. When prompted to continue, click Yes. All databases in the storage group will be temporarily dismounted while the process completes.

Exercise 4: Move a Database

Right-click the HelpDesk mailbox store and click Properties. Click the Database tab. Observe that even though you moved the System Path Location for the storage group, the databases themselves do not move automatically and still reflect their original location.
Click Browse next to Exchange Database and select D:\Exchsrvr\Mis\Helpdesk for the new path. Click OK.
Click Browse next to Exchange Streaming Database and select D:\Exchsrvr\Mis\Helpdesk for the new path. Click OK twice, and then click Yes when prompted to continue. The database will be temporarily dismounted while the process completes, but no other databases in the storage group will be affected.
Repeat the process and move the SysAdm and Engineering mailbox stores.
Right-click the MIS storage group, point to New, and then click Mailbox Store. Type Development for the name. Click the Database tab. Observe that the default location of the Exchange Database and Exchange Streaming Database has changed to reflect the move of the System Path Location for the storage group.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and then try the question again. You can find answers to the questions in the "Questions and Answers" section at the end of this chapter.

You are the Exchange Server administrator for Contoso, Ltd. Because of the high level of interactivity between the Sales group and Contoso's customer base, executive management is concerned that if e-mail went down, it would take too long to get the Sales staff back online. The CIO researches Exchange Server 2003 and asks you about segregating the e-mail for Sales into its own group outside the general mailbox store so that Sales could be restored first in case of a disaster recover. He also does not want Sales to have the mailbox limits that everyone else has. Furthermore, whereas the general mailbox store is backed up nightly, the CIO wants the Sales group e-mail to be backed up twice a day in order to minimize potential data loss. How would you meet these requirements?

You are a network administrator who has been asked to define the specifications for a new server running Exchange Server 2003 that will be purchased to replace an existing server. The server will host three storage groups that each contain 2 to 5 databases, as follows:

Storage Group	Database
General	General Mailbox Store
	General Public Store
Executive	Executive Mailbox Store
	Executive Public Store
Support	SysAdm Mailbox Store
	Development Mailbox Store
	HelpDesk Mailbox Store
	Engineering Mailbox Store
	Support Public Store

Because of the existing server's previous reliability problems, you have been told that cost is not a consideration and that performance and reliability are the deciding factors. Design a disk configuration for the new server that will maximize the performance and reliability of the new server, as well as give the best flexibility in administering information stores.

You are the network and Exchange Server administrator for a small company that uses Exchange Server 2003. The server running Exchange Server 2003 has only two hard disks, so you have moved the single storage group and its two databases to the second disk (D), leaving the transaction logs on C. Your company does most of its communication with customers and clients by e-mail. After about six months, you occasionally run into a problem where the Information Store service shuts down toward the end of the day. This usually happens on days when one or more mass e-mails have been sent to customers. You find that after the nightly full backup runs, you are able to restart the Information Store service successfully. Management is concerned about the Exchange server going down too often and wants to know what the problem is and how you can fix it.

Lesson Summary

Exchange Server 2003 uses a combination of database files and transaction logs to manage data. Information is first written to a transaction log and later committed to the database.
Transaction logs are always 5 MB in size. Exchange Server 2003 creates an empty 5 MB file and then fills it up with data. Once the log file is full, a new empty 5 MB file is created, and the process repeats.
Exchange Server 2003, Enterprise Edition, supports up to four storage groups. Each storage group can contain up to five databases, which can be any combination of mailbox stores and public stores.
Exchange System Manager is used to create storage groups and databases and to change the folder locations for them.
Circular logging reduces the disk space usage by transaction logs but at the expense of being able to perform incremental or differential backups.