Given a multiple site Active Directory we occurence problems with slow link detection GPO's. We want to use slow link detection on laptops which connect are via coorperate WAN (MPLS 4-Mbit/s) to main site (with DC). The problem is, that the slow link detection is not working as expected, so there isn't a slow link recognized. The client machine is Windows 7, DC is Win Server 2008 R2.

The slow link detection is configured for computer and user via the policies:

Computer Configuration\Policies\Administrative Templates\System\Group Policy\Group Policy slow link detection
User Configuration\Policies\Administrative Templates\System\Group Policy\Group Policy slow link detection

Both are activated and set to 15000kbps. This setting are activated on clients and work fine. But it seems bandwith calculation does something freaky.

In boot analyzes via xbootmgr / xperf I can see, that for the Computer GPO a slow link is detected with a 12618kbps (<15000kbps) so IsSlowLink is true -> everything fine.

But for the User GPO's the detected bandwith is 228711kbps. There is no slow link detected and for example "Folder Redirection" is processed.

I didn't find any reason for this huge difference, the network route doesn't change between Computer and User Policy processing. Is it possible that the NLA uses any cached content to determine the available bandwith? We have a riverbed Wan-Optimizer between the two locations, is it possible that it optimizes the NLA bandwith detection? Any ideas where to look how the returned bandwith was calculated?


There's a TechNet article describing how the bandwidth is calculated. It's a little out of date, but I doubt it's changed significantly.

The new mechanism takes the form of measuring the response time from a sequence of TCP/IP pings from the client computer to the server to determine the average transfer rate in kilobits per second (kbps). The client pings the server three times with 0 bytes and three times with 2048 bytes. If the response time from any of the pings is less than 10 milliseconds (ms), the link is automatically considered fast. Otherwise, the average transfer rate is calculated by averaging the differences between the first (0 byte) and second (2048 byte) ping times. If the transfer rate is slower than the default or a value that is defined by the administrator, the connection is considered slow.

Windows 2000 uses the following formula: LinkSpeed=32000/ulTotal

In this formula, ulTotal is the average of the differences between the first and second ping times.

The example table they show in the article has output from USERENV showing the actual round trip times. This makes me believe that this information is probably (still) logged if you turn on USERENV logging. This may not solve your issue, but at least you might be able to see what figures Windows is basing the slow-link detection on.

Enabling USERENV logging in Windows Vista/7 hasn't changed too much since XP. Instructions can be found here. I'll forewarn you that this log is obnoxiously verbose (think -vvvvvvvvvvv) and historically difficult to understand. A simple google search on the topic will revel plenty of advice for wading through it.

Hope this helps get you started!

  • Thanks for this Information. Tried USERENV debugging but couldn't find any information regarding the slowlink calculations, found only the calculated results as in the xbootmgr / xperf. – fadanner Nov 20 '15 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.