As a Microsoft Exchange Server 2003 administrator, one of your most important tasks is managing the information store. Each Exchange server deployed in an organization has an information store. The information store can contain storage groups, data stores, and databases. This chapter focuses on management of storage groups and databases. You’ll learn the following:
How to enable, create, and use storage groups
How to manage databases and their related transaction logs
Why you might want to enable full-text indexing of Exchange databases
How to manage indexing once it’s enabled
To learn how to manage data stores, see Chapter 10.
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. When Exchange Server is installed, the information store has a single storage group called First Storage Group. You can create additional storage groups as needed. Exchange Server 2003 Enterprise Edition is the most flexible. With the enterprise edition, you can create up to four additional storage groups as needed for a maximum of five storage groups per server (with one of the storage groups, called the recovery storage group, being reserved for database recovery operations).
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 and public folder stores. You create mailbox and public folder stores within storage groups, and each storage group can have multipledata stores.
An Exchange database is associated with each data store. You use Exchange databases to ease the administration burden that comes with managing large installations. For example, instead of having a single 100-GB database for the entire organization, you can create five 20-GB databases that you can manage more easily.
When you install a new Exchange server in an organization, two data stores are created automatically: a default mailbox store and a default public folder store. Two database files are associated with the default mailbox store:
Priv1.edb. A rich-text database file containing message headers, message text, and standard attachments
Priv1.stm. A streaming Internet content file containing audio, video, and other media that are formatted as streams of Multipurpose Internet Mail Extension Extensions (MIME) data
The default public folder store has two key files associated with it as well:
Pub1.edb. A rich-text database file containing message headers, message text, and standard attachments
Pub1.stm. A streaming Internet content file containing audio, video, and other media that are formatted as streams of MIME data
All Exchange databases have .edb and .stm files associated with them. When you create a mailbox or public folder store, you can specify the names for these files. By default, the .edb and .stm file names are the same as the name of the data store. For example, if you create a mailbox store called Administration and don’t change the default .edb and .stm file names, these files are called Administration.edb and Administration.stm, respectively.
Storage groups have files associated with them as well. These files can be placed into two categories: transaction log files and system files. Transaction log files include the following:
E##.log. The primary transaction log file for the storage group, where ## represents the storage group prefix. The first storage group has the prefix E00, meaning its primary log file is named E00.log; the second has the prefix E01, meaning its primary log is named E01.log; and so on.
E#######.log. Secondary transaction log files for the storage group, where each # represents a digit. The first and second digits in the transaction log file name are the prefix for the related storage group. The remaining digits are numbered sequentially. This means the first log file for the first storage group is named E0000001.log.
Res1.log. A reserved log file for the storage group. The reserve logs are 5 MB each, and they act as a buffer to allow Exchange Server to continue writing transactions when the disk drive is out of space. These files are important because they buy you time to free up disk space without interrupting service. They should never be deleted.
Res2.log. A reserved log file for the storage group.
System files include the following:
E##.chk. A check file containing recovered file fragment, where ## represents the storage group prefix
Tmp.edb. A temporary workspace for processing transactions
Note
In this section, I’ve listed the standard Exchange files. Depending on the state of Exchange Server, you might see other files as well. For example, sequentially numbered files with the .stf file extension are used when writing message attachments into the database. You’ll see files with the name 1.stf, 2.stf, and so on. When Exchange Server is creating a new log file, you’ll see a file called Edbtmp.log. This file is the template from which Exchange Server creates log files.
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 9-1, which outline some ways that small, medium, and large organizations could configure Exchange Server based on performance needs.
Table 9-1. Configuring Exchange Data Files for Small, Medium, and Large Organizations
Organization Size | Performance Needs | Storage Groups | Recommendation |
|---|---|---|---|
Small | Low | 1 | Place all data files on the same drive. Consider using redundant array of independent disks (RAID) 1 or RAID 5 to protect the data. |
High | 1 | 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 | 1 | 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 | 1; multiple | 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 | Multiple | 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 | Multiple | 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 | Multiple | 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 the drive in case of failure. Place system files for each storage group on separate drives. |
Note
The scenarios outlined in Table 9-1 don’t take into account the use of virtual servers. Virtual servers also provide a way to balance Exchange Server loads and improve performance. For more information on virtual servers and how you can use them to grow an organization, see Part IV.
You can use storage groups to manage Exchange Server 2003 backup and recovery more effectively as well. 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 as well.
You can create a storage group by completing the following steps:
In System Manager, access the Servers node within the administrative or routing group you want to manage. Typically, you would expand Administrative Groups, then First Administrative Group, and then the Servers node.
In the left pane (the console tree), right-click the Exchange server you want to manage, and then select New, Storage Group from the shortcut menu. You should now see the Properties dialog box shown in Figure 9-1.
In the Name field, type a descriptive name for the storage group. If you want to follow the default naming convention, name each storage group in sequence, as in First Storage Group, Second Storage Group, Third Storage Group, and so on.
Click Browse to the right of the Transaction Log Location field, and then select a location for the transaction logs. You can’t store files for additional storage groups in the same directory in which you have an existing storage group.
Tip
Each storage group has its own set of transaction logs. These logs are used to perform transactional processing within Exchange Server. To improve performance, you could place each set of transaction logs on a physically separate drive, and the number of transaction log drives should equal the number of storage groups you’re using. For example, if a server uses two storage groups, the server should have two transaction log drives. To protect transaction log drives against failure, you should mirror them as well. RAID 1 (disk mirroring) is recommended over RAID 5 (disk striping with parity) because you’ll have better write performance with RAID 1 in most instances—and the transaction log drives are written too frequently on busy servers.
Click Browse to the right of the System Path Location field and then select a location for the system files that the storage group will use.
Click OK to create the storage group. You can now add mailbox and public folder stores to the storage group.
As discussed earlier, the transaction log location and system path have an important role in managing Exchange Server performance. The transaction log location determines where primary, secondary, and reserved log files are stored. The system path determines where check files are stored and where temporary transactions are processed.
You can change the transaction log location and system path for an existing storage group by completing the following steps:
In System Manager, click the plus sign (+) next to the Exchange server you want to manage. Typically, you would expand Administrative Groups, then First Administrative Group, and then the Servers node.
You should see a list of storage groups that are available on the server. Right-click the storage group you want to change, and then select Properties from the shortcut menu. You should now see the Properties dialog box shown in Figure 9-2.
Click Browse to the right of the Transaction Log Location field, and then select a new location for the storage group’s transaction logs.
Click Browse to the right of the System Path Location field, and then select a new location for the storage group’s system files. The folder location must already exist. If the folder location doesn’t exist, you’ll need to create it in Windows Explorer or by clicking New Folder in the Browse window. If you don’t place the system files on a separate drive, you should place them on the same drive as the transaction logs.
Click OK.
Databases read and write information in pages. Each time Exchange Server needs to increase the size of a database, it does so by creating new data pages and then filling those pages with information. Zeroing out deleted database pages (rather than removing them) allows Exchange Server to reuse previously created data pages. By zeroing out deleted pages, you can realize a slight performance enhancement in an environment in which old data is frequently being deleted and new data is frequently being stored in the database.
You control the zeroing out of database pages at the storage group level. Each storage group can have a different policy for zeroing out deleted database pages. To enable or disable zeroing out of database pages, complete the following steps:
In System Manager, click the plus sign (+) next to the Exchange server you want to manage. Typically, you would expand Administrative Groups, then First Administrative Group, and then the Servers node.
Right-click the storage group you want to change, and then select Properties from the shortcut menu.
Select or clear the Zero Out Deleted Database Pages check box as appropriate, and then click OK.
Circular logging allows Exchange Server to overwrite transaction log files after the data they contain has been committed to the database. Overwriting old transactions reduces the disk space requirements for Exchange Server, yet makes it impossible to recover Exchange Server up to the last transaction. If circular logging is enabled, you can recover Exchange Server only up to the last full backup.
You control circular logging at the storage group level, which allows each storage group to have a different policy for logging. To enable or disable circular logging, complete the following steps:
In System Manager, click the plus sign (+) next to the Exchange server you want to manage. Typically, you would expand Administrative Groups, then First Administrative Group, and then the Servers node.
Right-click the storage group you want to change, and then select Properties from the shortcut menu.
Select or clear the Enable Circular Logging check box as appropriate, and then click OK.
Caution
If you enable circular logging, you are limiting your recovery options for Exchange Server. As mentioned previously, you will only be able to recover Exchange Server up to the last full backup. Thus, you won’t be able to successfully apply changes contained in differential or incremental backups that were created after the last full backup.
Renaming storage groups is simple. Right-click the storage group, select Rename from the shortcut menu, and then enter a new name for the storage group. What you don’t see are the repercussions of renaming, and this is what you need to be aware of.
All objects in Active Directory are located by a unique identifier that uses the directory namespace and works through each element in the directory hierarchy to a particular object. When you change the name of a storage group, you change the namespace for all the objects in that storage group, which includes databases, data stores, mailboxes, and more. Thus, the simple act of renaming a storage group has a definite impact on Exchange Server.
Before attempting to delete a storage group, you must delete or move the data stores it contains. Exchange Server allows you to delete storage groups only when they are empty (that is, only when they contain no data stores).
Once the storage group is empty, right-click the storage group and then select Delete from the shortcut menu to remove it. When prompted, confirm the action by clicking Yes.
Content indexing is a built-in Exchange feature. Every Exchange server in your organization supports and uses some type of indexing. To manage indexing more effectively, use the techniques discussed in this section.
Content indexing enables fast searches and lookups through server-stored mailboxes and public folders. Exchange Server supports two types of indexing:
Standard indexing
Full-text indexing
The Exchange Server storage engine automatically implements and manages standard indexing. Standard indexing is used with searches for common key fields such as message subjects. Users take advantage of standard indexing every time they use the Find feature in Microsoft Office Outlook. With server-based mail folders, standard indexing is used to quickly search To, Cc, and Subject fields. With public folders, standard indexing is used to quickly search From and Subject fields.
As you probably know, users can perform advanced searches in Outlook as well. In Outlook, all they need to do is select the Advanced Find option from the Tools menu, enter their advanced search parameters, and then click Find Now. When Exchange Server receives an advanced query without full-text indexing, Exchange Server searches through every message in every folder. This means that as Exchange mailboxes and public folders grow, so does the time it takes to complete an advanced search. With standard searching, Exchange Server is unable to search through message attachments.
With full-text indexing, Exchange Server builds an index of all searchable text in a particular mailbox or public folder store before users try to search. The index can then be updated or rebuilt at a predefined interval. Then when users perform advanced searches, they can quickly find any text within a document or attachment.
Note
Full-text indexes work only with server-based data. If users have personal folders, Exchange Server doesn’t index the data in these folders.
The drawback of full-text indexing is that it’s resource-intensive. As with any database, creating and maintaining indexes requires CPU time and system memory, which can affect Exchange performance. Full-text indexes also use disk space. A newly created index uses approximately 20 percent of the total size of the Exchange database. This means that a 1-GB database would have an index of about 200 MB.
Each time you update an index, the file space that the index uses increases. Don’t worry; only changes in the database are stored in the index updates. This means that the additional disk space usage is incremental. For example, if the original 1-GB database grew by 50 MB, the index would use about 210 MB of disk space (200 MB for the original index and 10 MB for the update).
As an administrator, you have fairly granular control over indexing. You set the maintenance schedule and determine the indexing priority. By scheduling maintenance during off-peak hours, you can reduce the impact on operations. By lowering the indexing priority, you can restrict the level of system resource usage.
System resources, such as CPU time and memory, are used every time Exchange Server builds, updates, or re-creates an index. The level of resource usage is completely configurable and is determined by the indexing priority set for the server’s information store. There is a direct trade-off between the indexing priority and the time it takes to complete an index. The higher the priority, the more system resources are used and the less time is required for creating an index. The lower the priority, the fewer system resources are used and the more time is required for creating an index.
Each Exchange server has its own indexing priority setting. You can view or change the indexing priority by completing the following steps:
In System Manager, access the Servers node within the administrative or routing group you want to manage. Typically, you would expand Administrative Groups, then First Administrative Group, and then the Servers node.
Right-click the Exchange server you want to manage, and then select Properties from the shortcut menu.
As shown in Figure 9-3, use the System Resource Usage drop-down list on the Full-Text Indexing tab to set the indexing priority. The available values are as follows:
Minimum. Sets the indexing priority to its lowest value, which has the least impact on system resources. The downside is that this setting requires the most time to index and reindex content.
Low. Sets the indexing priority to low. This reduces the impact on system resources while maintaining a fairly adequate indexing speed.
High. Sets the indexing priority to high, which has modest impact on system resources while achieving good indexing speed. This setting is the default.
Maximum. Sets the indexing priority to its highest value. Although this greatly increases the impact on system resources, Exchange Server is able to index and reindex content in much less time.
Click OK.
You can create full-text indexes for both mailbox stores and public folder stores. With mailbox stores, the full-text index is based on all text in message bodies and message attachments. With public folders, the full-text index is based on all text in postings and attachments to postings. Data in personal folders isn’t included in the full-text index generated by Exchange Server.
You can create a full-text index for a mailbox or public folder store by completing the following steps:
In System Manager, work your way down to the storage group that contains the mailbox or public folder store you want to work with. Typically, you would do this by expanding the server node and then the storage group node.
Right-click the mailbox or public folder store that you want to index, and then select Create Full-Text Index from the shortcut menu.
Type the folder location for the index files. If the folder location doesn’t exist, Exchange Server will create the folder.
When you click OK, Exchange Server creates the index. The index will be about one-fifth of the size of the original data store, so you’ll need to use a folder on a drive with plenty of free space.
You can update or rebuild an index manually at any time. Exchange Server updates an index by making note of any changes to the data store and then indexing those changes. Exchange Server rebuilds an index by re-creating it. This means that Exchange Server takes a new snapshot of the database and uses this snapshot to build the index from scratch.
To manually update or rebuild an index, follow these steps:
In System Manager, work your way down to the storage group that contains the mailbox or public folder store you want to work with. Typically, you would do this by expanding the server node and then the storage group node.
Right-click the mailbox or public folder store that you want to work with.
To update an existing index, select Start Incremental Population. (This option is also available on the All Tasks shortcut menu.) Confirm the action by clicking Yes.
To rebuild an index, select Start Full Population. (This option is also available on the All Tasks shortcut menu.) Confirm the action by clicking Yes.
During the updating or rebuilding process, you can pause or stop the indexing. A key reason to pause the process is to allow Exchange Server to perform other tasks. A key reason to stop indexing is to postpone the update or rebuild.
You can pause and then resume in-process indexing by completing the following steps:
In System Manager, work your way down to the storage group that contains the mailbox or public folder store you want to work with. Typically, you would do this by expanding the server node and then the storage group node.
Right-click a mailbox or public folder store that is actively being indexed and select Pause Population. (This option is also available on the All Tasks shortcut menu.)
When you’re ready to resume indexing the population, right-click the mailbox or public folder store, and then select Resume Population.
To stop in-process indexing, complete these steps:
In System Manager, work your way down to the storage group that contains the mailbox or public folder store you want to work with. Typically, you would do this by expanding the server node and then the storage group node.
Right-click a mailbox or public folder store that is in the process of full-text indexing, and select Stop Population. (This option is also available on the All Tasks shortcut menu.)
Confirm the action by clicking Yes.
You can configure Exchange Server to automatically update full-text indexes and to allow clients, such as Outlook users, to search the indexes. You configure these processes separately for each data store by completing these steps:
In System Manager, work your way down to the storage group that contains the mailbox or public folder store you want to work with. Typically, you would do this by expanding the server node and then the storage group node.
Right-click a mailbox or public folder store that you want to configure and then select Properties. In the Properties dialog box, click the Full-Text Indexing tab, as shown in Figure 9-4.
Use the Update Interval drop-down list to choose how often the indexes should be updated.
Usually, you will want to update the index daily at a specific time rather than updating the index every hour or continuously as changes are made. With this in mind, you could select one of the run daily options, such as Run Daily At 1:00 AM.
If you want to set a custom schedule, click Customize. You can then use the Schedule dialog box to set the times when Exchange Server should make updates. In this dialog box, you can set the detail of the view to be in hourly or 15-minute intervals. Each hour or 15- minute interval of the day or night is a field that you can turn on and off. Intervals where updates should occur are filled in with a dark bar—you can think of these intervals as being turned on. Intervals where updates shouldn’t occur are blank—you can think of these intervals as being turned off. To change the setting for an interval, click it to toggle its mode (either on or off).
Select the This Index Is Currently Available For Searching By Clients check box, and then click OK.
If you’ve configured full-text indexing and users are still unable to search on text in a data store, you might have a corrupt index. In this case, you might want to disable the index, rebuild it during off-peak hours, and then make the index available to users again. You can do this by completing the following steps:
In System Manager, work your way down to the storage group that contains the mailbox or public folder store you want to work with. Typically, you would do this by expanding the server node and then the storage group node.
Right-click a mailbox or public folder store that you want to configure, and then select Properties. In the Properties dialog box, click the Full-Text Indexing tab.
Set the Update Interval selection menu to Never Run.
Clear the This Index Is Currently Available For Searching By Clients check box.
Click OK. After the index is rebuilt, restore the data store properties to their original settings.
Exchange Server 2003 tracks fairly detailed information on each full-text index. You can access and use this information by completing the following steps:
In System Manager, work your way down to the storage group that contains the mailbox or public folder store you want to work with. Typically, you would do this by expanding the server node and then the storage group node.
Click the plus sign (+) next to the mailbox or public folder store on which you want to view indexing statistics, and then select the Full-Text Indexing node.
In the right pane, you should see the following indexing statistics:
Index State. The full-text indexing status for the data store. States you could see include: Idle (the data store isn’t being indexed), Crawling (Exchange Server is actively indexing the data store), and Paused (the indexing has been paused by an administrator).
Number Of Documents Indexed. The total number of documents indexed.
Index Size (MB). The size of the index in megabytes.
Tip
If the number of documents indexed or the index size seems inaccurate, you might have a corrupt index. To resolve this, rebuild the index.
Last Build Time. The date and time stamp for the last manual or automatic build of the index. If no index exists, you’ll see the message "There is no full-text index for this store." If the index is newly created and hasn’t been updated or rebuilt, you’ll see the message "This catalog was never built."
Index Name. The name of the index. You’ll find a folder with this name at the location specified by Index Location. All index files within this folder begin with this identifier as well.
Index Location. The folder location of the index files.
Once you’ve started full-text indexing, Exchange Server doesn’t allow you to change the index file location. A workaround is to stop indexing, delete the fulltext index on the data store, and then re-create the index in a new location.
To delete indexes and stop data store indexing, complete the following steps:
In System Manager, work your way down to the storage group that contains the mailbox or public folder store you want to work with. Typically, you would do this by expanding the server node and then the storage group node.
Right-click a mailbox or public folder store that is currently being indexed, and select Delete Full-Text Index. (This option is also available on the All Tasks shortcut menu.)
Confirm the action by clicking Yes.
When you delete the full-text index for a data store, you remove the index catalog files and stop indexing. No scheduled updates or rebuilds will be made afterward.