cancel
Showing results for 
Search instead for 
Did you mean: 

PST Migrate Wizard don´t use the right user

Jakob
Level 5
Partner

Hi,

we have a seperate pst migration account to run the automated pst migrations.  It´s a seperate user because of compliance topics etc. This user is assigned to all pst migration tasks an the automated tasks works fine.

In some cases the admin wan´t to start a manual import. We log on to EV as this pst migrator account and start the wizard. But the wizard fails because of permission errors. In a dtrace is visible that the task failed because the VSA didn´t have permissions to access the file in the network.

Is it possible that the migrator wizard runs as the currently logged on user?

EV12.0.2 on Windows Server 2012R2

 

Thank you

Jakob

1 ACCEPTED SOLUTION

Accepted Solutions

Jakob,

I'm actually the Backline TSE who has been helping Kaustav with your case, so the answer Veritas gave you is the answer I told Kaustav to give you. Smiley Happy

 

I did some research on this and the reason we can't simply do a SQL workaround that doesn't check the file is that the stored procedures that are run when you add PST files (AddPstComputer and DonatePstFile) require as input a unique EntryId for the computer/file record that you are adding. This unique value (of EVGUID data type) is generated by the EV Directory Service at the time you add the file (for instance, by running the Add-EVPstFile cmdlet) and fed to the stored procedure that creates the record. Unfortunately I was not able to find a way to generate these EntryId values directly in SQL; it appears that they must come from the Directory Service. Without a valid and unique EntryId value, the DonatePstFile SP cannot add the PST file record to the PstFile table.

I hope that helps explain the difficulty behind the issue a bit more.

 

--Chris

 

 

View solution in original post

7 REPLIES 7

CConsult
Level 6
Partner    VIP   

Have you checked the service? normally all tasks run with VSA. Its is also recommended to give the VSA the permissions to all targets.

Jakob
Level 5
Partner

Hi CConsult,

which Service? I have to run the manual import as another account than the VSA because of security/compliance topics. In the automated tasks it works as wished because it´s running as the pst migrate account.

But the manual imports run in every case with the VSA Account Logon Informations which is my problem. Also if I use the powershell command ADD-EVPSTFileImport it runs as VSA and not as the logged on PST Migrate Account.

So how to run a manual PST Import Task as another user then the VSA?

Jakob

 

Jakob
Level 5
Partner

Is this a general EV issue? I´ve tried the same thing in another surrounding with EV10. There happens the same...

I´ve opened a ticket for this. We will see.

ChrisLangevin
Level 6
Employee

Jakob,

The manual import operations (the wizard and the Add-EVPSTFile cmdlet) will run as the Vault Service Account (VSA). The automated PST tasks (Locator task, Collector task, Migrator task) can be configured to run as a separate account, but this is only applicable to those tasks, not to all PST import operations. If it is required for compliance that the VSA not be able to access the PST files in their original paths, then you will need to use the automated PST tasks to locate and collect them.

 

--Chris

Hi Chris,

thank you for your comment. Veritas also give me this answer a few hours ago... It has taken a few days till Veritas gave me this reply..

I´m wondering if there is a workaround for this step (Add-EVPSTFile / Locator Task). For example a sql query that inserts a new PST File without checking the location. If the file is in the list of PST Files than we have no problem. The collector and migrator task will run with an authorized account.

Jakob

Jakob,

I'm actually the Backline TSE who has been helping Kaustav with your case, so the answer Veritas gave you is the answer I told Kaustav to give you. Smiley Happy

 

I did some research on this and the reason we can't simply do a SQL workaround that doesn't check the file is that the stored procedures that are run when you add PST files (AddPstComputer and DonatePstFile) require as input a unique EntryId for the computer/file record that you are adding. This unique value (of EVGUID data type) is generated by the EV Directory Service at the time you add the file (for instance, by running the Add-EVPstFile cmdlet) and fed to the stored procedure that creates the record. Unfortunately I was not able to find a way to generate these EntryId values directly in SQL; it appears that they must come from the Directory Service. Without a valid and unique EntryId value, the DonatePstFile SP cannot add the PST file record to the PstFile table.

I hope that helps explain the difficulty behind the issue a bit more.

 

--Chris

 

 

View solution in original post

Hi Chris,

thank you for your support. I will create a feature request for this topic.

I think in generall it should be possible to import PST Files without using the permissions of the VSA.

Jakob