PST Locator Task Issues (Contd.)

[AKL]

Hello again Guys

Sorry I have been in middle of PST migration project and that's why keep adding the questions regarding PST locator task. (I am sure I will get into lot of trouble when starting collector & migrator tasks but more on that later)

This forum is in continuation of below:

https://www-secure.symantec.com/connect/forums/pst-locator-task-issues

We started PST locator task on 3rd February 2012 - and after nearly 14 days, it has completed/have been able to detect nearly 12% of PST files only. Have been able to search 9% of machines in domain for registry. The errors recorded are same.

So far, I corrected security group vault service account was part of - made sure it has local admin access on all workstations in domain. As per direction from Symantec tech team - removed the computers which had permission error and restarted PST locator task. Though they didnt give me SQL query for same, but below is what I used for same.

useEnterpriseVaultDirectory

select* from dbo.PstComputer where RegistryFailureText = 'Requested registry access is not allowed.'

--Delete from dbo.PstComputer where RegistryFailureText = 'Requested registry access is not allowed.'

As per Symantec document, nothing can be done to fasten this Locator task process as highlighted below:

http://www.symantec.com/docs/DOC2817

In the introductory paragraph on page 39 it talks about Large-scale migrations and their need for careful planning due to the fact they can take several months or longer and once you begin archiving will compete for resources with your daily Archiving and Journaling.

As it talks about in the guide on page 40, there is no way to predict the amount of time to locate the pst's when using the Locate and Migrate method.

On page 41, it talks about increasing the concurrent migrations which may be of help to you when it comes to the migrator task.

I was wondering if anyone has any further ideas that could be used in same direction? Do you guys feel we shoud deploy third party solution like Transvault or Quadrotech or sometihng else?

[TonySterling · Accepted solution]

I would personally recommend Quadrotech.  I have worked with it in the past I really like it.  I used to work with the guys that developed it and think very highly of them.

http://www.quadrotech-it.com/products/pst-flightdeck/

As I said on a previous post, I would recommend you get some quotes from Transvault and Quadrotech and weigh that against the man hours you are going to spend working with the native EV Tools. 

[MichelZ]

Usually, locating the files is the least of your problems, when dealing with the native Enterprise Vault tools.

Once you start migrating, you will see that assigning PST Files might be a challenge, that migrating them using either Server Driven or Client Driven is a challenge, as it is sometimes very error prone, you might find that Password protected PST files are a challenge, that "private" PST files (which should not get imported) might be a challenge, or that simply the lack of reporting is a challenge.

We (QUADROtech) solved a lot of those challenges with our PST Flightdeck product.

http://www.quadrotech-it.com/products/pst-flightdeck/

Cheers
Michel
 

[AKL]

Thanks guys.

I will surely put up this idea for third party solution to team and see what their response is. They might not be comfortable with idea but will try to push harder.

Beside same, any other ideas to boost this process only with EV native tools? Also, if I change the account locator task is currently running under - Will I need to recreate the dbo.PstComputer table or simply restart the locator task?

[AndrewB]

you should be able to continue after restarting the task without dropping the table.