5.1 Configuring Outlook Web Access | Monitoring and Managing Microsoft Exchange 2000 Server (HP Technologies)

Chapter 5 - Managing Exchange Servers
Monitoring and Managing Microsoft Exchange 2000 Server
by Mike Daugherty
Digital Press 2001

5.3 Managing the Information Store

Microsoft has significantly enhanced the Information Store for Exchange 2000. The first and least important change is nomenclature . The Exchange Information Store is now often referred to as the Web Store . Although the name change occurred largely for marketing purposes, it is based on very real technology enhancements. There are three key Information Store technology changes for Exchange 2000:

The Information Store has been redesigned to handle streaming content.
The Information Store can be partitioned into multiple storage groups and multiple databases.
Information Store access has been expanded to allow non-messaging clients to easily store, retrieve, and manage documents, as well as store streaming data such as audio and video.

The Exchange 2000 Information Storea.k.a Web Storeis intended to be the core technology for integrating knowledge sources by providing a single repository for managing not only e-mail messages but documents, Web pages, calendar information, contact information, voice mail, and other object types in a common infrastructure. It supports a variety of Application Programming Interfaces (APIs), protocols, and file formats to facilitate use by a wide range of other applications.

5.3.1 Information Store architecture

The Exchange 2000 Information Store includes several components as shown in Figure 5.6. The key components are:

Internet Information Server (IIS) Front End . The IIS servers are dedicated to the task of handling incoming connections for clients using the Internet protocols.
Protocol Stubs . These provide support for Internet protocols such as IMAP, POP3, SMTP, NNTP, HTTP, and WebDAV.
EDB Files . The PRIV.EDB and PUB.EDB databases containing the Exchange private and public folders.
STM Files . The streaming files (.STM) are the repositories for rich MIME content from clients using standard Internet protocols such as HTTP and IMAP4. Streaming files can contain audio, video, voice, or other multimedia formats as streams of MIME data.

Figure 5.6: Exchange 2000 information store architecture
Extensible Storage Engine (ESE) . The underlying database engine for Exchange 2000 and for the Active Directory. To ensure the integrity of the database, ESE uses discrete, individual transactions that are recorded in log files. ESE is an improved version of the Joint Engine Technology (JET) database used with Exchange 5.5.
Exchange Installable File System (IFS) . IFS is a file system interface to the Web Store that supports Win32 interfaces such as CreateFile, ReadFile, and WriteFile. This allows applications to access Web Store data in the same way that they access files on a file share.

The key technology enhancements and Information Store components are discussed in the following sections.

Streaming file (.STM)

The data format of a typical e-mail message is changing rapidly . In the past, plain text was the norm, with rich text used in only limited cases. Today, rich text has become the norm, and an increasing number of messages are being sent with very large audio and voice components. These multimedia formats will place new requirements on messaging systems as the formats become more common. Exchange 2000 Server supports these changes by moving to MIME content as the native format.

Microsoft introduced the new streaming file (.STM) to hold rich MIME content from clients using standard Internet protocols such as HTTP and IMAP4. Streaming files can contain audio, video, voice, or other multimedia formats as streams of MIME data. To improve performance and to eliminate the potential for data or format corruption, all of this content, including the multimedia content, is kept in its native format (i.e., it is not converted before being stored). Only the header information is stored in the PRIV.EDB or PUB.EDB databases.

Clients that understand these formats can quickly access the data through file streaming interfaces, increasing the performance and scalability of the system. Conversion is required only when a MAPI client needs access to the data in the streaming file. At that time, the data is converted and passed to the MAPI client. (This process is often referred to as deferred content conversion .) If the MAPI client only reads the object, no permanent change is made to the format of the stored object. The next time a MAPI client access the same object, the data will once again be converted to MAPI format. However, if the MAPI client modifies object attributes, the object is converted to MAPI format and restored in the .EDB database.

The streaming file natively supports Internet protocols and file formats so that end users can use any Internet client to find and retrieve information. This includes support for Simple Mail Transport Protocol (SMTP), Post Office Protocol (POP), Internet Mail Access Protocol (IMAP), Network News Transport Protocol (NNTP), HyperText Transfer Protocol (HTTP), and HyperText Markup Language (HTML).

