There are a couple misleading errors and behavior in regards to the actual issue.
User does not have access on any archive will be shown to any user trying to perform a search.
The issue can be identified in a Dtrace of w3wp and AuthServer on the affected EV server (EV01) during an attempt to retrieve a shortcut:
EV01
3740 00:36:50.683 [10472] (AuthServer) <24976> EV:L {CClientAuthIntImpl::RegisterClient} Completed registration. Client [CONTOSO\SKV4485102], AuthToken [EVSERVER02.CONTOSO.COM 9TgJnSNU/o*****], SIDs count [43], Cancel Id [7571].
3741 00:36:50.683 [7352] (w3wp) <3164> EV:L {ClientAuthImpl::RegisterClientToken} Windows token [00000000], Flags [None (0x0)], AuthToken [EVSERVER02.CONTOSO.COM 9TgJnSNU/o*****]
The AuthToken is pointing to another EV server which is not correct as seen with the Alias EVSERVER02. A Dtrace on that EV02 server will show the failed attempt with an Event ID 4224 error:
EV02
5 00:36:50.878 [37184] (AuthServer) <27028> EV~E Event ID: 4224 Authentication request failed. |Reason: Attempt to authenticate with an invalid token |Caller: CONTOSO\ESG21451 |Token: EVSERVER02.CONTOSO.COM 9TgJnSNU/o***** |Failure Count: 6 |
V-437-4224
During the Enterprise Vault Cluster Setup wizard the ConfigState (HKEY_LOCAL_MACHINE\SOFTWARE\KVS\Enterprise Vault\Admin\ConifgState) registry key gets created and later deleted at the end of a successful cluster configuration. However, if the wizard gets cancelled or interrupted the ConfigState registry key will remain on the EV server which can cause this issue as the ClusVirtualServer key can incorrectly point to another EV server. This causes authentication requests to be sent to that other EV server as seen in our example where the AuthToken is sent to EVSERVER02 instead of EVSERVER01.
Rename the ConfigState registry key to .old and then restart all EV services.
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KVS\Enterprise Vault\Admin\ConfigState.old
Clus (DWORD) 1 [0x1]
ClusResourceGroup (SZ) EVCLUSTERG01
ClusVirtualServer (SZ) EVSERVER02