Exchange 2000 SMTP Logging and Archiving

Diagnose and report SMTP server communication with these helpful tools

Most people who use email aren't concerned about the details of email communication because email works—most of the time. When it doesn't work, the task of figuring out why falls to you, the Exchange administrator. SMTP is the Internet protocol that lets email systems communicate with one another. Let's look at options for configuring and using two Exchange 2000 Server SMTP tools: protocol logging and archiving.

SMTP Protocol Logging
Whenever a user makes an SMTP connection to or from your Exchange server, the server establishes an SMTP session, and the two hosts exchange a series of commands, data, and response codes. Figure 1, page 2, shows an example of a typical SMTP dialogue between two computers. The >>> chevrons indicate the commands the sending system issues, and the <<< chevrons indicate the receiving system's response. You can use the log of the two hosts' conversation for diagnostic and reporting purposes.

Enabling SMTP Protocol Logging
Before you configure your server for SMTP protocol logging, you must decide where to store the log files, how long you want to retain the logs, and how much data to record. Earlier Exchange releases required that you configure protocol logging on a per­Internet Mail Service (IMS) or per­Internet Mail Connector (IMC) basis; Exchange 2000 requires that you configure logging on a per­SMTP virtual-server basis.

To configure SMTP protocol logging, open the Microsoft Management Console (MMC) Exchange System Manager snap-in. Right-click the SMTP virtual server and select Properties. In the Properties dialog box, select the General tab, as Figure 2, page 2, shows. Enable logging and select the log file format from one of four options: Microsoft IIS Log File Format, NCSA Common Log File Format, W3C Extended Log File Format, or ODBC Logging.

Selecting ODBC Logging lets you write log data directly to an ODBC-compliant database. If you select this option, you need to manually create a database table to store the log data (use the database software you prefer, such as Microsoft SQL Server or Microsoft Access). A SQL Server template file named logtemp.sql is included in the C:winntsystem32inetsrv directory; you can use this file to create the necessary fields in the database table. Configuring IIS for ODBC logging is more complex than configuring IIS for the other three types of logging. For step-by-step instructions, see the Microsoft article "How To Configure ODBC Logging in IIS" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q245243). Although the article mentions Microsoft Internet Information Server (IIS) 4.0, the steps are also valid for Internet Information Services (IIS) 5.0.

After you implement ODBC logging, SMTP logging operation performance is subject to the database's performance. In addition, you must configure and manage the account you use for authentication.

The IIS format, National Center for Supercomputing Applications (NCSA) Common format, and World Wide Web Consortium (W3C) Extended format are text based—in other words, IIS writes the log data to one or more text files on the local system's disks. Each of the three logging formats lets you configure settings that control how large a log file becomes. After you select a log format, click the Properties button on the General tab in the Properties dialog box to display the Extended Logging Properties dialog box that Figure 3 shows. From this dialog box, you can configure sizing options, log location, and other format-specific settings. You can let the text-based logs grow to an unlimited size, or you can configure the rollover options to create new logs hourly, daily, weekly, monthly, or when logs reach a specific size. (You can't configure rollover options for pre­Exchange 2000 SMTP protocol logging.)

You can't use general metrics to determine how quickly a log will grow; logs grow at different rates depending on the level of SMTP traffic that passes through the server and the logging format you select. Whichever format or rollover option you select, periodically purge the accumulating log files. How often you purge the log files depends on the logging partition's free disk space and your organization's record-retention requirements. When the logging partition is full, IIS logging stops until space becomes available. This action doesn't affect processing and message-traffic delivery, but it does affect logging operations. You can use your favorite scripting language and a scheduled task to easily automate the deletion of old log files.

The Extended Logging Properties dialog box lets you specify the log location. The default path is C:winntsystemlogfilessmtpsvcn, where n uniquely identifies a virtual server. By default, Exchange has only one SMTP virtual server, so the path is C:winntsystemlogfilessmtpsvc1. If you add a second SMTP virtual server, the system will identify the second directory as C:winntsystemlogfilessmtpsvc2.

