Lesson 1: Management of Server Resources | MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration

When you examine the content of the Servers container in Exchange System Manager, you will notice one or many server objects each representing one server within the selected administrative group. In an organization with only one administrative group, the Servers container appears directly underneath the organization until you change the View settings in the General tab of the organization object (Display Administrative Groups check box).

This lesson concentrates on the administration of Exchange 2000 Server at the server level, which has a higher priority than the administrative group level. You can read about dedicated server configurations and the activation of full-text indexing and diagnostics logging.

At the end of this lesson, you will be able to:

Manage storage groups as well as mailbox and public stores.
Activate full-text indexing for mailbox and public stores.
Enable diagnostics logging for troubleshooting and system analysis.

Estimated time to complete this lesson: 75 minutes

Storage Management in Exchange System Manager

Exchange System Manager can connect to any Microsoft Windows 2000 domain controller for retrieval of Exchange 2000 configuration information from Active Directory directory services. Yet, when adjusting information store settings, you need to communicate directly with the selected Exchange server via remote procedure calls (RPCs). If the server cannot be reached over the network for any reason, Exchange System Manager will display an error message and mark the resources as unavailable.

IMPORTANT
If you want to manage storage groups and server properties, make sure the selected server is available in the network and its Information Store service is running.

Storage Groups and Information Stores

When you expand the object of an out-of-the-box server in the Exchange System Manager, you can find underneath it one sublevel container called First Storage Group, which provides access to one mailbox and one public store. You can add additional storage groups on a single computer running Exchange 2000 Enterprise Server, as mentioned in Chapter 3, "Microsoft Exchange 2000 Server Architecture." A server is able to handle a maximum of four storage groups, each capable of managing up to five individual stores.

Storage groups define the boundaries for mailbox and public store databases. Within a single storage group, all stores share a common set of transaction log files. Consequently, the transaction log location is a storage group's most important configuration parameter. The purpose of transaction logs is explained in Chapter 20, "Microsoft Exchange 2000 Server Maintenance and Troubleshooting."

For storage groups, the following settings are available:

Transaction Log Location. Specifies the directory where the database transaction log files are located.
System Path Location. Specifies the location of temporary files that may exist during an online backup or normal operation. This is typically the same as the Transaction Log Location.
Log File Prefix. This read-only parameter indicates the name of the active transaction log. For instance, the default First Storage Group uses the prefix E00, which results in a log filename of E00.LOG. Additional storage groups would be assigned the prefixes E01, E02, and so forth.
Zero Out Deleted Database Pages. Helps to increase the security of the server system by clearing deleted data entries from the database file. Activating this option affects the server performance.
Enable Circular Logging. Allows reuse of existing log files for new transactions. This feature helps to save disk space but decreases the system's fault tolerance, as explained in Chapter 20, "Microsoft Exchange 2000 Server Maintenance and Troubleshooting."

Configuring Information Stores

You can manage information stores in storage groups individually or maintain them more conveniently through system policies. With only a few exceptions, system policies provide the same set of properties as information stores. You can read more about the configuration of message stores via mailbox and public folder policies in Chapter 12, "Management Tools for Microsoft Exchange 2000 Server."

Most configuration settings apply to both mailbox and public stores, but a few are store type-specific. Mailbox stores, for instance, allow you to set an Offline Address List in the General tab. Users on this mailbox store will download that address list in Microsoft Outlook 2000 on the Tools menu when you select the Synchronize option and then the Download Address Book command. You can read more about the configuration of Outlook 2000 for offline usage in Chapter 9, "MAPI-Based Clients."

Mailbox stores also give you the option to change the Default Public Store in their General tab, which is the public store that users connect to when browsing through the hierarchy of public folders in Outlook 2000 or when they create top-level folders. Outlook 2000 only supports access to one hierarchy that corresponds to the Public Folders tree, known as the MAPI-based public folder hierarchy. It is not possible to specify a public store in the General tab that does not correspond to the MAPI-based Public Folders. You can read more about public folders in Chapter 17, "Public Folder Management."

Configuring Dedicated Servers

