Remote location cannot browse \\servername but CAN ping.

[XRJoe]

We have an application server in house that was recently rebuilt with Windows 2003 R2. It IS working for all internal users and all but one remote facility.

This one remote facility can ping the server name and can browse to the IP address of the server using \\IPADDRESS\SHARENAME but CANNOT browse to \\SERVERNAME\SHARENAME. The client on these computers uses the hostname to connect to the application server so this is a problem.

We have been told we cannot change the server hostname and we cannot change the way the clients connect to the application (i.e. using the IP instead of DNS name).

The server in question has all the proper DNS entries and WINS entries and as I said it is working fine for all internal users and all but one of our WAN sites.

Any thoughts? This has been baffling us for some time.

 

[GrimR]

You need to add the Server's Hostname to the remote facilities DNS records.

 

[XRJoe]

They're all on our domain and are getting our DNS and WINs servers. They CAN ping the hostname and it does resolve to the correct IP address. We've entered static DNS and WINs servers, added the host name to the HOST file, and we still cannot browse to \\SERVERNAME\ from any of the 20 computers in this WAN site.

I agree that it does sound like a DNS or WINs issue but we cannot find anything wrong with this servers entries. We've deleted and recreated the DNS and WINs entries for this server. They can browse to 99% of our other servers just fine. However there are 4 or 5 other servers that they are having similar problems with.

 

[pgaliardo]

How are the remote sites connected? Could it be a firewall issue, where packets are being denied to those 4 or 5 problem servers? I'm not sure which ports need to be open for browsing, but maybe something to investigate.

 

[XRJoe]

They're connecting with an older Cisco VPN concentrator. We have other remote WAN sites with the same hardware and they are working fine. We rebooted the VPN concentrator last night, out of desperation mostly, and no change.

On a side note, we found that for one of the problem servers if you add a period to the end of the hostname (i.e. \\SERVERNAME.\SHARENAME), you can see the shares and it attempts to connect only to fail with an error stating there are too many connections to this server at this time.

 

[Davetoo]

When you enter \\servername, what error eventually displays? (not going to the sharename, just the servername). Also, what OS are the target servers?

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

 

[Davetoo]

Are all the sites coming through the same concentrator? Are all the sites in the same group on the concentrator?

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

 

[XRJoe]

The error you get when running \\SERVERNAME is the standard "The network path was not found." although it takes nearly 2 minutes for this error to pop up. The servers that are having problems are running Windows Server 2003 (Enterprise and Standard) w/ SP2.

These WAN sites have their own VPN concentrator, we found recently the problem site is running an older firmware version and we are going to be updating it sometime soon today.

 

[XRJoe]

We updated the firmware on the concentrator and still no change. I think someone, possibly myself, will be driving 2 hours to the site soon and doing some heavy testing at the site.

 

[pgaliardo]

Just re-read your original post and saw that you can browse by IP Address, so ignore my first post. It seems that adding the host file should have resolved this. What OS are the clients at the remote site running?

 

[XRJoe]

Issue resolved! (Clients are Windows 2000 and XP btw) It turns out it wasn't related to DNS, WIN's or Windows 2003 at all. It was a setting on the Cisco 3002 VPN Concentrator.

IPSec Fragmentation Policy was set to:
- Fragment prior to IPsec encapsulation without Path MTU Discovery (Clear DF bit)

We changed this setting to:
- Fragment prior to IPSec encapsulation with Path MTU Discovery (ICMP)

We found this after going through each line of the VPN Concentrator configs looking for any differences.

Thank you for all the help and suggestions. Hopefully if someone else comes across the same problem they find this thread!

 

[Davetoo]

Seeing as they came through unique concentrators it was clear that that is where the issue would be resolved.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.