VPN and Outlook performance issue

[rolandlaw]

We have many field workers who use dialup to the local POPs, and then connect back to the VPN 3030 concentrator using VPN Client 3.5.x. We also have an AS5300 for direct dialup access to the LAN.

After we compared the performances between these two types of accesses, we realize that the performance is very bad when using Outlook to send emails with an attachment via VPN. We also notice that the transmit traffic will stop for a very brief moment every 5 to 10 seconds during the email sending process. It does not happen when we dial directly to AS5300. The IP Compression is set on the 3030. We also tried different MTU values from 512 to 1500, but it still doesn’t help.

Any idea what is going on?

[jwanker]

i am having the exact same problem....but only with a few users, dial up and broadband. i have tried every trick suggested. TAC has suggested change the mtu on the exchange server, but that could have adverse affects on other users. i've tried changing the mtu on the client, using ipsec over tcp and udp, turning compression off, etc.....nothing works.

[dcwalker]

I find that Outlook/Exhange uses very little of the available bandwidth. I have a Cable Modem and we have a 100Mbps line into work but Outlook never uses much bandwidth (I have a graph showing throughput).

[hansonla]

I would love to see your graph - our experience is that Outlook is a bandwidth hog. The combination of IMAP and NetBIOS seems to be very ugly.

[hansonla]

IMAP and NetBIOS do not perfrom well over VPN connections, period. I am in the process of evaluating several VPN products, and that is the one constant. The workaround is to deploy Outlook Web Access and let the users reach email via HTTP. Performance is much, much improved.

[kkaiser]

I am having this same wierd Outlook problem mostly with dial-up users. HOwever, I have had this same problem with with ALL my DSL users using Verizon DSL. I seem to be able to fix this by putting a D-link Cable Router in between the Verizon users and the DSL.. but still no luck on the dial-up clients. I also have tried the client MTU settings but nothing has helped???? HELP!!!

[jwanker]

try the latest 3.6.1 client. i have been having this problem for a few months and have tried verything tac has told me. but once the 3.6.1 client was used, this was not an issue.

[jofleming]

We are also experiencing slow outlook problems. Lowering mtu on the servers did help but we are still seeing long sync times. Can you quantify the improvement you saw after the upgrade?

[b-pelphrey]

i have to be honest with you all, i have a cable modem at home, and i vpn into corp. with a similiar setup and i have no real trouble. we have a vpn 5001 and i use outlook. understanding that i am not connected at 100meg, but that is obvious, my performance is no worse than i would expect from cable modem with vpn. actually i am very pleased with our performance in this case, and i have had no other compliants from any other end users.

i just wanted to let you know that it does work and performance can be tolerated. FYI.

[patrick.audet]

We run into the same problem here with some clients. We have a 3005 in a DMZ and exchange servers outside the DMZ. It seems that if you do static port mapping for your exchange server, it speeds things up. On Exchange, the client talks to the port mapper on TCP 135 and they agree to use two high TCP ports for the data exchange (really, access to the MTA and something else, I forget off hand). Anyway, there is a reg hack that that allows you to specify what ports to use. Put in Static Port map in TechNet and you'll get a ton of hits on this.

On customers where they DO NOT do port maping, it takes, like 5-7 min for the outlook client to come up. With port mapping it is much faster - 30 sec. or so.

Not saying this is the fix, just reporting what I have seen with 2 organizations using 2 exchange servers and the same VPN infrastructure.

[dpatkins]

Can you all tell me what version of Office you are using? My experience with this is that it is with Office XP or Outlook 2002. I am not sure what is causing the problems. I have reloaded Office and sometimes this helps. I have rediscovered the name (check Name) and sometimes this has helped. We have even wen back to Office 2000 and this has helped. I have alos lowered MTU and this has helped. It is kinda trial and error. Are there Microsoft folks out there that maybe able to expand on this?

[mapoitras]

