Enterprise Vault archived file recovery
Hi all,
I'm only getting to know EV through a lab environment, which is intended to replicate a project I'm working on, so please bear with me if I ask something that is obvious to everyone.
I have established a single EV server, which is connected to a Fileserver role running on a Windows Failover cluster. The role has 2 nodes, both on Windows Server 2012R2 and after much trouble, I have managed to get archiving to work as intended. All machines in the lab are domain-joined.
I have a policy set up to archive all PDF files and log files larger than 2 KB just to see if it will correctly pick up both options - it does. It archives the files as intended and marks them as archive
When I try to recover a file from any server or client system, I always get the same error in Event Viewer of the server which is the owner of the role - Error downloading file, event ID 20491. I have tried this from: client PC (Win11), EV server, both failover nodes, tertiary server unmanaged by EV, and from the domain controller.
I found the article below saying that I need to add https://<fqdn-of-server>to the Local Intranet zone (https://www.veritas.com/support/en_US/article.100018054) and another one very similar to this, saying the same thing. I have done this and it did not solve the issue. I also added it to the Trusted Sites just to test - same result.
When I click the link in the Event Viewer, it goes to download and performs a full download of a file which I can open, with one possible issue - it asks for confirmation because the certificate is not trusted. Once I click "Continue", it immediately downloads the file (does NOT ask for password).
To combat this, I've added the EV certificate to the local trusted certificates on the Fileserver nodes and now it goes straight to download, but asks for a password. After entering the password, it downloads the file.
On the client, domain-joined, machine, if I paste the link from the Event viewer, I also get the sign in interface.
This leads me to believe that re-hydrating the file is only permitted to the EV service account after manual login, while other users do not have this privilege. However, I have set up permissions in the Archive so that Everyone and Domain Users has full permissions:
Am I missing something else here? What else can be checked to get re-hydration to work normally?
To be clear, the goal here is not even to rehydrate the files - it is to move away from WS2012R2 to WS2022, this whole process of building a lab and rehydrating files is just to verify that my upgrade process 2012R2->2016->...2022 - is designed properly :)
Thank you to anyone who actually read all of this and especially if you have a suggestion on how to solve the issue!
I figured it out.
Calls from the owner node (and standalone fileserver, too) are made to the EV website, which is serving an untrusted certificate. Once I imported the server certificate to the Root Certificates or 3rd Party Root Certificates store, it immediately started working as expected.
To compound the issue, I had previously imported the certificate to Node1 store and it would occasionally work, but forgot to do it on Node2. So, every time Node2 would take ownership, stuff would stop working, making it a hassle to pick up a pattern.
I confirmed this by additionally using a standalone fileserver hosting a share, also archived by EV. As soon as I added the certificate to one of the stores, rehydration started working as expected.