DFS Namespace unavailable at login

▲
1
▼

Edit: I was not fully aware of what was going on with my issue, but it has since been fixed. See my answer below.

Background

We are having some issues with DFS namespaces in our environment after a change to how we configured our environment and I was looking to get some insight on how to troubleshoot, before we spend money on a support call with Microsoft.

We use the DFS Namespaces for clean paths, but do not use DFS replication. Previous to the change, we had one namespace we'll call \\my.domain.com\main. This domain worked great, but we support 5 divisions so we decided to create namespaces for each division. \\my.domain.com\Div1, \\my.domain.com\Div2, etc.

Before the change everyone had mapped a drive like Q: \\my.domain.com\main\Div1Dept and after the change they map a drive like Q: \\my.domain.com\Div1\Folders. \\my.domain.com\main\Div1Dept would be the same location as \\my.domain.com\Div1\Folders. The only difference would be the namespace.

Problem

The user 'Q:' preference item in the 'Standard_DriveMaps_Divisional {5559ca2b-79af-4a37-82d8-451d2fb71543}'

Group Policy object did not apply because it failed with error code '0x80070035 The network path was not found.' This error was suppressed.

We have various occasions (we support 2,000 users and get a few calls a week with this issue) where when the user logs in the location is unavailable and the drive fails to map. We can confirm that have a quality connection to the network and can reach the domain controllers and namespace servers.

This issue would never really arise when we used the main namespace. When the user navigates to the path manually, it becomes available. The workaround is to run a gpupdate to map the drives again, but we cannot ask the user to do that every time it occurs.

We do have one non-DFS drive that maps successfully every time these DFS related maps fail. Which leads me to believe that it is not entirely network connectivity.

Troubleshooting performed

I'm far from a DFS pro, but I know enough on how to make folder targets and such.

Using DFS Management, I reviewed the Cache Duration and other settings between namespaces and they all match. They are also using the same namespace servers.

Using the DFSDiag command we have positive test results for all the namespaces.

Question

Given the information provided, can anyone think of some specific things I might be over looking? Are there any settings outside of the DFS Management GUI that could impact the availability of the non-main namespaces, because main seems to always be available.

dfs
distributed-filesystems
asked on Server Fault Nov 20, 2017 by Shawn Esterman • edited May 23, 2019 by Shawn Esterman

2 Answers

▲
1
▼

Maybe the GPO gets applied without Network Access and so they cant get the changes(Networkdrive mapping)

Has this occured on the same Person?

There is a GPO Policy to Wait for Network, but ensure it is only active on Internal Domain Clients, and not on Mobile/Laptop Computers

Check this https://technet.microsoft.com/en-us/library/gg486839.aspx

Without this Settings, Clients maybe Authenticate with Local Credential Store but the Network stack don't finished loading.

We got this Problem on our Site, but its a Computer/Network Driver issue that the initializeing/loading of the Networkdrivers/Stack are taking so long.

answered on Server Fault Nov 20, 2017 by daBONDi • edited Nov 20, 2017 by daBONDi
▲
0
▼

To be honest I forgot I posted this issue. However, since this issue has now been viewed 1000 times I figured I should give those 1000 people an answer.

This issue was solved by referencing this article called Slow-Link with Windows 7 and DFS Namespaces written by one of my favorite people on Twitter Ned Pyle. I did not have a complete understanding of my issue so here is what you need to know:

When we mapped network drives for our users, they would get a couple of drives:

H: \\my.domain.com\div1\Users\Username
Q: \\my.domain.com\div1\Folders

Problem

The H: drive was actually a redirected folder that was cached on the computer. If the latency of the connection to reach the path \\my.domain.com\div1\Users\Username was too high, the computer would transition the share \\my.domain.com\div1 as offline and use the cache instead. The H: drive (redirected folder) would appear because it is cached, but any other drive using the DFS share/namespace \\my.domain.com\div1 would appear disconnected. This was because the other directories were not in the cache being used by the computer.

Solution

  1. Create a new GPO linked to those affected computers (or use an existing one)
  2. Navigate to Computer Configuration > Policies > Administrative Templates > Network/Offline Files
  3. Enable Configure slow-link mode
  4. Add a high latency for the namespace roots
  5. Add a low latency for the user data paths

Example:

UNC Path                     Latency
--------                     -------
\\my.domain.com\div1\*       32000
\\my.domain.com\div2\*       32000
\\my.domain.com\div1\Users\* 60
\\my.domain.com\div2\Users\* 60

This should prevent the folder redirection from turning the DFS roots offline.

answered on Server Fault May 23, 2019 by Shawn Esterman

User contributions licensed under CC BY-SA 3.0