Lesson 1: Designing the Information Store of Exchange 2000 Server | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

For Exchange 2000 Server, Microsoft completely redesigned the Information Store service to support new features, such as the Web Storage System (WSS) and a flexible database layout. To achieve flexibility, the Information Store relies on a new version of Extensible Storage Engine (ESE), formerly known as Joint Engine Technology (JET), which is a very reliable transaction-based database engine. For example, ESE can handle up to 16 or 32 TB of data in a single database, depending on the size of the database pages, which can be 4 KB (Exchange) or 8 KB (Active Directory service) in size. Keep in mind, however, that the Information Store of Exchange 2000 Server Standard Edition is limited in flexibility. The maximum database size is 16 MB and you can only have one mailbox store and one public folder store. To put gigantic servers into service, you need to use the Enterprise Edition.

This lesson focuses on the features of the Exchange 2000 Server Enterprise Edition and discusses options to structure the Information Store so that fault tolerance, resilience, and system performance are increased. You can read about the various database files that ESE uses, their purposes, and resulting options to distribute the data across the disks of your server. You can also learn about the advantages and disadvantages of certain disk configurations for Exchange 2000 Server.

After this lesson, you will be able to

Explain why and how to separate the files of an information store to improve system performance and achieve fault tolerance
Determine optimal hard disk configurations according to the various file types of the Information Store for optimal performance and system resilience
Design storage groups, mailbox stores, and public folder stores for an Exchange 2000 server that supports up to several thousands of users

Estimated time to complete this lesson: 60 minutes

Understanding the Database Technology of Exchange 2000 Server

At the core level, the database technology hasn’t changed much from earlier versions of Exchange Server. The information stores still consist of database files and transaction logs. If you are an experienced Microsoft Exchange Server 5.5 administrator, you will find it straightforward to work with the new version. The main difference is that you can now have multiple mailbox stores or public folder stores, as indicated in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."

Databases and Transaction Log Files

By default, all database files are in the \Program Files\Exchsrvr\Mdbdata directory. There, you find two very important file pairs called PRIV1.EDB and PRIV1.STM, and PUB1.EDB and PUB1.STM, which are the attribute and streaming databases of the default mailbox and public folder store (see Figure 10.1). A TMP.EDB file also exists, but this file is not important because it contains only temporary information that is deleted when all stores in the storage group are dismounted or the Information Store service is stopped. More important are the transaction and previous log files, which all have a .log file extension. A checkpoint file (.chk) is used in conjunction with the transaction log.

Figure 10.1 - The database files of the default mailbox and public folder store

Note

When you create additional mailbox stores or public folder stores, you can place the database files in arbitrary directories on the server’s local disks and assign them any desired filename. The filenames do not have to end with .edb or .stm. However, to keep the server configuration easy to understand, you should stay with the default extensions.

Every Exchange 2000 information store consists of the following database file types:

Exchange database (.edb), also known as attributes database This database contains data in standard rich text, in a format based on Messaging Application Programming Interface (MAPI). Microsoft Outlook 2000 and other MAPI-based applications work primarily with this repository.
Exchange streaming database (.stm) To achieve a high level of performance for Internet mail clients, such as Microsoft Outlook Web Access (OWA), Exchange 2000 Server supports streaming Multipurpose Internet Mail Extensions (MIME) content directly into the store without conversion. For example, when you use OWA to read or send messages, you communicate with the Information Store service via Internet Information Services (IIS), in which case the data comes from and is placed directly into the streaming database. To allow users of MAPI-based clients to view a list of all messages in the folder, such as your inbox, the Information Store converts the header information, such as From, To, CC, BCC, Delivery Time, and so on, to MAPI and stores this data in the attributes database. When an Outlook user actually opens the message, the entire item is converted into a MAPI object before it is delivered to the client. Deferred content conversion saves time and system resources because items are only processed when necessary.
Transaction logs (E0X.LOG) ESE uses transaction logs to preserve transactions committed in the memory cache to ensure that these transactions are not lost if the server goes down unexpectedly. To handle data storage efficiently and with high speed, ESE stores new transactions, such as the delivery of a message, in a memory cache and writes the data concurrently to the log file. New data is added to existing data without the need for complex database operations. Later, ESE transfers the transactions en masse from the memory cache into the actual databases.
Checkpoint file (.chk) ESE uses a checkpoint file to determine which transactions have not yet been transferred into the databases from the log files. ESE updates the checkpoint whenever the engine writes a transaction into a database, so the checkpoint file always points to the last transaction that was transferred successfully. This provides a fast recovery mechanism. If the server shut down suddenly, transactions might still require processing. If you start the server again, the Information Store starts and ESE discovers these transactions and transfers them into the databases. It is important to note that the checkpoint file is not absolutely necessary to commit transactions to databases. ESE can determine, by itself, which transactions have not yet been transferred, but this takes significantly more processing time. Under all circumstances, ESE guarantees that transactions are not written to databases multiple times.
Previous logs (.log) Transaction logs are always exactly 5,242,880 bytes (5 MB) in size. If a log is completely filled with data it is renamed to allow the creation of a new, empty E0X.LOG file. Renamed transaction logs are called previous log files. The naming format of previous log files is <Log Prefix>XXXXX.LOG (such as E00XXXXX.LOG), where XXXXX represents a five-digit hexadecimal number from 00000 to FFFFF. Previous logs reside in the same directories as the transaction log file.
Reserved logs (RES1.LOG and RES2.LOG) Reserved logs are an emergency repository for transactions when the current log file is filled but no new transaction log can be created because the server’s hard disk is used to capacity. Reserved logs are created automatically when the databases are initialized because—for obvious reasons—they cannot be created later when they are actually needed. ESE uses RES1.LOG and RES2.LOG only to complete a current transaction process. After that, the database engine sends an error notification to the Information Store, depending on which database is affected, to shut down the service safely. In this situation, you should create additional free hard disk space before you restart the services. Another possible option is to restart the services immediately and perform a full backup of the databases. This deletes existing transaction logs and frees the server’s hard disk resources. Backup types and strategies are covered in Chapter 11, "Designing a Disaster Recovery Plan for Microsoft Exchange 2000 Server."
Patch files (.pat) Patch files ensure that the transactions that happen during online backups are included in the backup process so that the current online backup represents the most recent state. During online backups, users can still send and receive messages, but because the backup program works with the log files, those transactions cannot be incorporated into the transaction log. Patch files catch these current transactions, are included in the current backup at the end of the operation, and are incorporated into the databases afterward. Patch files should not exist during regular server operation.

Increasing the Fault Tolerance of the Information Store

By default, Exchange 2000 Server does not delete transaction logs files. In other words, ESE stores each transaction (that is, messages and other data) in two locations: the transaction log files and the databases. This means that each byte of data in the store consumes two bytes of data on the hard disks, but it also enables you to reconstruct an entire database from the transaction logs. For example, if the current .edb and .stm databases are corrupted, you need only to create new database files and mount the affected mailbox or public folder store. ESE can then replay the transaction logs and recover all data. Figure 10.2 illustrates this process.

Figure 10.2 - Restoring a database from transaction log files

By separating the transaction logs from the databases and placing them on a different hard disk, you can measurably increase the resilience of the Information Store against disk failures. If the hard disk containing the databases breaks, you can replace the disk, create new databases, and then replay the transaction logs, which are still available because they reside on another disk. Users are then able to work again as if nothing happened. On the other hand, if the disk containing the transaction logs is malfunctioning, the databases are still available—only the most recent transactions may be lost if they were not incorporated into the databases before the problem occurred.

To move the databases to a different disk, right-click the desired information store in the Exchange System Manager snap-in, select Properties, click the Database tab, and then click the corresponding Browse buttons to specify a new location for attributes and streaming databases. You can place the .edb and .stm files in different directories, but because they form a complete store, you should keep them together. Bear in mind that moving databases to new directories temporarily dismounts the affected store and all users with mailboxes in it. You should perform a full backup immediately after moving databases.

Alternatively, you also can move the transaction log files. In the Exchange System Manager snap-in, right-click the desired storage group (such as First Storage Group) and select Properties. In the General tab, determine the Transaction Log Location. You can also change the System Path Location, where ESE stores temporary and recovered files, and examine the Log File Prefix field, which is used to construct the complete transaction log filename, such as E00.LOG. Changing the location of transaction log files temporarily dismounts all stores that belong to the storage group.

