With the exception of backup and recovery, no administration tasks are more important than maintenance, monitoring, and queue tracking. You must maintain Microsoft Exchange Server 2003 to ensure proper flow and recoverability of message data. You need to monitor Exchange Server to ensure that services and processes are functioning normally, and you need to track Exchange Server queues to ensure that messages are being processed.
This section examines message tracking, protocol logging, and diagnostic logging. You use these features to monitor Exchange Server and to troubleshoot messaging problems.
You use message tracking to monitor the flow of messages into the organization and within it. With message tracking enabled, Exchange Server maintains daily log files with a running history of all messages transferred within the organization. You use the logs to determine the status of a message, such as whether a message has been sent, received, or is waiting in the queue to be delivered. Because Exchange Server handles postings to public folders in much the same way as e-mail messages, you can also use message tracking to monitor public folder usage.
Tip
Tracking logs can really save the day when you’re trying to troubleshoot delivery and routing problems. The logs are also useful in fending off problem users who blame e-mail for their woes. Users can’t claim they didn’t receive e-mails if you can find the messages in the logs.
Each Exchange server in your organization can have a different message logging setting. Standard message tracking allows you to search for messages by standard header information (date, time, message ID), as well as by sender and recipient. Extended message tracking allows you to perform searches based on message subject lines, header information, sender, and recipient.
To configure message logging, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers, right-click the server you want to work with, and then select Properties. This displays the dialog box shown in Figure 17-1.
To enable standard logging, select the Enable Message Tracking check box.
To enable extended logging, select the Enable Subject Logging And Display check box and then select the Enable Message Tracking check box.
When prompted, note the path to the network share used for logging, such as \Mailer1Mailer1.log, and then click OK. You need to grant read access on this network share to users performing message tracking.
If you want Exchange to delete log files periodically, select the Remove Log Files check box and then type the logging interval in the Remove Files Older Than (Days) field. You must enter a value between 1 and 99. In most cases, you’ll want to keep log files at least 7 days.
Click OK.
You use the Message Tracking Center to search through the message tracking logs. The tracking logs are very useful in troubleshooting problems with routing and delivery. You can search the logs in several ways:
By message ID
By sender
By server that processed the messages
By recipient
By date
To begin a search, you must specify one or more of the previously listed identifiers as the search criteria. You must also identify a server in the organization that has processed the message in some way. This server can be the sender’s server, the recipient’s server, or a server that relayed the message.
To search through the message tracking logs, complete the following steps:
Start System Manager and then, in the console tree, double-click Tools and then select Message Tracking Center. You should now see the Message Tracking Center in the details pane as shown in Figure 17-2.
Set the search criteria using the following options:
Message ID. Specifies the ID of the message you want to search for
Sender. Sets the sender’s e-mail address
Server. Sets the name of one or more servers that processed the message within the organization
Recipients. Sets the e-mail address of one or more recipients
Logged Between. Searches for messages from a starting date and time to an ending date and time
Note
To search for messages, you’re required to identify only the name of a server that processed the message within the organization and the search interval. All other search parameters are optional. Keep in mind that only messages that match all the search criteria you’ve specified are displayed. If you want to perform a broad search, specify a limited number of parameters. If you want to focus the search precisely, specify multiple parameters.
Click Find Now to begin the search. Messages matching the search criteria are displayed. If you need to cancel the search operation, click Stop.
Select a message to view its message tracking history, as shown in Figure 17-3.
Exchange Server creates message tracking logs daily and stores them in the ExchsrvrServerName.log directory, where ServerName is the name of the Exchange server. Each log file is named by the date on which it was created, using the format YYYYMMDD.log, such as 20030925.log.
The log files are written as tab-delimited text, and they begin with a header that shows the following information:
A statement that identifies the file as a message tracking log file
The version of the Exchange System Attendant that created the file
A tab-delimited list of fields contained in the body of the log file
You can view the log files with any standard text editor, such as Microsoft Notepad. You can also import the log files into a spreadsheet or a database. Follow these steps to import a log file into Microsoft Office Excel 2003:
Start Excel 2003. Choose Open from the File menu. Use the Open dialog box to select the log file you want to open. Click Open.
The Text Import Wizard starts automatically. The wizard should detect all the appropriate settings, so click Finish immediately.
The log file should now be imported. You can view, search, and print the log as you would any other spreadsheet.
By default, Exchange Server saves all tracking log files. If you’d like to delete log files after a specified period of time, you’ll need to change the default settings by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers, right-click the server you want to work with, and then select Properties.
If you’d like to keep all log files, clear Remove Log Files. If you’d like Exchange Server to automatically delete log files at a specified interval, select Remove Log Files, and then type the logging interval in the Remove Files Older Than (Days) field. The logging interval must be a value between 1 and 99.
Click OK.
Protocol logging allows you to track commands that virtual servers receive from clients. You use protocol logging to troubleshoot problems with Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and Network News Transfer Protocol (NNTP). However, you shouldn’t use protocol logging to monitor Exchange activity. This is primarily because protocol logging is process and resource intensive, which means that Exchange server has to perform a lot of work to log activity related to a particular protocol.
When you enable protocol logging, you specify the properties that you want to track. The more properties you track, the more system resources protocol logging requires.
Table 17-1 summarizes key properties that you’ll want to track. The first column shows the name of the logging property. The second column shows the name of the field in the protocol log file.
Table 17-1. Key Protocol Logging Properties and Fields
Property Name | Log Field | Description |
|---|---|---|
Date | date | Connection date. |
Time | time | Connection time. |
Client IP Address | c-ip | IP address of the client making the request. |
User Name | cs-username | Account name of an authenticated user. |
Service Name | s-sitename | Name of the service processing the command. |
Server Name | s-computername | Server on which the log entry was generated. |
Server IP Address | s-ip | IP address of the server on which the log entry was generated. |
Method | cs-method | Protocol command sent by the client. |
Protocol Status | sc-status | Protocol reply code. |
Win32 Status | sc-win32-status | Microsoft Windows status or error code. Zero indicates success. |
Bytes Sent | sc-bytes | Bytes sent by the server. |
Bytes Received | cs-bytes | Bytes received by the server. |
Time Taken | time-taken | Length of time the action took in milliseconds. |
HTTP, SMTP, and NNTP support a slightly different set of properties. If a protocol doesn’t support a property, the related field is recorded with a dash (-) or a zero (0).
You enable protocol logging on each virtual server separately. You use HTTP virtual servers to track protocol logging for HTTP, Outlook Web Access, and Outlook Mobile Access.
To enable protocol logging for HTTP, complete the following steps:
Start Internet Information Services (IIS) Manager, right-click the Web site you want to work with, and then select Properties. In most cases, the Default Web Site is the one configured as the default HTTP virtual server.
On the General tab, select the Enable Logging check box. Use the Active Log Format selection list to choose one of the following log formats:
W3C Extended Log File Format. Writes the log in ASCII text following the World Wide Web Consortium (W3C) extended log file format. Fields are space-delimited, and each entry is written on a new line. This style is the default.
Microsoft IIS Log File Format. Writes the log in ASCII text following the IIS log file format. Fields are tab-delimited, and each entry is written on a new line.
NCSA Common Log File Format. Writes the log in ASCII text following the National Center for Supercomputing Applications (NCSA) Common log file format. Fields are space-delimited and each entry is written on a new line.
ODBC Logging. Writes each entry as a record in the Open Database Connectivity (ODBC)-compliant database you specify.
Click Properties to display a dialog box similar to the one shown in Figure 17-4. You can now set the log time period. In most cases you’ll want to create daily or weekly logs, so select either Daily or Weekly.
Use the Log File Directory field to set the main folder for log files. By default, log files are written to a subdirectory of %SystemRoot%System32LogFiles.
Use the Log File Name field to determine the subdirectory and the name format used with the log files. The specific directory used for logging and the log file name depend on the type of virtual server you’re configuring and the log time period. For example, if you’re configuring the default SMTP virtual server with daily log files, the full path to the log file subdirectory is %SystemRoot%System32LogFilesSmtpSvc1 and the log file is named using the format EXYYMMDD.log, such as EX000925.log.
If you selected W3C Extended Log File Format, click the Advanced tab, and then choose the fields that should be recorded in the logs.
Click OK twice.
You enable protocol logging on each virtual server separately. You use SMTP virtual servers to track protocol logging for SMTP mail submission and SMTP mail transport. You use NNTP virtual servers to track protocol logging for NNTP newsgroups.
To enable protocol logging for SMTP or NNTP, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
In the console tree, navigate to the Protocols container. Expand Servers, expand the server you want to work with, and then expand Protocols.
Expand SMTP or NNTP as appropriate. Right-click the virtual server you want to work with, and then select Properties.
On the General tab, select the Enable Logging check box. Use the Active Log Format selection list to choose one of the following log formats:
W3C Extended Log File Format. Writes the log in ASCII text following the W3C extended log file format. Fields are space-delimited, and each entry is written on a new line. This style is the default.
Microsoft IIS Log File Format. Writes the log in ASCII text following the IIS log file format. Fields are tab-delimited, and each entry is written on a new line.
NCSA Common Log File Format. Writes the log in ASCII text following the NCSA Common log file format. Fields are space-delimited and each entry is written on a new line.
ODBC Logging. Writes each entry as a record in the ODBC-compliant database you specify.
Click Properties to display a dialog box similar to the one shown previously in Figure 17-4. You can now set the log time period. In most cases you’ll want to create daily or weekly logs, so select either Daily or Weekly.
Use the Log File Directory field to set the main folder for log files. By default, log files are written to a subdirectory of %SystemRoot%System32LogFiles.
Use the Log File Name field to determine the subdirectory and the name format used with the log files. The specific directory used for logging and the log file name depend on the type of virtual server you’re configuring and the log time period. For example, if you’re configuring the default SMTP virtual server with daily log files, the full path to the log file subdirectory is % SystemRoot%System32LogFilesSmtpSvc1 and the log file is named using the format EXYYMMDD.log, such as EX000925.log.
If you selected W3C Extended Log File Format, click the Extended Properties tab and then choose the fields that should be recorded in the logs.
Click OK twice.
Protocol log files can help you detect and trace problems with HTTP, SMTP, and NNTP. By default, protocol log files are written to a subdirectory of %SystemRoot%System32LogFiles. You can use the logs to determine the following:
Whether a client was able to connect to a specified virtual server and if not, what problem occurred
Whether a client was able to send or receive protocol commands and if not, what error occurred
Whether a client was able to send or receive data
How long it took to establish a connection
How long it took to send or receive protocol commands
How long it took to send or receive data
Whether server errors are occurring and if so, what types of errors are occurring
Whether server errors are related to Windows or to the protocol itself
Whether a user is connecting to the server using the proper logon information
Most protocol log files are written as ASCII text. This means you can view them in Notepad or another text editor. You can import these protocol log files into Excel 2003 in much the same way as you import tracking logs.
Log files, written as space-delimited or tab-delimited text, begin with a header that shows the following information:
A statement that identifies the protocol or service used to create the file
The protocol, service, or software version
A date and time stamp
A space-delimited or tab-delimited list of fields contained in the body of the log file
If you recorded the log files in an ODBC database, you’ll need to perform database queries to search for log entries. Contact your database administrator for assistance.
You use diagnostic logging to detect performance problems related to Exchange services. Unlike other logging methods, diagnostic logs aren’t written to separate log files. Instead, log entries are written to the Windows event logs and you use Event Viewer to monitor the related events.
All Exchange services record significant events in the Windows event logs. For key services, however, you can configure additional levels of logging and then use the additional information to diagnose performance problems.
Like protocol logging, diagnostic logging can significantly affect the performance of Exchange Server. For this reason, you should enable diagnostic logging only when you’re trying to troubleshoot a performance problem. When you do enable it, you should select the level of logging that makes the most sense.
Exchange Server supports four levels of diagnostic logging:
None. The default level of diagnostic logging. At this level, Exchange Server records only significant events. These events are written to the application, system, and security event logs along with other information, warnings, and error events generated by Exchange services.
Minimum. Writes summary entries in the event logs. At this level, Exchange Server records one entry for each major task it performs. You can use minimum logging to help identify where a problem might be occurring but not to pinpoint the exact problem.
Medium. Writes both summary and detailed entries in the event logs. At this level, Exchange Server records entries for each major task performed and for each step required to complete a given task. Use this logging level once you’ve identified where a problem is occurring and need to get more information to resolve it.
Maximum. Provides a complete audit trail of every action that a service performs. At this level, Exchange Server records everything it is doing, and, as a result, server performance is severely affected. You’ll need to watch the log files closely when you use this level. If you don’t, they might run out of space.
Table 17-2 provides a summary of Exchange services that support diagnostic logging. Entries written to the event logs are recorded according to the event source that generated the event. The event source relates directly to an Exchange service that you’ve configured for diagnostic logging. You can use the category of an event to determine what major task is being performed by the event source and thus troubleshoot a related problem.
Table 17-2. Exchange Services That Support Diagnostic Logging
Service Name | Event Source | Description |
|---|---|---|
- | MSExchangeActiveSyncNotify | Provides Microsoft Active-Sync notification services |
Microsoft Exchange Calendar Connector | MSExchangeCalCon | Allows sharing of Lotus Notes and Novell Group-Wise Free/Busy information |
- | MSExchangeDSAccess | Allows Exchange to access Active Directory |
- | MSExchangeAL | Allows users to address e-mail using address lists |
- | MSExchangeMU | Replicates Exchange configuration information to the IIS metabase |
Microsoft Exchange Connector for Novell GroupWise | LME-GWISE | Links Exchange Server and Novell GroupSise |
Microsoft Exchange Connector for Lotus Notes | LME-Notes | Links Exchange Server and Lotus Notes |
Microsoft Exchange Router for Novell GroupWise | MSExchangeGWRtr | Routes messages between Exchange Server and Novell GroupWise |
Microsoft Exchange Directory Synchronization | MSExchangeADDXA | Synchronizes Active Directory with previous versions of Exchange Server |
Microsoft Exchange IMAP4 | IMAP4Svc | Provides Microsoft Exchange IMAP4 Services |
Microsoft Exchange Information Store | MSExchangeIS | Manages Microsoft Exchange Information Store |
Microsoft Exchange MTA Stacks | MSExchangeMTA | Provides Microsoft Exchange X.400 Services |
Microsoft Exchange POP3 | POP3Svc | Provides Microsoft Exchange POP3 Services |
Microsoft Exchange Routing Engine | MSExchangeTransport | Processes Microsoft Exchange message routing and link state information for SMTP |
MSExchangeSRS | Replicates Exchange information within the organization | |
Microsoft Exchange System Attendant | MSExchangeSA | Provides monitoring, maintenance, and Active Directory lookup services |
You configure diagnostic logging separately for each Exchange server in the organization. Logging begins immediately at the level you specify. The default logging level is None.
To enable diagnostic logging, complete the following steps:
Identify the performance problems that users are experiencing and use Table 17-2 to identify services on which you might want to configure diagnostic logging to resolve the performance problems.
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
Click the Diagnostics Logging tab shown in Figure 17-5.
Use the Services list to select a service you want to track. The Categories list should now display a list of major activities that you can track, such as replication, authentication, or connection.
In the Categories list, select an activity to track and then choose a logging level—Minimum, Medium, or Maximum. Repeat this step for other activity categories that you want to track.
As necessary, repeat Steps 5 and 6 for other services that you want to track.
Click OK.
To disable diagnostic logging, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
Click the Diagnostics Logging tab. Use the Services list to select each service in turn. Watch the Categories list. If any activities are being tracked, select the activity to track and then choose a logging level of None.
Click OK.
Events generated by diagnostic logging are recorded in the Windows event logs. The primary log that you’ll want to check is the application log. In this log you’ll find the key events recorded by Exchange services. Keep in mind that related events might be recorded in other logs, including the directory service, DNS server, security, and system logs. For example, if the server is having problems with a network card and this card is causing message delivery failure, you’ll have to use the system log to pinpoint the problem.
You access the application log by completing the following steps:
Start Computer Management. Click Start, point to Programs, point to Administrative Tools, and then select Computer Management.
In the console tree, right-click the Computer Management entry and choose Connect To Another Computer from the shortcut menu. You can now choose the server for which you want to manage logs.
Expand the System Tools node by clicking the plus sign (+) next to it, and then double-click Event Viewer. You should now see a list of logs as shown in Figure 17-6 on the following page.
Select Application.
Entries in the main panel of Event Viewer provide an overview of when, where, and how an event occurred. To obtain detailed information on an event, double-click its entry. The event type precedes the date and time of the event. Event types include the following:
Information. An informational event, generally related to a successful action.
Warning. Details for warnings are often useful in preventing future system problems.
Error. An error such as the failure of a service to start.
In addition to type, date, and time, the summary and detailed event entries provide the following information:
Source. The application, service, or component that logged the event.
Category. The category of the event, which is sometimes used to further describe the related action.
Event. An identifier for the specific event.
User. The user account that was logged on when the event occurred.
Computer. The name of the computer where the event occurred.
Description. In the detailed entries, this provides a text description of the event.
Data. In the detailed entries, this provides any data or error code output created by the event.
Use the event entries to detect and diagnose Exchange performance problems.
As an Exchange administrator, you should routinely monitor connections, services, servers, and resource usage. These elements are the keys to ensuring that the Exchange organization is running smoothly. Because you can’t be onsite 24 hours a day, you can set alerts to notify you when problems occur.
The Tools node in System Manager has a special area that you can use to track the status of Exchange servers and connectors. To access this area, follow these steps:
Start System Manager.
Expand Tools, and then expand Monitoring And Status.
Select Status in the console tree.
Note
By default, you are connected to the local Exchange server or the last server you worked with. To connect to a different Exchange server, right-click Status and then select Connect To. Use the Select Exchange Server dialog box to select the server you want to view.
In the right pane, you should now see the status of the current Exchange server and each connector configured for use on this server. The status is listed as either of the following:
Available. The server or connector is available for use.
Unreachable. The server or connector isn’t available and a problem might exist.
In the Name column you might also see icons that give further indication of the status of a given server or connector:
A red circle with an X indicates that a critical monitor has exceeded its threshold value or the connector or server is unreachable.
A yellow triangle with an exclamation point (!) indicates that a warning monitor you’ve set for a server has exceeded its threshold value.
Tip
To get the latest status on a server and its connectors, right-click the Status node in the console tree, and then select Refresh. This refreshes the view, ensuring that you have the latest information.
You’ll learn more about configuring server monitors in the following section, "Monitoring Server Performance and Services."
Exchange monitors provide a fully automated method for monitoring server performance and tracking the status of key services. You can use Exchange monitors to track the following:
Virtual memory usage
CPU utilization
Free disk space
SMTP and X.400 queues
Windows service status
Using notifications, you can then provide automatic notification when a server exceeds a threshold value or when a key service stops.
Note
Windows performance monitors are an alternative to Exchange monitors. You use these monitors in the Windows Performance Monitor utility as discussed in Chapter 3 of Microsoft Windows Server 2003 Administrator’s Pocket Consultant (Microsoft Press, 2003).
Virtual memory is critical to normal system operation. When a server runs low on virtual memory, system performance can suffer and message processing can grind to a halt. To counter this problem, you should set monitors to watch virtual memory usage. You can then increase the amount of virtual memory available on the server or add additional RAM as needed.
You configure a virtual memory monitor by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
On the Monitoring tab, click Add. In the Add Resource dialog box, select Available Virtual Memory, and then click OK. As shown in Figure 17-7, you’ll see the Virtual Memory Thresholds dialog box.
In the Duration (Minutes) field, type the number of minutes that the available virtual memory must be below a threshold to change the state. Normally, you’ll want to set a value of 5 to 10 minutes.
To set a warning state threshold, select the Warning State (Percent) check box, and then select the smallest percentage of virtual memory your server can operate on before issuing a warning state alert. In most cases you’ll want to issue warnings when less than 10 percent of virtual memory is available for an extended period of time.
To set a critical state threshold, select the Critical State (Percent) check box, and then select the smallest percentage of virtual memory your server can operate on before issuing a critical state alert. In most cases you’ll want to issue critical alerts when less than 5 percent of virtual memory is available for an extended period of time.
Click OK. For automated notification, you must configure administrator notification.
You can use a CPU utilization monitor to track the usage of a server’s CPUs. When CPU utilization is too high, Exchange Server can’t effectively process messages or manage other critical functions. As a result, performance can suffer greatly. CPU utilization at 100 percent for an extended period of time can be an indicator of serious problems on a server. Typically, you’ll need to reboot a server when the CPU utilization is stuck at maximum utilization (100 percent).
You configure a CPU monitor by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
On the Monitoring tab, click Add. In the Add Resource dialog box, select CPU Utilization, and then click OK. As shown in Figure 17-8 on the following page, you’ll see the CPU Utilization Thresholds dialog box.
In the Duration (Minutes) field, type the number of minutes that the CPU usage must exceed to change the state. Normally, you’ll want to set a value of 5 to 10 minutes.
To set a warning state threshold, select the Warning State (Percent) check box, and then select the maximum allowable CPU before issuing a warning state alert. In most cases you’ll want to issue warnings when CPU usage is 95 percent or greater for an extended period.
To set a critical state threshold, select the Critical State (Percent) check box, and then select the maximum allowable CPU before issuing a critical state alert. In most cases you’ll want to issue warnings when CPU usage is at 100 percent for an extended period.
Click OK. For automated notification, you must configure administrator notification.
Exchange Server uses disk space for data storage, logging, tracking, and virtual memory. When hard disks run out of space, the Exchange server malfunctions and data gets lost. To prevent serious problems, you should monitor free disk space closely on all drives used by Exchange Server.
You configure a disk monitor by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
On the Monitoring tab, click Add. In the Add Resource dialog box, select Free Disk Space, and then click OK. As shown in Figure 17-9, you’ll see the Disk Space Thresholds dialog box.
Use the Drive To Be Monitored selection list to choose a drive you want to monitor, such as C:.
To set a warning state threshold, select the Warning State (MB) check box, and then select the smallest disk space (in MB) the server can operate on before issuing a warning state alert. Typically, you want Exchange Server to issue a warning when a drive has less than 100 MB of disk space.
To set a critical state threshold, select the Critical State (MB) text box, and then select the smallest disk space (in MB) your server can operate on before issuing a critical state alert. Typically, you’ll want Exchange Server to issue a critical alert when a drive has less than 25 MB of disk space.
Click OK. Repeat this procedure for all the drives that Exchange Server uses except M. For automated notification, you must configure administrator notification.
If a messaging queue grows continuously, it means that messages aren’t leaving the queue and aren’t being delivered as fast as new messages arrive. This can be an indicator of network or system problems that might need your attention.
You configure a queue monitor by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
On the Monitoring tab, click Add. To set an SMTP queue monitor, select SMTP Queue Growth, and then click OK. To set an X.400 queue monitor, select X.400 Queue Growth, and then click OK.
To set a warning state threshold, select Warning State, and then type the number of minutes that the queue can grow continuously before issuing a warning state alert. A queue that’s growing continuously for more than 10 minutes is usually an indicator of a potential problem.
To set a critical state threshold, select Critical State, and then type the number of minutes that the queue can grow continuously before issuing a critical state alert. In most cases a queue that’s growing continuously for more than 30 minutes indicates a serious problem with the network or the server.
Click OK. For automated notification, you must configure administrator notification.
Exchange monitors can track the status of Windows services as well. If a service you’ve configured for monitoring is stopped, Exchange Server generates a warning or critical alert.
When you install an Exchange server, certain critical services are automatically configured for monitoring. These services are displayed on the Monitoring tab under the heading Default Microsoft Exchange Services, and they’re generally the following services:
Microsoft Exchange Information Store
Microsoft Exchange Message Transfer Agent (MTA) Stacks
Microsoft Exchange Routing Engine
Microsoft Exchange System Attendant
Simple Mail Transport Protocol (SMTP)
World Wide Web Publishing Service
When you configure service monitors, you can add them to the Default Microsoft Exchange Services heading or you can create your own heading for additional services. The key reason for grouping services under a common heading is to ease the administrative burden. Instead of having to configure separate entries for each service, you create a single entry, add services to it, and then set the alert type for all the services in the group.
You configure service monitors by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
On the Monitoring tab, click Add. In the Add Resource dialog box, select Windows 2000 Service, and then click OK. As shown in Figure 17-10, you’ll see the Services dialog box.
Type a name for the group of services for which you’re configuring the monitor.
Click Add. Select a service to add to the monitor, and then click OK. Repeat as necessary.
When any of the selected services stops running, an alert is issued. This can be either a warning alert or a critical alert, depending on the value you select in the When Service Is Not Running Change State To field.
Click OK. For automated notification, you must configure administrator notification as described in the section of this chapter entitled "Configuring Notifications."
If you don’t want to use a particular monitor anymore, you can remove it by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
Click the Monitoring tab. You should now see a list of all monitors configured on the server.
Select the monitor you want to delete, and then click Remove.
Click OK.
When you’re troubleshooting Exchange problems or performing maintenance, you might want to temporarily disable monitoring and in this way stop Exchange Server from generating alerts. To disable monitoring, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers. Right-click the server you want to work with, and then select Properties.
Click the Monitoring tab. You should now see a list of all monitors configured on the server.
Select the Disable All Monitoring Of This Server check box, and then click OK.
One of the key reasons to configure monitoring is to notify administrators when problems occur. You can configure two types of notification:
E-Mail. Used to send e-mail to administrators when a server or connector enters a warning or critical state
Script. Used to have Exchange Server execute a script when a server or connector enters a warning or critical state
The sections that follow explain how you can create and manage notifications.
You use e-mail notification to send e-mail to administrators when a server or connector enters a warning or critical state. You can select multiple recipients to be notified and you can select a specific server to use in generating the e-mail.
To configure e-mail notification, follow these steps:
Start System Manager.
Expand Tools, and then expand Monitoring And Status.
Right-click the Notification folder, point to New, and then click E-mail Notification. This displays the Properties dialog box shown in Figure 17-11
To specify the server that will monitor and notify users by e-mail, click Select, and then choose a server.
Use the Servers And Connectors To Monitor list box to choose the servers or connectors you want administrators to be notified about. The available options are as follows:
You can configure notification for either warning alerts or critical state alerts. Use Notify When Monitored Items Are In to choose the state that triggers notification.
Click To, and then select a recipient to notify. You can notify multiple users by selecting an appropriate mail-enabled group.
Click Cc, and then select additional recipients to notify. Again, you can notify multiple users by selecting an appropriate mail-enabled group.
Click E-mail Server, and then choose the e-mail server that should generate the e-mail message.
Use the Subject field to set a subject for the notification message. The default subject line specifies the type of alert that occurred and the item on which the alert occurred. These values are represented by the subject line %TargetInstance.ServerStateString% on %TargetInstance.Name%.
The message box at the bottom of the window sets the body of the message. In most cases you’ll want to edit the default message body. The default text tells administrators the following information:
%TargetInstance.Name% is the name of the server or connector that triggered the notification.
%TargetInstance.ServerStateString% is the type of alert.
%TargetInstance.QueuesStateString% is the reported status of queues.
%TargetInstance.DisksStateString% is the reported status of drives.
%TargetInstance.ServicesStateString% is the reported status of services.
%TargetInstance.MemoryStateString% is the reported status of virtual memory.
%TargetInstance.CPUStateString% is the reported status of CPUs.
Click OK. Repeat this procedure to configure notification for other servers and connectors.
You use script notification to have Exchange Server execute a script when a server or connector enters a warning or critical state. The script can execute commands that restart processes, clear up disk space, or perform other actions needed to resolve a problem on the Exchange server. The script could also generate an e-mail through an alternate gateway, which is useful if the Exchange server is unable to deliver e-mail.
To configure script notification, follow these steps:
Start System Manager.
Expand Tools, and then expand Monitoring And Status.
Right-click the Notification folder, point to New, and then click Script Notification. This displays the Properties dialog box shown in Figure 17-12.
To specify the server that will monitor and notify users by e-mail, click Select, and then choose a server.
Use the Servers And Connectors To Monitor list box to choose the servers or connectors you want administrators to be notified about. The available options are as follows:
You can configure notification for either warning alerts or critical state alerts. Use the Notify When Monitored Items Are In selection list to choose the state that triggers notification.
In the Path To Executable field, type the complete file path to the script you want to execute, such as C:ScriptsMynotificationscript.vbs. You can run any type of executable file, including batch scripts with the .bat or .cmd extension and Windows scripts with the .vb, .js, .pl, or .wsc extensions.
To pass arguments to a script or application, type the options in the Command Line Options field.
Click OK.
You can view all notifications configured in the organization with the Notification entry in System Manager. Start System Manager, expand Tools, expand Monitoring And Status, and then select Notifications.
Each notification is displayed with summary information depicting the following:
Name of the monitoring server
Items monitored
Action performed
State that triggers notification
To edit a notification, double-click it, and then modify the settings as necessary. When you’re finished, click OK.
To delete a notification, right-click it, and then select Delete. When prompted to confirm the action, click Yes.
As an Exchange administrator, it’s your responsibility to monitor Exchange queues regularly. Exchange Server uses queues to hold messages while they’re being processed for routing and delivery. If messages remain in a queue for an extended period, there could be a problem. For example, if an Exchange server is unable to connect to the network, you’ll find that messages aren’t being cleared out of queues.
Exchange Server supports two types of queues:
System queues. The default queues in the organization. There are three providers for system queues: SMTP, Microsoft MTA (X.400), and Messaging Application Programming Interface (MAPI).
Link queues. Created by Exchange Server when there are multiple messages bound for the same destination. These queues are accessible only when they have messages waiting to be routed.
You have direct access to MAPI, SMTP, and X.400 queues through the queue viewer. MAPI queues are used with connectors, such as Connector for Novell GroupWise or Connector for Lotus Notes. X.400 queues are used with the Microsoft MTA, which provides addressing and routing information for sending messages from one server to another. The MTA relies on X.400 transfer stacks to provide additional details for message transfer, and these stacks are similar in purpose to the Exchange virtual servers used with SMTP.
The key queues used with the Microsoft MTA are the following:
SMTP Mailbox Store. Contains SMTP messages in the mailbox store for MTA
Messages Waiting To Be Routed. Contains messages that are waiting to be routed
Each SMTP virtual server has several system queues associated with it. SMTP queues are used to hold messages in various stages of routing. The SMTP queues are as follows:
DSN Messages Pending Submission. Contains data source name (DSN) messages that have been acknowledged and accepted by the SMTP service but haven’t been processed yet.
Failed Message Retry Queue. Contains messages that can’t be routed because the destination server is unreachable.
Local Delivery. Contains messages that are queued for local delivery—that is, messages that the Exchange server is waiting to deliver to a local Exchange mailbox.
Messages Awaiting Directory Lookup. Contains messages to recipients who have not yet been resolved in Active Directory.
Messages Pending Submission. Contains messages that have been acknowledged and accepted by the SMTP service but haven’t been processed yet.
Messages Queued for Deferred Delivery. Contains messages that are queued for deferred delivery.
Messages Waiting To Be Routed. Contains messages waiting to be routed to a destination server. Messages move from here to a link queue.
You access system and link queues by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
Expand Servers, expand the server you want to work with, and then select Queues.
As shown in Figure 17-13, the Queue Viewer provides an overview of the status of each queue:
On a busy server, messages are written to and read from the SMTP queue directory in rapid succession. Because of this, the disk drive used with the SMTP queue directory should be optimized for read/write performance. If it isn’t, Exchange might not be able to process messages fast enough, which could result in message processing delays of a few seconds, a few minutes, or even a few hours.
By default, the SMTP queue directory is placed on the same drive as the Exchange server installation: rootExchsrvrMailrootvsi#Queue, where root is the install drive for Exchange Server and # is the number of the SMTP virtual server, such as C:ExchsrvrMailrootvsi1Queue. You can change the location of the queue directory at any time. However, before you do this, you must stop the associated SMTP virtual server, which temporarily stops message processing. Because of this, you probably should make this change during nonbusiness or nonpeak usage hours.
To change the SMTP queue directory, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group in which the server you want to use is located.
In the console tree, navigate to the Protocols container. Expand Servers, expand the server you want to work with, and then expand Protocols.
In the console tree, expand SMTP. Right-click the virtual server that you want to work with, and then select Stop to halt message processing.
Right-click the virtual server entry again and then select Properties.
On the Messages tab, the Queue Directory field shows the current location of the SMTP queue. To change the queue directory location, click Browse and then use the Browse For Folder dialog box to choose a new queue directory.
Click OK to close the Properties dialog box. Next, right-click the virtual server entry in System Manager, and then select Start to resume message processing.
Select the Queues node and then click Refresh. The SMTP queues should be in the Ready state. Watch the queues to ensure messages are processing. If messages aren’t being processed, you might need to double-check the directory settings, the permissions, and the availability of drive space on the related hard drive.
You usually won’t see messages in queues because they’re processed and routed quickly. Messages come into a queue, Exchange Server performs a lookup or establishes a connection, and then Exchange Server either moves the message to a new queue or delivers it to its destination.
Messages remain in a queue when there’s a problem. To check for problem messages, use the Queue Viewer to examine the number of messages in the queues. If you see a queue with a consistent or growing number of messages, there might be a problem. Again, normally messages should come into a queue and then be processed fairly quickly. Because of this, the number of messages in a queue should gradually decrease over time as the messages are processed, providing no new messages come into the queue.
Whenever you click a Queues node in System Manager, you get a summary of the currently available queues for the selected node. These queues can include both system and link queues, depending on the state of the Exchange server.
Although queue summaries provide important details for troubleshooting message flow problems, you do have to know what to look for. The connection state is the key information to look at first. This value tells you the state of the queue. States you’ll see include these:
Active. An active queue is needed to allow messages to be transported out of a link queue.
Ready. A ready queue is needed to allow messages to be transported out of a system queue. When link queues are ready, they can have a connection allocated to them.
Retry. A connection attempt has failed and the server is waiting to retry.
Scheduled. The server is waiting for a scheduled connection time.
Remote. The server is waiting for a remote dequeue command (TURN/ETRN).
Frozen. The queue is frozen, and none of its messages can be processed for routing. Messages can enter the queue, however, as long as the Exchange routing categorizer is running. You must unfreeze the queue to resume normal queue operations.
Administrators can choose to enable or disable connections to queues. If connections are disabled, the queue is unable to route and deliver messages.
You can change the queue state to Active by using the FORCE CONNECTION command. When you do this, Exchange Server should immediately enable a connection for the queue, which allows messages to be routed and delivered from it. You can force a connection to change the Retry or Scheduled state as well.
Here is some other summary information that you might find useful in troubleshooting:
Time Oldest Message Submitted. Tells you when the oldest message was sent by a client. Any time the oldest message has been in the queue for several days, you have a problem with message delivery. Either Exchange Server is having a problem routing that specific message, or a deeper routing problem could be affecting the organization.
Number Of Messages. Tells you the total number of messages waiting in the queue. If you see a large number of messages waiting in the queue, you could have a connectivity or routing problem.
Total Messages Size (KB). Tells you the total size of all messages in the queue. Large messages can take a long time to deliver, and, as a result, they might slow down message delivery.
Time Next Connection Retry. When the connection state is Retry, this column tells you when another connection attempt will be made. You can use FORCE CONNECTION to attempt a connection immediately.
Use the queue summaries and queue state information to help you find queuing problems, as discussed in the earlier section of this chapter entitled, "Understanding Queue Summaries and Queue States." By default, the queues view is refreshed every 2 minutes. To change the refresh rate, click Settings in the Queue Viewer and then set a specific refresh rate of 1, 2, 5, or 10 minutes. To refresh the queue immediately, click Refresh on the toolbar or select Action, Refresh.
To manage queues, you must enumerate messages. This process allows you to examine queue contents and perform management tasks on messages within a particular queue.
The easiest way to enumerate messages is to do so in sets of 100. To display the first 100 messages in a queue, follow these steps:
Start System Manager, and then navigate to the Queues node on the server you want to work with.
If you select the Queues node, you should see a list of available queues in the details pane. Double-click the queue to display the Find Message dialog box.
Click Find Now. The search results are displayed in the lower portion of the Find Messages dialog box.
When a message is displayed in the Find Messages dialog box, you can double-click it to view message details, as shown in Figure 17-14. The details provide additional information that identifies the message, including a message ID that you can use with message tracking.
You can also specify message restrictions, including the specific number of messages to enumerate and the message state you want to search for, such as Retry. To do this, follow these steps:
Double-click the queue you want to work with. This displays the Find Messages dialog box.
Use the Number Of Messages To Be Listed selection list to choose the number of messages to enumerate. The available values are 100, 500, 1000, and 10,000.
Use Show Messages Whose State Is to restrict the enumeration by message state. For example, to find messages that are in the Retry state, select Retry, or to find messages that are Frozen, select Frozen.
Click Find Now.
Enabling outbound mail from queues makes them available for routing and delivery. Disabling outbound mail from queues makes them unavailable for routing and delivery.
To enable or disable outbound mail from queues, follow these steps:
Start System Manager, and then navigate to the Queues node on the server you want to work with.
To disable outbound mail from queues, click Disable Outbound Mail. Confirm the action when prompted by clicking Yes.
To enable outbound mail from queues, click Enable Outbound Mail. Confirm the action when prompted by clicking Yes.
In most cases you can change the queue state to Active by forcing a connection. Simply right-click the queue and then select Force Connection. When you do this, Exchange Server should immediately enable connections to the queue, and this should allow messages to be routed and delivered from it.
When you freeze a queue, all message transfer out of that queue stops. This means that messages can continue to enter the queue but no messages will leave it. To restore normal operations, you must unfreeze the queue.
You freeze and then unfreeze a queue by completing the following steps:
Start System Manager, and then navigate to the Queues node on the server you want to work with.
Right-click a queue, and then select Freeze.
When you’re done troubleshooting, right-click the queue, and then select Unfreeze.
Another way to freeze messages in a queue is to do so selectively. In this way, you can control the transport of a single message or several messages that might be causing problems on the server. For example, if a large message is delaying the delivery of other messages, you can freeze that message until other messages have left the queue. Afterward, you can unfreeze the message to resume normal delivery.
To freeze and then unfreeze individual messages, complete the following steps:
Start System Manager, and then navigate to the Queues node on the server you want to work with.
Right-click the queue and then select Find Messages. In the Find Messages dialog box, click Find Now.
Right-click the problem message, and then select Freeze. You can select multiple messages using Shift and Ctrl.
When you’re ready to resume delivery of the message, right-click the problem message, and then select Unfreeze.
You can remove messages from queues if necessary. To do this, follow these steps:
Start System Manager, and then navigate to the Queues node on the server you want to work with.
Right-click the queue and then select Find Messages. In the Find Messages dialog box, click Find Now.
Right-click the problem message. You can select multiple messages using Shift and Ctrl and then right-click as well. Select one of the following options from the shortcut menu:
Delete (With NDR). Deletes the selected messages from the queue and notifies the sender with a nondelivery report (NDR)
Delete (No NDR). Deletes the message(s) from the queue without sending an NDR to the sender
When prompted, click Yes to confirm the deletion.
Deleting messages from a queue removes them from the messaging system permanently. You can’t recover the deleted messages.