Working within protocols for several years, one of the most invaluable tools that we have in our toolbox is the Network Monitor (one of the tools in the Microsoft Systems Management Server, Microsoft Windows 2000 Server, or Microsoft Windows Server 2003, and has a nice little FAQ here: Frequently Asked Questions About Network Monitor ) Commonly referred to as a ‘packet sniffer’, this handy tool can often diagnose client to server communication problems such as a client behaving badly, or a client that’s unable to reach the server at all (due to firewall issues, port configurations, mis-configured DNS.) In some cases however, packet sniffers don’t have the ability to tell you useful information about when your client and server said to each other (such as through an IPSEC or SSL Encrypted session.) That’s where we turn to Protocol Logging.
Protocol logging is really nothing more then having a virtual server record conversations between itself and clients to either a text based file, or some database through an ODBC connection. It’s very similar to a packet log, except that it doesn’t provide as much detail, like TCP/IP properties for example, but for the purposes of diagnosing client issues from Outlook, Outlook Express, Eudora, Netscape, or any other open standards based email client, it does the job just fine.
For SMTP and NNTP, the logging options are available on the properties of the virtual server.
- Open The Exchange System Management Console
- Navigate through Organization -> Administrative Group -> Servers -> Server -> Protocols -> SMTP/NNTP -> Default SMTP/NNTP Virtual Server -> Right-click -> Properties.
- Click on Enable logging, select your logging format, and control the location and amount of detail in the logs through the properties option.
Protocol Logging for HTTP is available as well, but is configured through the Default Web Site properties in the Internet Information Services Manager.
- Open the Internet Information Services Manager
- Navigate to Server -> Web Sites -> Default Web Site
- Click on Enable logging, select your logging format, and control the location and amount of detail in the logs through the properties option.
Finally, there is Protocol Logging for POP and IMAP. Unfortunately, there is no nice and fancy UI for activating it, you gotta go strait into the guts, in the registry. Rather then divulge all the information here, I’ll give you the article that explains it much better then I: How to activate protocol logging for POP3 and IMAP4. I will tell you however, that the article describes possible logging levels as 0 through 5, but doesn’t give a lot of detail as to what is logged at each level. Essentially, 0 doesn’t log anything, 1-3 logs the same amount of detail (connections and disconnections only), 4 logs most client activity (but suppressed actual mail data) and level 5 logs everything. When using these logs for diagnosing client connections issues, level 4 is probably the most useful.
What you will see in all of these logs, are the commands that the client issued and the server's response. These logs are very helpful in letting you know how your clients are requesting their email and PIM data, how they are configured for sending email through SMTP, and a myriad of other information on how your protocol clients are behaving. If you’d like information on how to decipher what a client and server are saying to each other, you can lookup the RFCs for each protocol at www.ietf.org, or I would also recommend "Internet Email Protocols: A Developers Guide" by Kevin Johnson (ISBN 0-201-43288-9) which is an excellent book for learning to speak ‘protocol.’
Finally, be aware that these logs can eat up disk space quite quickly, and that most services will not let you delete logs on a whim. You may have to stop the corresponding service (thought the services control manager) to delete logs. In addition, stopping and then starting the service may be necessary to get the protocol service to recognize the change.
Benjamin Spain