Note

Disks with transaction log files should not contain any attribute or streaming databases.

Creating Multiple Storage Groups and Mailbox Stores

The Transaction Log Location parameter reveals an important fact: The logs are managed in the context of the storage group, which means that all mailbox stores and public folder stores within a single storage group share the same set of transaction log files. Among other things, this enables you to spread mailboxes across multiple databases without increasing resource consumption for additional transaction log sets. Exchange 2000 Server supports a maximum of four storage groups, and within a particular storage group, you can create a maximum of five mailbox stores or public folder stores. Figure 10.3 illustrates the configuration of a mailbox server with two stores in a single storage group.

Note

A problematic store does not prevent the Information Store service from running. Unaffected databases in the storage group remain mounted and available.

Figure 10.3 - A dedicated mailbox server with two stores in a single storage group

Purging Transaction Logs with Circular Logging

In a default configuration, if you never performed a backup, sooner or later your server would run out of disk space because the transaction logs would keep accumulating. It is not advisable to delete the log files manually due to the high risk of corrupting the databases. Fortunately, you do not need to take this approach. To purge the transaction logs, you need to perform a full or incremental online backup of all databases in the storage group. You can read more about the various backup types and their features in Chapter 11, "Designing a Disaster Recovery Plan for Microsoft Exchange 2000 Server."

Sometimes, however, you may want to configure the server to automatically purge transactions as soon as they are incorporated into the databases, which you can accomplish by enabling circular logging for the storage group. In the Exchange System Manager snap-in, right-click the desired storage group, then select Properties. In the General tab, select the Enable Circular Logging check box. Keep in mind, however, that automatically purging the transaction logs eliminates your ability to re-create mailbox data based on transaction log information. This feature is therefore only suitable for less important repositories that hold a large amount of data, such as newsgroups based on Network News Transfer Protocol (NNTP) implemented in a public folder store. You must create a separate storage group for this repository and then activate circular logging.

Note

Enabling circular logging for storage groups that hold business-relevant data is not recommended. Instead, perform frequent online backups. Microsoft recommends configuring backup operations for entire storage groups, because the transaction logs of a storage group are deleted only after all databases have been backed up.

Disk Subsystems for Exchange 2000 Server

There are two reasons to distribute the transaction logs and database files across the disks of your Exchange 2000 server—fault tolerance and input/output (I/O) performance. If your Exchange 2000 server is equipped with multiple hard disks, separating transaction logs from databases and implementing multiple storage groups can greatly improve system performance. Further, using multiple disk controllers overcomes I/O throughput limitations and allows Exchange to write transactions concurrently to log files and databases. Figure 10.4 shows a disk configuration that provides optimal performance.

Note

Configuring multiple IDE drives on a single controller does not increase disk I/O performance.

Figure 10.4 - A disk subsystem with a moderate level of fault tolerance for theInformation Store

The problem with the configuration shown in Figure 10.4 is that any disk failure has a severe impact on the server. To mitigate this risk, Microsoft recommends configuring the disk subsystem using redundant array of independent disks (RAID) technology. For optimal fault tolerance, use redundant RAID controllers in active/active mode and have one or more standby disks per subsystem. Table 10.1 lists the most common RAID configurations and their typical uses.

Table 10.1 Typical RAID configurations for Exchange 2000 Server

