Outlook & Cisco VPN

jlhct

Hello,

Has anyone ever seen this problem?

A user has a laptop, but doesn't use it remotely all of the time. When they use it remotely they have to constantly click retry to the message "your exchange server is currently avaliable" until the mail finally appears.

Does anyone have any insight on what could be the problem here?

Also, let me add that if the user connects remotely constantly, then the error will show up only once or twice, or sometimes not at all.

Thanks!

Danman32

Exchange relies on RPC, which can be fickle if the network connection is not 'just so'.

One of the major problems with connecting OL to Exchange is proper name resolution. The client has to be able to properly resolve the hostname of the exchange server via DNS, as well as other connections that have to be made, such as the global catalog, DC, etc.
It's because of all the huge requirements of RPC, including dyamic port usage that MS came up with RPC over HTTP, though it has its own troubles as well.

jlhct

Danman32 wrote:

Exchange relies on RPC, which can be fickle if the network connection is not 'just so'.

One of the major problems with connecting OL to Exchange is proper name resolution. The client has to be able to properly resolve the hostname of the exchange server via DNS, as well as other connections that have to be made, such as the global catalog, DC, etc.
It's because of all the huge requirements of RPC, including dyamic port usage that MS came up with RPC over HTTP, though it has its own troubles as well.

Ah ok, so would it be better to use RPC over HTTP? to connect outlook to avoid a lot of this overhead?

Thanks for the info!

Danman32

RPC over HTTP removes the requirement of a VPN connection. The RPC over HTTP is actually a windows 2003 server component, and the Exchange 2003 and OL 2003 are RPC over HTTP aware.

For it to begin to work, the server has to have a certificate installed, and the client has to recognize the certificate root authority that issued the server the certificate. If in trying to connect to the server's IIS through HTTPS the browser displays a certificate challenge saying that there's a potential security problem with the server's certificate, RPC over HTTP will not work with that client.

I am not sure that RPC over HTTP can be made to work without SSL, but I wouldn't advise it anyway.

But what I would check with the VPN connection is that the Exchange server and DC can be resolved at the client. The client should be using the AD DNS server for name resolution once the VPN connection is established.

jlhct

Danman32 wrote:

RPC over HTTP removes the requirement of a VPN connection. The RPC over HTTP is actually a windows 2003 server component, and the Exchange 2003 and OL 2003 are RPC over HTTP aware.

For it to begin to work, the server has to have a certificate installed, and the client has to recognize the certificate root authority that issued the server the certificate. If in trying to connect to the server's IIS through HTTPS the browser displays a certificate challenge saying that there's a potential security problem with the server's certificate, RPC over HTTP will not work with that client.

I am not sure that RPC over HTTP can be made to work without SSL, but I wouldn't advise it anyway.

But what I would check with the VPN connection is that the Exchange server and DC can be resolved at the client. The client should be using the AD DNS server for name resolution once the VPN connection is established.

Actually, we do have a certificate installed to make RPC happen. We did this for handheld connections to be able to connect to the Exchange server.

hmmm..not quite sure I understand the AD DNS resolution. Would this be a setting to locate in the VPN client, on the firewall itself or in Windows setup?

Thanks!

Danman32

Exchange 2000 and 2003 rely heavily on connections to AD, as does OL 2000/2002/2003 to connect to Exchange using native RPC. If the client is not using the DNS that hosts records for AD, it will have trouble finding the DC, the global catalog, and the exchange server in order to do its job.

So the question becomes, once the VPN connection is established, what is the client PC using for DNS? Hopefully not the ISP, that will fail or have problems.

blargoe

When connected to the VPN, how is the user's connectivity to other resources he needs to access?

TeKniques

Hi,

If I remember correctly, Exchange 2003 SP2 was supposed to fix Outlook over VPN problems. Are you running SP2 on your Exchange server?

jlhct

Danman32 wrote:

Exchange 2000 and 2003 rely heavily on connections to AD, as does OL 2000/2002/2003 to connect to Exchange using native RPC. If the client is not using the DNS that hosts records for AD, it will have trouble finding the DC, the global catalog, and the exchange server in order to do its job.

So the question becomes, once the VPN connection is established, what is the client PC using for DNS? Hopefully not the ISP, that will fail or have problems.

OK I think I understand now...well the settings are that the PC uses is to Obtain DNS automatically (the same settings as the IP address) so maybe for the laptop users we should configure to have the DNS hardcoded to use the DNS server in our internal network?

Would that cause a problem when they use the laptop remotely since the DNS is hardcoded?

Or do I suspect that additional profiles will be needed?

jlhct

blargoe wrote:

When connected to the VPN, how is the user's connectivity to other resources he needs to access?

They can connect to the other shared drives that they have mappings to with no problems

jlhct

TeKniques wrote:

Hi,

If I remember correctly, Exchange 2003 SP2 was supposed to fix Outlook over VPN problems. Are you running SP2 on your Exchange server?

Yes we are, thanks for the suggestion

blargoe

No, don't hard code the DNS.

When they are connected to the VPN and they do an ipconfig /all, is the DNS server listed for the VPN network connection the correct DNS server for your company? If not, that is what needs to be fixed.

I don't think this is your problem though, since it does eventually connect.

I think the desktop group at my company has found weird issues with the Cisco VPN client and there were able to work around them by changing the IPSec setting under the proerties of the VPN connection in the Cisco client. One option is IPSec over UDP and the other one is IPSec over TCP. Maybe try to switch that setting and see if it makes any difference.

Also, try google

Danman32

If you're able to get to shares on the LAN, then I don't think DNS is your issue either. But still, do an IPConfig /all to be sure.

sprkymrk

If the problem does turn out to be name resolution, you can create a hosts/lmhosts file on the clients that have your exchange server.

I don't have a Cisco VPN client handy, but on my Symantec client VPN I had an option to allow UDP encapsulation.

jlhct

sprkymrk wrote:

If the problem does turn out to be name resolution, you can create a hosts/lmhosts file on the clients that have your exchange server.

I don't have a Cisco VPN client handy, but on my Symantec client VPN I had an option to allow UDP encapsulation.

OK Great, I'm going to try all of these options...oh each laptop does have a local hosts file, but the UDP option is definitely worth a try!

Thanks again everyone! I'll update you when I have more info