Smart questions
Smart answers
Smart people
Join Tek-Tips Forums
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

maitakeboy (TechnicalUser) (OP)
10 Sep 03 15:26
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 (MIS)
10 Sep 03 15:44
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 (MIS)
10 Sep 03 18:49
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 (TechnicalUser) (OP)
11 Sep 03 9:40
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 (MIS)
11 Sep 03 10:35
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 (TechnicalUser) (OP)
11 Sep 03 10:45
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 (Programmer)
18 Sep 03 13:18
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
Helpful Member!  Candiri (MIS)
25 Sep 03 12:25
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 (TechnicalUser) (OP)
25 Sep 03 13:40
This is a registry setting on the Exchange Server, I assume?
Candiri (MIS)
25 Sep 03 15:25
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 (MIS)
25 Sep 03 18:51
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 (IS/IT--Management)
26 Sep 03 15:11
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 (MIS)
28 Sep 03 13:50
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 (IS/IT--Management)
29 Sep 03 10:40
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 (TechnicalUser)
7 Oct 03 6:05
Have you tried placing the vpn client PC in the routers DMZ

Worked for me.
ctsolutionsbiz (IS/IT--Management)
26 Nov 03 13:23
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.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close