Large organizations might want to distribute their mailbox resources across multiple servers. This increases the overall system scalability because multiple servers can share the workload of mailbox access. The same does not apply to public folders, however. Without public folder replication, which needs to be configured manually, a particular public folder resides on only one server. If all users in an organization need access to a particular public folder, they all have to connect to the same machine. This may slow down the affected server and users with mailboxes on this machine might start complaining about server response times.

The organization shown in Figure 14.1 uses one server where all public folders are located. Several, less powerful computers provide each a subset of users with mailbox access. Even if all users would connect to the public server concurrently, performance of the mailbox servers would not be affected.

To prevent the creation of public folders on the mailbox servers, you might want to delete their public store. This corresponds to a configuration of dedicated mailbox servers. Optionally, you can also remove the mailbox store from the public folder server to avoid the accidental creation of mailboxes on this machine (see Exercise 1).

click to view at full size

Figure 14.1 Configuring dedicated mailbox and public folder servers

Creating Additional Storage Groups and Information Stores

If you plan to concentrate thousands of mailboxes and public folders on a very large server, consider multiple information stores and storage groups. It would not be advisable to place all resources in a single mailbox or public store because the size of the database files could grow beyond reasonable limits. Huge databases can turn backup and restore procedures and regular maintenance routines into nightmares. It is advisable to avoid extremely time-consuming maintenance jobs.

At a minimum, distribute large numbers of mailboxes across multiple mailbox stores in one storage group. You can mount and dismount individual databases independently; in other words, you can back them up and recover them separately without affecting others. Typically, though, you will include all databases of a single storage group along with their corresponding transaction log files in one backup. If you would like to implement different backup schedules for different repositories, consider the configuration of multiple storage groups. It is necessary to configure multiple storage groups if you want to create more than five information stores on a server.

Multiple information stores can bring you a performance gain, provided that you place their transaction logs and database files on separate physical disk systems, as shown in Figure 14.2. It doesn't give you much of a performance boost to place transaction logs of multiple storage groups on a common physical drive.

NOTE
The single instance storage feature discussed in Chapter 13, "Creating and Managing Recipients," is not available across multiple databases.

Exercise 1: Creating Dedicated Mailbox and Public Folder Servers

In this exercise you will configure BLUESKY-SRV1 as a dedicated public folder server and BLUESKY-SRV2 as a dedicated mailbox server. You will also create an additional mailbox store on BLUESKY-SRV2.

To view a multimedia demonstration that displays how to perform this procedure, run the EX1CH14.AVI files from the \Exercise_Information\Chapter14 folder on the Supplemental Course Materials CD.

Prerequisites

Make sure Exchange 2000 Server was first installed on BLUESKY-SRV1; otherwise, trade the server names in the following exercise to avoid the deletion of important system folders.
You have removed all connector components from BLUESKY-SRV1, installed during Exercise 4 of Chapter 5, "Installing Microsoft Exchange 2000 Server." Launch the Setup program in maintenance mode to remove these components.

Figure 14.2 Multiple storage groups on a single server
Drive D: on BLUESKY-SRV2 is formatted with the NTFS file system.
Log on as Administrator to BLUESKY-SRV1.
Use the Active Directory Users and Computers snap-in to move all existing mailboxes from BLUESKY-SRV1 to BLUESKY-SRV2 (moving of mailboxes was demonstrated in Exercise 1 of Chapter 13, "Creating and Managing Recipients").
Administrative and routing groups are displayed in the Exchange System Manager (Display Routing Groups and Display Administrative Groups check boxes in the properties of the organization object Blue Sky Airlines [Exchange]).

To configure dedicated servers and add storage groups