Microsoft has also introduced a set of HTTP extensions for Distributed Authoring and Versioning (DAV) known as WebDAV. WebDAV is an Internet Engineering Task Force (IETF) draft standard extension of HTTP 1.1 that allows any HTTP client to have read and write access to the information store. To this, Microsoft has added the following extensions:

Access control . Supports Windows 2000 security.
Notifications . Supports sending messages to the client.
Replication . Provides client/server synchronization to support offline usage.
Transactions . Adds support for commit and rollback.
Distributed Authoring Search and Location (DASL) . Adds search functionality to allow for persistent searches, row ranges, and SQL.
Structured documents . Adds support for documents with multiple members , such as MIME Multipart or Web pages with images.
Versioning . Adds support for check in and check out, other versioning properties, and earlier revisions of information.

PRIV.EDB and PUB.EDB

Exchange 5.5 stored all data regardless of the original format as a set of MAPI properties in the rich-text .EDB database. For example, MIME messages coming from the Internet were always converted before being stored into the database. When a non-MAPI client accessed the message, it was converted to the format used by that client.

With Exchange 2000, only messages originating from MAPI clients are stored in the .EDB databases. All non-MAPI formats are stored in the streaming file with only the header information kept in the .EDB database.

Information Store and front-end/back-end servers

Exchange 2000 depends on the Microsoft Internet Information Server (IIS) to manage access to the Information Store by clients using Internet protocols such as POP3, IMAP4, NNTP, and HTTP. (The Information Store still manages access by MAPI clients.) The separation of the Internet protocol support from the Information Store and the use of IIS make it possible to deploy separate hardware platforms for the protocol support and the database access. The Internet protocol servers are dedicated to the task of handling incoming client connections (including client authentication), while the Information Store is focused on managing the database. These type of front-end/back-end configurations enhance scalability and can provide a degree of fault tolerance if you set up multiple front-end servers for each protocol.

Information Store access

The architectural changes, the support for new protocols, the use of IIS, and the introduction of the Exchange Installable File System (IFS) have all combined to greatly increase the number and type of clients that can access the Information Store. With support for multiple Windows and Internet clients, the Information Store can become a common repository for storing and managing documents. Multiple types of documents can be in the same folder for access by any clients.

Clients using Internet protocols such as SMTP, POP, IMAP, NNTP, and HHTP access the Information Store via the Microsoft Internet Information Server (IIS). This process is shown graphically in Figure 5.7 and is described in the following steps.

Figure 5.7: Internet protocol access to information store

The Internet protocol client connects to the IIS front-end server.
The front-end server queries the Active Directory to authenticate the user and to retrieve the user s mailbox location.
The Active Directory returns the users mailbox location, including the storage group name, database name, server IP name, and server IP address.
IIS communicates with the Information Store to create the users message (or document) in the users mailbox. Using the Extensible Storage Engine, the Information Store performs the following tasks .
- Obtains a file handle for retrieving or storing the information in the .STM file. The Exchange Installable File System (IFS) will use this file handle to access information stored in the .STM file.
- Creates an entry in the EDB database file describing the message. This entry includes a minimal set of properties, such as the recipient name, subject line, and date. (These, or other properties, may actually be pointers into the .STM file, to avoid duplicating information.)
The Information Store returns the file handle to the IIS service.
The IIS service uses standard Win32 API calls available from the Exchange Installable File System (IFS) to store the message to the location pointed by the file handle.
The Exchange IFS writes the message into the .STM file.

As with previous versions of Exchange, MAPI clients communicate directly with the Information Store. The Information Store sends a query to the Active Directory to authenticate the user. WebDAV also submits messages directly to the Information Store, at which point the submitted messages are processed the same as MAPI submissions.

