My Scripts and Tips » Windows

Slow Upload Performance

admin — Wed, 19 Jan 2011 05:02:45 +0000

We were having issues where some PCs had slow upload performance over the WAN. The WAN link was a E3 (34Mbps) with round trip latency of around 50ms and was not congested. When uploading to SharePoint, some PCs would upload at between 150 and 250 KBps. Otherwise identical PCs would upload at over 1MBps. The PCs were running the same physical hardware, the same Operating Systems (Windows XP, although we later reproduced the issue with Windows 7), the same patches and the same drivers. We also confirmed that they had the same TCP settings in HKLM\SYSTEM\CurrentControlSet\Services\TCPIP.

A comparison of packet captures was interesting. The graphic below shows two uploads.

Comparison of two TCP flows

The one on the left is of a slow upload between host “Client” and the SharePoint server “Server”. The one on the right is of a fast upload between host “Client2″ and the SharePoint server “Server”. Both are actually Flow Graphs from Wireshark. Notice that the one on the left pauses after 60ms (0.060 seconds) and waits for an ACK from Server. However, the one on the right continues on. Yet the TCP Window sizes are identical in both flows.

In the end we discovered another parameter in Windows. AFD.SYS is used to support Windows sockets applications. Registry parameters for ADF.SYS are found in HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters. The one that’s relevant is DefaultSendWindow. On the slow machines this parameter was not set and so used the default (decimal 8192 it seems). On the fast PC this was set to decimal 64512 (hex fc00).

Changing this value on the PCs with slow upload speed and then rebooting seems to have fixed the problem.

For more information on this parameter see Network: The relationship between TCPWindowSize and DefaultReceiveWindow.

So, why was this value different between PCs. It seems that when you install the Citrix MetaFrame Client the installer automatically increases this value. The fast PCs all had the MetaFrame Client installed.

One solution to “The network path was not found” Windows error

admin — Mon, 18 Jan 2010 08:30:52 +0000

I had an issue escalated to me where NetBIOS name resolution didn’t work on one particular machine. DNS was working – you could ping by hostname. However, you couldn’t connect to a remote share using hostnames (although connecting using IP addresses worked).

As a number of other people had already looked at this before me I assumed that the problem must be particularly fiendish and started Googling. I tried all the recommendations to reset Winsock using netsh etc. Nothing worked. I tried uninstalling anything that might be network related – that didn’t work either.

In the end I went back to the basics and found the problem. It seems that somewhere along the line the “TCP/IP NetBIOS Helper” service startup was set to Manual. I started the service and everything started working.

I have no idea how this service was changed from Automatic to Manual but it must have been some time ago as the user had been putting up with the problem for months.

So, if you get the above error and can ping the host by name I suggest you first make sure that the “TCP/IP NetBIOS Helper” service is running. After that try checking all the hard stuff.

Windows 7 and ATI – Screen does not wake from sleep after RDP

admin — Tue, 15 Dec 2009 03:04:36 +0000

You might have the following problem with Windows 7 64 bit with ATI Radeon 2400 HD (default Windows drivers or latest drivers from ATI). If you RDP to the machine after Windows has put the screen to sleep you might find that when you later try to use the computer, there’s no signal being sent to the screen.

A work around is to change your power options within Windows Control Panel and set “Turn off the display:” to “Never”.

Windows Server 2003 W32Time Errors

admin — Thu, 19 Mar 2009 15:54:19 +0000

The time on my PC at work has been gradually getting out of wack. So I took a look at the PDC Emulator (PDCe)in the root of our Active Directory forest and found lots of W32Time errors like:

The time provider NtpClient cannot reach or is currently receiving invalid time data from 192.168.1.1 (ntp.m|0x8|172.16.1.1:123->192.168.1.1:123).

192.168.1.1 is a Windows Server 2003 machine in our DMZ. The DMZ server synchs the time with time.windows.com and the PDCe synchs the time with the DMZ server. This used to work fine (well after many teething problems) when the server in the DMZ ran Linux. However, since moving the function to a Windows server it seems to have failed.

Looking at the debug logs (see the entries for the various filelog registry keys for information on enabling logging) I found the following errors:

