DFS Folder Redirection Woes… and a Fix!

If I encounter a network with multiple sites, especially if one of those sites is our datacenter, I generally implement DFS and replicate data between the sites.  I’ve been a big supporter of using DFS since way back in the Windows NT 4.0 Option Pack days.

However, DFS does create some unique challenges from time to time and I recently ran into one of those when I enabled Folder Redirection on our internal network and pointed the redirected folders to a DFS path.

When one redirects the AppData folder, the Taskbar shortcuts are relocated as part of that.  Once that happens, the following error occurs:

The shortcut still works; it’s just that since it’s on the network (which isn’t, by default, trusted), one must confirm the shortcut is safe by clicking on “Open”.

Frustrating.

Searching around the Interwebs, I learned this setting is controlled via Internet Explorer’s security zones.  Kind of stupid, but whatever.

The common solution to this problem is:

On the Security tab in Internet Explorer options, disable Protected Mode and then select the Local Intranet Zone:

Click “Sites” and make sure all of the checkboxes are selected:

This is where things started to get a little frustrating.  This seems to be all one has to do in order for servers on the network to be trusted, but it only works if the UNC path is a traditional \\server\share format.  It doesn’t work if you point to a DFS root because no server name is indicated in the UNC path.

As it turns out, if one is using DFS for Folder Redirection, those settings may not have to be enabled once the Local Intranet zone is sufficiently tweaked.

In the current window, select “Advanced” and add the UNC for the DFS root with a wildcard (*) as the server name:

The wildcard indicates that any host which is part of the domain will be trusted.  This includes not indicating a host at all, which is why DFS made this whole process so wonky.  This is also why the checkboxes in the previous window probably don’t matter… by including the wildcard, all servers in the domain are trusted.  If, however, there are servers on the local network that aren’t part of the domain, I’ll still need to worry about those checkboxes… along with the normal authentication issues that need to be addressed.

Make sure the server verification setting is NOT selected and click “Add”:

You’ll see the UNC path added to the list of trusted Websites (which, apparently, means “Websites and everything else”.

Keep in mind, we’re dealing with a web browser here, so everything is done from that perspective.  If you don’t indicate this is a UNC path by including the double backslashes, IE will assume it’s a website:

Because of this, the only way data on the local network would be trusted is if one accessed it via a web browser.  By adding the DFS root as a UNC path, access to the data is available across the network via shortcuts (and other methods of access).

To see this, hit “Close” after the DFS Root UNC path was added and then click “Advanced” again:

The UNC path has been changed into a standard URL with the “file” scheme.  If you have websites on your intranet which are accessed via web browsers, go ahead and add the path again without the backslashes for good measure.  I don’t know if that’s necessary – if you find yourself in that situation, please test it out and let me know.

Submit all of the changes and get out of Internet Explorer.  Test the shortcuts, and they should work fine.

I hope this helps out.  As always, your feedback is greatly appreciated!

If you found this helpful, please give a Thumbs Up!