by Kimmo Bergius
After you have your Exchange environment all configured and up and running, it is time to start maintaining the environment. Most of the server maintenance is automatically performed by the Exchange services with the administrator just monitoring the operations. There are, however, some maintenance tasks the administrator should perform manually.
Maintenance for the Exchange environment can be divided into three categories:
User maintenance mainly consists of defining and modifying mailboxes and other recipients. The administrator also has to monitor storage levels per user and for the whole private information store.
The administrator has to check the storage levels for public folders as well, and also check that the folder replication works properly. Most of the other public folder definitionsfor example, public folder creation and configurationare done on the client level by users.
The administrator does most of his or her daily work at user and server level. The administrator has to configure and modify the system, monitor server and service operation, free storage space, database files and, most important, take backups of the system.
Connection maintenance consists mostly of monitoring different message queues and checking that messages are delivered from sender to recipient as efficiently and as smoothly as possible.
There are a lot of different tools for monitoring and maintaining the system, some of which are discussed in this chapter and some in the following chapters.
Maintenance tools can be divided into two categories, tools used to maintain the client environment and tools used to maintain the server environment. Some of the maintenance tools are shipped either with the Exchange server or the Exchange client. Other tools used to maintain the Exchange server are part of the Windows NT Server operating system. The following sections give you a brief description of the tools available.
There are a few tools that come with Exchange that you can use to maintain the client environment.
The server maintenance tools can be further divided into two categories, tools that are a part of the Exchange environment and tools that come with Windows NT Server.
The following lists various Exchange tools:
The following are the Windows NT Server tools:
You should normally keep all diagnostics logging options in the None or Minimum setting, otherwise the Exchange services will create so many logging events that you will not be able to store them anywhere. Only when you have detected or suspect an error or malfunction in the system should you set the diagnostics logging to Maximum for the specific function you are trying to trace, and then follow the events logged in Event Viewer.
The predefined Performance Monitor icons are the easiest ways for an administrator to monitor the daily operation of an Exchange server (for example, the lengths of MTA and connector queues).
When you install Exchange on a server computer, the installation program will create a directory structure onto the disk that you choose. All files related to the Exchange server are located under this directory. Even though it is not usually necessary to examine or delete these files, an Exchange administrator should be aware of the contents of the subdirectories in the directory structure and of the files that the subdirectories contain. The following is a brief description of the contents of the Exchange directory structure.
When you install the Exchange server, by default it will be installed in the EXCHSRVR directory on the chosen drive. In a single-drive environment, all files related to Exchange are stored on the same drive. In a multi-drive environment you can, however, choose to store the files on different drives. If this is the case, an EXCHSRVR directory will be created on all the drives and the appropriate subdirectories created under this directory (see Figure 20.1.). If you run the Exchange Optimizer, it will examine the drives on your server system and suggest possible different locations for the directories. The Optimizer can also move the directories and files into their proper positions and change the values in the registry pointing to these files.
Figure 20.1. The Exchange directory structure.
The following list details the subdirectories under the EXCHSRVR directory, what each of the subdirectories contains, and whether they are shared or not.
ADD-INS
|
The ADD-INS subdirectory contains the administration extensions for the various connectors that will be used in the Administrator program to show the connector's property page. After a full installation this directory will contain subdirectories and DLLs for the Microsoft Mail Connector, the Microsoft Schedule+ Free/busy Connector and the Internet Mail Connector. These DLLs are further divided into subdirectories according to the platform on which they can be run. The installation program automatically shares the ADD-INS subdirectory using the share name ADD-INS.
|
ADDRESS
|
The ADDRESS subdirectory contains the address proxy generator DLLs for the three default address types, Microsoft Mail, SMTP, and X.400 addresses. These DLLs are stored in subdirectories according to the address type and platform. The installation program automatically shares the ADDRESS subdirectory using the share name ADDRESS.
|
BIN
|
The BIN subdirectory contains the executable files and components of the Exchange server and the Administrator program.
|
CONNECT
|
The CONNECT subdirectory contains executables and components for the Exchange connectors. After a full installation there are subdirectories for the Microsoft Mail Connector, the Microsoft Schedule+ Free/busy Connector and the Internet Mail Connector. In addition, the CONNECT subdirectory contains a subdirectory for various character translation tables. The installation program automatically shares the CONNECT subdirectory using the share name CONNECT.
|
The subdirectory for the Microsoft Mail Connector, MSMCON, contains two subdirectories: the BIN directory, which contains the executables and components for the Connector itself, and the MAILDATA directory, which contains the Microsoft Mail Connector's shadow post office. The MAILDATA subdirectory contains a directory structure that is almost identical to that of a normal Microsoft Mail post office. This directory structure is used to connect the Exchange server to an MS Mail post office. The installation program automatically shares the MAILDATA subdirectory using the share name MAILDAT$ (the share name ends in a dollar sign ($), so that the share will not be visible to normal users when they browse the server's resources).
| |
DSADATA
|
The DSADATA subdirectory contains the directory database file (DIR.EDB) and the directory transaction logs. These files are discussed in detail in the section "Maintaining the Exchange Databases," later in this chapter.
|
DXADATA
|
The DXADATA subdirectory contains the directory synchronization database file (XDIR.EDB) and the directory transaction logs. These files are discussed in detail in the section "Maintaining the Exchange Databases," later in this chapter.
|
IMCDATA
|
The IMCDATA subdirectory is used by the Internet Mail Connector to store the temporary data files it needs during message delivery and conversion. The IMC also stores some of its logs into these directories. If you turn on SMTP logging in the IMC's Diagnostic Logging database, the log files will be stored in the LOG subdirectory. Also included in the IMC's diagnostics logging is a function called message archival. This function will store a copy of each outgoing or incoming message into the ARCHIVE subdirectories under IN and OUT.
|
MDBDATA
|
The MDBDATA subdirectory contains the database files for the private (PRIV.EDB) and public (PUB.EDB) information stores plus all associated transaction log files. These files are discussed in detail in the section, "Maintaining the Exchange Databases," later in this chapter.
|
MTADATA
|
The MTADATA subdirectory contains various configuration, template, and log files for the Exchange server's Message Transfer Agent service (MTA).
|
SAMPAPPS
|
The SAMPAPPS subdirectory contains sample applications and forms written for the Exchange server and client by Microsoft. The installation program automatically shares the CLIENT subdirectory under the SAMPAPPS subdirectory using the share name SAMPLES.
|
TRACKING.LOG
|
The TRACKING.LOG subdirectory contains the log files for the Message Tracking function. The installation program automatically shares the TRACKING.LOG subdirectory using the share name TRACKING.LOG. |
Many of the settings for the various Microsoft Exchange server services and features are stored in the NT server registry in the same way as any NT service or application is. You can control and edit most of these settings using the Administrator program, so normally an administrator would not edit them directly in the server's registry. It might, however, be helpful for the administrator to be aware of the location of the different registry entries. Furthermore, some entries can be changed only using the registry editor.
If you are not sure how to change the settings in the NT Registry or are unsure about the effects of a particular change, do not change the settings. A faulty setting can prevent NT or one of the Exchange services from starting.
All the registry settings for the Microsoft Exchange server are stored under the HKEY_LOCAL_MACHINE subtree and in there under two hives, SOFTWARE and SYSTEM.
The key name SOFTWARE\Microsoft\Exchange is used to store the settings for the Exchange client, as well as some information on the server. The Setup program uses the subkey SOFTWARE\Microsoft\Exchange\Setup to store information on the Exchange installation. This information is stored when the setup has completed successfully, and will be used by the setup program to detect whether Exchange has been installed, and if so, where it has been installed.
The values under the subkey SOFTWARE\Microsoft\Exchange\Exchange Provider define which protocols will be used in client-to-server communications (Rpc_Binding_Order) and in server-to-server communications (Rpc_Srv_Binding_Order). The administrator should change these values to include only those protocols that are actually being used.
The purpose of this section is only to illustrate to the administrator the location of the various Exchange registry entries. Several entries are discussed in detail in various parts of this book, but a detailed discussion of all the entries is beyond the scope of this book.
The settings for the various Exchange services are stored under SYSTEM\CurrentControlSet\Services\<Exchange service>, where <Exchange service> is the name of the service as detailed in Table 20.1.
Abbreviation |
Service |
MSExchangeSA
|
Microsoft Exchange System Attendant
|
MSExchangeDS
|
Microsoft Exchange Directory
|
MSExchangeDX
|
Microsoft Exchange Directory Synchronization
|
MSExchangeFB
|
MS Schedule+ Free/Busy Connector
|
MSExchangeIMC
|
Microsoft Exchange Internet Mail Connector
|
MSExchangeIS
|
Microsoft Exchange Information Store
|
MSExchangeKMS
|
Microsoft Exchange Key Manager
|
MSExchangeMSMI
|
MS Mail Connector Interchange
|
MSExchangeMTA
|
Microsoft Exchange Message Transfer Agent
|
MSExchangePCMTA
|
MS Mail Connector (PC) MTA |
The Event Log settings for the various Exchange services are stored under
SYSTEM\CurrentControlSet\Services\EventLog\Applications\<Exchange service>
where <Exchange service> is the name of the service as detailed in Table 20.1.
The licensing information for the Exchange server is stored under
SYSTEM\CurrentControlSet\Services\LicenseInfo\MSExchangeIS
You can use the NT License Manager to change the licensing information.
User maintenance mostly consists of creating and modifying recipients and distribution lists and monitoring the storage space allocated for each user. Recipient and distribution list creation and modification is discussed in Chapters 18, "Mailboxes and Recipients," and 19, "Directories and Distribution Lists," so this chapter concentrates on tasks related to monitoring user storage space.
You can set the maximum amount of disk space allowable for a user by defining the storage limit values on the General property page in the Private Information Store property window. There are two levels of storage limits; when the user exceeds the first one, he is given a warning, and when he exceeds the second limit, the system will disable him from sending any messages. The default settings defined on the General property page can be bypassed by defining user-specific storage limits on the Advanced property page of the user's mailbox.
You can set storage limits on two levels, individual users and the whole Private Information Store. Storage space cannot be limited on the level of user groups or distribution lists.
You can monitor disk space used by each user by opening the Private Information Store property page under the server you want to monitor. The Logons property page lists all the user currently logged onto the system. The Mailbox Resources property page lists all the users defined on the server, the number of messages stored in their mailboxes and the storage space (in kilobytes) the messages take.
The Private Information Store is based on a single copy principal, which means that each message is stored only once in the private information store database, even though it might appear in several user's mailboxes. The total storage space reported for each user on the Mailbox Resources will, however, include the storage space used by the message separately for each user that has that particular message in his mailbox. The same applies to the user level storage limits.
The administrator can cleanin other words, deleteselected messages from one or more mailboxes using the Clean Mailbox function. To clean mailboxes, first select the mailboxes you want to clean and then select Tools | Clean Mailbox (see Figure 20.2). The program will display a dialog box that enables you to define the messages you want cleaned from the selected mailboxes.
Figure 20.2. The Clean Mailbox dialog box.
Use the Clean Mailbox function with caution, because it will delete all the specified messages without discrimination. It is generally more advisable to specify a mailbox storage limit and let the users clean their own mailboxes. The maximum storage levels defined to a user are very powerful: when the user exceeds the first limit, he will be notified of this, but when the user exceeds the second limit, he will not be able to send any mail until he has cleaned his mailbox, so that the storage space used is again under the second limit.
Sometimes, you might have to move a user from one server to another within a site or even to another site. Moving a user from server to server within a site is very simple; you just select the mailbox or mailboxes you want to move in the administrator program, select Move Mailbox from the Tools menu and select the target server from the displayed dialog box. The administrator program will move the user and his mailbox to the specified server.
Moving a user to a server in another site is a bit more complicated; you cannot use any single function to do this. You should first copy all the user's folders and messages to a .PST file, delete the user ID from the old server, create the user manually to the new server and then add a Personal Folders information service to the user's profile and point it to the .PST file created earlier. Then the user can copy all his folders and messages to his new mailbox.
Maintaining public folders consists of two tasks: monitoring storage space used by each public folder and all public folders in total and monitoring the replication of public folders to specified servers.
The default maximum storage space allowed for each public folder is defined on the General property page of the server's property window. You can bypass this setting by specifying a folder specific storage limit on the Advanced property page on the public folder's property window.
Folder replication is monitored from the Replication Status property page of the Public Folder's property window. This page lists all servers to which the folder has been defined to be replicated and the status of the replication to each of the servers.
You can move a public folder from one server to another server by first replicating the folder to a new server and then deleting the replica from the old server.
You cannot delete the last replica of a particular public folder in a site using the administrator program. To delete the public folder, use the Exchange client.
The Exchange Server uses databases to store most of the user and configuration information and user data. This information is stored in several databases using the Joint Engine Technology (JET) database technology. This database technology was chosen for Exchange because some of its features, mainly the small size of the databases and the database engine and the capability to store records of varying lengths efficiently, suited the Exchange environment better than some other database solutions such as the SQL Server environment.
JET technology is used to store information for three different services:
The Directory Synchronization database differs from the other two databases because it is used to store changes in data rather than the actual data. Furthermore, the Directory Synchronization database does not usually need any maintenance. This chapter therefore focuses on maintaining the Directory and Information Store databases. The same methods apply, however, to the Directory Synchronization database as well.
The JET files for the different services are stored in the Exchange server's directory structure under the subdirectories for the respective services. The directories contain three different types of files:
When you make a change to the Exchange directory or store an object in your mailbox, the changes are stored into the appropriate database. The JET database engine does not, however, write the change directly to the database file (*.EDB). The change is first written to a transaction log file (*.log), and the database engine will copy the change to the actual database file (*.edb) at a later time. This method provides several advantages:
Both of these advantages suggest that storing the database files and the transaction logs on different drives is most efficient. If you store the transaction logs on a separate drive, the database engine can store data simultaneously to the transaction logs while the other Exchange services use the other drive(s) for other purposes. Furthermore, if the drive containing the database files fails, you can always re-create the database from the transaction logs.
When you install Exchange, you have the option of running the Exchange Optimizer. This program will examine the hard disks attached to the system and suggest the best possible location for each of the components. It will generally suggest locating the database files and transaction logs on different drives. To achieve the best possible performance, you should usually let the Optimizer move the files the way it suggests.
One way to improve a server's performance is to locate the transaction logs on a partition formatted with the FAT file system. FAT is a bit faster than, for example, the NTFS file system for storing sequential data. All the other server components should be located on an NTFS partition.
The size of a transaction log is always 5MB (except for the Directory Synchronization database, which uses 1MB transaction log files), or more specifically 5,242,880 bytes. If a log file is of different size, it is most likely corrupt.
Because the changes to any database are written first into the transaction logs and only afterward to the database itself, the most current data will be the database plus the latest transactions in the transaction log. The point in the transaction log where data has been written to the database is indicated by a checkpoint file called EDB.CHK.
There are several transaction log files (*.log) in each of the data directories. The one in use is called EDB.LOG. When this file becomes full, it will be renamed EDB00001.LOG and a new file will be opened and named EDB.LOG. When this file becomes full it will be renamed EDB00001.LOG and a new EDB.LOG file will be created, and so on. The log files other than the EDB.LOG are called old log files; the smaller the number the older the log file is.
The old log files together with a backup of the database file can be used to recover a database in case of a hardware failure or any event that will corrupt the database. You do the recovery by restoring the old transaction files using the backup program and then letting the information store service "replay" the transaction logs into the database.
The database engine will not delete the old log files, and in time they can grow to take all available disk space. The administrator can delete the log files by hand, but this is an extremely unadvisable solution because the administrator cannot know which of the transaction logs have been written into the database file, and therefore might inadvertently delete some data. Also, if the log files are deleted they cannot be used to recover the database in case of a hardware failure. A controlled way to delete the log files is to use a backup software that supports Exchange, such as the NT Backup program. After all files, the database file, and the transaction logs have been successfully backed up, the backup program will delete all log files that have been committed to the actual database. The backup and restore processes are discussed in detail in the section "Backing Up and Restoring the Exchange Environment," later in this chapter.
The administrator can also define the directory and information store services so that they will always use the same transaction log. This function is called circular logging, and you set it from the Advanced property page on the server's property window. Circular logging means that the transactions will be written into the transaction log file as usual, but instead of creating a new file each time the file becomes full, the database engine will delete each transaction from the transaction log immediately after it has been committed into the database file. This means that you will save a lot of disk space because there will be no transaction log files to store. On the other hand, the log files cannot be used to re-create the database file if it becomes corrupt.
In each data directory there are two log files called RES1.LOG and RES2.LOG. These files are called the reserved logs. The purpose of these files is to reserve some room on the log file disk. When the EDB.LOG file becomes full the service stores the file as an old log file and tries to create a new EDB.LOG file. If there is not enough space to create the new file, the database engine will inform the service of this and request that the service terminate itself. To ensure that no data is lost, the service will use the reserved logs to store all unstored entries and then terminate itself.
In time, the data in the database files can become fragmented and can decrease server performance. There are two ways to perform maintenance on the database files. Most of the maintenance is automatic and is done while the server is up and running. This maintenance is called online maintenance, and is governed by two settings in the administrators program:
Online maintenance will defragment the databases, but it will not decrease the size of the databases. Space will only be freed from deleted objects and marked available to other objects. If you wish to decrease the size of the database files and reclaim unused disk space, you have to perform offline maintenance.
As an administrator you can also perform offline maintenance on the database files, but to do this you first must stop the corresponding service. Thus offline maintenance cannot be performed while the server is in use. You use the EDBUTIL.EXE database utility to do offline maintenance.
You should perform offline maintenance on a new server at least once a month. Monitor closely the performance of the server and particularly the directory and information store databases before and after running the EDBUTIL.EXE utility (for details on monitoring your Exchange server see Chapter 21, "Monitoring and Preventing Problems"). This will tell you how often you should run the utility.
You use the EDBUTIL.EXE utility to perform several different functions on the JET databases (the appropriate command-line switch is shown in parentheses):
As Exchange administrator, you should be concerned with only the three first options of the EDBUTIl.EXE utility. The database upgrade is not currently used and the database dump file can be used only by the JET developers.
An Exchange administrator most often uses the EDBUTIL utility to perform offline maintenance on the databases, such as defragment the database and reclaim unused disk space. To do offline maintenance the Exchange server has to be stopped. After this the administrator will run the EDBUTIL.EXE using the /d switch and possible optional switches.
You can use the /ispriv, /ispub, and /ds optional switches only if you are running the utility from the server computer. These switches will read the database directories from the registry and will not work if run remotely.
Defragmenting a database using the EDBUTIL.EXE performs essentially the same operation as the scheduled server online maintenance. The difference between these two is that offline defragmentation will reclaim unused disk space, whereas online defragmentation will only mark space taken by deleted objects as unused, and the database file size will not change.
Due to the online maintenance procedure, you should not need to perform offline maintenance on the database files very often. Smaller sites should not have to perform this procedure at all. If you have, however, deleted large amounts of objects from either of the information store databases, it is advisable to perform offline defragmentation to reclaim the disk space. You should also perform offline defragmentation every now and then and monitor closely how it affects your server performance.
Offline defragmentation requires a lot of free disk space because the EDBUTIL.EXE will essentially create a copy of the database. You will need a free space that is approximately the same size as the database file. The copy can be stored on another disk.
You can use the EDBUTIL.EXE utility to check the consistency of a database. An example of a consistency error is the unread counter; sometimes when you read a message, the header is changed from bold to plain text but the unread counter is not decreased. This is a consistency error, and can be corrected using the EDBUTIL.EXE utility.
You can also use the EDBUTIL.EXE utility to recover a database. The utility examines each record in the database and rewrites a recovered copy of the record into a copy of the database. You should use this option only if the database cannot be restored from a backup.
Recovery requires a lot of free disk space, since the EDBUTIL.EXE will essentially create a copy of the database. You will need a free space which is approximately the same size as the database file. The copy can be stored on another disk.
The ISINTEG.EXE utility checks and repairs the Exchange Information Store databases on the JET database level. You use this utility, for example, when you are restoring an offline backup or when you suspect that the database has been corrupted. The ISINTEG.EXE is saved in the \EXCHSRVR\BIN directory. You can get information on the utility's command-line switches by typing the command ISINTEG.EXE.
You need to back up the Exchange system like you do any important data processing system. You can use several different tools to create backups of the Exchange system. The best results can be achieved by using a backup software that supports Exchange, such as the NT Backup utility. You have two ways to back up an Exchange system: you can take a backup offline or online.
Taking an offline backup means that you stop the Exchange server and take a file-level backup of the whole Exchange directory structure or of selected subdirectories. This method has several disadvantages:
When you restore a file-level backup, some of the global unique identifiers (GUIDs) used in the restored database might be in conflict with existing GUIDs. This will result in a failure to start the Information Store service with the error -1011. To correct this you have to run the ISINTEG.EXE utility with the -patch switch.
When you have installed a new server, take a full offline backup of the whole server, including the NT and the Exchange environment. When you take online backups in the future, only the information store and the directory databases will be backed up. If you happen to lose the whole server it will be easier to restore it from a backup than start installing it from scratch.
You should also have a backup of your NT server environment, including the registry entries.
Online backup means that you take the backup when the Exchange server is up and running. This is the preferred backup method, because the procedure will also purge the log files. When you do an online backup it is also possible to use incremental and differential backup methods, which will enable you to take a backup of a large site as well.
Making an online backup will create a backup of only the information store and directory databases. If you want to back up the other Exchange components, you must use the offline backup method. It is recommended that you take a full offline file backup of the Exchange server files right after the server has been installed, and keep updating the backup every now and then.
When you install the Exchange server or administrator program on an NT server, the installation program will also install a new copy of the Windows NT Backup utility. The new version includes some new functionality that enables you to make online backups from an Exchange server.
If you do not want to install a complete copy of the administrator program on the NT machine from which you want to take the backups, you can also copy the new version of NT Backup from the Exchange server CD. The file is called NTBACKUP.EXE and can be found in the platform-specific directory under SETUP.
Table 20.2. illustrates the sizes, versions, and dates of the different versions of the NTBACKUP.EXE file.
Size |
Date |
Version |
Description |
716,560
|
3-8-96
|
4:00a
|
Includes support for Microsoft Exchange On-Line Backup. Ships With Microsoft Exchange Server.
|
675,488
|
3-8-96
|
4:00a
|
No Microsoft Exchange Extensions. Ships With Windows NT Service Pack 4.
|
675,504
|
9-23-95
|
10:57a
|
No Microsoft Exchange Extensions. Ships with Windows NT Server 3.51. |
The new backup utility has a new function in the Operations menu called Microsoft Exchange. When you select this function, the backup utility will display a window asking for the name of an Exchange server to which to connect (see Figure 20.3.). You can also start the Exchange Directory and Information Store services if necessary. After you have defined the server to connect to, the program will display all databases that you can back up.
Figure 20.3. NTBackup Microsoft Exchange dialog box.
After you have selected the server, the backup program will establish a connection to the selected server and get some information about the organization. The backup program will then show a list of all the sites and servers within the organization (see Figure 20.4.). You can back up all the servers to which you have an RPC-capable connection. In this window, you can also select to back up only the Information Store or the Directory database, or both, on selected servers.
Figure 20.4. NTBackup showing an Exchange organization.
After you have selected the servers and databases to be backed up, click the Backup button. The program will display the Backup Information dialog box, in which you can define the settings for the backup process (see Figure 20.5).
Figure 20.5. The Backup Information dialog box.
Figure 20.6. The Backup Status dialog box.
When you connect to an Exchange server using the NTBACKUP program to perform a full backup, the server will first store the current checkpoint from the EDB.CHK file. This checkpoint points to the record in the transaction log files that has been last committed to the database. The next step is to back up the database files *.EDB. In the beginning of the database backup the server will create a patch file (*.PAT) that will be used to store all changes to the transaction logs written during the backup process.
After the databases have been backed up, all transaction logs created during the backup process will be backed up. After this the process will write any patch files onto the backup tape. And finally the process will delete all transaction log files created before the current checkpoint stored in the beginning of the process.
The process is a bit different if you are using the differential or incremental backup method, because these methods take only a backup of the transaction logs.
There are four different backup methods you can use when making an online backup.
The best possible backup solution is to take a full backup every night of all Exchange databases. When your site grows in size, this can become impossible, because it will not be possible to take a full backup during one night. In such a case you can either upgrade your backup hardware, use more than one device to take the backup, or combine full backup with either the incremental backup or differential backup.
Never combine the incremental and differential backup methods together.
If you want to combine two backup methods, you should select the time to take the full backup so that it will not matter if the backup process is not finished during one night. Usually selecting Friday for the full backup is the best option. Then on Monday evening take the first incremental or differential backup, on Tuesday the second, and so on. The selection of the second backup method is based on the amount of data to be backed up. If you use incremental backup, only the changes made since the last backup (full or incremental) will need to be backed up, thus minimizing the time to take the backups during the week. If you use differential backup, the backup process will take a backup of all changes made since the last full backup on a Friday, thus increasing the backup time toward the end of the week.
Another thing to consider is the time you need for a full restore in case of a system failure. If you use full/incremental backup, you need the full backup tape plus all the incremental backups to do a full restore. If you use the full/differential backup method, you will need only the full backup plus the last differential backup to do a full restore.
You can run the restore process offline or online much the same way as you run the backup process. During an offline restore you restore all or partial contents of the Exchange directory structure on the file level. As mentioned earlier, you should take a full offline backup of the Exchange server every now and then, so that in case of a total system failure you can restore the entire Exchange environment without having to reinstall Exchange. To perform an offline restore, any Exchange services have to be stopped.
When you restore a file-level backup some of the global unique identifiers (GUIDs) used in the restored database may be in conflict with existing GUIDs. This will result in a failure to start the Information Store service with the error -1011. To correct this you have to run the ISINTEG.EXE utility with the -patch switch.
You do an online restore in much the same way as you do an online backup. The first thing you do is to establish a connection to an Exchange server in the organization. After that you can select the servers and databases that you want to restore. When you click on the Restore button, the program will display the Restore Information dialog box, where you can select the following options for the restore process (see Figure 20.7).
Figure 20.7. The Restore Information dialog box.
When you have defined the appropriate options, click OK. The program will display the Restore Status dialog box showing the status of the restore process (see Figure 20.8).
Figure 20.8. The Restore Status dialog box.
After the restore process is finished, you should run the IS/DS Consistency Check to check the consistency between the information store and the directory databases.
After you have installed your Exchange server, you should plan a suitable backup method and also go through the steps needed to perform a restore of your backup. In any large site you should always have an ample supply of backup hardware available. In some sites it might even be justifiable to keep a backup server available, ready with NT installed on it. In case of a system failure the only thing you would need to do is rename the server appropriately and restore your backups on the server, and you would be up and running again.
All the administration access right information on the Exchange server is stored in the Directory database. The administration rights are always defined to a certain NT user security identifier (SID). Because the SIDs are unique and will never be reused after they are deleted, you should always have a backup of the NT operating system files as well as Exchange files. If for some reason you have to restore a whole directory database, you will not be able to start any services if you do not have access to the same domain database that the original server was using, i.e. if you can not use the same user account (the same SID) to start and administer the service. Because of this it is highly risky to install the Exchange server onto a Primary Domain Controller in a domain with no Backup Domain Controllers; if you happen to lose the machine, you will lose the domain database, and you will not be able to restore your directory database and use it.
If you do not want to use the NT Backup program to take backups of the Exchange environment, many independent software vendors are including Exchange support in their backup products. You should view the ISV information page on Microsoft's WWW site to check whether your favorite backup software has support for Exchange. The page is located at the URL http://www.microsoft.com/Exchange/ExIsv. Search for the word Backup to obtain a list of all ISVs producing backup software for Exchange.
The Exchange Message Transfer Agent is one of the core services of an Exchange server, which must be running before the server can be considered usable. The MTA takes care of all message transfer within the server from one component to another (for example, from connector to information store) and also all message transfers between two servers within the same site. Furthermore, the MTA runs the site and X.400 connectors if they have been defined to the system. And the MTA is the service that expands the distribution lists.
The most important thing about maintaining the MTA and perhaps the whole Exchange server is to constantly keep an eye on the MTA queues. There are several ways to do this. You can open the MTA property window in the Administrator program and look at the Queues property page (see Figure 20.9). The Queue name drop-down list contains one line for each of the queues defined on this server. The list will also show the number of items in each of the queues. You can view the details of messages in the queue and delete messages, if necessary.
Figure 20.9. The MTA Queues property page.
Another way to monitor the MTA queues is to use the Performance Monitor. The are several counters that you can monitor that will tell you with a quick glance how the Exchange server is doing. The performance monitor is discussed in detail in the following Chapter 21.
The MTA can become corrupted and will not start. In such a case you should use the MTACHECK utility to fix errors within the MTA environment. This utility examines the MTA database files (*.DAT) for damaged objects, which it will then place into files that the administrator can examine. You should be careful when you run the MTACHECK utility, because it can remove data from the database that cannot be restored. When you run the MTACHECK all the damaged objects will be placed into *.DAT files into the MTADATA\MTACHECK.OUT directory.
Before you run the MTACHECK utility you should always empty the MTACHECK.OUT directory from any old *.DAT files. Then go into the EXCHSRVR\BIN directory and run the MTACHECK.EXE utility. The utility will find the MTA files automatically and will report any damaged objects found.
In order to ensure smooth operation of the different connectors configured in the system the administrator should constantly monitor the connector queues. The MTA queues were discussed earlier in this chapter. On top of the MTA queues the Internet Mail Connector and the MS Mail Connector have their own queues, which can be seen through each connector's property window.
All the connector queues can be monitored through the performance monitor as well.