Auditing Windows Systems
Recently during the setup of a SharePoint Project Server setup, the setup involved more than one IIS server. One for the projects, and one for the reports (reporting doesn’t do clusters).
After setting this up, we could access all the sets without issue while directly on the reporting server. Access the WSS Project Server website is also without issue from both the server and any workstation. however, when we try to run a report (which calls up IIS on the ‘other’ server) the dreaded three login strikes and you are 401.1′d happens.
To better isolate where the authentication is failing. There are two things to do.
a) check the IIS logs
b) enable some auditing on the folder directories
To enable auditing on access to particular files/folders:
On the machine the files reside, start gpedit.msc
enable the settings as above. Warning, if you enable process tracking – never ever do that on a production machine! Well, do so at your own peril. It is a resource hog. Also, make sure your event logs are going to have adequate space for the additional auditing. Our concern here is going to be the failure audits.
Next we go to the specific folder we want to watch/audit. By default, this will apply to all subfolders and files, though u can choose to monitor just that chosen folder or file.
Go to the properties of the folder/file and navigate to the Security Tab.
You can now choose the Audit tab. From here, you have to add each individual user and group for which to monitor. If a user which is either outside of the group, or is not added, then no audit entry will take place.
Auditing will take place indefinitely at this point. So if you are doing this solely for troubleshooting. Remove the users from here, and reconfigure the above gpedit.msc when you have finished.
Also, remember that if you are monitoring across multiple servers, this will need to be done on each machine. Also, getting familiar with Network Monitor 3.1 will be very helpful!
All of the above setup auditing will appear in your Windows Event Viewer Security Log. You should be able to correlate this either with other systems, AD, or events in the Application or System logs.