Enterprise Vault (EV) archiving can fail in a distributed environment with certain firewall configurations.

book

Article ID: 100027550

calendar_today

Updated On:

Cause

This can be seen in a Dtrace where the call is made. However, the response is extremely long and it may appear that the thread has hung.

(ArchiveTask)    <9228> EV:L       {CAutoStorageOnline::GetStorageComputer} (Entry)
(ArchiveTask)    <9228> EV:L       CBaseDirectoryServiceWrapper::CreateDirectoryService() - Entry [m_nNumTries = 40]
(ArchiveTask)    <9228> EV:L       CBaseDirectoryServiceWrapper::CreateDirectoryService() - Successfully communicated with an EV Directory Service on the local machine
(ArchiveTask)    <9228> EV:L       {CAutoStorageOnline::GetStorageComputer} (Exit) Status: [Success]
(ArchiveTask)    <9228> EV:L       {GETSTORAGEOBJECT.EN_US} (Entry)
(ArchiveTask)    <9228> EV:M       {GetStorageObject:#2258} Calling VaultCoCreateInstanceEx

The call to VaultCoCreateInstanceEx may take up to 15 minutes to respond. In this scenario archiving will fail as the DCOM communication is being interrupted by the Firewall.  
Reviewing a Network packet capture trace will show that a RemoteCreateInstance request is initiated. However, the request/response may indicate a Malformed Packet if using Wireshark to review the trace. In some circumstances, there may be an Access Denied response from the target server.
 

Resolution

In order to resolve this ensure that the RPC communication is fully open between the necessary EV servers and that no universally unique identifier (UUID) restrictions are in place.

Refer to the Firewall settings for Enterprise Vault programs for more information. 

Issue/Introduction

When EV is configured with an Archiving task in one VLAN, and the Storage servers on another with communication between the VLANs going through a Firewall configured to use MS-RPC Application Level Gateway packet inspection, EV may fail to successfully create a remote Storage object when archiving.