Auditing requires a scalable architecture

To ensure scalability for large organizations and provide fault tolerance, the auditing infrastructure has a multi-tier architecture that consists of the following layers:

  • Audited computers are the computers on which you want to monitor activity. To be audited, the computer must have an agent installed, audit features enabled, and be joined to an Active Directory domain.
  • Collectors are intermediate services that receive and compress the captured activity from the agents on audited computers as the activity occurs. You should establish at least two collectors to ensure that auditing is not interrupted. You can add collectors to your installation at any time and it is common to have multiple collectors to provide load balancing and redundancy.
  • Audit stores define a scope for auditing and include the audit store databases that receive captured activity and audit trail records from the collectors and store it for querying and playback. Audit store databases also keep track of all the agents and collectors you deploy. For scalability and network efficiency, you can have multiple audit stores each with multiple databases.
  • A management database server is a computer that hosts the Microsoft SQL Server instance with the audit management database. The management database stores information about the overall installation, such as the scope of each audit store, which audit store database is active and where there are attached databases, the audit roles you create, and the permissions you define. The management database enables centralized monitoring and reporting across all audit stores, collectors, and audited computers.
  • The Audit Manager and Audit Analyzer consoles are the graphical user interfaces which administrators can use to configure and manage the deployment of audit components, such as agents and collectors, or to query and review captured user sessions.

To ensure that audit data transferred over the network is secure, communication between components is authenticated and encrypted.

In addition to these core components of the auditing infrastructure, there is a separate Windows service that collects audit trail events when there are audit store databases that are not accessible, for example, because of network issues or the database server is shut down. This audit management server runs as a Windows service and spools the events on the management database, then sends them to the audit store database when the inaccessible database comes back online.

In addition to spooling audit trail events, the audit management server automatically calculates the approximate disk space used by audited sessions on the database server. The audit management server will calculate the session size for all completed audited sessions. The session size is not calculated for in-progress or disconnected sessions. You can view the session size for all completed sessions in the Audit Analyzer console’s query results.