Just to provide some additional information, I ran some packet captures on an affected machine. Anytime you are browsing around an SMB share you get 'Create Request File' packets as you move through the share.
As an example I have: \domain.com\company\div with 'div' having a target of \server01\div
I have an F: drive mapped to \server01\div and I have a T: drive mapped to \domain.com\company. If I click on the F: drive, a non-DFS share, I will see 'Create Request file' packets that look like 'Create Request File: Div'. It is relative to the drive letter. If I click on the T: drive and click on the div folder, mapped to a DFS location, the packet will look like 'Create Request file: \domain.com\company\div'. The DFS share always contains the full DFS path in the packets and not a relative path. Furthermore, the request packet will be sent to the currently active DFS namespace server for that user. So whatever shows up as the namespace server in the DFS tab. All of this is normal behavior.
What I am seeing on a machine with the T: drive broken is that they see all the root folders when they click on the T initially. When they click on that 'div' folder the packet looks like 'Create Request File: Div'. On a normal functioning drive mapped to a DFS location it would contain the full DFS path, but in this case it acts like a drive not mapped to a DFS location and just uses a relative path. Furthermore, the requests are sent to the original server the namespace was created on, and not the active namespace server for that user. This happens regardless of what namespace server I set as active in their DFS tab. When I re-map the drive it goes back to behaving like a normal DFS mapping, at least for a while. I haven't pinpointed exactly what makes the drive break. It seems to occur around VPN disconnects and re-connects.
Yes, we have been manually mapping the users who have problems, but the problem returns. Most of our users are on 1909 or 2004. The one I have been testing with is on 2004. We run patch jobs every week so the machines should all be up to date, but I have verified the one I'm testing with is patched.
could you find a solution. Im having the same problem.
No solution yet. As a workaround we pushed out a quick access pin to all of the users. We are considering just having everybody switch over to using the pin instead of a drive letter. I still intend to open a ticket with MS about it, so I will post back if we find a more permanent fix.
Sign in to comment