Slow-Link with Windows 7 and DFS Namespaces

Hey there, Gary here, and it has been a while since there has been a blog post relating to Offline Files and Slow-link. A couple of years ago I wrote a one in relation to Vista and the slow-link mode policy that still applies to Windows 7; here is the link:

“Configure slow-link mode” policy on Vista for Offline Files

As a quick refresher for those that do not want to read it right now, some takeaways from that post:

• TCP/SMB stacks - and not the Network Location Awareness (NLA) service - measure link speed/latency
• Help text still confusing but still do not include the quotes when entering the share and latency/throughput settings. We have gotten used to this by now and don’t see as many misconfigurations anymore
• A slow-link policy had to be defined to allow a cached location offline due to link speed
• The matching algorithm for path comparison and support for wildcards is still the same, with the same effect for DFS Namespaces (refer to blog post for explanation)

Ok, so what has changed that is worth writing about?

Default Slow-link defined…again

Windows XP has a default slow link threshold of 64Kbps that was nice and easy to measure... NOT! Windows Vista went for an opt-in approach with the definition of the slow-link policy. Now, Windows 7 brings back the default threshold idea. This time it is a default latency of 80ms. This means that any location the cache is aware of and has cached data can be taken offline when the network latency is measured above 80ms, without having to set a slow-link policy. Of course, if you desire different settings, you can still define your own policy. The default threshold amounts to the following type of policy definition:

When a location does transition offline due to slow link, the “Applications and Services Logs\Microsoft\Windows\OfflineFiles\Operational” event log records the following event and lists the latency measured when it went offline:

<==================================================================>

Log Name: Microsoft-Windows-OfflineFiles/Operational

Source: Microsoft-Windows-OfflineFiles

Date: 11/27/2011 9:05:47 AM

Event ID: 1004

Task Category: None

Level: Information

Keywords: Online/offline transitions

User: CONTOSO\offlineuser

Computer: Win7Client.contoso.com

Description:

Path \\server\shared$ transitioned to slow link with latency = 120 and bandwidth = 155272

<==================================================================>

Auto Transition back to Online State

Windows 7 also returned the ability for a cached network location to transition from an offline state due to slow-link back into an online state when network conditions improve, without additional intervention. If you ever dealt with Windows Vista and defined the policy, you know that you had to click the “Work Online” button or use a script to transition the location back into an online state.

After transition, client-side caching performs this check every 2 minutes. Windows Vista also checked, but only for locations offline due to network disconnection, interruption and the like. This does not necessarily mean that right when the check completes that it will transition back online. A slow-link transition is kept in either offline state for a default minimum of 5 minutes.

When the location transitions back into an online state thanks to improved network conditions, the following message records in the “OfflineFiles\Operational” event log:

<==================================================================>

Log Name: Microsoft-Windows-OfflineFiles/Operational

Source: Microsoft-Windows-OfflineFiles

Date: 11/27/2011 9:11:38 AM

Event ID: 1005

Task Category: None

Level: Information

Keywords: Online/offline transitions

User: CONTOSO\offlineuser

Computer: Win7Client.contoso.com

Description:

Path \\server\shared$ transitioned to online with latency = 11

<==================================================================>

That is all great but how does that affect DFSN?

That is a good question! It is actually part of what lead to this blog post and the need for the additional information above. We have been seeing an increased number of calls where part of a DFS Namespace is not accessible when it goes offline. Let us examine briefly a simple namespace that hosts at least one DFS folder. The namespace will include the folders as described below:

• I defined a Folder Redirection policy to redirect the user's My Documents folder to the user folder under \\contoso.com\DFSRoot\userdata. This by default will make the user’s My Documents folder available offline and information in the cache. The user’s home drive is also mapped in this location as drive H: as well.
• The Shared DFS folder has a drive mapped as drive S: or some folder underneath it.
• The user is at a remote branch with limited WAN link back and wants to access a document he was working on under the Shared folder. However, the user is unable to access that Shared folder through either the UNC path or a mapped drive he happens to have to that location. He is seeing this error message:

Or

However, he is still able to browse and access his Documents (mapped to drive H:) just fine in the same DFS namespace. That would be expected when on or off the network since it is available in the cache by the Folder Redirection policy.

Looking at a file in the user’s home directory it might show that it is “Offline slow link”, “Offline (disconnected)”, or “Offline (working offline)”. In addition, there could be messages in the “OfflineFiles\Operational” event log for ID 9 and/or 1004 referencing the DFS Root. These events represent that the root is offline owing to network disconnection, manually, or due to link speed.

Another quick way to see if the namespace is offline is by doing a quick “DIR \\contoso.com\dfsroot”:

How can the namespace go offline, when nothing is available offline from there?

When talking about DFS, Offline Files breaks it down into parts that equate to the namespace and DFS folders. Each evaluates independently from each other. Therefore, the namespace can be offline while the user’s folder can be online or even vice versa. The cache still needs to know about some information about the namespace because that is still part of the path that is available offline. Which means the default latency can apply to it, even though nothing is available there.

In the example above, the S: drive was mapped to a DFS folder that didn’t have anything made available offline from under it, but since the namespace was offline any DFS referrals are not evaluated and no traffic is leaving the box for that path. Thus, I received the error message.

Can we get the top area of the namespace to stay online?

As long as the DFS namespace had transitioned to slow-link mode, you can counteract the default latency by specifying an additional policy setting. You might consider something like the following to keep it online while allowing the userdata DFS folder content to go offline at the specified latency (Remember the blog mentioned at the start of this for more information on the pattern matching):

 Summary

The long and short of this ends up being a tale of default latency applying to where you may not think it should. That behavior can be overridden by defining a counter slow-link policy to set the bar high enough to not take if offline when truly not desired.

Gary "high latency" Mudgett