Just sharing some information.
Following this forum post - https://www-secure.symantec.com/connect/forums/dfs... - I've been able to successfully migrate PSTs using the client-driven migration method. There are a couple of requirements:
At the client-side computer, the OS cannot be Windows XP. I've only been able to get this to function when the OS is Win7 / Win8.
On our primary EV server - where the PST migrator task runs - a HOSTS file entry must be created that resolves the IP address of your primary DFS server with the short name and the FQDN of your domain name.
10.1.1.1 domain domain.com
Once you enable the mailbox for client-side migration, and the user has a PST opened in Outlook that's on - for example - their home directory that exists on a DFS network share (like my environment), the PST will successfully migrate.
An additional challenge to client-side migration behavior is the system searching for PSTs on the local hard disk and migrating that content into the Vault for whoever first logs into that machine and is client-side enabled, regardless of who owns the PST or what the PST tag indicates. I realize this aspect may be open to debate, but the Administrator's Guide - and my personal testing - both confirm that client-side migration ignores the marking of a PST to determine who owns the content.
Here's how I got around that: Within the PST Migration Policy, check the box "Restrict search to PST files under users' 'Documents and Settings' folder. Then, create a symbolic link within %userprofile% that links to their DFS-located Home Directory:
mklink /D %userprofile%\Documents\Symlink p:\
I realize that you can use server-side migration to target indivudal Windows servers that run DFS and house the home directory data, but you forego the automatic email messages that EV sends to the employee when they're enabled and when each PST is migrated successfully.