Launch the Exchange System Manager, expand Administrative Groups, then First Administrative Group, then Servers, then BLUESKY-SRV1, then First Storage Group, then Mailbox Store (BLUESKY-SRV1), and then select Mailboxes. Make sure no user mailboxes are displayed in the details pane (several system mailboxes may exist). If there are user mailboxes in this store, Exchange System Manager prevents you from removing it.
Right-click the Mailbox Store (BLUESKY-SRV1) and select Properties. In the Mailbox Store (BLUESKY-SRV1) Properties dialog box, click on the Database tab, write down the names and paths to the Exchange Database and Exchange Streaming Database, and then click OK. By default, these directories are C:\Program Files\Exchsrvr\Mdbdata\PRIV.EDB and C:\Program Files\Exchsrvr\Mdbdata\PRIV.STM.
Right-click Mailbox Store (BLUESKY-SRV1) and select Delete.
In the dialog box informing you that deleting this mailbox store may result in the loss of system messages, click Yes (see Figure 14.3).
Another Information Store dialog box will appear asking you if you are sure you want to remove this mailbox store. Click Yes.
In the final dialog box informing you that the store has been removed but you must delete the database files manually, click OK. While deleting is not a bad idea, you should keep the files for subsequent exercises.
At this point, you have configured BLUESKY-SRV1 with a public store only, which turns this machine into a dedicated public folder server unable to hold any mailboxes.

Figure 14.3 Deleting a mailbox store
In the console tree, under Servers, expand BLUESKY-SRV2, expand First Storage Group, open Public Folder Store (BLUESKY-SRV2), and then select Public Folder Instances. Make sure no public folders holding user data exist in this store and no system folders other than Globalevents, Internal, and StoreEvents{…} are listed. If there are other public folders, replicate them to BLUESKY-SRV1 (explained in Chapter 18, "Public Folder Replication") before continuing.
Right-click Public Folder Store (BLUESKY-SRV2) and select Properties.
In the Public Folder Store (BLUESKY-SRV2) Properties dialog box, click on the Database tab, note the names and paths to the databases, and then click OK. By default, these directories are C:\Program Files\Exchsrvr\Mdbdata\PUB1.EDB and C:\Program Files\Exchsrvr\Mdbdata\PUB1.STM.
Right-click Public Folder Store (BLUESKY-SRV2) and select Delete.
In the dialog box informing you that it is strongly recommended to move any public folder replicas to other servers before removing the public store, click Yes.
A Public Folder Store (BLUESKY-SRV2) dialog box will appear, informing you that you need to specify a new default public store for the mailboxes on this server. Click OK.
In the Select Public Store dialog box, select the reference to Public Folder Store (BLUESKY-SRV1), and then click OK (see Figure 14.4).
Another dialog box might be displayed, prompting you to select a new public store for system folders. In this case, click OK, and select the reference to Public Folder Store (BLUESKY-SRV1) again before clicking OK one more time. This dialog box will not appear in the test environment because BLUESKY-SRV2 does not contain system folders.
Another dialog box might appear informing you that this public store holds offline address lists that need to be rebuilt on a new public store. Click OK, select the reference to Public Folder Store (BLUESKY-SRV1), and then click OK again. This dialog box will not appear in the test environment because BLUESKY-SRV2 does not hold the offline address lists.
In the final Select Public Store (BLUESKY-SRV2) dialog box asking you whether you want to delete the public store, click Yes.
In the final Information Store dialog box informing you that you must remove the database files manually, click OK.
At this point, you have configured BLUESKY-SRV2 as a dedicated mailbox server unable to maintain any public folder data. To work with public folders, users will connect to BLUESKY-SRV1, which holds the default public store.

Figure 14.4 Deleting a public store
In the console tree, right-click BLUESKY-SRV2, point to New, and then select Storage Group.
In the General tab, under Name, type Management Group.
Under Transaction Log Location and System Path Location, change the drive letter from C to D in both text boxes, and then click OK.
If a dialog box appears informing you that the validity of the databases cannot be verified at this point, click Yes to continue.
A new, empty container will be created under BLUESKY-SRV2. Right-click Management Group, point to New, and then select Mailbox Store.
Under Name type VIP Mailboxes.
Verify that the Default Public Store resides on BLUESKY-SRV1.
Click on the Database tab, and notice that the Exchange Database and Exchange Streaming Database files are placed in the directory of the Management Group by default.
Click on the Limits tab, and, under Deletion Settings, in the Keep Deleted Items For (Days) text box, type 21. Click OK.
If a dialog box appears informing you that the validity of the databases cannot be verified at this point, click Yes to continue.
In the VIP Mailboxes dialog box informing you that the store was created successfully, click No to not mount the store yet. Give directory replication a few minutes to propagate the changes to BLUESKY-SRV2 first (you are working on BLUESKY-SRV1).
Right-click VIP Mailboxes and select Mount Store.
In the final VIP Mailboxes dialog box informing you that the store was mounted successfully, click OK.
At this point, you have created and mounted an additional mailbox store on a separate drive on BLUESKY-SRV2 (see Figure 14.5).
Launch Active Directory Users and Computers and open the Users container. Move the mailbox of the Administrator account into the Management Group/VIP Mailboxes store, as explained in Chapter 13, "Creating and Managing Recipients."