We have also had the same problems. More often though is that at some locations, (Certain hotels or airport lounges), users can't reach the exchange server. However if they go to the mail setup and click on check names again then it starts working again. I believe it's related to DNS resolution because sometimes that can ping only using the IP other times they can use the exchange server name and other times they need to use the fully qualified names. What's weird is that it's not consistent. It changes depending on where they connect. It's been hell to support. Speedwise we are ok although for some users it takes 10 minutes to close outlook event if we turn off the synching for offline folders. anyway, that's my 10 cents.

[JUSTIN LOUCKS]

I know this is a Cisco forum, but I would suggest solving problems like this with a MS solution. If you have not looked at MS ISA Server especially with the recently released Feature Pack 1, I would encourage you to look at it. Also, there's always the defacto OWA which is more robust in Exchange 2000 than it was in 5.5, however you do need an additional Exchange server license (of course).

[rwortman]

I have the same issue with only a certain user. Running Windows XP Pro with Office XP. When he dials up to national ISP he can connect fine, all be it slow, but when he is at home using broadband it takes 10 minutes to get Outlook to open. Have removed Packet Scheduling QOS from the computer and that corrected the issue for awhile but now has reappeared. When connected via broadband I have no problems with VPN doing anything else, copying files from network, including pinging the Exchange server.

[engel]

Anyone with VPN Client & Outlook issue, the following BUG ID is recorded at the bug tool kit. My users are running into this issue recently.

CSCdy73659

The VPN Client Administrators guide documentation of the vpnclient.ini

parameter OutlookNotify is incorrect. The Release-note for bug CSCdu36579 was

ambiguous. The Release-note has been clarified (see below). The Description

text and value meaning must be corrected.

Release-note from CSCdu36579:

The Cisco VPN Client manipulates Microsoft Outlook settings which impact Mail

Delivery behavior and Outlook Folder Synchronization.

Mail Delivery: Due to the fact that the VPN Client is not implemented with a

Virtual Adapter, the Outlook application is not aware of the VPN assigned IP

Address. When Outlook connects to an Exchange server, it detects that TCP/IP

services are available and registers for UDP notification of new mail using

the 'local' IP address, not the 'VPN' assigned address. New mail would only

be detected when Outlook contacts the Exchange server for other reasons, such

as switching folders, manually initiated Send/Receive, or other reasons (there

is a background poll cycle which will contact the server on a 30 minute

interval). Due to this, if Microsoft Outlook is detected as the default email

application (and mapi32.dll exists), the VPN Client automatically disables the

use of UDP notification and forces Outlook to revert to polling the Exchange

server for new mail in order to get more timely notice of incoming messages.

The polling interval is fixed by Outlook at 1 minute.

Outlook Folder Synchronization: Outlook versions prior to 2002 have a bug

which can cause the Folder Synchronization process to hang if a new mail poll

is received during synchronization. This can occur on a manually initiated

synchronization or an automatic synchronization done when the Outlook

application is Closed. Folder Synchronization is also used by Exchange to

deliver email security policies. The poll has to be received during a

specific portion of the synchronization process. Large folder

synchronizations or slow connection speeds will increase the window of

opportunity for a poll to impact the synchronization. Microsoft reports that

Outlook2002 resolves this issue.

To allow users to control this behavior, we have added the "OutlookNotify"

parameter to the vpnclient.ini file controls. The format for this is:

[main]

OutlookNotify=1

The values which are supported are:

OutlookNotify=0 will result in the default behavior of Outlook polling every

minute for new mail notifications. Polling may result in Outlook Folder

Synchronization issues. This is the default state if OutlookNotify is not

present in the vpnclient.ini file.

OutlookNotify=1 will prevent the VPN Client from forcing Outlook to poll for

new mail. This will prevent polling from affecting the synchronization

process. The result is that new mail will only be detected on a background 30

minute poll cycle or when the user initiates a manual send/receive or switches

between folders.