Recently, the MS PSS team received some reports regarding issues happening on the Windows Vista computers located in a domain. The typical symptom sounds like:
-Indefinite delay (hang) when opening the Certificate Services snap-in
-Slow (sometimes no) group policy application
-Trying to select a domain user in order to add that principal to a local security group (the object picker) would hang indefinitely
-Instant Messaging was not working well (sometimes not at all)
-Access to local file servers was slow and sometimes did not succeed at all (appears to hang).
In some scenarios, users cannot copy files from a network share to the Vista box from Windows 2000/2003 shares. The error is:
“You do not have permissions to perform this action”
“access is denied.”
With intensive testing, we can copy a .txt type of file (text, log, etc) as long as it is less than 4K, while any other type of file (.doc, .xls) fails regardless of size.
This issue is finally determined to be linked to a new feature included with the Vista -TCP Auto Tuning, which uses a scaling factor communication between the server and client, to negotiate a bigger window size during connection establishment so that more traffic can be transported in less time. Windows XP and earlier versions do not have this feature.
Here’s a bit more on that:
Note: Some Internet gateway devices and firewalls block packet flows because they do not correctly interpret the scaling factor used in TCP connections. Because of this, Internet Explorer in Windows Vista uses an initial scaling factor of 2. Other applications use a default initial scaling factor of 8. Microsoft is investigating changing the initial scaling factor for Internet Explorer-based connections to 8 in a future update of Windows Vista. Microsoft is working with the manufacturers of these devices so that they can be updated for compliance with TCP window scaling.
To see if this issue applies to you, first see if the criteria and symptoms mentioned above apply. If they do, please take some traces. The TCP Auto Tuning can be seen in the packets like these truncated samples:
Working (no problem seen):
…TCPWindow: 8192 (scale factor 0) = 8192
……WindowsScaleFactor not listed
Failing (problem supremely evident and most annoying):
…TCPWindow: 8192 (scale factor 8) = 2097152
……type: Windows scale factor. 3(0x3)
……Length: 3 (0x3)
……ShiftCount: 8 (0x8)
If the above symptom appears, we can try disabling this feature as a workaround and this will certainly tell the tale on what the problem is if the issue no longer happens afterward. From a command prompt:
netsh interface tcp set global autotuninglevel=disabled
If the issue no longer occurs, this reveals that you have a network device in your environment that doesn’t support RFC 1323 “TCP Extensions for High Performance”.
More on that here: http://www.ietf.org/rfc/rfc1323.txt?number=1323 . The primary focus should be on replacing that network device to get the most out of the rest of the network infrastructure. But temporarily the netsh command can be a good workaround.