Database Sizing and Resource Consumption

Data Retention Considerations

The Audit Event and Microsoft SQL Server Reporting Services databases used to support BeyondTrust Privilege Management Reporting may be hosted and scaled independently.

It's important to identify the length of time that Privilege Management for Windows audit event data must be retained in the Privilege Management for Windows database as it drives resource utilization projections, and initial allocation.

Privilege Management Reporting is designed to report on activity in recent time, not as a long term archival data storage solution.

  • Privilege Management for Windows provides a database purge utility that may be used to purge data manually, or automatically on a configured period to ensure database growth is capped.
  • Unlimited database growth inevitably reduces query execution performance, and increases resource utilization for queries.

Prior to purging large sets of data, please ensure your SQL Transaction logs are able to grow to accommodate. It may be necessary to delete data in stages when setting this up for the first time.

In order to facilitate your decision making regarding retention time in the Privilege Management for Windows database, please refer to the following sections in our standard documentation:

  • Description of the views of data exposed in Privilege Management Reporting. 
  • Description of the events audited by Privilege Management for Windows.
  • Description of the Workstyle parameters. You may consider these as the fields that are collected in the audit events, eventually stored in the Privilege Management for Windows Audit Events database.

For more information, please see the following:

Database Sizing

The Audit Event database has to be sized to accommodate substantial data volume, matching the number of clients generating audit data and the desired retention period.

Database storage requirements may be estimated roughly using the following calculation:

Number of hosts
× Number of events per host per day
× 5Kb per event
× Number of retention days
Number of hosts × Number of events per host per day
× 5Kb per event
× Number of retention days

For example, an organization of 10,000 hosts, with each host generating an average of 15 events per day, requiring a 30 day retention would require a database capacity of:

10,000 × 15 × 5 × 30 = 22,500,000Kb, or 21.5Gb

A typical event volume would be 10-20 events per host per day and varies based on Privilege Management for Windows auditing configuration, user job function (role/Workstyle) and user activity patterns.

Please see the Privilege Management for Windows Database sizing calculator to further explore database sizing and growth expectations.

Database resource utilization (CPU, Memory) is highly variable depending on the hardware platform.

Example Use Case Volumes

Based on an organization of 10,000 hosts requiring a 42 day (six weeks) retention.

Discovery: Between 40 – 60 events per machine per day

(4.6K per event (based on real world data))

Average total: 67.06GB


Production: Between 2 – 10 events per machine per day

(4.6K per event (based on real world data))

Average total: 5.66GB

If the number of events "per machine per day" is raised to 15, then the Average total increases to 16.99GB.

Key considerations

Volume of inbound audit event records

As seen above, the number of events per hour may be estimated following simple calculations.

Queries triggered from MSFT SQL Reporting Services Reports

As the database grows in size, the resource impact of the reporting platform queries becomes important.

The volume of data maintained in the audit event database will affect the duration and resource cost of these queries.

To maintain good performance, we recommend the ER Purge Utility is used to limit the timespan of audit event data retained in the database.

Finer-grained audit data management and clean-up is possible using the Privilege Management for Windows Database Administration Dashboard. The Database Administration Dashboard allows the purging of audits related to specific applications and suppression of incoming audit items related to those applications.

Prior to purging large sets of data, please ensure your SQL Transaction logs are able to grow to accommodate. It may be necessary to delete data in stages when setting this up for the first time.

For more information, please see the Database Administration description in the Reporting Dashboard Guide.

Configure Remote Computer Browser

The Privilege Management for Windows Workstyle Editor allows you to browse computers on the network for executables, Windows services and running processes, which can be added to Application Groups. This provides a convenient alternative to manual entry.

Remote computer browsing leverages Windows Remote Management (WinRM) and PowerShell, which must be configured on each target endpoint in advance of using the computer browser feature to access the remote computer.

WinRM and Powershell are components of the Windows Management Framework, and are part of Windows 7 and Windows Server 2008 R2. For older versions of Windows, the Windows Management Framework can be downloaded and installed as an optional update at https://www.microsoft.com/en-us/download/details.aspx?id=54616.

Configure the ePO Server

Configure WinRM trusted hosts:

  1. Open PowerShell (elevated).
  2. Type:
    winrm s winrm/config/client '@{TrustedHosts="<endpoint>"}'

    <endpoint> should be replaced with the hostname or IP Address of the network computer to be trusted. A wildcard (*) can also be used.

  3. Press Enter.

Configure a network computer

Verify PS-Remoting is enabled:

  1. Open PowerShell (elevated).
  2. Type Enable-PSRemoting, and then type A to accept all defaults (this can also be enabled with AD Group Policy).

Configure WinRM to allow remote connections

  1. In the same PowerShell window, type winrm qc and press Enter.
  2. Type:
    winrm set winrm/config/service @{AllowUnencrypted="true"}
  3. Press Enter.

Test for a successful connection

From the ePO server, run this command:

>winrm identify -r:http://<endpoint>:5985 -u:<username> -p:<password>

<endpoint> should be replaced with the hostname or IP Address of the network computer. Replace <username> and <password> with administrator credentials on the network computer.

If the connection is unsuccessful, edit the local security policy to enable classic mode authentication for network logons.

  1. Open Local Security Policy from Control Panel > Administrative Tools.
  2. Navigate to Local Policies > Security Options.
  3. Double click Network Access: Sharing and Security Model for local accounts.
  4. Set to classic.

Mixed environments:

  1. Open PowerShell (elevated).
  1. Type the following:
    new-itemproperty -name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1
  2. Press Enter.