Introduction
Auditing Exchange usage is considered crucial nowadays, so if you are not already auditing the Exchange server(s) in your messaging environment now, you may not even realize your Exchange Servers could be experiencing problems! Even worse, you may discover that you have a problem but may not even be able to track it down. Auditing can be separated in a couple of different categories; there are Windows Server event auditing, Exchange diagnostics logging and finally 3rd party products which can solve the task for you.
Auditing Windows/Exchange Server Event Logs
It’s the Event Log Service which takes care of all Windows Server auditing, most of you probably know the Event Log Service pretty well, and I’ll therefore not go into any details describing it or showing you how it works. I will instead give you a few tips on what you should audit in regard to the Exchange Servers in your messaging environment.
Note:
The Event log Service records all types of events on the system (server), it consists of several different logs, these are the Application log, Security log, System log, Directory Service log, DNS Server log and the File Replication log. When dealing with Exchange Server auditing the interesting log is the Security log, which audits everything specified in the Audit Policy located in the Local Policy or Domain Policy.
One of the essential security auditing tools that you can take advantage of is the built-in Windows Server event auditing that you can turn on through the Local Security Policy or through security templates. Figure 1 below shows the typical audit policy events that you would need to configure.
Figure 1: Local Security Policy MMC Console
The events you should choose to audit should be the ones that tell you when someone accesses the server, makes security or account related changes to the server, and when someone may have restarted the server.
Note:
Windows event logs can grow quite large over time, so you should be sure to increase the size of your audit logs to a reasonable size. But bear in mind there’s no golden rule as this differs from server to server (number of mailboxes, activity etc.)
Auditing Changes to the Exchange Configuration
It’s important you know where you control auditing, so that you can track the changes made on your Exchange Server(s). There is not a single auditing category that will allow you to track all possible changes that are made to an Exchange Server. To understand where to enable auditing in order to track changes, you must understand where the configuration data is stored and at least, as important, where it is modified.
Almost all of the configuration information in Exchange is stored in the Active Directory’s configuration partition. The configuration partition is replicated between all domain controllers in the entire organization and the configuration can be changed on any domain controller in the forest.
Auditing changes on the Exchange Server(s) requires enabling auditing through a group policy object (typically the Default Domain Controller Policy) that affects domain controllers in each domain. You must enable the Audit Policy setting ”Audit Directory Service Access” for the domain controllers, NOT the Exchange Servers. If you enable successes you will be able to track any successful changes to anything in the configuration partition, including the Exchange configuration. So enabling both Successful changes as well as failure changes is typically the best thing to do.
Once auditing is enabled you will be able to find the relevant events in the domain controller’s event logs.
Exchange Diagnostics Logging
There are also a few categories that you should enable for Exchange Diagnostics Logging. You can find the Diagnostics Logging tab under the properties of each Exchange server object in the System Manager.
Diagnostics logging levels determine which Exchange 2003 Server events are written to the Windows Server application event log. Typically you only log critical events, but when problems occur, diagnostics logging enables you to change the logging levels so that you can do a more comprehensive and detailed capture. Events ranges from significant events (such as application failures), to moderately important events (such as message receipts), to events relevant only to debugging.
To enable any type of diagnostics logging for an Exchange 2003 Server, you must configure the services and categories under the Diagnostics Logging tab for each particular server(s) individually. Figure 2 shows the Services and Categories under the Diagnostics Logging tab for an Exchange 2003 Server.
Figure 2: Exchange 2003 Diagnostic Logging
Note
Be careful when you specify type of logging level, as medium and especially maximum logging can put quite a performance load on your Exchange server(s). For most environments minimum logging should be sufficient, unless you’re troubleshooting a specific issue.
3rd party Exchange auditing products
Let’s face it, no matter how well you configure auditing using the native Windows event log service and the Exchange diagnostic logging feature, it can quickly become a bit too complex and cumbersome. So it should come as no surprise there are several more powerful and feature-rich 3rd party products on the market made especially for managing and auditing your Exchange server environment. One such product is StealthAUDIT for Exchange.
StealthAUDIT for Exchange is a fast and flexible agent-less product which install in a matter of minutes. It gives you complete visibility into your Microsoft Exchange Server(s) and the underlying architecture so you can manage the thousands of Exchange settings and dependencies without a glitch. You can even create a baseline and manage changes as well as document and diagnose all aspects of an Exchange server. You can also produce web-based reports and identify changed settings, anomalies, un-patched systems and virtually any other Exchange server or OS management issue – not bad! But of course there are many other great 3rd party products which can handle this task, among them are Microsoft’s own Operation Manager 2005 (MOM 2005) and Exchange Administrator from NetIQ.