The Exchange Installable File System (IFS) is a Win32 file system interface to the Information Store. IFS supports the same, standard Win32 calls (e.g., CreateFile, ReadFile and WriteFile) that developers use to read and write data to any Windows file system. Thus, any existing program that provides access to Windows files can access the Exchange Information Store without the program developers having to add new code. Since Exchange Information Store folders and files can be access in the same manner as other files, they can also be shared on a network file server by using a Net Share or Net Use command.

To users, the primary advantage of IFS is that they have direct access to private mailboxes or public folders using the same familiar Windows-based tools that they use to access other files. For example, you can use the standard Office 2000 File Open menu to access files from the Exchange Information Store. Of course, access to Information Store files is subject to the same permissions and access rights that control access to other Windows directories and files.

The Exchange Information Store is accessible through drive M:\. The folder hierarchy for the M:\ drive is shown in Figure 5.8. The mailbox folders, public folders, and contents can be viewed or accessed only by users with the appropriate permissions. Users with appropriate permissions can map a local share to any folder or mailbox in the hierarchy.

Figure 5.8: M drive hierarchy

The MBX folder is the root directory for all private mailboxes on the Exchange server. Each user is listed as a subdirectory under the MBX folder. A file with an .EML file extension represents each e-mail message.

The PUBLIC FOLDERS folder is the root directory for all public folders. The public folders themselves each have a subdirectory under the PUBLIC FOLDER directory.

A key feature of the Web Store is that each folder and each item in the store has a unique, readable Uniform Resource Locator (URL) and can be accessed using any Internet browser. No special code is needed to access items in the Information Store.

Exchange installs two virtual servers called Exchange (for private information stores) and Public (for public information stores). Any Web browser can access a document in a users inbox by using the following URL:

http:// server /Exchange/ user /Inbox/ document

where

server is the name of the Exchange server.

user is the users mailbox name.

document is the name of the document. (Remember that e-mail messages have a file extension of .EML.)

For example, the following URL can be used to access the e-mail message with the subject line of Test message in John Does Inbox on the ExSvr01 Exchange server:

http://ExSvr01/Exchange/John.Doe/Inbox/Test message.eml

Because an items URL includes the server name and folder name, the URL will change if the item is moved to another folder.

In a similar manner, any Web browser can access a document stored in a public folder by using the following URL:

http://server/public/folder/document

where

server is the name of the Exchange server.

folder is the name of the Exchange public folder.

document is the name of the document.

Web pages stored in the Information Store can include HTML and ASP content. They can also contain Exchange-specific functionality such as calendars and contacts.

Full content indexing

Exchange 2000 includes the capability to fully index the content of common key fields for all Information Store objects. This includes indexing every word in message subject text, message body text, and all attachments. This improves the retrieval time for Information Store searches.

Of course, full content indexing does not come free. It increases the disk space requirements by about 20% of the database size and requires considerable processing cycles to create and maintain the index. Both disk space and processing time are directly related to the amount of data being indexed. In most cases, you should schedule index builds for times when the server will be under a relatively light load. Indexing is performed at the database level and using multiple small databases rather than a single large database can lessen the impact.

5.3.2 Information Store partitioning

The Exchange 2000 Information Store can be partitioned, and this partitioning can significantly improve scalability and availability. These changes will influence Exchange organizational designs and will affect how Exchange is managed once it is deployed. Each Exchange 5.5 server was limited to a single large private database (priv.edb) containing the mailboxes for all users and a single public database (pub.edb) for public folders. The size of the private information store grew in direct relationship with the number of users and the number of messages retained by these users. The resulting private information storestored as a single Windows NT file could easily reach many gigabytes in size spanning multiple physical disks. The most significant problem caused by the large size was the increased amount of time required to restore the file from backup tapes should it be corrupted. This in turn had a direct negative affect on service downtime, Service Level Agreement compliance, and user satisfaction.

Exchange 2000 solves this problem by allowing the Information Store to be partitioned. Information Store partitioning is achieved through the introduction of Storage Groups. See Figure 5.9.

Figure 5.9: Exchange Information Store architecture

With Exchange 2000, each Exchange server can be partitioned into up to four Storage Groups. Each Storage Group is managed by a separate instance of the Extensible Storage Engine (ESE). All ESE instances on a server are managed by a single instance of the store.exe process.

