Often I am asked about how slow link detection on Windows Vista through to Windows 8, differs Windows XP when relating to Group Policies.
First some background.
When Windows XP attempts to download its Group Policies, it performs a slow link test, which consists of a series to ICMP pings to find out how the network is performing. Most network infrastructures have firewalls in place and of course, they almost always block ICMP. I regularly come across situations where the Windows XP client tis unable to action all of the Group Policy Settings, because some Client Side Extensions (CSE's) on the client to not run when we are on a slow network.
What is a client side extension (CSE)?
The CSE's are used on all clients to process settings that need to be implemented through Group Polices. Many people are familiar about the Group policy Preferences CSE's that need to be installed on a Windows XP client to extend its capability to use Preferences (these are now part of a service pack, so as long as you patch, you should already have them :) ). There are many other CSE's too, such as registry, Software installation, Security, Folder redirection and Disk Quota (see my other post for a list). These take the form of DLL's and if corrupted, then the CSE will not run and process those types of Group Policy Settings.
What CSE's do not process when on a slow link?
There are a few CSE's that will not run, such as Logon Scripts, Folder Redirection, software installation, IPSEC, IE Maintenance, EFS Recovery, GPP Printer connections, IE Branding and Disk Quota. To find out which CSE's are slow link sensitive, then have a look at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions\ in here there are a bunch of sub keys that are the CSE storage areas. If you go into each one of these keys, look for a value called NoSlowLink with a value of 1. This will give you an idea.
How is it different on Windows Vista/7/8?
Since the release of Windows Vista, Microsoft changed the way we detect slow links, they now use the NLA service to detect this situation. NLA performs many more tests to find out if the network is slow (please try not to disable this service, as many companies disable it for client hardening as they do not know what it is doing). This networking layer service and programming interface allows applications, like Group Policy, to solicit networking information from the network adapters in a computer, rather than implementing their own methods and algorithms. NLA accomplishes this by monitoring the existing traffic of a specific network interface. This provided two important benefits: 1) it does not require any additional network traffic to accomplish its bandwidth estimate-- no network overhead, and 2) it does not use ICMP.
So what happens with GPO's and slow link detection?
When the Group Policy service is ready to determine the status of the link between the client computer and the domain controller, the GPO Processing engine asks NLA to report the estimated bandwidth it measured while earlier Group Policy actions occurred. The Group Policy service compares the value returned by NLA to the GroupPolicyMinTransferRate named value stored in HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon, which is the preference key or, HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System, which is the policy key.
The default minimum transfer rate to measure Group Policy slow link is 500 (Kbps). The link between the domain controller and the client is slow if the estimated bandwidth returned by NLA is lower than the value stored in the registry. The policy value has precedence over the preference value if both values appear in the registry. After successfully determining the link state (fast or slow—no errors), then the Group Policy service writes the slow link status into the Group Policy history, which is stored in the registry. The named value is IsSlowLink and is located at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History. This value is an REG_DWORD value that is interpreted as a Boolean value; with a non-zero value equalling false and a zero value equalling true. If the Group Policy service encounters an error, it read the last recorded value from the history key and uses that true or false value for the slow link status.
I hope this helps give you an idea about what Microsoft are using for slow links.
This helped me to figure out why a new domain member 2012 Server at a remote site without a DC would show the network as unidentified. I thank you a lot for it. The issue was resolved by making an adjustment on the port of an older Cisco 4006 Catalyst Switch. The spanning tree protocol was enabled on the port which delayed every thing by 15 seconds. On the older set switches you don't see this in the show running config command. You have to use the show spantree command to see it. It's enabled by default so you have to disable it. This is also know as portfast on the newer switches which is ok to use provided you just have one host on the port. Once I did this for the port for the server the Group Policy History key showed a huge difference in time. You have to reboot the server before you see the difference in the key value. Hope this helps somebody. I went through several rebuilds before figureing it out.