RAID Technology	Description	Used For	Comments
RAID-0	An array of striped disks without parity	Disk drives of workstations	RAID-0 achieves very high performance because all disks can read or write data concurrently, but a significant disadvantage of this RAID technology is lack of fault tolerance and high risk of disk failure. If only one disk in the array breaks, all data is lost and must be restored from backup. For this reason, RAID-0 is seldom used in server systems.
RAID-1	An array of two mirrored disks	Operating system, paging file, and transaction logs	RAID-1 achieves very high performance and very high fault tolerance because all the data is mirrored as it is written and both disks contain the complete set of data. This technology is a perfect choice for data that requires the highest reliability; its most significant disadvantage is its high cost. RAID-1 is the recommended technology for the transaction logs on mailbox and public folder servers.
RAID-0+1	A striped array of mir- rored disks without parity	Information Store databases of large Exchange 2000 servers that require very high I/O per- formance and very high fault tolerance	A combination of mirrored disks included in a RAID-0 drive. Each disk in the array is mirrored to guarantee a very high level of fault tolerance. With increasing disk capacities, this RAID technology is gaining more importance in server configurations. For individual disk sizes larger than 18 GB, Microsoft recommends using RAID-0+1 instead of RAID-5. RAID-0+1 offers the highest performance and very high reliability.
RAID-5	An array of striped disks with parity	Information Store databases of Exchange 2000 servers that require high performance and fault tolerance	RAID-5 works similar to RAID-0, but includes a mechanism to write a checksum of the data to all of the disks. If one disk in the array fails, the system can reconstruct the data from the remaining hard disks. It is important to note that in a RAID-5 array, multiple small disks offer better utilization than fewer large disks. For instance, if you have three 27-GB disks, you only can use 54 GB of net- available storage space—about 67% efficiency. If you used nine 9-GB disks instead, you would end up with 72 GB of storage capacity—equal to 89% efficiency. However, the more disks you include in the array, the high- er the chance that two disks will break at the same time, which effectively would require you to re-create the RAID drive and restore the data from backup. It is safer to use fewer large disks instead of many smaller disks. As mentioned, with large disk capacities, RAID-0+1 is a suitable alternative to RAID-5. Due to the checksum calculation, RAID-5 cannot write data to the disks as fast as RAID-0+1.

Compared to the other RAID technologies, RAID-0+1 provides the highest level of fault tolerance and the best possible I/O performance. An entire mirror set must fail within a stripe set before data is irretrievably lost and must be restored from backup. In a stripe set with three mirrored disks, for example, up to three disks can fail at the same time without loss of data. However, RAID technology cannot protect against data corruption due to malfunctioning controllers, applications, viruses, and so forth. Figure 10.5 shows a standard Exchange 2000 server with a reliable disk subsystem.

The operating system and paging file are placed on separate disks to avoid negative impact of paging activities on the disk input/output (I/O) performance of the system volume. However, if you cannot install as many as four disk subsystems in your server, consider combining the drives of the operating system and paging file, but keep the transaction logs and database files separated. If the underlying disk I/O bus is fast enough, you may even be able to place all physical drives into a single RAID volume and divide that RAID volume using multiple partitions. In cases where the theoretical throughput of the drives in the RAID volume greatly exceeds the throughput of the disk I/O bus, add an additional RAID controller and create a second RAID volume on that controller.

Figure 10.5 - A high-performance disk subsystem with a high level of fault tolerance

Minimizing Disk Space Requirements

The number of mailboxes that you can put in a single Information Store database greatly depends on the capacity of your disk subsystem. If this capacity is limited, consider implementing storage limits, which allow you to warn your users if their mailbox size exceeds a certain maximum, prevent them from sending messages, and prevent message reception. To specify the thresholds, display the properties of the desired mailbox store in the Exchange System Manager snap-in, click the Limits tab, and then define your limits for Issue Warning At (KB), Prohibit Send At (KB), and Prohibit Send And Receive At (KB). Alternatively, you can create a system policy to define mailbox quotas for multiple mailbox stores at once, which is more efficient. Users who exceed the specified limits need to delete messages from their mailboxes, for instance, by downloading them into a personal folder store.

Using the Active Directory Users and Computers console, it is possible to overrule storage limits assigned to a mailbox store for individual user accounts. To do so, display the properties of the desired user, click the Exchange General tab, and then click Storage Limits. The configuration of user-specific mailbox quotas can be burdensome, however. If several users require alternate limits, consider adding a new mailbox store to the storage group, define the appropriate limits for this store, and move all relevant mailboxes into it. Remember, adding the mailbox store to an existing storage group does not increase the number of transaction logs on the server.

Single Instance Storage Feature

