Who are you running the PST Migrator Task as? Have you tried running this as Vault Service Account? Does it then work?

No it does not work, the PST admin account has":

Remote Registry (Full Access)
Remote File System (Full Access)

And Replace token, Act as part of operarting system, etc etc.

It did work until we changed the PST migration policy, by not keeping the PST file (Read Only, Hidden, Compress) but to delete it.
SInce that change, PST files are not deleted, and the migrator task throws an error (Only in the PST mig Task Log)
The details of the PST migration state "Complete"

If i login using the PST admin, I am able to delete the PST files...so file systems rights are in order.

Regards,
Edo

Can you post a log?  Anything extra in the event log?  Have you dtrace'd migratorserver?

Event Log is empty, no errors or warnings in the Event Log,

This is shown in the PST migrator Log.txt in the reports directory.

/6/2010 2:12:56 PM Failed to get Vault Store backup policy for Vault ID xxxxxxxxxxxxxxxxxxxxxxxxxxxServer1 for PST: 
PST Location  Outlook\ 2006.pst : Login failed for user "domain\sa_evpstadm'. **

The task in Personal File Store says, completing. (Still showing a chunk ID) but all PST Holder and Temp Folders are Empty.
PST file is still on the orginal location, only has a Read only Flag... Nothing changes if I clear the Read Only Flag.
While the Status of the PST migration on the History Tab states  "Complete"

PST Admin user has all necessary rights (Registry/ Hardisk is local Admin on Server and Clients) and is in the roles PST Admin and Power Admin for EV so that should be enough.
 
Will start a DTRACE, any "Items" I should look for? to catch in the dtrace?

324 08:17:52.597  [6092] (PstMigratorTask) <CopyBackThread:8140> EV-H {PstLogFile.LogError} Failed to get Vault Store backup policy for Vault ID 1F86E8312AE3EB148BA60C25AD70E4DC31110000EVServer1 for PST: \\Notebook\Outlook\Archief Outlook\archief 1 2006\archief 1 2006.pst : Login failed for user 'Domain\sa_evpstadm'

The user you are doing the migration has might need additional rights..  if they are not the VSA.  For example, I can see in the code where that error is thrown, and it would appear we're trying to find the vault store which relates to the archive we're importing items into.  We want to find the vault store, so that we can check the safety copy settings that determines whether we need to "wait" before we attempt to delete the PST file on the remote machine or not.

Is the user you're using setup with just a selection of the Roles Based Admin roles?

I would suggest (without having it set up in my lab to try it) to add Storage Administrator.

Yes, he is only PST admin and Power Admin, that is almost like an EV Service Account, but not all the rights.

I checked the PST Admin Account and it has all rights necesary stated in admin and help
I expanded FS rights on the server,

Strange thing is, the process worked perfectly, until we changed the PST migration policy, since that it can not "Delete" the PST file

Well if I logon with this user, I can delete the PST,

Does the PST mig user need SQL rights?

Okay, but I think it's more likely to be a missing RBA role.

As I explained.. the code is trying to check the safety copies setting on the vault store where the archive resides where you imported the PST data to.  It does this because you've opted to "delete" the PST... but we don't just delete it, we check what your policy is regarding safety copies first.  If you have opted to keep safety copies, until after backup, then the PST won't be deleted until after the items you've imported are backed up.

The problem is that the rights that your admin user has, isn't permitting it to check the vault store safety copy settings.

So, in my opinion, you need "more" RBA roles.  For example Storage Administrator.

He was member of EV Power Admin and PST admin,

Now also member of Storage / Exchange and Messaging.

But the membership of the EV power admin should do the trick..(Since it has rights on all layers)

Yes you're right it *should* be enough .. but there might be a small bug in this area..  All I can tell you or suggest to you is a way around it, and if it works .. or we "eventually" hit in on the right combination of RBA roles, then we can :-

a) bug it
b) document it.

Ok perfect,

For now we have given the PST admin exactly the same rights as the EV Service Account.  and we added him to the Power admin, messaging, storage and PST admin roles in Role based admin.

Restarted the tasks so all new rights are enabled for this user, still I get the "Unable to Login in the PST migtask log"

Can you state me the exact rights for the EV Service Account, maybe I am overlooking something.?

What comes in to mind is SQL rights?, We have not granted SQL rights, so as the policy is "Stored" in SQL he will not have rights "Reading" it.

Just a small brainwave..

I also used the VAC with the PST admin credentials, I can do everything in the VAC (did not change anything) nothing is greyed out.

So that looks good,

Well, without going into all the SQL that is performed, try, as your admin user, doing a :-

select * from vaultstoreentry

From the directory database.

Ok, I got a little bit closer to the Solution, we have given the PSTadmin user Read Access to SQL and the Login errors are gone, so definitly SQL related.

Now the status is still on completing, so wondering if it also needs Write Access to change that status in SQL. (Answer would be yes).

So, I guess the PST admin needs the same SQL rights as the SA Account? Not clearly documented in the Guides...

Can you provide the Rights this user needs on SQL ? DB owner is a bit much, but he should have some "Write" access somewhere I think?

same as SA EV?

Added the appropriate SQL RIGHTS for the PST admin, now he is able to update the SQL records, migrations are now finished!