Symptoms: Some Offline Files are inaccessible from the DFS namespace. Users may get the following errors when working on the files server from branch offices:
“locked for editing by another user”
Other users may get a "sync status" error, or "offline files unavailable", while connected to the LAN from the branch office.
Users may experience missing files or directories. Workstation system error log may indicate:
EVENT ID: 1004
Path \\file path transitioned to slow link with latency = 74 and bandwidth = 10580536
Cause:
The problem is most like caused because of high latency between
the main office and the branch office when DFS Namespace is enabled.
Windows Offline files measures for latency and sets the default threshold at 80ms for Windows 7. When the latency from the branch office passed the Offline threshold the DFS namespace directory automatically transitions to offline mode.
Windows Offline files measures for latency and sets the default threshold at 80ms for Windows 7. When the latency from the branch office passed the Offline threshold the DFS namespace directory automatically transitions to offline mode.
The Offline Files treats DFS namespace and DFS network shares
separately. A namespace can be offline while it's child directories
remain online; or vice-verse.
Even worse, if a client attempts to access the target Offline, and the target is unavailable, the Windows client interprets the entire namespace as unavailable; and will attempt to open a user’s locally cached files (if they exist). If they don't exist the user will get network unavailable or permission errors.
Here is a good explanation: http://blogs.technet.com/b/askds/archive/2011/12/14/slow-link-with-windows-7-and-dfs-namespaces.aspx
Also: http://blogs.technet.com/b/netro/archive/2011/01/24/using-offline-files-on-dfs-shares-all-shares-are-going-offline.aspx
Even worse, if a client attempts to access the target Offline, and the target is unavailable, the Windows client interprets the entire namespace as unavailable; and will attempt to open a user’s locally cached files (if they exist). If they don't exist the user will get network unavailable or permission errors.
Here is a good explanation: http://blogs.technet.com/b/askds/archive/2011/12/14/slow-link-with-windows-7-and-dfs-namespaces.aspx
Also: http://blogs.technet.com/b/netro/archive/2011/01/24/using-offline-files-on-dfs-shares-all-shares-are-going-offline.aspx
Fix:
The files never properly transitioned to an online state. Disabling the Offline Mode was the only short-term solution that
seemed to correct the DFS namespace problem. This is not practical long-term because staff may want to use the Offline File Sync.
BranchCache also has a dependency on the Offline Files service.
To resolve the cached DFS namespace must be manually deleted from the cache directory before the DFS root and the Offlies Files can run simultaneously. There may be an easier way but these are the steps I took:
To resolve the cached DFS namespace must be manually deleted from the cache directory before the DFS root and the Offlies Files can run simultaneously. There may be an easier way but these are the steps I took:
1. Disabled Offlie Files.
2. Installed the Windows Resource Tool, SubinACL, to allow me to take ownership of the Offline cache directories.
SubinACL is located athttp://www.microsoft.com/download/en/details.aspx?id=23510
SubinACL doesn't have to be used but all files are owned by the System; manually changing ownership and permissions would take forever.
3. From the command line:
C:\Program Files (x86)\Windows Resource Kits\tools>subinacl.exe /subdirectories c:\windows\CSC\*.* /setowner=domain.com\username
4. Manually Deleted the domainname.com namespace directory from: C:\Windows\CSC\v2.0.6\
There may also be a directory for the local namespace file server that should be deleted as well.
2. Installed the Windows Resource Tool, SubinACL, to allow me to take ownership of the Offline cache directories.
SubinACL is located athttp://www.microsoft.com/download/en/details.aspx?id=23510
SubinACL doesn't have to be used but all files are owned by the System; manually changing ownership and permissions would take forever.
3. From the command line:
C:\Program Files (x86)\Windows Resource Kits\tools>subinacl.exe /subdirectories c:\windows\CSC\*.* /setowner=domain.com\username
4. Manually Deleted the domainname.com namespace directory from: C:\Windows\CSC\v2.0.6\
There may also be a directory for the local namespace file server that should be deleted as well.
After ownership has been applied the security for the user must be changed to full or modify. Be sure to apply the change to all child directories or the files cannot be deleted.
Things should be back to normal after a restart.
Prevention:
I was surprised we hadn't run into this issue earlier. For
whatever reason, latency did seem higher than usual when the problem started. To correct the problem the Offline
latency threshold limits in either the local or group policy must be set.
Local Computer Policy > Administrative Templates > Network > Offline Files > Configure slow-link mode
Local Computer Policy > Administrative Templates > Network > Offline Files > Configure slow-link mode
Name: *
Value: Latency=32000
http://blogs.technet.com/b/askds/archive/2011/12/14/slow-link-with-windows-7-and-dfs-namespaces.aspx
http://blogs.technet.com/b/askds/archive/2009/02/11/configure-slow-link-mode-policy-on-vista-for-offline-files.aspx
Value: Latency=32000
http://blogs.technet.com/b/askds/archive/2011/12/14/slow-link-with-windows-7-and-dfs-namespaces.aspx
http://blogs.technet.com/b/askds/archive/2009/02/11/configure-slow-link-mode-policy-on-vista-for-offline-files.aspx
Because this issue can impact any staff, at branch offices, or on
VPNs, I recommend this GPO when DFS namespaces are used in correlation with branch offices. My understanding
this latency group policy setting is independent from latency settings for
BranchCache in Group Policy.
Last updated July 16th, 2013 by Steven Jordan
BranchCache
DFS
Network Administration
Last updated July 16th, 2013 by Steven Jordan
1 Comments
Great post man. I was working on this issue for a few hours. Deleting the local cache solved the issue.
ReplyDelete