The Tits: IIS Advanced Logging Module

The first time I thought "Wow, NetScalers sure fill my IIS server logs with a bunch of shit data" was about twenty minutes after my first encounter with the technology.  I had checked every setting I could think of on the IIS Logging feature and found nothing of use.  It's an all or nothing proposition: enabled, or off completely.

Tonight, the clouds parted, and the moon shone brightly.

I came in tonight to try to get some things ready for some server build audits we have coming up.  My two main tasks were as follows:

1. Get three of the core web application servers built on the NetScaler (that I finally have access to) and load balanced in a basic capacity.
2. Get the current version of the application deployed to those same three servers.

The first task I accomplished pretty handily, despite my apprehension logging into a production NetScaler for the first time.  I've been through the training, and I've been reading through their eDocs, of course, but I went very slowly for the first few minutes. 

I had not long completed #1 and successfully tested it when my thoughts again returned to my servers' IIS logs.  They were filled with 0-byte HEAD requests from the NetScaler.  By default, the NetScaler's built-in http monitor executes a HEAD method request against the target system every five seconds.  I knew this from earlier study and my general understanding of monitoring systems.  What I had not considered before the last month or so was what this method of monitoring looks like on the receiving end.

I turned to the Intergoogle for aid. There had to be an answer to this problem.  The legions of IIS administrators that I still think might be out there somewhere surely could not have, all this time, merely tolerated this situation.

Right?

Enter, the solution

There is, indeed, a solution to this problem, and it is called IIS Advanced Logging.  I've only just begun to explore its capabilities; however,I determined almost immediately that I must have this module on my servers.

All of them.

The reason is simple: it lets me filter out unwanted log traffic.  Further, should I determine a sound need to (which I'm still researching), I can separate out different log data into separate files based upon what I want to actually see.

If this module did nothing else of value, this one feature would justify its existence.  From the reading I've already done, though, this thing is all kinds of flexible.  There are some limitations, but at least for now they do not affect what I'm doing.

I have installed, enabled, configured, and tested AdvL on all three of tonight's target servers, and it's running like a champ.  I did find it odd that you have to manually disable standard IIS Logging, else it logs data in both places simultaneously.  I didn't initially notice that IIS Logging still existed as a separate feature and worried about the resource impact of such an arrangement.  Fortunately, that is now a non-issue.

~Fin~