>Really showing my lack of knowledge here on what seems like a basic Windows Server issue.
>
>A client of mine set up a server box for me to install Reporting Services. Assume the box is called SSRSBox. That all worked fine.
>
>Inside the client's domain, I can hit the SSRS site easily.....we'll just call it http://SSRSBox/reports
>
>
>Here's the problem. There are some people who connect to the domain via VPN. They are able to successfully ping the http://SSRSBox address, but they can't access http://SSRSBox/reports at all (even if running the browser as an administrator and even with UAC settings turned off). They are, however, able to hit the report site with the numeric IP address (e.g., http://111.22.3.4/reports)
>
>So I'm trying to figure out why the VPN users aren't able to use the domain name, and only the IP address...even though they can ping the core domain name. Not sure if there's some DNS setting in Windows Server that's necessary, or if it's something else. Has anyone run into this?

You're right that it's a DNS issue, but with the VPN clients, nothing to do with your SSRSBox server.

Your server probably has a FQDN something like SSRSBox.SomeDomain.local. That's a private subdomain/subnet known only to a DNS server on that subnet. Public DNS knows nothing about it.

When a remote client makes a VPN connection, it can choose to either:

1. Continue to use the DNS server it was using prior to connecting, or

2. Start using the DNS server on the new network

In your situation the VPN clients are choosing option 1. Their DNS server has never heard of "SSRSBox" or SSRSBox.SomeDomain.local so network services that rely on the host name won't work. As you've discovered, using the IP address still works because that bypasses DNS.

The main reason clients would choose that option would be if they are connecting from within their own corporate network. If they choose option 2, in that case your DNS server knows nothing about their corporate network, so they would lose DNS resolution for their own servers, printers etc. while connected via VPN.

The native VPN client in Windows (7, at least) defaults to option 2. The reasoning is in most cases a remote user will be in a hotel room, public cafe etc. where there are no other local resources they need to connect with. In that case the remote client would make use of your DNS server so would have no problems resolving SSRSBox.SomeDomain.local.

What you could do in your case:

- If your remote VPN clients are on a corporate network, they will legitimately want to continue to use their own DNS server. In that case the simplest thing would be for them to add a static route/entry in their DNS server e.g. an A record that says SSRSBox = 111.22.3.4. The beauty of this is that it immediately works for all DNS clients on their network.

If there are only a few clients on their corporate network that need to VPN to your network, another option would be to create entries in the HOSTS file on those computers. This will work but isn't recommended these days, as manual HOSTS entries are often associated with malware and get flagged by AV software.

- If the remote clients are standalone computers, the simplest thing would be to get them to switch to option 2. They may not be aware they have that choice with their VPN client software. Failing that, a HOSTS entry on their computer(s) would work in this case as well.