Link to home
Start Free TrialLog in
Avatar of djaabrams
djaabramsFlag for United States of America

asked on

Intermittant problems resolving fully qualified domain name from Terminal Server to Database server

We have a Windows 2003 Terminal Server which is also one of two DNS servers for a single domain enterprise. The terminal server users run an ERP application called Encompix which uses a Progress database, currently version 9.4. The Progress database and application are located on another server. Intermittantly the users get disconnected from the application and receive the error "Unable to find host encompix.bluesky.local in file HOSTS or HOSTS file not found in expected location (5193). When this occurs, pinging the FQDN encompix.bluesky.local returns a host not found error. Normally a ping to the FQDN returns a response. Pinging the NETBIOS name always returns a response. Entries appear to be correct in DNS. A bitmap of the error is attached. The event log does not appear to be logging the error. Not sure why the application is looking for a HOST file in the first place. The ERP application has a .ini file with the FQDN of the server registered in it. To change to the NETBIOS name would require reapplying for the software license, so this is an undesirable option. Let me know if further information is needed.
Error-5193.bmp
Avatar of Darksied9
Darksied9

In the TCP/IP settings for the machine getting the error on the last tab choose to UNCHECK the Enable LMHOSTS Lookup and then choose the second radio button below that.  Sorry I can't give the name off the top of my head I am on my MAC.  There are three radio buttons under the LMHOSTS Enable option.  You want the middle one.
Avatar of djaabrams

ASKER

It is the "enable netbios over TCP/IP" button. I will try that...may take a day or so to see if the problem goes away.Thanks!
Are your prefered DNS servers your internal Microsoft DNS servers, and not the gateway or an outside server?
Oh, I see.

Along with unchecking LMhost, as Darksied9 said, you might want to UNCONFIGURE the HOST file, except the loopback address>

The HOST file is used for DNS lookups. That is edited by using wordpad. It is found in:
C:\Windows\system32\drivers\ect\Host

The WINS record is LMHOST. and is found in:
C:\Windows\system32\drivers\ect\LMHOST

What are those records there for, you might ask?

Well, when the client sends out a query, it will try to resolve the query by itself:
1) The first place a client looks for is a cached entry. (To determine if this is the case, go to the command prompt of the client and type IPconfig /flushdns.) (For WINS cach, type NBTstat -rr)
2) Then if your client doesn't have the cached entry, it will look at the client's C:\Windows\system32\drivers\ect\Host file for resolution. (For WINS, you comptuer looks in the C:\Windows\system32\drivers\ect\LMHOST file(You can look at and edit the host file with word pad. Check and see that there are no entries, except 1.0.0.127 local host file in that file for the HOST file and no entries in LMHOST. These files are used if you don't have a DNS server or WINS server respectively. They can be configured to maintain a list of computers you want to contact via a DNS query or WINS query.)

If the query isn't resolved by the client, it will go look for the prefered DNS or WINS server.

The first place the server looks is its own DNS or WINS cache, then its own HOST or LMhost files, Then it looks for host A records or WINS records.

If the server can't find it, the query will go to outside servers for lookup.

If these HOST and LMhost records are configured, but the resolution is not present, you will see these errors because the client will think it can resolve WINS and DNS on its own and will prevent the query from going to DNS or WINS.
Since pinging the FDQN returns a valid record, you can eliminate the ipconfig /flushdns and disabling the LMHOSTS will remove the Hosts file from the equation, the WINS cache is the only thing in ChiefIT's response that could be checked but since the error is HOSTS based 99.999% positive that won't be the issue.  Just clearing the LMHOST check box should do the trick.  But, as ChiefIT mentioned, the flush WINS and DNS is always a good first step in any kind of a lookup issue.
Actually pinging the FQDN doesn't always return a valid record, only when it finds the entry. When the problem occurs, pinging the FQDN returns a "ping could not find host. check the name and try again". Entering the command nbtstat -R (RR) clears the error and allows a ping to the FQDN to respond. Will the /flushdns command have a permanent effect? I have a feeling that something is causing this change periodically. Thanks for both of your responses.
If you are running DNS on both domain controllers, which I hope, make sure that the primary DNS server for the domain controller are correct, and ensure that the field to update the entry in DNS checkbox and the use this servers suffix option are setup ont eh DNS tabs for the servers...  Also make sure that the WINS settings are correct in the IP settings.  Check both DNS and WINS servers to make sure that the entries are valid, especially DNS for A records at the root (SOA as well) for the domain controllers.  Run the ipconfig /flushdns followed by the ipconfig /registerdns on the servers and re-verify the DNS records are correct.  If they are not, tell us how you have your DNS setup cause there is an error.
I did some further discovery and found out that (after one of your last comments) one of the domain controllers DID NOT have DNS services, where the terminal server (not a domain controller but the source of all these problems) was setup with DNS services. In addition to following both of your configuration advice, I added DNS to the domain controller that was without, and removed DNS from the terminal server. I checked the lmhosts and hosts files on the terminal server (which in this case is the client, in case that has been lost in all the discussion!) and made sure the lmhosts file was deactivated and the hosts file only had the localhost IP address registered (127.0.0.1). I performed the ipconfig /flushdns and /registerdns and the entries in DNS appear correct. I will watch tonight and see what happens. We have experienced the lookup failure, earlier this morning. Will post any results as soon as they are available. BTW there is no WINS server on the network, in case this info is important.
ASKER CERTIFIED SOLUTION
Avatar of ChiefIT
ChiefIT
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial