Enhancements in custodian assignment for Enterprise Vault User Mailbox Archives collections in certain environment

Problem

Custodian assignment fails for collections targeting Enterprise Vault User Mailbox Archives as email address that is associated to the Enterprise Vault Mailbox Archive cannot be identified. This issue arises in a certain scenario where the on-premise Exchange Mailbox is first migrated to Office® 365 and then archived in Enterprise Vault using SMTP archiving.

Details

In the current mechanism of custodian assignment, eDiscovery Platform identifies the custodians based on the mapping between an Active Directory User, the user’s Exchange Mailbox DN, and the user’s Exchange Mailbox Archive in Enterprise Vault.

When a mailbox is moved to Office® 365, Enterprise Vault loses the Exchange Mailbox DN information that is associated with the archive and subsequently it becomes NULL in the Enterprise Vault databases. When eDiscovery Platform performs Enterprise Vault discovery, a NULL value of the user’s Exchange Mailbox DN is stored in the eDiscovery Platform database. As a result, the custodian assignment fails to identify the custodian that is associated with the archives.

Solution

A new mechanism to correctly identify and assign custodians is introduced in 8.3 CHF4 and 9.0.2.
The custodians are identified using the Display Name or E-mail Address that is associated with the MailboxId. If the MailboxId information is not available, then ArchiveId is used to determine E-mail Address for searching the right employee. The Archive Id is used to query the Archive to SMTP target (i.e. email address) mapping.

To implement this mechanism, you must set the esa.icp.ev.CustodianAssign.by.EVSmtpTargets property to True by using System > Support Features > Property Browser. By default, this property is set to False.

Note: You must first perform Active Directory sync and Enterprise Vault discovery before you can use this enhancement and start collecting data from Enterprise Vault User Mailbox Archives. You should perform Active Directory sync and Enterprise Vault discovery at regular intervals to ensure that the eDiscovery Platform database stays current and that custodian assignment works correctly.

On Enterprise Vault, multiple SMTP targets can be configured to store data in the same archive. In this case, multiple email addresses are identified when eDiscovery Platform searches for ArchiveId.

When an archive is mapped with more than one email address, you should configure the following properties using System > Support Features > Property Browser:

Property 1: esa.icp.ev.CustodianAssign.SmtpTargetsAmbiguity.ResolveBy.PreferredDnsList
Value: The values can be comma-separated list of DNS names listed in a preference order. The default value is set to “” (i.e. null).

Property 2: esa.icp.ev.CustodianAssign.MultipleEmployeesAmbiguity.ResolveBy.PrimaryEmail
Value: True or False. The default value is set to True.
When all records have the same primary email address, then the employee with the least EmpId is selected as a custodian. If the primary email addresses are not identical, then NONE is assigned as a custodian.

When an archive is associated with multiple email addresses, then you can set a preferred order to choose between multiple email addresses.

For example, “MMOORE” archive is mapped with three email addresses:

Records in the “t_employee” table:

Scenario 1:
When the properties are set as:

esa.icp.ev.CustodianAssign.SmtpTargetsAmbiguity.ResolveBy.PreferredDnsList="GO.CLEARWELL.COM","ONCLOUD.CLEARWELL.COM"

esa.icp.ev.CustodianAssign.MultipleEmployeesAmbiguity.ResolveBy.PrimaryEmail=true

In this case, the “mMoore@GO.CLEARWELL.COM” is first searched in the t_employee table. As no employee is found, then “mMoore@ONCLOUD.CLEARWELL.COM” is searched. As a result, two employee records are found. If the primary email address is same, then the employee with the least EmpId is selected as a custodian. Else, NONE is assigned as a custodian.

Scenario 2:
When the properties are set as:

esa.icp.ev.CustodianAssign.SmtpTargetsAmbiguity.ResolveBy.PreferredDnsList="GO.CLEARWELL.COM","ONCLOUD.CLEARWELL.COM"

esa.icp.ev.CustodianAssign.MultipleEmployeesAmbiguity.ResolveBy.PrimaryEmail=false

In this case, the “mMoore@GO.CLEARWELL.COM” is first searched in the t_employee table. As no employee is found, then “mMoore@ONCLOUD.CLEARWELL.COM” is searched. As a result, two matching employee records are found. The employee with the least EmpId is directly selected as a custodian without checking for the primary email address. Here, if no matching records are found, then NONE is assigned as a custodian.

Scenario 3:
When the properties are set as:

esa.icp.ev.CustodianAssign.SmtpTargetsAmbiguity.ResolveBy.PreferredDnsList=""

esa.icp.ev.CustodianAssign.MultipleEmployeesAmbiguity.ResolveBy.PrimaryEmail=true

In this case, if all three records have the same primary email address, then the employee with the least EmpId is selected as a custodian. If the primary email addresses are not identical, then NONE is assigned as a custodian. The database is queried for DNS in an unordered manner. The first DNS name is used for searching the employee records. If no record is found, then the second DNS name is used, and so on. If no records are found, then NONE is assigned as a custodian.

Scenario 4:
When the properties are set as:

esa.icp.ev.CustodianAssign.SmtpTargetsAmbiguity.ResolveBy.PreferredDnsList=""

esa.icp.ev.CustodianAssign.MultipleEmployeesAmbiguity.ResolveBy.PrimaryEmail=false

In this case, then the first matching employee for the first matching email address is selected as a custodian.