Blog Post

Exchange Team Blog
3 MIN READ

Snap, crackle... IMAP! er... SMTP? er... HTTP! Aw, heck...

The_Exchange_Team's avatar
Feb 20, 2004

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.

  1. Open The Exchange System Management Console
  2. Navigate through Organization -> Administrative Group -> Servers -> Server -> Protocols -> SMTP/NNTP -> Default SMTP/NNTP Virtual Server -> Right-click -> Properties.
  3. 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.

  1. Open the Internet Information Services Manager
  2. Navigate to Server -> Web Sites -> Default Web Site
  3. 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

Updated Jul 01, 2019
Version 2.0
  • Why isnt NetMon available for Professional Platform editions? I am sitting on Advanced Server becuse it has Netmon on it. WTF, what genius dreamt up that.
  • Get Ethereal
    www.ethereal.com
    It has even a MAPI parser of sorts.
  • I have deleted a comment because of offensive language. Here is the content without that language, slightly modified :-)

    Etherreal is not good. GTK = better. Can etherreal run my netmon plugin DLLs? Can it view my capture files?
  • Helpful tip: I'm not sure if this applies to all diagnotic logging in Exchange, but i've done this before while troubleshooting offline address books.

    Find the registry key for the applicable service and change the logging level to 7. You'll get the most detailed level of logging possible.

    It's not documented anywhere but it works. Not sure why? Can anyone from Microsoft comment?
  • Adam... I believe you're referring to Diagnostic Logging, which is applicable to many different Services in Exchange. Diagnostic logging basically turns up the amount of detail and number of events in your Event Log. Previously (Exchange 4.0 - Exchange

    5.5 days) this was done via registry keys, as this little KB describes (http://support.microsoft.com/default.aspx?scid=kb;en-us;181451) In Exchange 2000 and Exchange

    2003, this was added as a tab on the Server properties. (Exchange System Manager -> Org -> Servers -> Server -> Right-click, Properties -> Diagnostics Logging)



    This is different from the Protocol logs that I described above.

  • There are various articles that refer to logging level 7.

    262308 XCON: How to Generate Application Log Events for Non-Delivery Report
    http://support.microsoft.com/?id=262308

    is an example. Benjamin, logging level 7 is actually a higher level of logging then what you can set in the MMC. Maximum in the MMC is equivalent to logging level 5. Within PSS we use logging level 7 to trap a higher level of detail. It is not an available option in the GUI and not spoken of much because it typically will cause so much information to dump that it could be harmful to performance if left that way permanently. Generally we will only go to logging level 7 if we can not establish any other indicators of why an error is happening.
  • charliewoods's avatar
    charliewoods
    Copper Contributor

    Thank you for sharing your experience with network monitoring and protocol logging. These tools are indeed invaluable for diagnosing client-server communication issues, especially when troubleshooting email and web protocols.