09-19-2012 12:51 PM
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:
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 !
09-19-2012 08:02 PM
Do they sit on local storage or on network or both?
09-19-2012 09:42 PM
They sit on both - local & remote, mostly remote storage or file servers.
09-19-2012 09:48 PM
Are you using DFS?
09-19-2012 09:59 PM
At certain places, but not all. The issue reported above is happening for Non-DFS file servers.
09-20-2012 07:59 PM
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.
09-21-2012 02:12 AM
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.
09-21-2012 06:12 AM
Thanks Sortid
But in this case, the service account is already part of Domain admin. It also has three special permissions recommended by Symantec:
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.
10-02-2012 01:49 AM
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.
10-02-2012 03:21 AM
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.