Who changed my IIS 7.5 configuration?

I was asked today whether you can find out who was the last person to change the IIS 7.5 configuration files in case someone made a mess with the configuration.

This question is a decade-old question that bothers developers and IT all around the world - “Who touched my stuff?”

When talking about code changes in your applications, it is quite easy to open the source control tool you are using (VSS, SVN, ClearCase, TFS…) and search the history list for the person who recently changed the files.

When working with IIS configuration, it is a different story, because the configuration files of IIS 7.5 are not stored in a source control, and the only way to check who changed the configuration is by using security audits, if you’ve set them right in the GPO, and then check the event viewer’s security logs.

So what can we do in order to find out who is to blame? apparently, there is a simple way to do it, because IIS 7.5 sends trace messages for each configuration change it detects!

So to audit your configuration changes, just follow these steps:

1. Open the event viewer.
2. Expand Applications and Services Logs | Microsoft | Windows | IIS-Configuration.
3. Right-click the Operational option and select Enable Log.
   
4. From this point on, every configuration change that is made in IIS 7.5 will be logged, whether the configuration change causes the applicationHost.config to be changed or an application’s web.config file to be changed.
   Every configuration change will be logged with the information about the section that was changed, the value it was set to, the time, and most important – the user that was responsible for the change.
   

Now there are some important things to note:

1. The auditing process uses ETW which is a highly-performing infrastructure of the Windows operation system, so you shouldn’t see any noticeable CPU overhead.
2. It is advisable to limit the size of the log file that is created, because every small change to the configuration, such as creating a virtual directory, or changing the configuration of the application pool, will cause several log messages to be written.
3. Auditing is performed whenever you change the configuration through a controlled application, such as the appcmd.exe or the IIS Manager application. If the change is made by manually editing the configuration file (either the applicationHost.config or the web.config), the change won’t be audited.

By the way, a similar metabase auditing feature also exists for IIS 6. For more information on how to audit IIS 6 configuration changes, see the following TechNet article.

So turn on your logs and start catching those hooligans.