Unable to access UNC path on 2012 R2 file server with ABE enabled

Question

Brief Description:
We have granted access to people via a domain local group on a folder on a file server that is three levels deep from the share, i.e. \\servercluster\share\folder1\folder2\folder3, where folder3 is where the group is granted Read & Execute
access.  The share has Access-Based Enumeration (ABE) enabled and the Everyone group has Full Control share permissions.  We also use DFS, so the path for that is \\domain\dfsrootname\folderfororganization\share\folder1\folder2\folder3.  People
in the aforementioned group only have access to folder3, its subfolders, and files.  They do not have any access to folder2 or any of the other folders higher in the tree at all.  Also, consider that folder3 contains a subfolder folder4, which is
simply inheriting permissions. 
What we have found is that clients running Windows 7 SP1 have strange access issues when attempting to access the folder via either the DFS or cluster name UNC paths.
Detailed Testing Results Accessing Folder3 Directly:
NOTE:  "UNC path" in the following test results means either the DFS or the cluster name share path.  The results are the same regardless which path is used.
1 - Enter UNC path without trailing backslash in Windows Explorer's address bar:
Windows Explorer seems to do nothing for about 30 seconds and then displays the following error:
"Windows cannot access <UNC path>
Check the spelling of the name.  Otherwise, there might be a problem with your network.  To try to identify and resolve network problems, click Diagnose."
2 - Enter UNC path with trailing backslash in Windows Explorer's address bar:
The same error encountered in #1 is displayed immediately.
3 - Enter UNC path with or without trailing backslash but contained in double quotes in Windows Explorer's address bar:
Internet Explorer opens and displays the error:
"Internet Explorer cannot display the webpage"
4 - Enter UNC path without trailing backslash in Run dialog box:
An error message immediately appears:
"<UNC path>
The specified path does not exist.
Check the path and then try again."
5 - Enter UNC path with trailing backslash in Run dialog box:
Same as #4.
6 - Enter UNC path without trailing backslash but contained in double quotes in Run dialog box:
Same as #4.
7 - Enter UNC path with trailing backslash and contained in double quotes in Run dialog box:
Windows Explorer opens the correct UNC path location and displays the folder contents.  This is the expected behavior for all of these attempts.
8 - Create Shortcut to UNC path by performing #7 and then dragging the folder icon in Windows Explorer's address bar to either to the desktop or the Favorites section, and then attempt to access the folder via
the shortcut.
Same as #7.
9 - Attempt to create a shortcut to the UNC path using the New Shortcut wizard:
Unable to successfully create the shortcut, regardless if you add a backslash at the end or enclose the path in double qutoes.  When you press Next after entering the UNC path, you receive the following error:
"The file <UNC path> cannot be found."
10 - Disable ABE on the share and repeat all tests:
All tests with ABE disabled on the share have the same result as #7.  There is no issue whatsoever accessing the desired folder when ABE is disabled.
Other Notable Behaviors:
If the aforementioned folder (folder3) contains one or more subfolders (e.g. folder4), you are able to access those subfolders via UNC path directly and then go up one level to folder3 without issue, even when ABE is enabled.  You just cannot access
folder3 directly via UNC path unless you attempt to access it via the method used in #7 above or a successfully created shortcut.
Adding a user account directly to the folder3 ACL rather than using group membership makes no difference.
If access is granted to folder4 instead of folder3 (the fourth folder deep rather than the third), accessing folder4 directly via UNC path is not an issue regardless of ABE status or attempted access method.
Windows 8 and 8.1 clients have no trouble directly accessing the folder's UNC path via any method.  The unusual, undesirable behavior seen in Windows 7 is non-existent on Windows 8.x clients.
Systems Involved:
Client:  Windows 7 Enterprise SP1 x86
Server:  Windows Server 2012 R2 Standard in cluster
Other Details About the Systems:
Both the client and the file server cluster are in the domain AD DS domain.
The client and the file server cluster are in different subnets.
There is no firewall or other packet inspection or compression service/device in between the client and server (not even Windows Firewall).
Question:
Is there a way to fix this behavior with Windows 7 clients and ABE enabled on the share so that it works correctly without forcing the clients or server to use SMBv1 or disabling ABE on the shares?

Answer 1

7-Zip 9.20
Adobe Flash Player 13 ActiveX
Cisco WebEx Meetings
Java 7 Update 51
It should be noted that I can't repeat the behavior on my test machine again today after some changes were made in our environment.
Today, I found that someone had modified permissions on the folder to give the group my test account was a member of rights to traverse the folder hierarchy from the root of the share.  Additionally, in testing something with FIPS mode, I ended up reverting
my virtual machine to an older snapshot.
After removing the extra permissions that weren't present when I was doing my testing and reverting to the older snapshot, I  am not having issues accessing the real equivalent of folder3 directly in Windows Explorer via DFS UNC path or creating a shortcut
with the New Shortcut wizard.
Things have been fundamentally changed and I cannot repeat the behavior on this particular folder.  I will see if I can recreate the same situation on another folder.