This post briefly discusses the new configuration auditing functionality to trace the changes done to the IIS configuration store. This is similar to the Metabase Auditing which was available in IIS 6.0 with SP1 on Windows 2003 Server; you can refer this KB article which talks about enabling metabase auditing on IIS 6.0 (with SP1).
What is Configuration Auditing?
IIS configuration auditing is a feature that would let you monitor the changes that are done to the IIS configuration store. It generates event messages (similar to those generated by enabling metabase auditing in the previous versions). It would display the configuration element which was changed, user who initiated the change, and the original and the new value of the element.
Why do you need to turn it on on your server?
There are times when the admin wants to monitor the changes done to the IIS config store. A classic situation is when someone had accidentally changed some settings on the server which then affected the website. Or there might be some scripts running in the background which changed few properties which affected the website behavior. So, you want to know the change made to the IIS configuration, and the process and the user who initiated that change. Turning on the IIS configuration auditing helps you in getting that information when the change is made next time.
Enabling Configuration Auditing
IIS configuration Auditing is a feature which is available only with IIS versions from 7.5 which is shipped with Windows Server 2008 R2 (and Windows 7).
To enable the configuration auditing feature, follow the below steps:
- Open Event Viewer (Administrative Tools –> Event Viewer)
- Expand the “Application and Service Logs”
- Expand “Microsoft”, and expand “Windows”
- Expand “IIS-Configuration”, and right click on “Operational”, and choose “Enable Log”
By default, the log file would be saved in %SystemRoot%\System32\Winevt\Logs\Microsoft-IIS-Configuration%4Operational.evtx. You can change it by clicking on the “Properties”, and changing the “Log Path”. You can also consider changing other parameters like the maximum size of the file, when to clear the logs, etc. in the properties window.
After enabling, you would see corresponding events in this event viewer log whenever there is a change to the IIS configuration store.
Sample Events while changing AppHost
Below is a sample event which occurred when I changed the port number in the binding of the website by directly editing it in the IIS manager.
Changes to ‘/system.applicationHost/sites/site[@name="Default Web Site" and @id="1"]/bindings/binding[@protocol="http" and @bindingInformation="*:8080:"]/@bindingInformation’ at ‘MACHINE/WEBROOT/APPHOST’ have successfully been committed.
If you click on the details in the event, you will find some more information associated with the change. I’ve just given only little information below, open the event in the event viewer to see the complete event data.
[ UserID] S-1-5-21-2146773085-903363285-719344707-387480
Configuration /system.applicationHost/sites/site[@name="Default Web Site" and @id="1"]/bindings/binding[@protocol="http" and @bindingInformation="*:8080:"]/@bindingInformation
There are a few important things which might be useful here in this event log entry. First is the Process ID, this will give you the PID of the process which was changing the entry. You can find the process name by looking at the task manager for this corresponding PID.
This event also shows the username which initiated the change. This is a very important data if you are tracking who changed certain IIS configuration. This in fact gives you the Security Identifier of the username (SID), and you can find the username by using psgetsid which is a part of our Windows Sysinternals tools (usage: psgetsid <SID>).
You can also see what were the changes made, details about the configuration where the change was made, the old value of the configuration element, and the new value.
Key points to remember
- If someone uses appcmd to modify the IIS configuration, you will see the config auditing entry for the same, but the PID won’t be a valid one. That is because that appcmd process is actually completed, so you won’t find it in the task manager’s processes list. But, you will still see the user information which initiated the change.
- Manual changes to the configuration store are not audited. For example, if you use appcmd or MWA, it is captured, but if someone modifies the value of a section in the applicationHost.config directly such as by opening it in Notepad.exe, that won’t be recorded in the audit logs.
Will it affect my server’s performance?
This would be a question in every admin’s mind whenever they turn on any auditing, or logging functionality on their servers. IIS configuration auditing utilizes the Windows ETW subsystem which would be able to handle thousands of events per second without any noticeable CPU overhead. But, you can limit the size of the log file that this IIS configuration auditing generates. You can change the size of the file in the “Properties” section of the Operational logs.
So, what are you waiting for? Enable IIS configuration auditing, and know what’s happening on your server! It’s your server; you deserve to know what’s happening!