Auditing requires a scalable architecture

To ensure scalability for large organizations and fault tolerance, audit and monitoring service 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 it occurs. You should establish at least two collectors to ensure that audit and monitoring service 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 audit and monitoring service 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, 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.
  • 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 query and review captured user sessions.
  • A reporting database collects data from audit stores and the management database and saves the data in a format that is optimized for reporting. With the reporting database, you can generate event notifications, such as when an audited system goes offline.

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 audit and monitoring service infrastructure, there is a separate Windows service that is optional to collect 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 service spools the events on the management database, then sends them to the audit store database when the inaccessible database comes back online.