Outlook over VPN over DSL 1

[maitakeboy]

I'm ready to tear my hair out with the inconsistent
performance of Outlook over a VPN on DSL. The VPN works
fine, but even though I establish a tunnel, often Outlook
returns a "network problems are preventing a connection to
the Exchange server". I have an NT4 network, though
Exchange 5.5 sp4 is running on a W2K server with SP3. I
have a hardware VPN (Netscreen 50) with a full T1 out to
the internet. My remote users are generally on a Verizon
DSL 128/768. I have lmhost files on the client machines for name resolution. I had a case this morning with two users in the same remote office, both had established a VPN tunnel, one couldn't connect at all to the exchange server, the other could connect and receive emails, but would just
hang when he tried to send them. Other users have reported behavior such as making a successful connection, then getting booted off or freezing up, they reconnect and the same thing happens again after 5 or 6 minutes. It's this inconsistency
which is driving me crazy. Does anybody have any ideas
what this is all about?
.

 

[ChicagoTechNet]

if you have a domain controller, it is better to setup wins instead of lmhosts. if you already have wins, make sure the vpn clients point to the correct wins and dns.


For more tips or information, go to

http://www.ChicagoTech.net

Robert Lin, MS-MVP, MCSE & CNE
Windows, Network and How to at

http://www.ChicagoTech.net

 

[dopehead]

This sounds alot like a performance issue on your dsl.
Exchange/Outlook in a workgroup kinda install uses quite a lot of bandwidth compared to pop3/smtp connections.

Have you tried pinging the exchange server when this happens and then when it is running ok, and comparing the response times ?

Jan

 

[maitakeboy]

I just had a user who was able to send but not receive emails do a ping and they all timed out. I've suspected DSL performance as the problem because I know the bandwidth issue with Exchange/Outlook in corporate mode. But that seemed too easy a fallback, so I wanted to check everything else before I went and bought more bandwidth. I had a hardware to hardware VPN over DSL at 768/768 between my headquarters and a remote office which performed flawlessly, which sets me to thinking that it is a bandwidth issue.
On the DNS/WINS thing, I have Linksys routers at these sites doing DHCP for the clients and I don't know if I can define a WINS/DNS server on them. I am running both WINS & DNS. Would a hosts file be a good alternative? Also, I know MTU size has been an issue in the past, but I would think that would not be indicated because of the inconsistent nature of these symptoms. If the MTU isn't right, nothing goes, correct? Anyway, the issue I had with my remote folks yesterday was strictly Outlook/Exchange performance, the VPN was up and running, as far as I can tell. If there are any other tests I can perform that you know about, I would greatly appreciate being clued in. Thanks again for your responses.

 

[JimBob1]

This may or may not work, but found it cleared up problems we had with Outlook 2000 and Exchange server. BE sure to back up your registry before trying this. A sideeffect of this fix is that it seems to slow down your connection.


I have found that this fix will help considerably with the problem of writes to the Exchange Server when using Outlook 2000 on Windows 2000.
You have to make two DWORD additions to your registry.
Make sure that you are careful with Registry manipulation. You could seriously damage your system if any mistakes are made.


SYMPTOMS

Client computers that experience these problems are typically running Microsoft Windows 95, Microsoft Windows 98 or Microsoft Windows Millennium Edition (Me) and are connecting to your network by using Virtual Private Networking (VPN), but may also include Windows 2000 or Microsoft Windows NT 4.0 clients depending upon your network configuration.

If you are using non-Microsoft VPN servers or any routers that are using Network Address Translation (NAT), you may also see these symptoms from client computers.

Your Windows 98 client may receive the following error message when you try to copy files to or from a file share on the remote Windows 2000 server:

Cannot copy file name the specified network resource or device is no longer available.



Add these two DWords to your Registry:



EnablePMTUDiscovery

When set to 1 (True), TCP attempts to discover MTU automatically over
the path to a remote host. Setting this parameter to 0 causes MTU to
default to 576 which reduces overall performance over high speed
connections. Note that this setting is different than our Windows 9x
recommendation.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters EnablePMTUDiscovery="1"

(DWORD - boolean, valid settings are 0-->False and 1-->True.
Many connections perform better with this entry at 1, however,
if you prefer to set your upstream to send fixed 1500 packets,
you might want to use 0 instead). When set at 1, establishing
connections and initial transfer speed might slow down a bit,
however you will get better throughput if somewhere in the
path large packets need to be fragmented.

EnablePMTUBHDetect

Setting this parameter to 1 (True) enables "black hole" routers to be
detected, however it also increases the maximum number of
retransmissions for a given segment. In most cases you'd want to keep
BHDetect to 0 (False).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters EnablePMTUBHDetect="1"

(DWORD - boolean, valid settings are 0-->False and 1-->True.
Recommended setting is 0)

 