The Information Store service supports single-instance storage, a special feature that minimizes the storage requirements of information stores and improves the efficiency of message delivery. Single-instance storage means that a message sent to multiple users on the same server is initially stored as only one copy in the database. All local addressees receive a pointer to this particular object. For example, instead of delivering a message addressed to 1000 recipients to 1000 mailboxes, the message is delivered once, saving 999 instances of delivery time. Users can access this single message instance and read it as if it belonged exclusively to them. When they delete the message, only their reference is removed from the single message instance. When a user changes the message properties, an individual copy is created.

When calculating the required disk space for a mailbox store, however, it is good practice to ignore the single instance storage feature and assume that every user receives individual message copies. Among other things, this simplifies the calculation. Besides, the single instance storage feature does not really reduce disk space requirements significantly. This may sound astonishing at first, but practice shows that over time the single instance storage ratio drops to two or just one recipient per message. Most messages are sent just to one recipient anyway. If you are interested in examining the effectiveness of the single instance storage feature on your servers, use the Performance tool and create a report using the MSExchangeIS Mailbox performance object’s Single Instance Ratio counter.

Note

The single instance storage feature is only available for mailboxes in the same store. If two recipients have their mailboxes in different stores on the same server, the Information Store service must create two individual copies of the message.

Defining Minimum Disk Space Requirements

The potential size of the information stores is not the only important factor in determining the required hard disk capacity. Future growth and potential database corruption problems should also be taken into consideration. Exchange 2000 Server includes two low-level database utilities called ESEUTIL.EXE and ISINTEG.EXE that can be used to fix database inconsistencies. These utilities may be your last resort if backups are unavailable or useless.

ESEUTIL.EXE and ISINTEG.EXE work with temporary database files, which require disk space. For this reason, you should reserve half of your database drives’ capacity for maintenance and recovery purposes. If this is not feasible, you can specify a location for the temporary file on another drive or shared directory in the network, but this significantly slows the recovery operation due to the additional copy process.

You should reserve the following amount of disk space on the transaction log and database drives for future growth and recovery purposes:

Transaction log drive Reserve two to three times the average amount of transaction log files for unexpected increases in transactions. The number of transaction log files may increase due to failed backup operations, as backup failures prevent the deletion of the logs. Dramatic increases may also occur during virus attacks or when faced with a message loop.
Database drive Reserve as much disk space as necessary on the local drive to store a complete copy of the attribute and streaming databases.

Designing the Information Store for Mailbox and Public Folder Servers

The design of a high-performance information store is a matter of avoiding single points of failures in the disk configuration, but you also must ensure that sufficient disk space is available for the mailbox stores and public folder stores. It is a good idea to strive for relatively small database sizes. Huge databases are difficult to back up and even more difficult to restore in a timely fashion. If necessary, consider spreading the mailboxes over multiple stores to avoid large files. A structured arrangement of storage groups and mailbox stores is a vital requirement for large mailbox servers. Table 10.2 lists typical issues that your project team may have to address when outlining the design of mailbox and public folder stores.

The three main elements of a sophisticated Information Store architecture are as follows:

Fault tolerance through disk redundancy
Performance through distributing the messaging data across all disks of the server
Simplified restores through small individual databases

Table 10.2 Typical Information Store Design Issues