The names of the files in the smtpsvcn directory vary depending on the options you select. For example, if you select the IIS format with monthly log rollover, the log filename will begin with the letters in followed by two digits for the year and two digits for the month (e.g., in0201.log for January 2002). If you select daily W3C Extended logging, the filename will begin with the letters ex followed by six digits for the year, month, and day (e.g., ex020417 for April 17, 2002). The Extended Logging Properties dialog box displays the available naming conventions based on your selection. (For a detailed description of the naming conventions, see the Microsoft article "IIS Log File Naming Syntax" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q242898.)

If you select a rollover option based on a time period (e.g., daily), the date you use to generate the filename is based on midnight. However, the NCSA Common and IIS formats use midnight local time, whereas the W3C Extended format defaults to midnight Greenwich Mean Time (GMT). You can override the GMT default by selecting the Use local time for file naming and rollover option. Using the local time can be an advantage if you use the log data to generate daily-activity statistics because you open only one file to find all the entries for a 24-hour period.

After you enable and configure SMTP protocol logging, you need to restart the SMTP virtual server. Otherwise, the changes won't take effect.

Logging Flexibility
Exchange 5.x and 4.x offer four logging levels: none, minimum, medium, and maximum. The minimum level records only one line for each connection and indicates whether the system accepted the connection. (The first line in Figure 1 shows an example of a minimal level record.) The medium level captures the SMTP dialog between Exchange and the sending or receiving system, with the exception of the data stream Exchange sends after the SMTP DATA command. (Exchange 2000 uses the BDAT command instead of the DATA command, which makes SMTP communication much faster.) The medium setting produces log content similar to that shown in Figure 1. The maximum level includes medium setting content as well as the text stream Exchange sends after the DATA command lets you record the full message header and the visible text in the email message body. In Exchange 5.x and 4.x, the medium level typically provides the best compromise between log file size and usefulness; Exchange 2000 uses only the medium setting. The most flexible logging option (and the one I recommend) is the W3C Extended option, which gives you control over which data to write to the log file. (The other options log only a predefined data set.) You can select which fields to include in the W3C Extended format, but you can't select minimum, medium, or maximum logging levels. Table 1 lists the available fields for the three text-based logging options. (The description information in parentheses shows the field names that W3C Extended logging writes to the header line.)

The IIS and W3C Extended formats log the same information, but the W3C Extended option provides greater flexibility because it lets you log only the fields you need. Choose the fields by making selections on the Extended Properties tab, as Figure 4 shows. (This tab is visible only when you select W3C Extended logging.) IIS now provides Internet protocol support for Exchange 2000, including SMTP support. As a result, some field names are more applicable to HTTP concepts, and not all the fields available on the Extended Properties tab are applicable to SMTP logging. For example, the URI Stem, Host, User Agent, Cookie, and Referrer fields aren't applicable to SMTP logging.

Using the Data
Figure 5 shows a sample of Exchange 2000 SMTP protocol logging data. Lines 1 through 12 depict an outbound message's log entries; lines 13 through 22 show log entries for two inbound connections. Exchange 2000 logs a complete SMTP session differently from earlier Exchange releases, which used intermediate files to store the SMTP dialog, then merged those files into one master log file. This process maintained the SMTP commands and replies from connections in a contiguous block. Exchange 2000 writes commands and reply codes into the log as they complete, so log entries from simultaneous sessions might be interleaved.

In the bottom half of Figure 5, notice the log entries in bold. These five entries make up one of the inbound sessions. In this session, demo.com initiated a session, but before the session finished, a second session from Compaq.com began. On a busy server that accepts many simultaneous sessions, all the log entries for a single session might not be contiguous and might not even be anywhere near one another in the log file. To correlate such entries, you can use a spreadsheet application such as Microsoft Excel to associate data. For example, you might associate the date and connection time with the sending host's IP address or name.

You can use log-file data for general troubleshooting. For example, to explain how users receive messages when their addresses don't appear on the To or Cc lines, you can match the recipients specified in a RCPT TO command with addresses posted in a message header or the message's To and Cc lines. Or you can look for a remote system's message ID, such as the one on line 10 in the cs-uri-query column (021DD309F), to collaborate with another systems administrator to trace a message. To determine the maximum-size message a server will accept, you might also look for response codes that a receiving server returns after your server issues an EHLO command (e.g., 250-SIZE 60000000). You can also use the log data to generate reports. If another server attempts to use your server as a relay (assuming your server is properly configured to prevent unauthorized SMTP relays), the log file posts a numeric response code of 550 (which equates to Relaying Prohibited) in the protocol status (sc-status) field. A script can easily search this field and tally the number of reported 550 codes.

