This is a followup on my post DFS domain name resolution headaches.
Occasionally there are times when the solution seems correct since it fixes the issue there and then. But then it turns out you where looking in the entirely wrong place…..
Turns out the issue was the rather common issue of using DFS together with Offline files.
If Offline files is enabled and Windows detects a “poor connection” it will automatically go into Slow-Link mode which drops all connection/access to the DFS share beyond those files that have been selected for caching (selected either automatically or by the user).
The simple solution to this is to configure the “Slow-Link” setting in a computer configuration GPO.
By default slow-link will initiate at 80ms on Win7 and 35ms on Win8 and onwards.
Preferably you should set your DFS root to a high latency (like a 1000ms). Then you can for example set the user network folder to something like 50ms or 100ms.
For example like this:
\\example.com\DFSRoot Latency=1000
\\example.com\DFSRoot\Users Latency=100Now that the solution is found it seems obvious, and it also seems strange that the cause was not discovered earlier.
However this is is where the !fun is; usually only you laptops would have enabled Offline files (desktops are usually always connected to the network), and indeed that is how it looked in our GPO… that is filtering with a WMI query for laptops.
So why did we also have desktops with this same issue?
Well… don’t let your colleagues check the computer form factor by simply query kind of RAM form factor is used, desktops too can have SO-DIMM modules…. 🤨
So what have i learned from this?
– If you have any issues at all with DFS connections, verify your Offline files configuration. And remember to configure Slow-Link.
– Even if the GPO WMI filter is named “Laptops Only”, does not make it true. Select * from Win32_PhysicalMemory WHERE (FormFactor = 12) do NOT a laptop make….