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.
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.