click to view at full size

Figure 14.5 Creating an additional mailbox store

Exercise Summary

To avoid the possible loss of user data, mailboxes must be moved to a new home server and public folders must be replicated to another public store before configuring dedicated servers. After a store has been removed successfully, you need to delete the corresponding database files manually. You can determine the path to the databases and their names when displaying the Database property sheet of the affected store prior to its deletion.

The creation of new storage groups and information stores, on the other hand, is uncomplicated. At a minimum, you need to specify a name for new resources. As soon as you have created and mounted a new mailbox store, you can move mailboxes into it using the Active Directory Users and Computers snap-in.

Full-Text Indexing

By default, Exchange 2000 Server supports attribute-based searches for messages and documents. This corresponds to the search capabilities of earlier versions of Exchange Server, where Outlook users could look up messages and other items based on their attributes. For example, you could search for all messages in your Inbox with the phrase "Full-Text Indexing Was Not Supported" in the subject line. This search would examine every existing object in your Inbox and return the matching items. Depending on the number of messages, this search method might take a very long time.

You could also locate documents by searching for subject, author, keywords, and other document properties. However, full-text searches across documents and attachments in messages were not supported. This reduced the attractiveness of Exchange Server 5.5 as a document management platform.

Microsoft Search Integration

The good news for the knowledge worker is that Exchange 2000 Server supports sophisticated searches for words and phrases contained in documents and message attachments. This functionality is achieved by integrating the query engine of the Information Store with the Microsoft Search service (see Figure 14.6).

NOTE
Microsoft Search is a Windows 2000 service installed as part of the Exchange 2000 Server setup procedure. It is configured to start automatically. This service operates in the context of the LocalSystem account.

The Microsoft Search service provides support for the following tasks:

Indexing. Maintains full-text catalogs and indexes for mailbox and public stores and populates the full-text indexes.
Querying. Processes full-text searches passed over by the Information Store search engine and returns entries in the index that meet the full-text search criteria. According to this information, the Information Store search engine can construct the query result and return it to the user.

Full-Text Indexing and Catalogs

Full-text indexes provide information about significant words in messages, documents, and attachments for sophisticated word searches. By default, item body, subject, sender, and recipient information are indexed. Because the full-text catalogs are queried instead of the actual message items and documents, searches are performed with increased efficiency, especially if numerous items are involved. However, before the search engine can process a full-text query, the catalog must be populated. Furthermore, the query results can only be as accurate as the information in the catalog.

click to view at full size

Figure 14.6 Attribute and full-text searches

NOTE
Full-text indexes and catalogs are not stored in the Information Store. They are located in the Program Files\Exchsrvr\ExchangeServer_<Server Name> \Projects directory and managed by the Microsoft Search service. They consume approximately 20% of disk space of the corresponding store size.

Indexing Information Stores

Full-text indexing can be enabled per individual mailbox and public store. First, you need to create a full-text index for a store. You then need to populate the store's full-text catalog. As soon as this is accomplished, you can make the catalog available for full-text searches by clients. After that, you may define update and rebuild intervals to ensure that search information is always up to date.

Creating a Full-Text Index

