Can I ask your views on the following - I recently had auditors in and one of their recommendations was to increase the maximum number of error log files to a value of 25000 or higher via a registry hack. In the vulnerability report they give the following reason for this:

To prevent the loss of auditing data, it is recommended that you set this value high enough that the error logs will not be overwritten when restarting the database. Also note that there is a stored procedure, sp_cycle_errorlog, that closes an errorlog and creates a new file. An attacker could attempt to cover their tracks by overwriting files using this stored procedure. It is recommended that you set the value high enough that an attacker could not cycle the logs enough times in a reasonable amount of time to overwrite the error log containing an attack.

For auduting purpose I would recommend saving up the Default Trace log; depending on your work load, you can save that daily, or multiple times/day. And that trace log has alot more information the SQL Server error logs do.

I understand having that on for the first little while in a new system to make sure you know who is hitting the system. But by enabling both Successfull and Failed will it not fill up the error log alot quicker. Like for example on some of my serers there are over 3000 successful connections/day. I track successful for a while when setting up new server to make sure things are funcitonal; then I switch to Failed log ons only.

Recommendations are both or just failed? Comments?

Point #7, Create a maintenance database ...

I just starting doing that recently on SQL Server 2000 environment because we needed to track access to the user/database login. And be able to report it out quickly. I am also using this for storing some Stored procedure for selective reindexing? What else can be in this database?

Thanks for the Article, really good pointers :D.

I will be reading the articles you posted today they look really good :D.