Here are two slightly different, but similar scenarios:
- 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?
Best Answer
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.