Each of the Storage Groups can have up to five private or public database sets, with all database sets in the Storage Group sharing a common set of transaction log files. This provides a theoretical limit of 20 databases (four Storage Groups, each with five databases) per server. Each of these database sets actually includes two files:

An EBD file similar to those found in Exchange 5.5
An STM file that stores messages submitted by Internet clients (e.g., HTTP, SMTP, NNTP, POP, or IMAP) in their native format

Exchange databases can now be smaller and can be restored more quickly.

The changes to the information store influence both the placement of user mailboxes and the backup and recovery strategy for Exchange 2000. An updated backup utility that understands and takes advantage of the new Information Store architecture is included with Exchange 2000.

The ability to distribute the Information Storage across multiple physical databases provides a number of administrative advantages. For example, you can arrange mailboxes on multiple private databases to increase manageability. The total Information Store can continue to grow as you add new users without any of individual databases growing to an uncontrollable size.

From a backup and recovery perspective, each of the individual databases is independent. A database can be mounted or dismounted at any time for administration. This reduces the amount of data that needs to be recovered if a disk drive should fail. The amount of data to be recovered has a direct relationship to the recovery time, and thus, to the user impact. The overall user impact is also reduced because the failed database can be restored while other databases remain operational.

The ability to partition the Information Store provides you with many possibilities for distributing users (and their data) across multiple Storage Groups and/or databases within Storage Groups. For example, you could partition users by their importance within the company, such as putting all of the executives in their own database. This allows you to independently set the content indexing, data retention settings, storage limits, and other configuration parameters for this critical group. If this executive database is kept small, then it could be quickly restored, minimizing downtime.

It is still important to segregate the partitioned databases on different physical volumes . Partitioning without careful planning on the physical database placement will not provide the desired reduction of affect by a single disk failure.

Transaction logging

The Exchange 2000 Information Store uses write-ahead transaction logging to ensure data integrity and consistency. Transactions are first written to memory, then written to a log file, and finally written (or committed) to the Information Store database.

If a disk controller or disk drive failure causes one of the Exchange databases to be destroyed , it can be recovered without loss of data using a combination of the most recent database backup and the transaction logs. Of course, this assumes that your transaction logs are available. I have known some administrators who mistakenly believed the transaction logs were less important than the database files. While they protected the database files using RAID technology, the transaction logs were left unprotected . This was fine, until it came time to recover data. At that point, these administrators discovered that the transaction logs are criticaleven more critical than the database itself. The most recent backup plus the current transaction logs can be used to completely restore the database. However, if the transaction logs are lost, all database changes since the last backup will be lost. Because the transaction logs are critical to the operation of the Exchange Server, they should be protected using RAID-1 (mirroring).

Each Storage Group has its own set of transaction logs that are shared by all databases within the Storage Group. Although it is possible to configure the system to have the transaction logs for all Storage Groups on a common disk drive, the system performance would be significantly impacted. For best performance, the transaction logs for each storage group should be placed on separate disk drives .

In addition, the transaction logs should never be placed on the same disk drive as the database. If the drive fails, you will lose both the current database and the transaction logs required to rebuild the database from the previous days backup tape. Putting the transaction logs on a separate disk drive also improves performance.

All database changes since the last backup are kept in the transaction logs. Exchange 2000 reserves 5 MB for each log file. A new log file is created once the existing one becomes full. Eventually, the transaction logs will grow to a very large size. If the disk becomes full, you will no longer be able to access the Information Store. There are two methods available to keep the transaction logs at a reasonable size, but only one method is useful in a real production environment.

Circular logging . Circular logging overwrites transaction log files after the data they contain has been committed to the database. Unlike Exchange 5.5, circular logging is disabled by default in Exchange 2000for good reason. With circular logging enabled, you can restore information only to the last full backup. You would not be able to recover any information written to the database since the last full backup was performed. Circular logging should never be enabled in a production environment.
Periodic full backups . When you back up the databases using Exchange-aware backup software, the transaction logs are archived and then deleted, freeing up the disk space. This is the appropriate method for managing transaction log disk space.

The only maintenance that needs to be done on the transaction logs is to perform regular backups. It is possible to back up any storage group or database at any time without affecting the other storage groups or databases. However, backing up at the database level rather than at the storage group level does not capture the associated transaction logs. It is recommended that you back up storage groups rather than individual databases since this automatically backs up the correct transaction log files.

Note	Even though all databases within a storage group share a common set of transaction logs, each transaction is marked with a database instance ID so you can recover individual databases.

Single instance store with multiple partitions

With the introduction of multiple storage groups and multiple databases, the single instance store concept needs further clarification . Single instance store was supported in Exchange 5.5 and continues to be supported with Exchange 2000. With Exchange 5.5, when an e-mail message is sent to multiple mailboxes on the same system, only one copy of the message is actually stored in the Information Store.

With Exchange 2000, the single-instance store is used when an e-mail message is sent to multiple mailboxes that are in the same database. If the mailboxes are in different databases, then one copy of the message is stored within each database. If the databases are in different storage groups, then the message is added to each database as well as the transaction log for each storage group. Typical savings due to the single instance storage can often be minimal. You should estimate your expected savings to determine if single instance store warrants using a single database.

Storage groups and clustering

The Exchange 2000 Information Store is a key consideration if you are running Exchange on a cluster. A cluster is a set of independent systems, known as nodes , working together as a single system to ensure that critical resources and applications will continue to be available even if one of the nodes experiences a failure. At the system level, the Information Store fully supports Windows 2000 active/active clustering. When one system in a cluster experiences a failure, the Information Store services on one of the other cluster nodes can accept control over the storage groups on the failed system. The transfer of control from one system to another is seamless and should be invisible to users.

Exchange support for clusters was introduced with Exchange Server 5.5 Enterprise Edition. However, this support was only for active-passive cluster configurations, meaning that Exchange could be running on only one cluster node (the active system) at a time while the other node (the passive system) remained idle waiting for a failure. Exchange 2000 supports activeactive clustering available with Windows 2000 Advanced Server, meaning that none of the cluster nodes needs to be sitting idle waiting for other nodes to fail.

For Exchange, the unit of fail over in a cluster is the storage group . You can configure fail over preferences for the storage groups so that if one cluster node fails, the storage groups on the failed node will be distributed to the remaining cluster nodes. The databases and transaction logs associated with the storage group are preserved with no loss of data.

One strategy for distributing storage groups in a cluster is to base the number of storage groups on each node on the number of nodes in the cluster. If you have x nodes in the cluster, you should have a multiple of x 1 storage groups on each node. For example, if you have a four-node cluster, then each of the four nodes would have three storage groups. If one of the nodes should fail, responsibility for the three storage groups on the failed node could be evenly distributed to the remaining three nodes in the cluster. Each of the remaining active nodes would then be running four storage groups.

While Exchange 2000 supports active-active configurations, it is important that the nodes in a cluster not be running at their maximum capacity. Each system should have enough processing power available to accept the increased load if one of the cluster nodes should fail. In general, the load on the cluster nodes should not exceed 100% (100%/ x ) where x is the number of nodes in the cluster. For example, servers in a four-way cluster should always run at less than 75% load (100% (100%/4)); servers in a three-way cluster should always run at less than 66% load; and servers in a two-way cluster should always run at less than 50% load.

Planning considerations

Exchange 2000 provides considerable Information Store flexibility, but this can also cause confusion. This is especially true when you try to decide if you should implement multiple storage groups and/or multiple databases. The following guidelines should help.

You should consider implementing multiple databases in the following situations:

You want to reduce recovery times . Reducing recovery time is generally very important and this will usually be the primary reason for implementing multiple databases. Database size has a direct impact on the time required to restore the database. If you currently have a large multiple-gigabyte database, divide it into separate databases to reduce recovery time.
You want to support more mailboxes on a single server . With Exchange 5.5, the factor that most often limited the number of mailboxes you could safely place on a single server was the database recovery time. Because multiple small databases can be restored faster than a single large database, you can potentially increase the number of users on an Exchange 2000 server.
You want to separate departments, project teams , or executives . Different groups sometimes have different requirements, such as availability or recovery time. You should remember that placing groups of users in separate databases impacts single instance message store, so users who frequently correspond with each other should all be kept in the same database as much as possible.
You want to isolate large public folder applications . These applications may have different administrative requirements.
You want to isolate databases requiring full content indexing . Full content indexing increases the administrative and hardware requirements. If a subset of your users requires full content indexing, you can isolate them in their own database.

You should consider implementing multiple storage groups in the following situations:

You want to separate multiple companies or corporate divisions . Each company or division can have its own storage group, databases, transaction log files, public folders, and administrative policies.
You want to separate databases that have differing backup requirements . You may have different backup schedules for different sets of mailboxes or public folders. Since it is best to perform backups at the storage group level, you should use different storage groups to match these requirements.
You want to enable circular logging for some databases . Circular logging should be disabled in almost all cases. However, there may be certain mailboxes or public folders such as NNTP servers where data recovery is not essential. Since circular logging is enabled at the storage group level, you should implement a separate storage group for those databases that will use circular logging.
You want to run Exchange in a cluster . For Exchange, the unit of fail over in a cluster is the storage group.
You want to have more than five databases . If your current storage group already has five databases, then you must create a new storage group to add the sixth database.

5.3.3 Creating a new storage group

A storage group contains up to five databases and an associated set of transaction logs. A storage group is the best unit of backup, because storage group backup automatically includes the associated transaction logs. The following procedure can be used to create a new storage group:

Start the System Manager from the Windows 2000 Start menu by selecting Programs Microsoft Exchange System Manager.

Note

By default, administrative groups and routing groups are not displayed. If you have not already enabled these, right-click on the Exchange organization and select Properties to display the organization properties. Select the Display administrative groups check box to allow the administrative groups to be displayed and select the Display routing groups check box to display the routing groups. You must restart the Exchange System Manager after enabling display of administrative groups and routing groups.

Expand the Administrative Groups section.
Expand the administrative group (e.g., First Administrative Group) that contains the server where the storage group will be located.
Expand the Servers section.
Right-click on the server that will contain the storage group, and select New Storage Group.
On the General tab, enter a name for the new storage group. The Transaction log location and System path location are automatically created using the new storage group name. See Figure 5.10.

Figure 5.10: The General tab
Select the Enable circular logging check box if you want to use circular logging for this storage group. Circular logging will reuse a transaction log file instead of creating a new one when the log file becomes full.
Select the Zero out deleted database pages check box to clear deleted data from the drive. This option provides higher security but impacts server performance.
Use the Administrative note field on the Details tab to enter additional information about the storage group.
Select OK when finished. The new storage group will be displayed in the Exchange System Manager window under the server section.

5.3.4 Creating a new mailbox store

The following procedure can be used to create a new mailbox store.

Start the System Manager from the Windows 2000 Start menu by selecting Programs ƒ Microsoft Exchange ƒ System Manager.

Note

Expand the Administrative Groups section.
Expand the administrative group (e.g., First Administrative Group) that contains the server where the storage group is located.
Expand the Servers section.
Expand the server where the storage group is located.
Right-click on the Storage Group that will contain the new mailbox store, and select New Mailbox Store.
On the General tab, enter a name for the new mailbox store (Figure 5.11).

Figure 5.11: The General tab
In the Default public store field, select the public store that will be used by the users with mailboxes in this mailbox store.
In the Offline address list field, select the offline address list for this set of mailboxes.
Select the Archive all messages sent or received by mailboxes on this store check box if you want to archive messages.
Select the Database tab (Figure 5.12).

Figure 5.12: The Database tab
The Exchange database and Exchange streaming database fields contain the default names and locations for the .EDB and .STM files, respectively. The .EDB file maintains the content for messages sent using MAPI clients. The .STM file is the streaming media store and contains the content for messages sent and received using most Internet protocols.
The database requires regular maintenance to prevent or to diagnose and repair a variety of problems. The internal structure of the Exchange database becomes fragmented as objects are removed from the database. This fragmentation will eventually result in many small holes in the database, none of which are large enough to store new objects. In severe cases of fragmentation, the Information Store may spend so much time searching for available database space that it cannot accept messages fast enough to keep up with the incoming volume. Periodic defragmentation consolidates the separate pockets of empty space. This helps ensure that needed space is available when new, large objects are added to the database, and generally, helps provide optimum performance for the information store. Users on the system while the maintenance process is running can continue to send and receive mail, but they may see a slight decrease in performance. Use the Maintenance interval drop-down list to select the time when the Information Store will perform maintenance on this database. You can accept one of the intervals on the drop-down list or select Customize to display the Schedule dialog box where you can specify the desired maintenance interval.
Select the Do not mount this store at startup check box to prevent automatic mounting of this store at startup.
Select the This database can be overwritten by a restore check box to allow automatic updating of this database at startup.
Select the Limits tab (Figure 5.13).

Figure 5.13: The Limits tab
Use the Issue warning , Prohibit send , and Prohibit send and receive check boxes and associated values to specify the default storage limits for users with mailboxes in this database.
Use the Warning message interval drop-down list to select the time period when the Information Store will check for storage limit violations on this database.
Use the Keep deleted items for (days) and the Keep deleted mailboxes for (days) fields to specify how long deleted items and mailboxes will be retained before permanent deletion.
Select the Do not permanently delete mailboxes and items until the store has been backed up check box to ensure that a backup tape is made before items are permanently deleted.
Select the Full-Text Indexing tab. The fields on this tab are used to specify that a full-text index should automatically be maintained for items in this database. The tab is also used to specify the update interval and rebuild interval for this index.
Select the Update this index automatically check box to enable automatic full-text indexing.
Use the Update interval drop-down list to select an update interval. You can accept one of the intervals on the drop-down list or select Customize to display the Schedule dialog box where you can specify the desired interval.
Use the Rebuild interval drop-down list to select a full-text indexing rebuild interval. You can accept one of the intervals on the drop-down list or select Customize to display the Schedule dialog box where you can specify the desired interval.
Select the This index is currently available for searching by clients check box to make the index available to users.
Select the Details tab.
Use the Administrative note field on the Details tab to enter additional information about the mailbox store.
Select OK when finished. The server will automatically create the necessary files and after a few moments display a message stating that the database was created and mounted. The remount process may take some time.

5.3.5 Creating a new public store

The following procedure can be used to create a new public store:

Start the System Manager from the Windows 2000 Start menu by selecting Programs Microsoft Exchange System Manager.

Note

Expand the Administrative Groups section.
Expand the administrative group (e.g., First Administrative Group) that contains the server where the storage group is located.
Expand the Servers section.
Expand the server where the storage group is located.
Right-click on the storage group that will contain the new public store, and select New Public Store.
On the General tab, enter a name for the new public store (Figure 5.14).

Figure 5.14: The General tab
In the Associated public folder tree field, select the associated public folder tree. Exchange supports multiple public folder hierarchies, and each hierarchy (or tree) is stored in a public folder store. However, a server can hold only one public store per public folder tree.
Select the Clients support S/MIME signatures check box to show that mail clients are using the Secure/Multipurpose Internet Mail Extensions standard.
Select the Display plain text messages in a fixed- sized font check box to enable display of plain-text messages in fixed-size font.
Select the Database tab (Figure 5.15).

Figure 5.15: The Database tab
The Exchange database and Exchange streaming database fields contain the default names and locations for the .EDB and .STM files, respectively. The .EDB file maintains the content for messages sent using MAPI clients. The .STM file is the streaming media store, and it contains the content for messages sent and received using most Internet protocols.
The database requires regular maintenance to prevent or to diagnose and repair a variety of problems. Use the Maintenance interval drop-down list to select the time when the Information Store will perform maintenance on this database. You can accept one of the intervals on the drop-down list or select Customize to display the Schedule dialog box where you can specify the desired maintenance interval.
Select the Do not mount this store at startup check box to prevent automatic mounting of this store at startup.
Select the This database can be overwritten by a restore check box to allow automatic updating of this database at startup.
Select the Replication tab to set parameters for public folder replication (Figure 5.16). A public folder can be configured to have replicas on multiple public folder servers. Replicas distribute user load on servers, distribute public folders geographically , and back up public folder data.

Figure 5.16: The Replication tab
Use the Replication interval drop-down list to select a replication interval. You can accept one of the intervals on the drop-down list or select Customize to display the Schedule dialog box where you can specify the desired replication interval.
The Replication interval for always (minutes) field is used when the Replication interval drop-down list is set to Always run . In the Replication interval for always (minutes) field, specify a replication interval.
In the Replication message size limit (KB) field, specify a value for replication-message size limit.
Use the Restore Defaults button to restore defaults for Replication interval for always (minutes) to 15 minutes and Replication message size limit (KB) to 300 KB
Select the Limits tab to set database storage limits and to set data deletion parameters (Figure 5.17).

Figure 5.17: The Limits tab
Select the Issue warning at (KB) check box and associated value to warn you when the database has reached the specified storage space value.
Select the Prohibit post at (KB) check box to prohibit posting messages that are larger than the size you specify in the associated text box.
Select the Maximum item size at (KB) check box and associated value to specify the maximum item size.
Use the Warning message interval drop-down list to select a warning message interval. You can accept one of the intervals on the drop-down list or select Customize to display the Schedule dialog box where you can specify the desired interval.
Enter a value into the Keep deleted items for (days) field to specify the number of days that mailboxes deleted from this store should be retained.
Select the Do not permanently delete items until the store has been backed up check box to ensure that a backup tape is made before items are permanently deleted.
Select the Age limit for all folders in this store (days) check box and associated value to set the age limit for folders in this store.
Select the Full-Text Indexing tab to set the full-text indexing parameters for the public store. Exchange 2000 can create and manage full-text indexes to enable fast searches and lookups. With full-text indexing, every word in a database is indexed.
Select the Update this index automatically check box to enable automatic full-text indexing.
Use the Update interval drop-down list to select an update interval. You can accept one of the intervals on the drop-down list or select Customize to display the Schedule dialog box where you can specify the desired interval.
32. Use the Rebuild interval drop-down list to select a full-text indexing rebuild interval. You can accept one of the intervals on the drop-down list or select Customize to display the Schedule dialog box where you can specify the desired interval.
Select the This index is currently available for searching by clients check box to make the index available to users.
Select the Details tab.
Use the Administrative note field on the Details tab to enter additional information about the public store.
Select OK when finished. The server will automatically create the necessary files and after a few moments display a message stating that the database was created and mounted. The remount process may take some time.

5.3.6 Dismounting a mailbox store or public store

Dismounting a mailbox store or public store is not required for normal administrative purposes and should be avoided since it disables user access to the dismounted mailboxes. However, if you should find it necessary to dismount a mailbox store or public store, the following procedure can be used.

Start the System Manager from the Windows 2000 Start menu by selecting Programs Microsoft Exchange System Manager.

Note

Expand the Administrative Groups section.
Expand the administrative group (e.g., First Administrative Group) that contains the server where the database is located.
Expand the Servers section.
Expand the server where the database is located.
Expand the storage group where the database is located.
Right-click on the database, and select All Tasks Dismount Store.
Select Yes when asked if you want to continue. The dismount process may take a few minutes.

5.3.7 Mounting a mailbox store or public store

The following procedure can be used to mount a mailbox store or public store:

Start the System Manager from the Windows 2000 Start menu by selecting Programs Microsoft Exchange System Manager.

Note

Expand the Administrative Groups section.
Expand the administrative group (e.g., First Administrative Group) that contains the server where the database is located.
Expand the Servers section.
Expand the server where the database is located.
Expand the storage group where the database is located.
Right-click on the database, and select All Tasks Mount Store. The remount process may take some time.