Let's assume you want to create a full-text index for the mailbox store added to BLUESKY-SRV2 in Exercise 1 (VIP Mailboxes). Right-click this store and, from the shortcut menu, select Create Full-Text Index. In the Mailbox Store (BLUESKY-SRV2) dialog box accept the default directory, which is \Program Files\Exchsrvr\ExchangeServer_BLUESKY-SRV2\Projects, and click OK. As soon as the catalog is created, right-click VIP Mailboxes again and select Start Full Population. In the Mailbox Store (BLUESKY-SRV2) dialog box informing you that this operation may take time and server resources, click Yes. When the population is complete, expand VIP Mailboxes, and select Full-Text Indexing. Verify that the index was created successfully. You might need to refresh the view for latest status information.

You can also click the Start Full Population command if you want to purge and rebuild an existing index. The index is purged at once but one document at a time. While this process is running, searches against the store will not be able to use the full-text index. When the full population is complete, you should reactivate the full-text index for client searches.

Activating a Full-Text Index

At this point, you have created and populated the full-text index, but your users are still unable to use it because it isn't included in full-text searches. Right-click VIP Mailboxes one more time and select Properties. Click on the Full-Text Indexing tab, and select the This Index Is Currently Available For Searching By Clients check box. When you click OK, a dialog box appears, reminding you that you must make sure that the index is not out of date; otherwise, searches might return incomplete or invalid results. Click OK.

NOTE
It is advisable not to back up or restore an index separately from its information store. This will guarantee that both index and store are always synchronized. Otherwise, searches will return incomplete or invalid results.

Updating and Rebuilding a Full-Text Index

Changes to folder contents within an indexed store trigger a synchronization event, which informs the Microsoft Search service to update the index correspondingly. By default, however, the index is not updated. You will need to specify an explicit update and rebuild interval in the Full-Text Indexing tab. For automatic updates, under Update Interval, select Always Run. During scheduled and automatic updates, incremental populations are performed, where new items are indexed and their references are added to the catalog. Incorrect references, however, may remain in the index until it is entirely rebuilt. Rebuilding takes significantly more resources than updating; therefore, you should schedule a weekly rebuild interval for off-peak hours over the weekend (you may update the indexing information more frequently or automatically).

NOTE
If you need to refresh the indexing information manually, consider updating the index incrementally. This allows your users to perform searches while the catalog is being refreshed. Only new and modified items will be indexed. Right-click the desired store and select Start Incremental Population.

Controlling System Resource Consumption

It is important to keep the full-text index current, but indexing consumes system resources. Resource consumption is controlled at the server level. Display the properties of the desired server object (for example, BLUESKY-SRV2) and click on the Full-Text Indexing tab. You will find a parameter called System Resource Usage in this tab, which can be set to four levels: Minimum, Low, High, and Maximum. Low is the default. As mentioned, you should schedule rebuild intervals for off-peak times and set System Resource Usage value to High or Maximum. The index information is then refreshed as quickly as possible. If you must index while users are working with their mailboxes, set System Resource Usage to Low. On a system with high memory usage, decrease the value to Minimum.

Supported File Types and Gather Logs

Microsoft Search supports specific file types through document filters. Filters are provided for Microsoft Office documents, and other documents, such as Adobe .pdf files. Supported file types are recognized by their filename exten-sion, such as .doc or .xls. However, the Microsoft Search service may attempt to index a corrupted document, in which case the indexing fails and continues with the next message or document. A corresponding error will be written to the application event log summarizing the number of corrupted documents. In addition, problematic documents will be logged together with other statistical information in gather files, which can be found in the \Program Files\Exchsrvr\ ExchangeServer_ <Server Name>\GatherLogs directory. Gather files are text files with a filename extension of .gthr.

Microsoft Search provides you with GTHRLOG.VBS, which is a useful utility to examine gather files. You can find it in the \Program Files\Common Files\ System\MsSearch\Bin directory. Launch GTHRLOG.VBS with the desired gather log in the command line (for example, gthrlog <path + filename.gthr>). A series of dialog boxes will display the data found in the gather log file, such as statistical information about the last indexing cycle and references to problematic documents, together with an explanation of error codes. For usage information on this utility, use the command gthrlog /?.

Performing a Full-Text Search

