除了最小型的企业外，所有组织都有针对服务器的某些等级的安全审计。不管它收集的信息关于失败登录次数、安全文件访问、文件删除、活动目录修改或是其它，事实是我们大部分人需要获取一定量的信息。
在一次讨论会上，我发起了一次有关审计的小组讨论，这次讨论弄清楚了一件事：Windows的本地安全审计明确地有些安全问题。某位先生的故事可以代表每个人的经历：
管理方面要求我提供一些关于失败登录、成功登录等事情的细节。我告诉他们，我们目前没有收集这些信息，他们命令我们要去做这件事。我启用了必要的审计，又尽快地几乎将它们全关了。我们的域控制器根本不能处理额外的负载。
审计导致性能损失的事实最初让很多管理员感到惊讶，因为这不完全是直觉。毕竟，域控制器已经在执行工作，为什么仅仅对它做个标注会这么难呢？它确实很难：有人表示，审计在他的公司是放在容量规划里的工作。他估计他的团队拥有的域控制器是处理登录流量所需域控制器的两倍，因为它已经开启了几乎每一个可能的审计选项。
对文件服务器而言，拒绝访问文件的请求是一件事，而打开事件日志并将事实标注出来又是完全不同的操作。虽然Windows的本地事件日志架构是roburst，它并不是免费的。它需要计算力，它可以耗尽一台服务器的所有性能。这也是审计几乎总是在性能和知识间平衡的原因。发生越多的审计，这台服务器最终处理的用户工作负载就越少，因为它在审计工作负载上花的时间更多。一些组织只部署更多的计算资源来处理这些工作负载，其它企业为了保持服务器在理想的性能级别运行，不得不将审计量调整回去。
第三方审计解决方案有时候比本地事件日志架构处理更高等级的审计。它们通过结合三种基本技术来完成这一任务：
安装在服务器上的代理可以直接接入Windows的应用程序接口（API），而不是等待事件写入到事件日志中。这些代理节省了事件日志的日常开支，因为本地审计可以关闭。直接从API流量中获取数据通常花费也更少。
审计数据可以“慵懒写入”，这意味着它可以在较段时间内排队等候日志。这通常不是很长的一段时间，但它确实允许审计占用次要位置来处理用户工作负载。
事件通常传输到中央数据库用于从服务器上实际地编写、移除多一点的工作负载，因为该服务器不需要维持实际的日志。
管理员可能不得不做一些基于实验室的实验来精确地查看服务器环境中创建什么级别的性能会影响所选的审计配置。选择审计方法的核心信息是：你不能拥有全部。管理需要理解，获取每一点可能的信息都会产生性能影响，公司需要愿意为这些影响付出额外的服务器、更大的服务器或降低性能的代价。