Design Issue	Comments
Are your servers equipped with multiple backup drives to support concurrent restore operations using multiple sessions?	To support concurrent restores, you need to implement multiple storage groups, because it is not possible to restore the databases of a single storage group concurrently. Do not configure more than three storage groups, because Exchange 2000 requires the fourth possible group (in addition to the internal storage group that the system usually uses for restores) to perform the parallel restore operation.
Do you have to accomplish database restore operations in a certain time frame according to service level agreements or organizational policies?	If so, and the number of mailboxes is large, consider splitting the mailbox store and implementing multiple databases to keep the database size per individual mail-box store within the limits that the restore requirements permit. Based on the data transfer rates of your backup solution, you can calculate the maximum possible database size.
Do you intend to implement virtual organizations in your Exchange 2000 environment?	To realize a true separation of messaging resources for virtual Exchange organizations, you must implement a separate mailbox store for every company that you plan to support, regardless of the number of users per company. You can read more about the design of virtual organizations in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."
Do you need to comply with different maintenance policies according to the role of a person in the organization?	It is a good idea to implement a separate mailbox store for all users that fall under the same maintenance policy. For instance, the managers of an organization may demand the fastest possible restores of their mailboxes in case of a disaster, whereas restores for other employees may not be time critical. In this situation, it is advantageous to implement a separate mailbox store for the managers and a second mailbox store for the remaining employees.
Do you need to implement different backup procedures or schedules for mailbox or public folder stores, or enable circular logging for a particular repository, such as a newsgroup store?	Implement multiple storage groups according to the backup requirements and place each store in its corresponding storage group. As mentioned, you should back up all stores within a particular storage group as a unit.
Do you need to minimize the disk space requirements for the Information Store?	Consider placing all users in the same mailbox store to benefit as much as possible from the single instance storage feature, and define mailbox quotas for your users to control the amount of data stored on the server.
Do you plan to index the contents of particular mail- boxes or public folders only?	If it is not necessary to support fast, full-text searches over all folders or mailboxes, consider implementing a separate information store and index only this repository. This can help you minimize indexing overhead. The integration of Exchange 2000 Server with the Microsoft Search Service for content indexing and full-text searches was introduced in Chapter 1, "Introduction to Microsoft Exchange 2000 Server."
Do you want to maximize the I/O performance of your servers’ disk subsystems?	Use large hard disks and utilize a RAID-0+1 instead of RAID-5 configuration for the physical drive of the databases. Make sure your disk controllers are equipped with error-correcting cache memory. If you plan to use write caching, ensure the cache memory is backed up by a battery. If you are not using RAID, consider implementing multiple storage groups and placing the transaction logs on separate physical drives. This will increase the system performance because ESE threads can then write transactions for separate storage groups to the transaction log files concurrently. If you are using RAID, place all drives within a single RAID volume to allow the RAID controller to read and write to multiple drives simultaneously.

Designing an Information Store Architecture for Adventure Works

Adventure Works, a fictitious Canadian travel agency, was introduced in Chapter 3. The company offers customized expeditions through North America and the Arctic Circle, as well as photographic safaris through South Africa and Australia. Adventure Works has fully deployed Exchange 2000 Server in their messaging environment. "On average, our Exchange 2000 servers host 500 mailboxes," says John Y. Chen, Senior IT Administrator at Adventure Works. "I don’t expect the database sizes to grow beyond the capacities of our backup systems, but we want to be able to restore the mailboxes of managers and supervisors before those of any other users to allow important persons to communicate quickly even after a total disaster. We also intend to create a public folder store for tourist-related newsgroups and replicate the information via NNTP within the Internet."

Chen planned the following general Information Store architecture for the servers of Adventure Works:

On the server that runs the NNTP service to replicate newsgroups with the Internet, we will configure two storage groups. We will place the NNTP service’s public folder store in the second storage group and activate circular logging. All other stores should belong to the other storage group, for which circular logging must be deactivated.
We need to create two separate mailbox stores in the default storage group and place the mailboxes of managers and supervisors in the first and the mailboxes of all other users in the second.
All of our servers must be equipped with five RAID drives—three RAID-1 drives for the system files, paging file, and transaction logs and two RAID-5 drives for the mailbox stores of managers and ordinary users.
On the NNTP server, we will implement one more RAID-5 drive and place the transaction logs and public folder store of the newsgroup store on it. Because the newsgroup data is not considered business-critical information, we will not separate the transaction logs from the database files and we will not include this store in our normal backup operations. We will back up this storage group on a monthly basis.

Activity: Designing Information Store Architectures

In this activity, you will design Information Store architectures for two companies that want to increase the reliability and performance of their mailbox and public folder servers. The companies are Consolidated Messenger, introduced in Chapter 1, and Woodgrove Bank, introduced in Chapter 3.

Tip

You can use Figure B.27 in Appendix B as a guideline to accomplish this activity.

Scenario: Consolidated Messenger

