Forum Discussion

AKL's avatar
AKL
Level 6
13 years ago

PST Locator - Partial Search Results

Hello

We're working on a PST migration effort in corporate env using EV native PST migration tools (Server Driven approach).

During production run, we're seeing below trend:

  1. PST locator task runs fine & searches workstation registry for open PST files (registry search configured)
  2. No failure text logged & last registry search time updated to most recent in SQL tables for particular machine.
  3. However, it only returned 1 out of 3 files or partial results. i.e. if user has 5 files (example), Locator will mark only 1/2 files of them into PSTfile table for migration.
  4. Connected to remote registry for same workstation and make sure that registries do contain information about the remaining files. i.e. files open in Outlook and registry has the information for them.

Any idea what could be causing partial result? It is getting hard to manage with above issue increasing since we disable the PST usage as we go.

Also, Un-related to above, if anyone knows that EV turns "UseDatabaseQuotaDefault" ON? Basically, we've to keep it off so that EV can adjust mailbox size quotas as it ingests file to user mailboxes. But in certain scenarios we see that it is turned back ON after few hours or 1 day causing migration failure or user mailbox shutdown.

P.S. I know the tools like Quadrotech and others should be preferred while doing corporate or large scale migration but that's that atm. :S

Thanks in advance !

  • They sit on both - local & remote, mostly remote storage or file servers.

  • At certain places, but not all. The issue reported above is happening for Non-DFS file servers.

  • We have the same problem.  I have DFS servers which I can't see via client or server side.  But if I map my drives to the specific server and not the DFS namespace, I have had one successfully located pst file.  Client side nor server side are working for the others on network drives after redirecting to specific network server names. Client side works from local disk.  I don't know whats going on.  Might log a call.

  • So we managed to solve our problem.  We ran a dtrace of the migration task and found it didn't have full rights to the files on the shares.  Although it could read, it needed write as well.  We ended up making the service account Domain Admin as these have full rights across the DCs which were also our File servers (no other account had access all the way through) (found an article which said only the account which runs the Directory Service needs this access, and in our case it's the service account.)  It'll do until the migration is over.  So if you run a dtrace, see what is happening for you.

    We also got around the issue of DFS, so we can now target DFS shares - just had to get creative with the name space resolution.

    Good luck.

  • Thanks Sortid

    But in this case, the service account is already part of Domain admin. It also has three special permissions recommended by Symantec:

     

    • Act as part of the operating system
    • Log on as a service
    • Replace a process level token

    I might run another query just to make sure it has full access to all file servers. But it is part of Domain admin group & another groups that have full access to all servers & desktops.

  • I would suggest picking one or more test users where this problem is happening ...  and

     

    DTRACE the PSTLocatorTask

    Gather environment information about the workstation(s) that you're scanning - OS, Service Pack, etc, and WHERE the PST files.

     

    Also, remember that re-scanning is normally delayed.  By that I mean that on the PSTComputer entry in the Directory Database records when the file system scan, and the registry scan last took place... and the Settings tab of the PST Locator task there is the option to configure how frequently machines will be scanned.

     

    It would be even more great if you can do this on a machine that are you sat in front of, so you can see the disks spinning when the scanning takes place.

     

    Also remember that if you start the task, and 1 second later it reports no errors, but 'success'..  well, it's not likely to have scanned a whole remote registry or file system in that space of time - so in other words something is probably broken.

  • Thanks Rob. I'll try same.

    I also opened case with Symantec on same. They mentioned issue is because of registry HKCU\Network that the locator task use for mapping the PST files and storing them to dbo.PSTFile table accordingly. If the registry doesn't exists, locator reports error "Invalid PST" in DTrace logs.

    HKCU\Network key is not populated if user's home drive is mapped to their workstations using AD Object property rather than using logon script & manual mapping of home drive.

    Trying to validate the result. Symantec is working to publish this as a tech document as well so other people do not see this issue.