Video Screencast Help

EV Deployment Scanner reporting on removed FSA Volume

Created: 11 Apr 2014 • Updated: 07 May 2014 | 3 comments
This issue has been solved. See solution.

Hi all,

We going to be upgrading EV (Two Steps, 8.0.4 to 9.0.5 and 9.0.5 to 10.0.4 R1 + CHF2) and we're running the Deployment scanner to see what needs cleaned up prior to the work.

Most of the error's/warnings have been cleared but there are a number of issues relating to "File Share Permissions".


We used to create a volume for each file server drive (e.g E$ or K$) prior to creating the actual volume and subsequent Folder archive point to allow some scripted operations used by our server team. We've now removed the need for these drive volume points and as they don't actually archive anything we'll be removing them.

Deployment scanner however is reporting "Enterprise Vault Deployment Scanner is unable to determine whether or not the user CLD1\evaccount has read\write permissions to the share \\file_server\e$. Please verify that the user has read\write permissions to \\file_server\e$ before adding it as a File Server Archiving target."

We've removed e$ as a volume point within EV for the file server in question yet it's still reporting on it within Deployment Scanner.

I've rebooted the environment since making the change but this hasn't cleared it up.

I know Deployment scanner populates the "File Shares" config before running so why would it still be reporting on a volume which is no longer configured ?

It's not a major problem as we don't archive anything under the likes of e$ directly anyway but I'd like to clear it up before the upgrade anyway.



Operating Systems:

Comments 3 CommentsJump to latest comment

TonySterling's picture

Have you removed the share from the Deployment Scanner configuration?  Just select it and choose remove.


Kevin O'Connor's picture

Hi Tony,

I have now but in our test environment once it was removed from the admin console as an archive point it automatically removed itself from the deployment scanner on the next run so it looks like whatever update process it usually would use isn't working.

It's not the end of the world but would be nice to know why it's not updating automatically prior to the upgrade.

Just want to be sure it's not leaving config info behind itself which could cause problems with the upgrade.

We still have one such point which has a subsequent archive point and can't remove which is also still reporting a "read\write permissions" issue so I'll have to resolve this one anyway.



Kevin O'Connor's picture

Hi Tony,

We went ahead and upgraded from 8 to 10.0.4 R1 CHF3 at the weekend and everything is still working thankfully.

We had a minor hitch with the 9.0.5 upgrade, found an etrack issue that only one other person has found so far, but now we're up at 10.0.4 the shares are still accessable and files are being archived so it looks like I shouldn't have been so worried afterall.