Enterprise Vault™ Auditing

Last Published:
Product(s): Enterprise Vault (12.3)

The format of audit database entries

In Enterprise Vault 12.3, auditing of administrative activity (Admin Activity auditing category) has been enhanced. In particular, the quality of information relating to administrative activity in the following areas is significantly improved:

  • Exchange, SMTP, and Search policies

  • Exchange and SMTP tasks

  • Exchange and SMTP targets

  • Exchange Message Classes

  • Archives

Improvements have also been made to the auditing of roles-based administration, vault store and partition administration, and advanced settings.

The improved information is available for activities performed using the Administration Console, or PowerShell cmdlets.


Veritas is enhancing Enterprise Vault auditing over several releases. The detailed information in this Appendix may change in future releases.

The EVAuditView database view in the Auditing database can be used to display audit entries and consists of the following columns:

Table: Description of EVAuditView columns

Column title

Description of content


A unique identifier for the audit entry.


SUCCESS or FAILURE. Whether the operation has completed successfully or failed.


Date and time of the action or operation that caused the audit entry.


The user who performed the action.


The audit category, as defined in the Computer Properties of the Enterprise Vault server.


A more specific categorization of the audit entry.


The ID of the entity that was changed, for example, Saveset ID, Site ID, Archive ID.


For high volume audits only, this often contains the Archive ID or ArchivePoint ID.


Freeform text providing more information on the action performed.

In Enterprise Vault 12.3 and later, much more detail about the audited action is provided in this column. The content of this column in different audit entries is the main topic of this Appendix.


The machine from which the audit entry was generated.

A new format has been introduced for the Info column, that allows information about the audited action to be displayed in a structured and consistent way. The remainder of this Appendix explains the content of the Info column in a variety of audit entries. Note that the full audit entry also contains the information listed above, such as the date and time, the user who performed the action, and the ID of the entity that was changed.

We recommend that you use SQL queries to view and filter audit entries based on criteria such as a date range, user name, or ObjectID.

To return formatted XML in the results, use a query like the following:

USE EnterpriseVaultAudit 
SELECT TOP 50 ObjectID, AuditDate, UserName, 
  TRY_CAST(info AS XML) AS infoXML
FROM EVAuditView
Info content in simple audit entries

The following example shows the content of the Info column in an audit entry that was created when a setting in an Exchange Mailbox policy was changed. Table: Description of XML fields in the example explains the values included.

<Update ObjectType="ExchangePolicyView" 
     ObjectName="Exchange Mailbox Policy 2">
  <Property Name="ProcessUnreadMail">
    <Previous Value="0" />
    <Current Value="1" />
  <Property Name="ProcessUnreadMail:TextValue">
    <Previous Value="Off" />
    <Current Value="On" />

Table: Description of XML fields in the example

XML field



The type of action. This is usually Create, Update, or Delete.


The type of entity that the action affected. This is often the name of the database table or view that changed. However, in some entries a friendlier name is provided.


The name of the entity that changed. ObjectName may not be populated if there is no appropriate value.

Property Name

The name of a property relating to the entity. (See note 1.)

For Create and Delete operations, most properties are listed because they have all gained or lost a value. (See note 2.)

For Update operations, only changed properties are included. (See note 3.)

:TextValue at the end of the Property Name field indicates that the following values are textual values for the setting. In the example, the textual values shown for the values "0" and "1" are "Off" and "On".

Previous Value

The value of the property before the action was taken.

Current Value

The value of the property after the action was taken.


  1. The name is often the one used in the database, so it may not match exactly the name in the user interface.
  2. To avoid unnecessary bloating of the audit trail, some properties that change very frequently are not included, for example, the size of an Exchange mailbox.
  3. Extra properties are occasionally included for context. This also applies to other types of audit entry.
Info content for composite properties

For some settings in the Enterprise Vault database, multiple settings are represented by a single value. The audit entry splits these out into separate properties. In Update entries, typically only the settings that have changed are displayed.

The following example Info content was generated in an audit entry after changing the settings, Include banner and Include link to archived item, on the Shortcut Content tab of the Exchange Mailbox policy. These two settings are stored as a single value in the Enterprise Vault database.

<Update ObjectType="ExchangePolicyView" 
     ObjectName="Exchange Mailbox Policy 2">
  <Property Name="excShortcutDetail">
    <Previous Value="1000005" />
    <Current Value="1000029" />
  <Property Name="excShortcutDetail:IncludeArchivedBanner">
    <Previous Value="False" />
    <Current Value="True" />
  <Property Name="excShortcutDetail:IncludeLinkToArchivedItem">
    <Previous Value="False" />
    <Current Value="True" />

As you can see, information about the Include banner and Include link to archived item settings are displayed as separate properties.

Info content when multiple settings are stored in a single property

The following example Info content was generated in an audit entry when an SMTP target was deleted.

<Delete ObjectType="SmtpTargetViewEx" 
  <Property Name="TargetId">
    <Current Value="19" />
  <Property Name="Address">
    <Current Value="JDoe@example.com" />
  <Property Name="poName">
    <Current Value="Default SMTP Policy" />
  <Property Name="RetentionCategoryName">
    <Current Value="RetCat01" />
  <Property Name="poPolicyEntryId">
    <Current Value="1781F4D98B1045F438445AC9
       8AD9579331s10000ev.local" />
  <Property Name="RetentionCategoryId">
    <Current Value="141E6B5A255237C4D83BB499
       390F27F091b10000ev.local" />
  <Property Name="ArchivingEnabled">
    <Current Value="1" />
  <Property Name="TargetType">
    <Current Value="1" />
  <Property Name="ArchiveInformation">
    <Current Value="<AI tn="JDoe@example.com" tid="19" 
       an="Archive1" at="2049" aid="1868FD2720BFF62
       4483309845BDCCFEDB1110000ev.local" vs="Store1" 
       ev="ev.local"/><AI tn="JDoe@example.com" tid=
       "19" an="Archive2" at="2049" aid="151D27
       0BA9638354DBE2B02FBFF7AF25C1110000ev.local" vs="Store1" 
       ev="ev.local"/><AI tn="JDoe@example.com" tid="19" 
       an="Archive3" at="2049" aid="13C3DC68A1FB836
       479CA542E4AE0CF9761110000ev.local" vs="Store2" 
       ev="ev.local"/>" />

The ArchiveInformation property contains XML that gives details of three archives that were assigned to the SMTP target.

To make the information in the ArchiveInformation property more readable, a separate audit entry is created for each archive. The example below shows the audit entry for Archive3 in the ArchiveInformation property above.

<Delete ObjectType="SmtpTargetViewEx:ArchiveInformation" 
  <Property Name="TargetAddress">
    <Current Value="JDoe@example.com" />
  <Property Name="TargetId">
    <Current Value="19" />
  <Property Name="ArchiveName">
    <Current Value="Archive3" />
  <Property Name="ArchiveType">
    <Current Value="2049" />
  <Property Name="ArchiveId">
    <Current Value="13C3DC68A1FB836479CA542
       E4AE0CF9761110000ev.local" />
  <Property Name="VaultStoreName">
    <Current Value="Store2" />
  <Property Name="EvServer">
    <Current Value="ev.local" />

Splitting an audit entry into multiple entries is used where it provides additional clarity. Other examples where multiple audit entries may be created include roles-based administration updates, and the administration of X-Headers in SMTP policies.