Consolidated Messenger, a broadcasting company with 1500 users at its headquarters in Portland, Oregon, and 200 users in a separate video department, has successfully deployed Exchange 2000 Server in all locations. "At first, we did not focus on sophisticated or fault-tolerant hard disk configurations," says Gregory J. Erickson, Senior IT Administrator at Consolidated Messenger, with a sad undertone. "We had equipped our server with four processors, one gigabyte of memory, and a large RAID-5 disk subsystem to properly support all 1500 users here at headquarters with a single server. However, we did not eliminate all possible single points of disk failure, and of course, according to Murphy’s law, it hit us right there. The hard disk of the operating system broke after just four weeks of operation. We were not prepared for this and didn’t have a spare disk on hand, so it took us more than two days to repair the system. Management is now demanding a system configuration that provides maximum fault tolerance for mass storage. Furthermore, we must be able to restore the resources of upper management and supervisors quickly and before any other users."

It is your task to design a fault-tolerant Information Store for Consolidated Messenger that meets the requirements of upper management:

Upper management of Consolidated Messenger has requested maximum fault tolerance for the hard disk subsystem of the Exchange 2000 server. You decide to separate the disks by operating system/system files, paging file, transaction logs, and databases. You intend to use RAID technology to eliminate single points of failure in the disk subsystem and provide the best possible fault tolerance. Which RAID technology should you use for the four separate disk drives?
The IT administrators at Consolidated Messenger must be able to restore the mailboxes of upper management and supervisors before the resources of any other users. How do you need to structure the mailbox store to achieve this without increasing system overhead?

Scenario: Woodgrove Bank

Woodgrove Bank, a Swiss bank, has successfully deployed Exchange 2000 Server in Switzerland. "We have placed all 600 users from Zurich, Bern, and Basel on a single server in Zurich," says Mr. Luis Bonifaz, Chief Information Officer at Woodgrove Bank. "What worries me is that this system may not provide the required level of fault tolerance. Problems might happen, of course, so we must think about options to increase the system’s resilience. We already have separated the mailbox resources and configured three individual stores in the default storage group according to the geographical location of the users. Perhaps there is a way to add more disks or reconfigure the existing disk sets to further increase fault tolerance. Our server should not lose messaging data even if more than one disk fails. We have the budget to acquire any necessary hardware." The current disk configuration of the server in Zurich is shown in Figure 10.6.

Figure 10.6 - The disk configuration of ZUR-01-EX

It is your task to identify options to increase the fault tolerance of ZUR-01-EX’s mailbox stores:

Bonifaz stated that the Exchange 2000 server should not lose messaging data even if more than one disk fails. How do you need to change the RAID configuration to achieve this goal, and what is the limit of this configuration?
How do you need to configure the database storage to minimize the impact of disk problems on the user community?

Lesson Summary

Exchange 2000 Server supports advanced hard disk configurations to accommodate thousands of users on a single system. Based on RAID technologies, multiple mailbox stores, and even multiple storage groups, you can build extremely powerful server machines. For best performance and fault tolerance, consider a sophisticated disk configuration based on RAID technology. If your hardware is sufficiently powerful, you can place operating system, paging file, transaction logs, and databases on a single RAID volume with multiple partitions. Microsoft recommends RAID-1 for operating system and system files, the paging file, and transaction logs and RAID-0+1 for the database drives. If a moderate level of performance and fault tolerance is acceptable, RAID-5 can be used instead of RAID-0+1 to cut costs. For storage groups that contain business-relevant data, always separate the transaction log files from the databases.

There are several reasons to split mailbox resources and separately place them in multiple mailbox stores. Multiple stores help to keep the individual size of databases small, which in turn allows for faster restores when disaster recovery is needed. Separate mailbox stores also allow you to implement priority services, for instance, for managers and supervisors in your company. You can plan different restore schedules for individual stores and dedicate individual stores to particular departments or virtual organizations. Placing additional stores in an existing storage group doesn’t increase the requirements and overhead for transaction logs because all databases in a single storage group share the same set of logs.

Implementing separate storage groups is only required if you need to create more than five mailbox stores or public folder stores, or if you want to implement different backup policies for individual information stores. Noncritical repositories, such as newsgroups, may be placed in a separate storage group and backed up less frequently than business-relevant data, such as user mailboxes. Among other things, you can activate circular logging for all stores in a particular noncritical storage group to automatically purge the transaction log files.