149095 16:21:16.1250000s - ListeningThread -- response heard from 192.168.1.1:123 149095 16:21:16.1250000s - /-- NTP Packet:
149095 16:21:16.1250000s - | LeapIndicator: 3 - not synchronized;Â  VersionNumber: 3;Â  Mode: 4 - Server;Â  LiVnMode: 0xDC
149095 16:21:16.1250000s - | Stratum: 0 - unspecified or unavailable
149095 16:21:16.1250000s - | Poll Interval: 15 - out of valid range;Â  Precision: -6 - 15.625ms per tick
149095 16:21:16.1250000s - | RootDelay: 0x0000.0000s - unspecified;Â  RootDispersion: 0x0001.0400s - 1.01563s
149095 16:21:16.1250000s - | ReferenceClockIdentifier: 0x00000000 - unspecified
49095 16:21:16.1250000s - | ReferenceTimestamp:Â Â  0xCD676E70C58C64FD149095 16:21:16.1250000s -Â  - 12881592560771673500ns - 149092 12:09:20.7716735s
149095 16:21:16.1250000s - | OriginateTimestamp:Â Â  0xCD6B9DFC20000000149095 16:21:16.1250000s -Â  - 12881866876125000000ns - 149095 16:21:16.1250000s
149095 16:21:16.1250000s - | ReceiveTimestamp:Â Â Â Â  0xCD6B9D6D4D7C02AF149095 16:21:16.1250000s -Â  - 12881866733302673500ns - 149095 16:18:53.3026735s
149095 16:21:16.1250000s - | TransmitTimestamp:Â Â Â  0xCD6B9D6D4D7C02AF149095 16:21:16.1250000s -Â  - 12881866733302673500ns - 149095 16:18:53.3026735s
149095 16:21:16.1250000s - >-- Non-packet info:
149095 16:21:16.1250000s - | DestinationTimestamp: 149095 16:21:16.1250000s - 0xCD6B9DFC20000000149095 16:21:16.1250000s -Â  - 12881866876125000000ns149095 16:21:16.1250000s -Â  - 149095 16:21:16.1250000s
149095 16:21:16.1250000s - | RoundtripDelay: 000ns (0s)
149095 16:21:16.1250000s - | LocalClockOffset: -142822326500ns - 2:22.822326500
149095 16:21:16.1250000s - \--
149095 16:21:16.1250000s - Peer 192.168.1.1 (ntp.m|0x0|172.16.1.1:123->192.168.1.1:123) is not Win2K. Setting compat flags.
149095 16:21:16.1250000s - Packet test 6 failed (not syncd or bad interval since last sync).
149095 16:21:16.1250000s - Packet test 7 failed (bad stratum).
149095 16:21:16.1250000s - Ignoring packet that failed tests from 192.168.1.1 (ntp.m|0x0|172.16.1.1:123->192.168.1.1:123).

Note the bad stratum message. I don’t know why these servers didn’t want to work together. The commands

w32tm /stripchart /computer:192.168.1.1

and

w32tm /monitor /computers:192.168.1.1

showed that they communicate using NTP. The way I got around it was to simply configure the PDCe to synch with the time server of a local ISP:

rem Stop the Windows Time service
net stop w32time

rem Set everything back to defaults
w32tm /unregister
w32tm /register

rem Start the Windows Time service
net start w32time

rem Specify the NTP server
w32tm /config /manualpeerlist:100.20.3.4 /syncfromflags:manual /reliable:yes /update

Note I thought about synching the PDCe with time.windows.com, but that address resolves to time.microsoft.akadns.net – so I imagine that the IP address will change fairly often which would cause a problem on the firewall access-list.
For troubleshooting information on Windows and NTP I recommend Windows Time and the W32TM service.

Show Drive Letters First via Group Policy

admin — Sat, 01 Sep 2007 15:31:11 +0000

Ever noticed how Windows Explorer, by default, shows the drive letter after the label. For example:

\\longservername.subdomain.domain\AllOurData M:

The problem with this is that in some dialogs you can’t see the drive letter. Wouldn’t it be better if it did it the other way around:

M: \\longservername.subdomain.domain\AllOurData

Here’s how you can change that using group policy. First you need a custom Group Policy template file. Group Policy template files have a .ADM extension. Please see the text at the bottom of this post for an example.

To add the template do the following:

Edit the Group Policy to be modified (or create a new one)
Expand Computer Configuration
Right click Administrative Templates and select Add/Remove Templates
Select the template file to add

The template will add an entry under Administrative Templates called Customisations. Under that you will see another called Explorer Settings. If you click on that you won’t see anything in the right hand pane. That’s because you need to change a filter to view this setting. Do the following:

On the menu select View and then Filtering
Untick “Only show policy settings that can be fully managed”

You should now see an entry in the right hand pane. Select the option you want (for example, “Show all drive letters before the label”).

If you don’t want to use Group Policy then you will need to come up with some other way of setting the entry in the registry. The registry key is
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer. The setting is a DWORD called ShowDriveLettersFirst. Values are:

0
1
2
4

Setting 0 gives letters after the label (the default)
Setting 1 gives network letters before the lable
Setting 2 will mean no drive letters
Setting 4 will give all drive letters before the label

You can download the administrative template from here –> ShowDriveLettersFirst.zip