Enterprise Vault™ Administrator's Guide

If the active server hosts an Indexing service, then the failover server must have an Enterprise Vault server cache configured.

The Enterprise Vault Storage queue location must be on a file system that is shared with the associated building blocks servers.

The Enterprise Vault cache location must have the same path on each Enterprise Vault server. The cache location is local to each server but the name must be the same to prevent errors after a failover. For example, all servers can have a cache location of D:\MyCache.

Each building blocks server can include a local Storage service. The storage files and index files must be stored on a file system that is shared with the associated building blocks servers.

See About the Storage queue.

You must install and configure the Enterprise Vault SMTP Archiving components on any building blocks server that is to support SMTP Archiving.

SMTP Archiving and Skype for Business Archiving use the SMTP Archiving task. If an SMTP Archiving task is running on both the active server and the failover server, then two SMTP Archiving tasks run on the failover server after you run Update Service Locations. For this reason, the SMTP holding folder path on the active server and failover server must be different.

You must log on to the active Enterprise Vault server using the Vault Service account, or an account that has been assigned to the Power Administrator role.

If Enterprise Vault needs to create a service on the failover server, you are prompted to log on using the Vault Service account, even if you use an account that is assigned to the Power Administrator role.

You must assign the user account the SC_MANAGER_ALL_ACCESS access right for the Service Control Manager (SCM) on all Enterprise Vault servers in the Enterprise Vault site. For more information, see Service Security and Access Rights, available at the following address on the Microsoft website:

https://msdn.microsoft.com/en-gb/library/windows/desktop/ms685981(v=vs.85).aspx

To secure Enterprise Vault servers, install on each server a certificate obtained from a trusted authority. The certificate must include the fully qualified DNS alias of the other Enterprise Vault servers in the building blocks configuration. These server names should be added to the certificate as subject alternative names.

By default in a new installation of Enterprise Vault 12.3 or later, Enterprise Vault configures HTTPS on port 443, and enables SSL on each Enterprise Vault virtual directory in IIS. If no valid certificate exists, the configuration wizard creates and uses a self-signed certificate for the HTTPS binding. You should regard this certificate as a temporary measure, until you install a certificate from a trusted authority.

The self-signed certificate created by Enterprise Vault configuration does not include the names of the other Enterprise Vault servers in the building blocks configuration. You can create a replacement self-signed certificate using a certificate tool, such as OpenSSL. To include subject alternative names in an OpenSSL certificate, you need to use the configuration file, openssl.cnf with the OpenSSL command. In the [v3_req] section of configuration file, list the fully qualified DNS alias of the other Enterprise Vault servers in the subjectAltName section, as shown in the following example:

[ v3_req ]
# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName = @alt_names
                
[alt_names]
DNS.1 = evserver1.example.local
DNS.2 = evserver2.example.local
DNS.3 = evserver3.example.local
DNS.4 = evserver4.example.local

In the Default Web Site in IIS, replace the automatically generated, self-signed certificate with the SAN version that you have created.