I am having real troubles with a VPN connection. The VPN connection is not used for a internet connection just for file browsing.

File browsing is slow, taking about 3-4 seconds to bring up a list of folders. I can live with this, however the problem is when I right click on a file. Sometimes the right click menu comes up instantly but sometimes it brings up the wait icon for anywhere between 30 seconds to a few minutes before displaying the menu.

I ran speedtest.net and the results were: 3.08 Down/0.13 Up (Mbps)

0.13Mbps = 16kbps upload. So I am not experiencing miracles with opening files. A 120kb file can take anywhere from 5 to 30 seconds. Sometimes transfering/opening files happens as expected other times its slow but the real issue is with the right click as mentioned.

Anyone have any ideas?

Using PPTP

Clients are all windows 7 pro

  • What OS do you have on your clients? SMB over a high latency link sucks unless you have Vista + 2008. Even then it isn't going to be great. – Zoredache Sep 4 '12 at 5:12
  • Nice for the banwidth, what about packet loss and latency? Crappy connections may result in the VPN needing to reestablish regularly. – TomTom Sep 4 '12 at 5:21
  • @Zoredache, all client using windows 7 pro. – Reafidy Sep 4 '12 at 9:12
  • Have you any apps installed which have added context menu items to Explorer? WinZip, 7-Zip and others will do this. Try disabling any additional context menus and see if that resolves the issue. – Chris McKeown Sep 4 '12 at 9:49
  • @TomTom, latency is 59ms – Reafidy Sep 4 '12 at 21:28

Have you any apps installed which have added context menu items to Explorer? WinZip, 7-Zip and others will do this. Try disabling any additional context menus and see if that resolves the issue.


SMB is somewhat of a "ping-pong-protocol" - it does a lot of interdependent back-and-forth communications for most of its actions. A Technet blog entry explains this quite colourfully:

If I wanted to copy a 1MB file over HTTP, it would look something like this over the wire:

Client:  HTTP GET /myfile.zip HTTP/1.0  
Server:  HTTP 200 OK, followed by 1MB of data

The only things that will slow down the HTTP transfer are a TCP window that is too small, slow start, and congestion avoidance.

The same transfer over SMB would look like this:

Client:  C SMB NT Create AndX myfile.zip  
Server:  S SMB NT Create AndX  
Client:  C Read AndX offset 0x0 data 0xf000  
Server:  R Read AndX (with 61440 bytes of data)  
Client:  C Read AndX offset 0xf000 data 0xf000  
Server:  R Read AndX (with the next 61440 bytes of data) 
(Repeat this another 16 times until we get 1MB of data)

So transfers and directory listings will not only depend on your available downstream bandwidth, but also greatly on the latency of your link and the bandwidth of your upstream connection. The same blog article recommends changing SizReqBuf on the file servers to 61440 as described in KB 320829 to somewhat alleviate this situation - this especially should help with speeding up directory listings.

  • CIFS 1 is very chatty and highly dependant on round trip latency, but CIFS 2.x is supposed to be much better but server and client need to properly negotiate CIFS 2.x. You can get enterprise grade WAN accelerators for CIFS from Cisco et al but it won't get much better than CIFS 2.x anyways and that's far from good (depending on RTT latency). – pfo Sep 4 '12 at 9:17
  • Thanks @syn, I changed the SizReqBuf on the server to 61440. Unfortunately is hasn't appeared to have helped. I had a good read over the technet blog, to be honest its a bit over my head. – Reafidy Sep 4 '12 at 22:41
  • @Reafidy did you restart the server service or the server altogether? Also, you did not mention your file server's version and service pack. As already noted by pfo, it would not be effective for SMB version 2 connections (only available with Windows Server 2008 or newer servers and Windows Vista or newer clients). – the-wabbit Sep 4 '12 at 23:06
  • @syn, yes I have restarted the server itself. Using Windows Server 2008 R2 Standard with Service Pack 1 and Windows 7 Pro on the clients. Sorry for not mentioning that. I presume from your comments that means changing the SizReqBuf wont have any effect? Any other ideas? – Reafidy Sep 4 '12 at 23:16

This is going to sound weird, but we have seen slow Windows Share issues (directory displays, right clicking, etc..) if we did not disable "Automatically detect settings". This configuration setting is under Internet Explorer \ Tools \ Internet Options \ Connections Tab \ LAN Settings. With that setting disabled there is a remarkable difference when accessing file shares vie file explorer.

  • Your right that does sound weird, I'm willing to try anything though. Although the answer by Chris helped it has not completely solved the issue. – Reafidy Oct 26 '12 at 21:23
  • Didn't make any difference unfortunately. – Reafidy Oct 29 '12 at 6:06

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.