Microsoft Exchange Server 2010 Logs
Location of Exchange Logs
Whenever you get a problem in Exchange 2010 I guarantee that one of the logs will provide vital clues to find the root cause. The hidden agenda of this page is to open your eyes to the numerous types of Exchange logs, and show you where to find them.
Topics for Exchange Server 2010 Logs
Microsoft is not perfect. However, I have always felt that from the earliest Windows operating systems Microsoft provides lots of troubleshooting information in their logs.
The reason that Exchange 2010 has so many logs in so many locations is simply because it has so many components. On an Exchange server there are database logs for the mailstore, Windows 2008 application logs, SMTP protocol logs and virus logs. If that is not enough, you can create your own performance logs.
Unfortunately there is no central location to view all these Exchange related logs, therefore you have to start exploring locations such as the \exchsrvr folder, Event Viewer and even the root of the C:\ or D:\ drive.
Whenever I get an email problem, I try and make myself look in the Event Viewer earlier, rather than later in the troubleshooting process. Therefore in the case of Exchange 2010, I urge you to begin with the Application Log. People often say 'finding the problem is like looking for a needle in a haystack'. My reply is: ' master Event Viewer's Filter '. Click on the View Menu, Filter and select one of these from the Event Source box.
Using the same technique that I described above for the Application log, investigate these categories, remember the key menu is Filter source:
Exchange also has two setup logs to troubleshoot install programs. These files are created in the root of the drive where the Exchange 2010 binaries are installed. For example look in C:\ or D:\. These files give reasons why setup failed. Perhaps Exchange 2010 could not extend the schema, or encountered problems overwriting priv1.edb in the MDBDATA folder. I once used the progress log to solve a replication problem when migrating from Exchange 5.5.
LEM will alert you to problems such as when a key application on a particular server is unavailable. It can also detect when services have stopped, or if there is a network latency problem. Perhaps this log and event management tool's most interesting ability is to take corrective action, for example by restarting services, or isolating the source of a maleware attack.
Yet perhaps the killer reason why people use LEM is for its compliance capability, with a little help from you, it will ensure that your organization complies with industry standards such as CISP or FERPA. LEM is a really smart application that can make correlations between data in different logs, then use its built-in logic to take corrective action, to restart services, or thwart potential security breaches - give LEM a whirl.
Exchange 2010 Server SMTP Logs
In Exchange 2010 server, SMTP (Simple Mail Transport Protocol) has several shades of meaning. On this page I use the word SMTP in the context of understanding logs. These SMTP logs contain records of each server's email conversations. However, bear in mind that the acronym SMTP has other connotations, for example, SMTP Virtual Server, the SMTP service in IIS and SMTP routing connections.
Let us take the situation where one server is collecting email, but only intermittently. We would like to investigate the SMTP conversation between two Exchange 2010 servers and thus discover the cause of the problem. Here is a classic job for SMTP protocol logging.
There are two ways of locating the diagram opposite, either visit IIS, or launch the Exchange System Manager, navigate to Protocols folder and click on the SMTP server icon.
Choice of SMTP Log Formats
You have 4 methods for collecting SMTP conversations:
The default log format is W3C Extended. This format is the best way to get started with SMTP logging. However, when you need more extensive search capabilities, such as investigating a SQL database, then select ODBC Logging.
The W3C format is my favourite SMTP logging method. In particular, I like the flexibility provided by extended properties on the advanced tab. Here is the output of log where I chose to record the client IP, the SMTP method, and the reply code or sc-status.
#Software: Internet Information Services 6.0
#Software: IIS v 6.0 (Probably from a Windows Server 2010)
#Version: 1.0 Means W3C Extended log format (Not ODBC)
#Date: Probably USA day month format.
Understanding the SMTP codes
s- means server, whereas sc- means server to client. For example sc-bytes means the number of bytes sent by the server. c- I expect that you have already guessed, c- means client.