Archiving Messages
As I already mentioned, earlier Exchange releases let you capture the entire message text (including the header and body) in the SMTP protocol log when you set the logging level to maximum. Although this process sounds like a convenient troubleshooting tool, the resulting data is difficult to read and is less usable than data captured with other methods. If you need to capture the full data of an SMTP session, SMTP message archiving provides a usable format.

Archiving can be a useful diagnostic tool if your problem is related to formatting, content, or encoding. When you capture the message as an archive, you can examine the message header and message body line by line to determine whether the format is causing a particular problem. For example, one of my company's customers developed a Web application to send a report to employees as an HTML email message. The company MIME-encoded the message so that recipients could see the correct format when they opened the message in Outlook. But Outlook displayed the MIME-encoding information instead of translating the MIME content into HTML content. When we archived the messages, we discovered that the Web application inserted a blank line in the header at the wrong place. SMTP protocol requires that a message have two parts: a header and a message body. The protocol looks for a blank line to determine where the header stops and the message body begins. MIME-encoded messages include a set of tags in the message header and place other tags in the message body. When the customer's application inadvertently inserted a blank line, the MIME tags intended for the header were included in the message body, which caused Outlook to treat the message as plain text instead of MIME.

Installing and Configuring Archiving
Exchange 2000 uses a transport event sink, which is included in Exchange 2000 Service Pack 2 (SP2), to trap and archive SMTP messages as they move through the system. SP2 includes a VBScript script that you can use to install the sink, but because VBScript doesn't have a GUI, you must make a few registry edits to customize the configuration. To install the archive sink, apply Exchange 2000 SP2, then open a command prompt and change to the directory in which you installed the Exchange binaries. (The default location is C:program filesexchsrvrbin.) At the command prompt, enter

cscript archivesink_setup.vbs  install 1 c:Program Filesexchsrvrbin 

The 1 specifies the SMTP virtual server to which the sink should apply, so if you need to install the sink for other virtual servers, adjust this number appropriately. The path that follows 1 is the path to the DLL, which SP2 places in the exchsrvrbin directory. By default, the sink archives Messaging API (MAPI)­client-submitted outbound messages as well as SMTP-submitted inbound messages and ignores system messages and public-folder replication traffic. The sink archives messages as plain text .eml files and places those files in two directories: MAPI-Gateway Messages and SMTP Messages. You can override these defaults by editing values (not Active Directory—AD—registry values) below the HKEY_LOCAL_MACHINESOFTWAREMicrosoftExchangeArchiveSink registry subkey.

I recommend only one change: Move the default archive location. If you leave the archiving process unchecked or the system archives a large number of files because of a Denial of Service (DoS) attack or message loop, you might end up with a crashed server when the system partition runs out of disk space.

One possible archive location is a set of archive subdirectories you can create below the SMTP virtual server's working directory, assuming you moved the working directory from its default installation location (usually C:program filesexchsrvrmailroot) to a separate disk. Below mailroot you'll find a folder for each virtual server (e.g., vsi 1 for virtual server instance 1, vsi 2 for virtual server instance 2). In the appropriate vsi folder, create an archive folder, then create In and Out folders. After you create the folder structure, edit the SMTP Messages and MAPI-Gateway Messages registry subkeys, respectively, to direct the sink to archive in the new location. This process places the archived messages in the same location as the other files the virtual server uses and removes the archived messages from the system partition. Reboot the server to put any registry changes into effect. The system reads the registry subkeys only after the IIS Admin service starts. Because the Exchange services are dependent on the IIS Admin service, a server reboot is typically the easiest way to proceed.

When to Use SMTP Logging and Archiving
SMTP logging and archiving are two useful tools that can help you see the data moving into and out of your systems. Because of its storage overhead, archiving is a tool that you'll probably want to use only for specific troubleshooting situations. But don't treat SMTP logging as a diagnostic tool you activate only when you perceive a problem. Enable SMTP logging so that you have a record of commands and responses. This record can help you answer those "What happened?" questions and determine whether the system is behaving in a typical fashion.