[maitakeboy]

Thanks for the reply, JimBob1! I was a little confused, though. Do I need to add the entire registry key for both of these? If not, exactly what do I need to add? Also, which setting are you recommending for fixing my particular problem, 0 or 1?
Thanks again for your reply!

 

[OlHausler]

Hello Maitakeboy.

I am experiencing exactly the same problem. Let me tell you what I know about it so far: Though Exchange-Outlook sync is not working very well over low bandwidth connections, I think DSL 128/768 in one direction should be more than fine.

To exclude the DSL issue, I tried to connect over 2500kbit cable modem and another provider, and I am still experiencing the same issue. And I tried to connect over DSL in Germany, and still have the same trouble. So I wouldn't want to blame it on the connection or provider.

In regards to the registry keys above, I would not think this may help, as the problem - at least with me - is not a TCP/IP issue. Pinging always works and anything else from pcAnywhere to file transfers works fine, also.

I also tried to connect that same workstation that wouldn't work well with my Exchange server, to connect to another Exchange server (professional Exchange hosting provider), also via VPN, and yes, it works.

I have the suspection that it may be the response time, when Exchange is busy with Online connected users at the same time. Slow response maybe results in timeout on the Outlook side. I will check on this tonight, when Exchange is not busy.

Also I've been reading there maybe RPC protocol issues over VPN and there are RPC patches available from Microsoft. But I didn't look into this yet.

If you get to know new things, please let me know, also I will keep you posted if I find out.

oliver.hausler@hausler.info

 

[Candiri]

Have you tried limiting the Outlook client protocols to TCP only? Try this reg file:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider]
"Rpc_Binding_Order"="ncacn_ip_tcp"

The default value uses RPC first, and also includes spx, named pipes, netbios, and even Banyan Vines. As long as the server has TCP, it's generally all the Outlook client needs. This fixed the problem for our VPN users, and used to be the 1st thing we check for Outlook issues, second now only to RPC worms.

 

[maitakeboy]

This is a registry setting on the Exchange Server, I assume?

 

[Candiri]

No, NO! It's on the Client, either Outlook or Exchange. It is actually used by (I think) the MAPISP32.EXE process. I believe I tried changing it and/or a corresponding server-seeming value on the Server, with either no or bad results. This is strictly a client setting, which means distributing reg files or pushing it with policies, SMS, etc.

 

[IsaacNewton]

Just to get back to basics. I recommend re-checking the DNS config and make sure it does resolve the name of the Exchange server OK easy enough from the command prompt. I've been caught before where name resolution was not working and connectivity from Outlook to Exchange could not be established. WINS was working OK so all other Windows networking was OK, but Outlook/Exchange was sick until DNS name resolution worked properly.
Good luck.

 

[onepair]

Ok I had the same issue in a little different way. I could connect by IP everytime but by name only sometime until I added to c:\winnt\system32\drivers\etc\hosts this file seemed to make it work every time after I put in a ip hostname.

192.168.1.150 mail.server.com

Easy to try...

 

[Candiri]

Limiting Exchange to IP only with the client reghack notably helps our situation, but then it's true you need to resolve the server name on an IP level. If you can ping the server and it resolves to the name alone all caps, you could be relying on WINS and NBT. If it resolves to name with domain in lowercase, it's likely using DNS. If you add the server entry to the hosts file as mentioned above, it should fix any DNS problems.

A way to confirm this is by building a new profile when you're on VPN. If the Check Name button resolves your mailbox name and server correctly then you're successfully reaching the server. You can even use the fully qualified DNS name in the server field, and it should resolve to the nbname alone, underlined. Configuring profiles in this manner has helped us as well, as it seemingly stores an IP version instead of the nbname that it displays.

 

[RobNS]

Id like to add my 2 cents if I may...

Ive had similar issues and now have a setup that works pretty well

1) decrease the MTU value on your machine. If you dont know, this simply is the amount of data that can go in any packet. On a wired LAN it can be higher, but over the VPN there is an overhead for the entcryption, and if you are using wireless the overhead is even more - Im using around 1300, you can try higher but I have heard it suggested to go down as low as 500. There are values tools to do it for you, but its just a registry change. You need to reboot to take effect.

2) work offline rather than connected to the exchange server. I can work fine connected to the server, but if my internet connection flutters, I can get disconnected and get corrupt ost files and the like. I have had a 100% success rate since I started working connected in the office and offline at home - and schedule send/recieve every 5 or 10 minutes

give this a try & post if you still have issues


Rob

 

[stevesmart]

Have you tried placing the vpn client PC in the routers DMZ

Worked for me.

 

[ctsolutionsbiz]

Wow! Thank you thank you thank you! Limiting clients to TCP/IP via the registry saved me so much aggravation and my client a bunch of money in bandwidth. Thanks for taking to time to post.