W2K8 R2 domain enviroment, DFS NameSpace is \\domain.local\dfs, single domain.
We have some users who can see file shares with their given permissions using\\domain\dfs\Accountants\User.One while others have to type in\\domain.local\dfs\Accountants\User.Two for to see theirs (the .local being the only thing different).
When I type \\domain\dfs\Accountants\User.Two at their PC (Run...), I see only their folders that were previously setup for Sync with Offline Files in Windows 7. The files are listed as Online in the Explorer window.
When I type \\domain.local\dfs\Accountants\User.Two they see all the sub folders they should be seeing. Also when I type the UNC path\\server\shares\Accountants\User.Two they see all the nested folders they should see.
Existing AD Profile: Home folder: Connect: X: To: \\domain\dfs\Accountants\User.Two and they can't see thier X: drive at all when loging into the domain, but mapping it manually (after disconnecting it first) works, using the domain.local and/or the UNC path.
Here's what changed. We had a DFS server that hosted the files (via iSCSI SAN) and has been taken out of production. It was replaced with the production server and the iSCSI SAN was connected to the new server. Permissions from "old" shares were copied via PowerShell (get-acl) and printed out for integrity. The same permissions were applied to the "new" shares for the given folders and confirmed with the same PowerShell script so that before-after permissions were verified.
It seems the users who did not have their X: drive (as configured via AD) to use Offline Files aren't seeing this issue. I'm wondering if that is playing a role in this. I'd like to get a better understanding of what's going on before arbitrarily changing AD Profiles to reflect the \\domain.local\dfs path for those users.