Exchange Event Log Report and Database         Download Files

The Windows event log on a Exchange Server acts as the medium to which your Exchange server logs information about its normal daily operations. Depending on the level of diagnostic logging you have configured the level of detail that a server reports in the event log can vary greatly. But by just using the default information Exchange logs about the backup operation, online de-fragmentation  and deleted item/mailbox retention you can gather some interesting operational data. What this script and report database does is first it retrieves all the events in the Server application log and saves them into an Access database. Within the access database are queries which first separate certain events and then parses text within the message database field and separates information within this field such as the name of the store and sizes and results of information store maintenance operations. Parsing information with VBA in Access is a fairly easy but tedious task . When parsing event log data the first thing that makes it easy is that your starting point is always going to be an absolute reference because certain events always start the same way (ex: the first text part eg "Cleanup of items") until you get to the store specific data such as the information store names or database file paths. Other then that its just a matter of nesting enough instr statements on certain event log text points and you can pretty much retrieve anything. What this report does is retrieves and reports on information that can be broken down into the following categories.

Information Store Uptime

Whenever the information store starts up and shuts-down (gracefully) it will log an event in the event log which will be event code 100 from source ESE for startup and event code 101 for a shutdown. Within each startup and shutdown event is a startup number which correlates to each other and changes every time the store is started and shutdown. Using this information you can link start and shutdown events together in pairs and with this you can work out the information store uptime which is how long the information store has been up since the last time it was restarted. Because the startup and shutdown events are sequential you can also work out the downtime which is the amount of time between the last shutdown down event and next startup event. If there is no shutdown event for a startup event then its probably because the store was shutdown dirty (eg the server was powered off with out shutting down). This information is compiled into a single query and used to produce the first report page which looks like this

Information Store Backup Results

Whenever a backup is performed via the Exchange Backup API the Exchange server will log a event code 210 which states that its starting a backup via the Exchange Backup API. Most commercial backup programs use the Exchange Backup API such as Verities and Arcserve (Brightstore) but there are a other companies that have developed backup products that don't use the Exchange Backup API see Q311898. For anybody running products that don't use the Exchange Backup API then the next two pages wont work. Event 220 is logged by the Exchange Backup API when it starts the backup of each different database store file this event records the size of each file in the event log message. The report database parses the size of each file out of the message field, these sizes are then added together and used in the reporting page to display the total size of the backup and also to workout the throughput of the backup. If the backup finishes successfully a event code 213 is logged, if the backup is unsuccessful it could log a number of different event codes the main one is usually 215 which means the backup has failed because of a media error or loss of connection.. With all this information the report page now shows when the backup started, finished, how long the backup took, how much data was backed up and what the throughput was. The throughput is worked out by dividing the size of the data backed up with the time in minutes it took to backup the data. If any failed backups are detected it should show that line of the report in red. The report it produces looks like this.

Information Store Size Usage Trend

As I mentioned above when the information store performs a backup via the Exchange Backup API one of the events it logs as part of the backup process is event code 220 which states the size of each file before it is backed up. What the report database does is parse this size of each file out of the message text database field for each of the different store files that are backed up. Along with the date which is also logged with each event you can use this information to then track the growth of each store file across a period of time. With the time filter for each backup period I used the range of between 6:00 PM and 6:00 AM that the back events should fall in to be included in that  particular time range. For this page to work there must have been a backup the pervious night because all the queries are linked to the first query which looks for last nights backup result. The trend periods shows the amount of disk spaced used across the time period stated, it does this by subtracting the size the file was during the time period to the size it is was on the last backup. With Exchange database files the growth is usually liner (unless you are performing offline defrags) so you should see it increase and stop regularly (as the white-space generated by the online de-fragmentation process is used and exhausted). The Trend page looks like this.

Information Store Maintenance Reports

The next 3 report pages are based on the events that are logged as part of the Information Store Maintenance period. During the information store maintenance period a lot of important stuff relating to the continued operation of your information store is performed. What these reports look at is the three main things that a Sys Admin may be interested in out of this maintenance period.

Deleted Item Retention

When someone deletes an item from a mailbox by performing a soft delete (eg emptying their deleted items folder) that item becomes available for deleted item recovery see Q249680. As part of the Information store maintenance period Exchange calculates all the items that are available for deleted item recovery compares the time that each item was deleted against the Deleted Item retention period and then marks those items to be purged  that are older then the deleted item retention period. When the Exchange server does this it logs a event code 1207 with the number and size of the items held in deleted item retention before it does any calculations on which items have recently expired and then it shows the number and size of items after it has purged all the newly expired items. What the report database does is parse each one of these item counts and sizes into separate database fields. The report then shows this data to you in a flat format and also does a calculation on how much data is being purged from the Information Store each night by subtracting the end size from the start size. This information is especially handy if you are struggling with disk space on your server and you want to know the effect that changing the deleted item retention settings on your store is going to have. The report page is a combined page with the online de-fragmentation report it looks like this.

Online De-fragmentation

Exchange Online de-fragmentation detects and removes database objects that are no longer being used and then makes the space used by these objects available as free space within the database see Q328804. When the On-line De-fragmentation process has finished it logs an event code 1221 to the event log with the free space available within the database (white space in the database) after the de-fragmentation in the event message. The report database parses out this free space available and then provides it to a report page which looks like this.

Deleted Mailbox Retention

When a Mailbox is deleted in Exchange 2x the mailbox is disconnected for a default period of 30 days (which is the deleted mailbox retention period). As part of the information store maintenance period it checks to see which disconnected mailboxes have expired the deleted mailbox retention period and sets those mailboxes to be purged. As part of this operation a event code 9535 is logged which states in the message text the number and size of mailboxes retained and then the number and size of mailboxes after any newly expired mailboxes are purged. What the report database does is parse these four number and size values from the message text along with the store name and separates them into there own fields. The report then shows this data sorted by date that can allow you to see the effects of your deleted mailbox retention period over a period of time. The report looks like this.

Total Size Retained

To work out the total amount of free-able space within your Exchange database what you need to do is add the size of the retained deleted items from event code 1207 and the retained size of mailboxes from event code 9535. The result will be the total amount of space that is free-able in the Exchange database once all the items have expired their retention period. The report looks like this

Next Page Event log Export Script

Download Files