Update: 5/14
So I ended up fixing the issue yesterday afternoon. In our working DFS share Authenticated Users had "Traverse Folders/Execute Files" permissions while one that didn't work did not. Once I applied that permission to the $group2_folder_redirection group it worked as intended. I will add a edit to the bottom to show the additional steps I took to get to there. So make sure users have "Traverse Folders/Execute Files" access to only the root share folder.
Original Problem:
I just wanted to go over an issue I have run into at work. I am still working on resolving it, and will update here when I have found a resolution.
We first were notified of an issue the day after we changed our Folder Redirection path. We are in the process of retiring a Windows Server 08 and the first step was moving Folder Redirection off of it. We were using the UNC path for our previous route, but are switching to DFS for future proofing. We already have one group that has its Folder Redirection from the same DFS, but a different share.
So users were complaining that they were having issues opening Publisher documents, saving office documents soon after they were opened, and attaching files to outlook. It was odd because the original DFS Folder redirection was configured very similarly and was having no issues. These issues were not happening if the files were accessed with the UNC path to the DFS share.
It was configured \\$domain.com\$groupusers with authenticated users having read access to the parent share and only the specific user with access to their respective folders. Domain Admins had access to all. The one different between the two was that there was a $group_folder_redirection group that had read access to the parent share in the original group and nothing like that in the new group. I made that switch with adding the users to an $group_users group and then added that group to $group2_folder_redirection group that had read access. After testing the change for a while we noticed no different.
That was when I decided to try a few different tools. First I tried Process Explorer. I noticed when the files were having issues that in the TCP tab of Process Explorer it was scanning through each of our Domain Controllers via http and once it was done (about 20-30 sec per) it would then act normally.
I then dug in more running Wireshark on the client I was testing on. After testing a few times on both affected accounts and accounts from the previously working redirection and comparing the packet captures I noticed a few things.
The client would have an Access Denied SMB packet from the DFS share in the middle of the communication.
Then it would reach out to each of the Domain Controllers via port 80 and never get a response back.
Lastly it would reach out to the Domain Controllers again via Port 445 and that was when the file would work properly.
So there are two possible issues:
1) There is a share access issue for the DFS share that is preventing the users from properly accessing the files.
2) The DC are ignoring traffic over port 80 (properly) and once the computer switches over to 445 it works. After looking up port 445 it is a TCP/IP port for Networking access without NetBIOS or Microsoft-DC Active Directory. So there could be an issue with clients trying to communicate with AD over unsecured ports.
I will be looking a lot more next week and will update with anything I find. I hope this has helped anyone who may have been having similar issues.
Edit: 5/14
Yesterday I dug more into the packet captures I had on the non-working shares and ran a few more to verify what I was seeing. When I really dug deep I saw that the Access_Denied packet was when accessing the root DFS share. Then in the next few packets the client queried the DFS name with DNS, and tried to communicate with each IP it received from DNS. So I built a new DFS share to test with and noticed one difference in permissions between the working and not working. The $group_folder_redirection had the same permissions, but each share also had authenticated users permissions. The working one had "Traverse Folder/Execute File" permissions while the other did not. After testing, applying that permission to the $group2_folder_redirection group fixed the issue. So folder redirection works, and files can be accessed without that permission, but it will cause issues with office and DFS shares.
This was originally posted on my blog.