Microsoft added “auditing” for the IIS Configuration file Metabase.xml
It was a service pack release hence it doesn’t have the flare of the RTM release and hence often features get missed. I have been attending a lot of conferences the past few weeks and I keep noticing that many people are not aware of the features included in Service Pack 1 for Windows Server 2003 & IIS 6.0.
One feature, in particular, seems to get their attention is Metabase Auditing. It is really an easy feature to implement and doesn’t “cost” a lot but does help track down when changes have occurred to the ever-critical configuration file for IIS.
It tracks the following information -
- Date\Time the change occurred
- Who the user that changed the configuration file
- Whether it was a success or a failed attempt
- What was changed
- Old Value (previous setting)
- New Value
Over the past 2 years since we released IIS 6.0, customers have loved IIS 6.0’s automatic history feature. This feature, outlined here in the help – – will first always make a copy of the current configuration before committing the change. This is easily viewed in the IIS Manager by right-clicking on the server and choosing All Tasks >> Backup\Restore Configuraiton. The one drawback to this feature is you have no means of determining “what” was changed between each history file as they are only named by backup and the date\time.
This isn’t the case anymore as you can now use the auditing feature to effectively determine what backup to restore based on the date\time. They may not match exactly, but in most cases (95%) you can track down which history file goes with what audited change.
To enable this cool feature in IIS 6.0 SP1, you have to make one global system change in Windows Server 2003. In the Local Security Policy, you should locate the Audit Policy and select “Audit Object Access” and select Success\Failure. Of course, if you are only interested in seeing failures – choose failure. Success, well choose success only.
After this has been changed, IIS 6.0 will now log any changes to the configuration to the Event Viewer’s Security Event Log. It is pretty easy to locate as its source is “IIS-Metabase”
The last step is to indicate what should be audited. This feature is not turned on by default so you do need to tell IIS what to audit in the metabase. You can audit the entire file (/LM) or go granular and only audit a site, virtual directory, or even down to a directory or file if necessary.
To do it, you only supply the following in the command-line -
iiscnfg /enableaudit w3svc/1/root
To disable this and no longer audit, you issue this command -
iiscnfg /disableaudit w3svc/1/root
It is a requirement to have Service Pack 1 and you can copy this *.vbs to RTM builds and use it as auditing was not available. However, that is the extent of it…so, what are you waiting for? Start Auditing…