Client driven migration

Client Driven is meant to migrate PST files that are actively connected to the users mail profile, for PST files out there on shared drives, then you probably should look at server migration, if you actually read the documentation it suggests considering using a mix of both client and server driven in order to have a succesful migration strategy

Jesus - That's exactly what we are thinking - use a mix of client driven and server driven migration. So, basically we want EV to ingest all of the PST on shared drives that are connected to the users mail profile. Thereafter, we can use the server driven process to identify the rest of the PST.

ISSUE: The client driven process is not identifying the network share based PSTs. Though, it does identify all of the PSTs on users C:\ drive. We have tried every configuration imaginable but we are still missing something. Not sure if there is a log where it would identify any issues of network share PSTs etc...

Can you suggest something? I have  case open with Symantec.

See this technote:

http://www.symantec.com/business/support/index?page=content&id=TECH68805

If this not solves your issue, please post a client trace.

Symantec is saying that we are on DFS (distributed file systems) and client driven PST ingestion does not support DFS. We will get final conclusion after a conference call. Has anyone done a client drive PST ingestion from DFS?

Theres really conflicting stuff unfortunately

http://www.symantec.com/business/support/index?page=content&id=TECH55043
"This is because the UNC Path is virtual and is a part of a Distributed File Sharing (DFS) and is currently not supported.  To workaround the issue perform a Server side migration on the DFS server for those PST files."

http://www.archivingcentral.co.uk/uploaded_files/PST-Part3.pdf
"Neither client- nor server-driven migration will locate PST files that are located on DFS shares. This is
because, in both cases, the server must resolve the PST file path to an actual location so it can be sure
the PST file is not being migrated by both server- and client-driven migration"

Hi there

We are currently developing an add-on to our PST Migrator Software, which basically replaces the Client Driven Migration process by our own "Advanced PST Migrator Client".

Depending on the size of you project, this might be a valuable alternative to the basic Symantec tools.
We usually do not have the limits Symantec has with DFS, CIFS shares, Celerra, etc. Basically, all that can be accessed trough CIFS/SMB should be supported.

Have a look here and contact us if you need further information:
http://www.evtools.net/products/pst-flightdeck

Cheers
Michel

normally i hate sales pitches on the forums, but can actually say that pst flightdeck is really impressive

Michael - I will definately look at PST-flightdeck.

Jesus - When you say the serverside will also not work on the DFS - we have "Located" the PST files on the file server, after we "Searched" the server where the file server was locally connected. Though we have not try to migrate them. Are you saying that on the server side, we will run into the same issue?

Also, we have tried to map the users directly to the file share and we are coming up with spotty results for client driven migration.

I will keep you all updated as I get more info.

Jesus - Let me clarify - are you saying that when we try to migrate the file from the File Servers with DFS, eventhough the server-driven migration has located it, we will run into the same issue as client-driven, where the process just goes to sleep for 60 seconds as it believes there is nothing to migrate?