Navigate to the Log Files packages. In this section there should be two packages configured to monitor IIS logs that have not been assigned to anything.
Since I have IIS 6 running on Windows Server 2003 I will assign it to my web server then save and updated the configuration on that machine.
In most cases, this is all you will need to do to start monitoring your IIS logs. Once the configuration is updated and there is activity on your web server you should start to see information in the Log File Delimited section of the web reports within a few minutes.
Let's look under the hood and set how things are configured.
Here we can see that the IIS 6 log file is already set to write to our Primary Database Action. We are currently writing every line of the log file to the database. You do not have write everything, another option is to use filter text to match strings that you would like to include in the database. This may be a favorable option if you are monitoring several log files that are very active and you want to prevent the database size from getting too big.
You will also notice that location of the IIS log file is %SYSTEMROOT%SYSTEM32LOGFILESW2SVC1EX$YEARSHORT$MONTH$DAY.LOG. It is a good idea to verify that you have your IIS logs writing to this location with this naming convention.
By default this dialog will not have any additional logging to the APPLICATION event log turned on. Because we are monitoring IIS I think it would be rather useful to set a Warning to be written to the Application log whenever a user encounters a 404 error message. In this case I will turn on the event log option and use wildcards to match my filter text of 404.
After setting up a filter that looks for the Event Category as "Log File Monitoring" and the Event Source as "EventSentry" I now receive an email when a user navigates to the missing page. The email that is sent includes all the information on that line of the log file so we can quickly see which url they were trying to access.
At this point we should have delimited log file information writing to our database and we should be receiving email alerts when anyone encounters a 404 error.