Here are two slightly different, but similar scenarios:

  1. There is an S:\ drive mapped to \\server\share. A DFS namespace is then implemented, with S:\ changed to \\domain.local\dfs\share (which is pointing to the legacy share). Now, some files with linked/embedded files and various applications act weird and malfunction. To note, these embedded file links (ex. linked Excel tables) point to the legacy share, while the parent file is opened from the DFS share.

2. There is a PST for a POP/IMAP account located in My Documents. Documents is then Folder Redirected to a network share. Now, Outlook has trouble accessing the PST associated with the account, despite the fact that the Data Files tab indicates the correct network path for the file (\\server\share\user.name\Documents\outlook.pst). Outlook loads, but it claims the PST cannot be found, hence the Inbox for the associated account cannot be viewed. *

*Turns out this was a specific known issue. I'll post a link later

Why do things "break" when performing these types of redirection, even though the path to the files is still the same from a front-end point of view?

  • Regarding 2. , do you have the namespace sharing permissions for the folder(s) in question set appropriately? It's worth noting that if the folder(s) were previously shared outside of DFS, although the security ACLs will be unchanged that the DFS shares won't necessarily be identical; maybe this is worth checking?
    – BE77Y
    Dec 16, 2014 at 16:27
  • Further to the above, can you please elaborate on what the weird behaviours/malfunctions are, that you observe?
    – BE77Y
    Dec 16, 2014 at 16:56
  • What permissions are appropriate for the DFS namespace shares? As for #2, the redirected folder is given CREATOR OWNER permissions for the root folder, subfolders, and files. Should SYSTEM also be given permission for the redirected file share?
    – Bigbio2002
    Dec 16, 2014 at 17:18
  • Share permissions for DFS namespace shares can be whatever you wish/whatever is appropriate for you - eg perhaps just mirroring the ACLs. In your example you mention user data folders, so at a minimum the user(s) in question should have read access to the folder(s), for example.
    – BE77Y
    Dec 16, 2014 at 17:22
  • some files with linked/embedded files and various applications act weird and malfunction. - Needs clarification. Outlook has trouble accessing the PST associated with the account - Needs clarification.
    – joeqwerty
    Dec 16, 2014 at 18:07

2 Answers 2


This is an old thread but maybe someone could benefit from my comment.

There is a service called Distributed Link Tracking Client that finds a file that was moved or renamed on an NTFS network share (KB312403). This works for shell shortcuts and OLE links as well.

We had a similar problem when we moved folders on our DFS share. The experience was that after the folders were moved the shortcuts on users' desktops were changed from \dfsvirtualname\sharename to \realservername\sharename. Yes, the files were found but only one time. The next time the folder was moved (like archived to a folder named 2014, etc) the shortcuts broke.

The issue you have with some files could be that those files were already moved in the past and the Distributed Link Tracking Client found them, changing the link to a full \realservername\sharename reference and now it can't find the moved file.


You might be making the mistake of treating DFS as just an easy way of giving your share a nicer name, or a name that is more portable - not hardcoded to any particular server.

DFS does not support file locking, and I would guess this is the cause of your embeded file issues.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.