Client migration
Updated: 01 Mar 2012 | 2 comments
This issue has been solved. See solution.
what permission do you have to give to the ev_service account so on client migration it can assecc network shares rather than just the local machine. is there anyway of reporting on how the client migration is doing
Discussion Filed Under:
Comments
You're talking about Client
You're talking about Client Side PST migration right?
Typically it will be regular read write and delete, so that it can be able to find the files, copy them and then eventually delete them etc. You *can* run the PST tasks as a Domain Admin account or another user that has access to networks, and thus not having to give the EV Extra permissions.
If you do do that though, you will have to give that user the PST Administer role through Roles Based Administration so it can perform the tasks it needs to do in EV.
As for the reports, you should be able to go through Vault Admin Console, expand out Personal Store Management, right click Files and go to "Report"
I also believe it does write events and report files in the \Reports directory
Having worked through this
Having worked through this quite recently, if you're doing Client Driven PST Migrations, and the clients have PST files on network shares (not recommended, etc, etc, etc) then the Vault Service Account needs to be either an administrator on the remote device/file-server, or a power user (?? I forget the exact name, and can't find it out from this Windows 8 machine). This is because when the client tells the server where the PST file is, it needs to 'convert' the share name to an admin share based name (eg C$, D$, E$, etc)
If the EV Server can't convert the share to an admin-based-share-name.. then the client won't migrate that PST file. Usually the reason for not being able to convert the share name is that the account doesn't have access to the admin shares, ie it's not an admin, or power user (? see above ?)
Would you like to reply?
Login or Register to post your comment.