As soon as you activate a full-text index, your Outlook users (and users of IMAP4 clients) are able to perform full-text searches. The user doesn't have to use any new utilities or change search habits because the Information Store takes care of the communication with the Microsoft Search service (see Figure 14.6). In Outlook 2000, for instance, open the Tools menu, and select Advanced Find as usual. In the Advanced Find dialog, type the word or phrase you want to search for under Search For The Word(s), and, from the In list box, select Subject Field And Message Body. Click Find Now, and all items containing the specified phrase, including Office documents, will be returned. It is important to note that full-text searches return complete matches only. A search for the phrase "index" will result in a list of documents that actually contain the word "index." The word "indexing" is not considered a match.

NOTE
With full-text searches enabled, client searches are performed against the index of the Microsoft Search service first and, after that, against the attributes in the information store. Hence, two separate searches are executed to return one list of resulting messages and documents.

Indexing Service

Don't confuse the Microsoft Search service with the Indexing service. The latter is installed under Windows 2000, but it is not started by default. The Indexing service provides functionality similar to the Microsoft Search service but doesn't work in conjunction with the Information Store directly. It is used against files of the operating system and Web resources. You can configure the Indexing service in the Computer Management snap-in.

Nevertheless, the Indexing service allows you to search for items in mailboxes and public folders via the Microsoft Web Storage System. The Web Storage System provides access to resources based on HTTP and Web Distributed Authoring and Versioning (WebDAV), as discussed in Chapter 11, "Internet-Based Clients." Consequently, users of Web browsers can search the Information Store, even though WebDAV clients do not support searches via the Microsoft Search service. When combined with full-text indexing and HTTP client support, Exchange 2000 Server becomes a very attractive document management platform.

Diagnostic Logging

All active components of Exchange 2000 Server are implemented as Windows 2000 services, which has significant advantages. Windows 2000 services can offer their services to local and remote processes or client programs connected over the network, and they can be controlled and administered remotely. The various communication paths between the individual Exchange 2000 Server components were highlighted in Chapter 3, "Microsoft Exchange 2000 Server Architecture."

For system administrators, nevertheless, Windows 2000 services have one considerable disadvantage: They run entirely unattended, presenting absolutely no user interface. The services of Exchange 2000 Server, for example, run in the context of the LocalSystem account. Even if these services did display a user interface, you would not be able to see it because you aren't working with the same user credentials.

Examining System Activities

To inform the administrator about specific activities and error states, Exchange 2000 components write status information in form of events into the application event log. By default, only a minimum of events, or error notifications, are logged, which can be viewed using the Event Viewer utility mentioned in Chapter 12, "Management Tools for Microsoft Exchange 2000 Server."

If you experience server problems or are interested in more details about the activities of a particular Exchange service in general, you should increase the amount of logged events. This can be accomplished using the Diagnostics Logging tab that every server object provides. To give an example, right-click the server object BLUESKY-SRV1, select Properties, and click on the Diagnostics Logging tab. From the Services list, select the desired component, such as MSExchangeTransport. The Categories list will display corresponding internal components, such as the Routing Engine, Categorizer, and so on. Select one or multiple categories, set the desired Logging Level (None, Minimum, Medium, or Maximum), and then click OK. It is not necessary to restart the affected services for the changes to take effect.

NOTE
Entries in the application event log can become overwhelming if you set the Diagnostics Logging level to Maximum because most detailed status information will then be retrieved.

Diagnostics Logging Settings in the Registry

When you modify the Diagnostics Logging level for a component in Exchange System Manager, the settings are written to the Windows 2000 Registry. Exchange System Manager also informs the corresponding service to update its configuration information. If you change the settings directly in the Registry, however, you should restart the affected service to make sure the changes are applied.

The diagnostics logging information for Exchange 2000 Server components is located under:

 HKEY_LOCAL_MACHINE  \SYSTEM   \CurrentControlSet    \Services     \<Exchange 2000 Component>      \Diagnostics

Within this subkey, REG_DWORD values exist for each of the logging categories. Possible values are 0 for a logging level of None, 1 for Minimum, 3 for Medium, and 5 for Maximum logging. For super-detailed diagnostics logging, you may increase the value to 6. This level is only available when directly editing the Registry.