MS Exchange via Outlook Over VPN

For some reason a client’s outlook was having issues connecting to Exchange via the VPN connection. Turns out it was a simple DNS resolution problem, setting a static entry via the hosts file solved it.

Outlook 2003, upon opening would sit there “Trying to Connect” (to the Exchange on SBS 2003) for ages, if you left it long enough eventually it would connect. This had only been happening the last week, prior it never did this.

I made sure the VPN connection was connected and I could ping the Exchange host (via IP, not name) and I could. Then as I was sitting there flicking the setting for Cached Exchange Mode on and off and restarting Outlook, it dawned on me “hang on, when I type the IP address in during setup, Outlook resolves the IP to the servers DNS entry”. I pinged the DNS name and it didn’t work. Adding the static entry to the hosts file, flushing the resolver cache and then restarting Outlook, presto connected!

Talk about a pain, be good if Outlook could give some sort of feedback rather then “Trying to Connect” and then “Error”. The whole issue is probably the fact that I setup DNS resolution to OpenDNS and it doesn’t do “nx domain” responses unless you set that up….

  • http://www.dnsit.com.au Patrick Pierre

    Nick – not sure if you are aware but you don’t need to setup a VPN in order to get Outlook 2003 to work with Exchange 2003 remotely. You can use Outlook via RCP over HTTP to securely connect Outlook to your Exchange Server.

    BTW – your exchange server DNS resolution should be your internal IP address and point your home PCs to use your office DNS server for resolution when they are connecting via the VPN tunnel. Otherwise, as you did, you can have a static IP. If you are using the above method of using RPC over HTTP, you won’t have this DNS issue.

  • http://nicholasorr.com Nick

    Thanks Patrick :)

    I’m aware of the RCP over HTTP – the issue with that is I’ve turned off IIS. Only turn it on/start it to manage the Public Folders, which is rare. Really this particular SBS/hardware has out grown it’s capacity and is really not in an optimal state. First of all the information store db is has exceeded the 18GB limit and dismounts regularly, resulting in the restart of the MS Exchange Information Store service nearly everyday to avoid “MAPI call” errors. I’ve gone around to each users pc and configured Outlook to auto archive, this isn’t enough to bring users mailboxes down to size…

    Yeah I’m not going to point the home PC’s (3 of them) at the office DNS. I’ve setup the VPN connection to not be the default gateway, so I’ll leave up to the ISP to handle DNS/internet traffic. Internally (at the office) DNS is handled by the server AD and all that jazz.

    All this is temporary anyway, by September/October this year we’ll have a complete online application to abolish Outlook/Excel/Word/Exchange/SBS. We’ll have a vanilla Windows 2008 Std server to handle print serving and management of the Windows XP clients (local DNS cache, windows updates, policies, anti-virus, SOE deployments, etc).

    The goal is to get the clients (as in companies clients) information out of the current SILO state (users outlook mailboxes) and get it into something that can be accessed universally. The current way of doing things doesn’t really marry well to how the business actually wants to do business. If an employee is sick, have to physically go to that persons pc and open their outlook to see where things are at etc…

    As much as I like using the Microsoft solution it just doesn’t fit the way this company wants to do business. Plus the users aren’t that proficient at the office suite either. It all comes down to the fact that users are users, computers are tools, they just want to get their work done. Building a customised web based application to handle all the tasks is simpler in the long run. People who aren’t that good at computers will have lower learning periods to get up and running and selling etc.

  • http://nicholasorr.com Nick

    I’ve now employed Hamachi as well and ditched the problematic MS VPN solution.

    There would be miss dials, I’d have to restart the “Routing and Remote Access” service sometimes as well as power cycle the modem.

    Now I have no issues. Install Hamachi on the client pc’s and set their hosts file up and all is well. The notebook users benefit as well. Hamachi is intelligent and knows when to use the Local Area Network to peer when it can. When remote and there is an internet connect a route is found via the net.

    Hamchi – it just works – it’s great!!!

  • Joe

    Hi!
    I am using Hamachi for vpn sollution, but still problems with dns records. How can I set up my remote pc to point the AD?

  • http://nicholasorr.com Nicholas Orr

    Hmmm.

    Well the thing to get is all I've done is create a record in the client pc's hosts file to point at the exchange server and only the exchange server. If the client wanted to access the rest of the network controller by the AD servers I'd need to set the client's pc to use the AD enabled NameServers.

    I have solution but it depends on what you are trying to acheive.

    1. Do you want to use Hamachi VPN instead of MS VPN solution so the client can appear on the network as if they
    were physically connected to the network?

    OR

    2. Do you just want the client pc (which isn't connected to the domain, it is a pure standalone workgroup pc) to talk to Exchange so Outlook works?

  • some I.T. dude…

    Great post. Ran into this recently – same thing – it resolves when setting up, but not afterwards… How exactly does it resolve IP to hostname in the first place then??? That's what I'd like to know…
    I thought to try the same thing – well, if it can't resolve hostname, why shouldn't I be able to just use IP??? …And then it suddenly changes to hostname there… Which means it has to have SOME way of doing this on its own… If it can do its own lookup and figure this out, you'd think there would still be a way to either have it KEEP resolving, or let you use the IP address……. Oh well….

    Anyway, I thought no way, too simple to add to hosts file, got to be some other stupid setting… Nope.
    Added one line to hosts file, done!

    Thank you for the blog post here on this. Easiest solution to this, unless your server is already set to do RPC over HTTP (which, most probably aren't…).

    Why its coded this way, who knows. Just glad that the solution is rather simple. Thank you again, take care!

  • http://nicholasorr.com Nicholas Orr

    I think maybe the exchange server tells outlook the host name.

    Glad my post helped you out :)

  • stressedoutitguy

    Great article, this is exactly what our company has been looking for. I have one question though, do you enter the exchange servers IP address in the hosts and lmhosts file and should it look like this?:

    192.168.X.X servername

    Many thanks!

  • http://nicholasorr.com Nicholas Orr

    That is correct.

    IP Address of the exchange server in your hosts file with the exchange server name :)

  • exchange hosting

    ………..

  • Stephan

    Great post!  Fixed my problem, however, I'd add a little something.

    In my case, the hosts file already had the Exchange server in it, but without the domain name.  i.e. an entry like:
    <ip address=””> server

    This wasn't working, with Outlook failing to connect over the VPN.  With a packer sniffer I could see Outlook trying to resolve a full DNS query for server.companyname.com and getting an external IP address, and then trying to connect to that directly, rather than over the VPN (and failing).

    I then tried changing the hosts file to the full server name including the domain and it started to work.  i.e.

    <ip address=””> server.companyname.com

    This shouldn't work, but it does.  There may be a bug somewhere, but having gotten it to work easier to get on with life….</ip></ip>

  • Stephan

    I got curious and did some more digging around.

    I pinned the problem down to using OpenDNS (or indeed any other DNS service that doesn't “Fail” outright when a DNS look-up is done for an externally invisible server name).  

    In my case, I would find that for certain networks, the Outlook over VPN would work perfectly, yet on a different network on the same day it would not.

    What was happening was that despite having an entry in my hosts file which looked like:

    <ip address=””> server

    Windows would always do a DNS look-up.  (this feels like a bug to me).  On networks where the DNS lookup fails (i.e. not OpenDNS or similar), Windows would then go to the hosts file, get the right IP address and Outlook would connect over the VPN without a problem.

    On Open DNS, all DNS requests succeed.  What would happen is the DNS query would return the OpenDNS web address, and Outlook would then try to connect to that, and fail.

    For some reason, adding the explicit

    <ip address=””> server.companyname.com 

    line to the hosts file prevents the DNS look-up from taking place, and makes everything work.</ip></ip>

  • http://nicholasorr.com Nicholas Orr

    it is probably more to do with what Outlook is looking for and I'd imagine it needs to use FQDN. When I was adding a user to Outlook using “server” as the address Outlook would change it to the FQDN of the Active Directory DNS entry.

  • Kashif

    Good post Nicholas, it solved my issue :-)

  • http://nicholasorr.com Nicholas Orr

    Excellent :)