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.
- MSExchangeAL - Addressing Email
- MSExchangeIS - IIS Access
- MSExchangeSA - Active Directory related
- MSExchangeTransport - SMTP Routing
- POP3Svc
Using the same technique that I described above for the Application log,
investigate these categories, remember the key menu is Filter source:
- SMTPSVC - SMTP Service
- W3SVC - IIS
- MSExchangeIS Mailbox Store
- ClusSvc - Cluster Service
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.
Guy Recommends: SolarWinds' Log & Event Management Tool
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.
Download your FREE
trial of SolarWinds Log & Event Management tool.
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:
- W3C Extended Log File Format
- NCSA Common Log File Format
- ODBC Logging
- Microsoft IIS Log File Format
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
#Version: 1.0
#Date: 2006-02-03
15:18:43
#Fields: time c-ip cs-method cs-uri-stem sc-status Explanation: #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.
#Fields: As the name field suggests the column heading for the data recorded. Example, cs-uri-stem means the
resource
requested. 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.
| 
