Issue with DFS-N and mapped drive letters

sto 1 Reputation point
2020-12-17T15:33:33.647+00:00

We have a namespace called 'Company' with all of our users mapped to it with drive letter 'T'. We have a seemingly random group of users who occasionally have the drive mapping break, but in a weird way. When they click on the 'T' drive the Namespace still comes up and shows all the folders in it. They can click through any folder that doesn't have targets, but when they click on a folder with a target they get a message that the path is not available. If the user goes to the namespace using the UNC path everything works. We have a second drive letter, 'I', that maps to '\domain.com\company\Archive' with Archive being a folder with targets. That mapping does not have any issues, it only seems to be the one that goes to "\domain.com\company". Remapping the drive letter fixes the problem. Some users get remapped once and don't seem to have an issue again while others continually have the problem over and over. We push the mapping through GPO with an update policy.

  • I have tried switching the user to different namespace servers for their T drive connection and clearing DFS cache, but the problem persists.
  • DFSutil /pktinfo from the users machine shows all of the correct folders and targets
  • DFSutil diag viewdfspath \domain.com\company\div from the client resolves the 'div' folder to the correct namespace server
  • I think most DFS checks I can run from the machine will work because the namespace still works fine if using the UNC path. I can map a new drive letter to it and that will work. So it seems to be a weird interaction with the drive mapping and the Namespace. Sometimes the issue will resolve itself after a reboot.

Any thoughts?

Windows 10
Windows 10
A Microsoft operating system that runs on personal computers and tablets.
10,597 questions
Windows Server
Windows Server
A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.
12,109 questions

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. sto 1 Reputation point
    2020-12-21T16:37:14.673+00:00

    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.

    0 comments
  2. Candy Luo 12,656 Reputation points Microsoft Vendor
    2020-12-22T02:56:00.69+00:00

    Hi ,

    Based on your situation, we need to trace network traffic to analyze the cause. However, analysis of network traffic is beyond our forum support level and due to forum security policy, we have no such channel to collect user log information. So we recommend you open a case with MS Professional tech support service, they will help you open a phone or email case to Microsoft, so that you would get a technical support on a one-to-one basis while ensuring private information.

    Here is the link:

    https://support.microsoft.com/en-us/gp/customer-service-phone-numbers

    Best Regards,

    Candy

    0 comments
  3. Shaun Millward 1 Reputation point
    2021-08-09T09:53:31.767+00:00

    Having this exact problem - don't suppose you managed to get anywhere with it?

    0 comments
  4. Brian Purchell 21 Reputation points
    2022-09-15T16:32:57.85+00:00

    We're having the same exact issue, anyone come across a solution by chance?

    0 comments