Having issues with DNS and Windows 7
My company is connected to my home office via T1. We run a IE based inventory system called Tecsys Elite. Our DNS servers are pointing to a Windows Server 2008 machine at the home office. My workstations in my office are using Windows 7.
My problem is that some of my windows 7 workstations are losing the connection to Elite throughout the day. At one point in the day it works fine, then it just goes out, says page cannot be displayed. then I can reboot and it will go back to working sometimes. other times a reboot still will not fix it. have to wait about 30 minutes to get it back up.
At the same time one won't work my other windows 7 workstations will. so i know the connection is not being lost.
Is DNS the issue here? is it getting overloaded?
Not sure what else to explain. I can provide any other info needed.
My problem is that some of my windows 7 workstations are losing the connection to Elite throughout the day. At one point in the day it works fine, then it just goes out, says page cannot be displayed. then I can reboot and it will go back to working sometimes. other times a reboot still will not fix it. have to wait about 30 minutes to get it back up.
At the same time one won't work my other windows 7 workstations will. so i know the connection is not being lost.
Is DNS the issue here? is it getting overloaded?
Not sure what else to explain. I can provide any other info needed.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Here is the ipconfig /all
Will have to look at the event log next time it happens
As for the last request/question: Is the software located at HQ? Yes
Is HQ DNS servers only pointing to internal DNS servers in their TCP\IP properties?
Yes. Here is the DNS setup for the Network Adapter on the DNS server: 10.1.254.8, 10.1.254.13, 127.0.0.1. The DNS servers IP address is 10.1.254.8.
Windows IP Configuration
Host Name . . . . . . . . . . . . : ABAKER
Primary Dns Suffix . . . . . . . : am-corp.net
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : am-corp.net
Wireless LAN adapter Wireless Network Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : 802.11n Wireless LAN Card
Physical Address. . . . . . . . . : AC-81-12-6B-52-BD
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physical Address. . . . . . . . . : E0-69-95-70-27-0A
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::ca3:590e:a37e:5939%13(Preferred)
IPv4 Address. . . . . . . . . . . : 10.6.1.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 10.6.254.1
DHCPv6 IAID . . . . . . . . . . . : 283142549
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-15-3B-E6-70-E0-69-95-70-27-0A
DNS Servers . . . . . . . . . . . : 10.6.254.2
10.1.254.8
10.1.254.13
216.218.93.166
216.218.93.165
NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel adapter isatap.{412AE443-5EBC-4120-973C-479947C38DED}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter Local Area Connection* 9:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft 6to4 Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter Local Area Connection* 12:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter isatap.{91EF0F49-8AE4-43F2-BB2D-3120799CCB62}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : YesWill have to look at the event log next time it happens
As for the last request/question: Is the software located at HQ? Yes
Is HQ DNS servers only pointing to internal DNS servers in their TCP\IP properties?
Yes. Here is the DNS setup for the Network Adapter on the DNS server: 10.1.254.8, 10.1.254.13, 127.0.0.1. The DNS servers IP address is 10.1.254.8.
Yes, it is a DNS problem on your client computers:
Erase the 216... DNS servers on client machines. If all clients have these, then erase them out of DHCP scope options. These DNS servers are not on your network and your clients shouldn't be pointed towards them for Domain Services. Those Domain SeRVices (SRV) records are found on your DNS servers, not public servers or routers.
--I would also Consider a better setup. Right now, it appears you have a dedicated T1 connection between sites for ALL traffic. That's expensive, and a single point of failure if your dedicated T1 goes down. Consider hosting internet at both sites with a Cable modem or you could still use the T1. But, use a VPN connection between sites. This way, not all of your traffic goes through the Main office site, AND if the T1 connection between sites fails, you have internet at home to VPN data through.
Erase the 216... DNS servers on client machines. If all clients have these, then erase them out of DHCP scope options. These DNS servers are not on your network and your clients shouldn't be pointed towards them for Domain Services. Those Domain SeRVices (SRV) records are found on your DNS servers, not public servers or routers.
--I would also Consider a better setup. Right now, it appears you have a dedicated T1 connection between sites for ALL traffic. That's expensive, and a single point of failure if your dedicated T1 goes down. Consider hosting internet at both sites with a Cable modem or you could still use the T1. But, use a VPN connection between sites. This way, not all of your traffic goes through the Main office site, AND if the T1 connection between sites fails, you have internet at home to VPN data through.
ASKER
TriadX1
The workaround by placing the dns in the host file seems to have worked :)
Not a fix but should get me going for now.. any other
The workaround by placing the dns in the host file seems to have worked :)
Not a fix but should get me going for now.. any other
Yes, take out the 216 addresses out of the preferred DNS servers... That's your problem. The clients are going outside the network for Domain Services. The clients will not find any Domain services from the servers outside the network. Then, you have to delete the hosts file entries you just made or you could have other problems with DNS.
Please evaluate this article I wrote:
https://www.experts-exchange.com/Networking/Protocols/DNS/A_323-DNS-Troubleshooting-made-easy.html
Please evaluate this article I wrote:
https://www.experts-exchange.com/Networking/Protocols/DNS/A_323-DNS-Troubleshooting-made-easy.html
Hi,
I totally agree with previous answer about removing external DNS servers from your IP settings.
To complete these answers and explain a little more why can might randomly be unable to reach a internal AD domain if you have external DNS in your IP settings you must learn some things about DNS :
1) there is 2 types of DNS answers : authoritative and non authoritative
Let's look at the difference between answers like "I don't know this domain" and "This domain does not exist"... The first answer is a negative non-authoritative DNS answer : the DNS server informs you that is not able to resolve this name so you should try another way to resolve this.
The second answer is also a negative DNS answer but it is an authoritative one : the DNS servers informs you that it is not able to resolve the requested name and that this name DOES NOT exists and so you don't have to try anymore.
2) If you ask an external DNS server (on Internet) for a DNS domain name that is unknown externally (meaning not defined on external public DNS servers) the DNS answer will ALWAYS be negative AND AUTHORITATIVE. The external DNS servers will always answer that the domain doesn't exists and that it is no need to search elsewhere.
3) the DNS client service on computers will always stop to search if it receive an authoritative answer.
4) When a Windows computer has obtained a DNS answer from one of the DNS servers of its IP settings, it will always try to interrogate the DNS server at first the next time it needs to resolve a DNS name.
That means that the DNS servers order in the IP settings is only used at computer startup but after that you can not be sure that the computer will always interrogate the first DNS server in the list fo the next DNS request.
In fact, the computer will try to interrogate in first the DNS server that had answered during the last DNS request.
This is very important... Because if for any reason (internal DNS servers unreachable at a time, DNS request about an external name,...) your computer had to interrogate an external DNS server for anything, it will continue to interrogate this external DNS server for the next requests until this DNS server stop responding or this DNS server give a non-authoritative answer !
And as an external DNS server NEVER gives a non-authoritative answer, you client computer will never interrogate internal DNS servers anymore, until reboot.
In that situation, your computer is unable to resolve internal names anymore !
I hope this is clear enough and I apology for my poor english.
Have a good day.
I totally agree with previous answer about removing external DNS servers from your IP settings.
To complete these answers and explain a little more why can might randomly be unable to reach a internal AD domain if you have external DNS in your IP settings you must learn some things about DNS :
1) there is 2 types of DNS answers : authoritative and non authoritative
Let's look at the difference between answers like "I don't know this domain" and "This domain does not exist"... The first answer is a negative non-authoritative DNS answer : the DNS server informs you that is not able to resolve this name so you should try another way to resolve this.
The second answer is also a negative DNS answer but it is an authoritative one : the DNS servers informs you that it is not able to resolve the requested name and that this name DOES NOT exists and so you don't have to try anymore.
2) If you ask an external DNS server (on Internet) for a DNS domain name that is unknown externally (meaning not defined on external public DNS servers) the DNS answer will ALWAYS be negative AND AUTHORITATIVE. The external DNS servers will always answer that the domain doesn't exists and that it is no need to search elsewhere.
3) the DNS client service on computers will always stop to search if it receive an authoritative answer.
4) When a Windows computer has obtained a DNS answer from one of the DNS servers of its IP settings, it will always try to interrogate the DNS server at first the next time it needs to resolve a DNS name.
That means that the DNS servers order in the IP settings is only used at computer startup but after that you can not be sure that the computer will always interrogate the first DNS server in the list fo the next DNS request.
In fact, the computer will try to interrogate in first the DNS server that had answered during the last DNS request.
This is very important... Because if for any reason (internal DNS servers unreachable at a time, DNS request about an external name,...) your computer had to interrogate an external DNS server for anything, it will continue to interrogate this external DNS server for the next requests until this DNS server stop responding or this DNS server give a non-authoritative answer !
And as an external DNS server NEVER gives a non-authoritative answer, you client computer will never interrogate internal DNS servers anymore, until reboot.
In that situation, your computer is unable to resolve internal names anymore !
I hope this is clear enough and I apology for my poor english.
Have a good day.
ASKER
Not a fix, but a workaround
Works fine with the hosts setup
Works fine with the hosts setup
The hosts files work-around won't for all occasions. Removing external DNS servers is the correct fix. The Hosts files can cause problems with DNS resolution on the clients from time to time. I made that as a point in the article I wrote (provided above).
ASKER
i can't remove the external dns servers because they are needed to keep internet traffic local and not use internet from home office
Hi,
I don't understand why you say that removing external DNS server will change anything in your internet traffic.
DNS is only used to obtain IP address from a server name...
Only IP routes may change the way the internet traffic goes outside.
And by the way, you don't have a choice because as I explained to you interogating internal and external DNS servers will lead you to issues like the one you have.
The correct configuration is to do like this:
1) Add forwarders on your internal DNS servers so that they ar able to transmit DNS request to external DNS servers if the requests are for a non internal DNS zone.
2) configure every computer to ONLY interrogate internals DNS servers.
As soos as the DNS resolution has been done, the way the computer reach Internet is ONLY about IP routes and has no more things to do with DNS servers !
Have a good day.
I don't understand why you say that removing external DNS server will change anything in your internet traffic.
DNS is only used to obtain IP address from a server name...
Only IP routes may change the way the internet traffic goes outside.
And by the way, you don't have a choice because as I explained to you interogating internal and external DNS servers will lead you to issues like the one you have.
The correct configuration is to do like this:
1) Add forwarders on your internal DNS servers so that they ar able to transmit DNS request to external DNS servers if the requests are for a non internal DNS zone.
2) configure every computer to ONLY interrogate internals DNS servers.
As soos as the DNS resolution has been done, the way the computer reach Internet is ONLY about IP routes and has no more things to do with DNS servers !
Have a good day.
Now, what's your argument?! Sounds to me we said the exact same thing in different words. I am telling the author to remove external DNS servers (therefore using only his own internal DNS servers) from the clients and only putting them in DNS forwarders, or rely upon root hints servers. Then, the author should remove all host file configurations except the loopback adapter.
I certainly don't need a class on how DNS works, or routing.
I certainly don't need a class on how DNS works, or routing.
ChiefIT, I was reacting to the last author comment, not yours...
By the way, my english is not as good as yours probably and I might have misunderstood something, in this case I apology, but please stop being agressive.
By the way, my english is not as good as yours probably and I might have misunderstood something, in this case I apology, but please stop being agressive.
Oh, I see. If the author wishes to remain with configured host files, then it's his/her animal to contend with. I have seen a lot of issues resolved by deleting host files and using real DNS servers.
There's an old saying: You can lead a horse to water, but you can't make them drink.
There's an old saying: You can lead a horse to water, but you can't make them drink.
ASKER
Wow, i find a resolution that worked for me. Not sure what the big deal is.
I've been using the method for a week now and have worked perfect ever since. What's wrong with that.. I understand its not a fix, but a workaround, as i stated before, but what's wrong with that. It's working 100% for me.
I thank you all for your concern but i see no need to dive deeper into this, if i have found a workaround (solution, imo)
I've been using the method for a week now and have worked perfect ever since. What's wrong with that.. I understand its not a fix, but a workaround, as i stated before, but what's wrong with that. It's working 100% for me.
I thank you all for your concern but i see no need to dive deeper into this, if i have found a workaround (solution, imo)
OK, you asked what could potentially be future problems with this workaround:
-If you change DNS server IPs and not change it in every host file you will have DNS resoution problems for all the machines you configured this HOSTS file on.
-As you bring in new workstation computer online, you will have to change the host file for that workstation or suffer the same DNS resolution problems you are currently seeing.
-If the host file can't resolve the query, sometimes it will time out without even querying the Domain's DNS servers and you will not be able to resolve DNS for INTERNAL domain SeRVices (SRV records) like Active Directory, File replications, Distributive file servers, Global catalog servers.
-The administrative overhead of configuring every client and server's host file is rediculous. Think of it this way. You don't go to each machine and configure the users for all users on your workstations, do you? Instead, you have an Active Directory server that centralizes your authentication and authorization. So, why would you go to every client machine and configure each one resolve DNS and locate that same authentication server when you have a centrally managed DNS server? Adding administrative overhead to yourself, especially as your company grows, is like bailing the ocean dry with a teaspoon. I'd like to see you configure hosts files on 15,000 machines and keep them up as those machines are updated.
Distributive File Services use DNS these days, instead of NetBIOS resolution. So, you may see intermittent communications with file shares. In the near future when Group policy goes to DNS, you will see problems with group policy.
-Bottom line is: Host Files should never be configured when you have a DNS server, or in a workgroup/home environment when your router provides internal DNS... So, that pretty much covers every instance, these days.
-If you change DNS server IPs and not change it in every host file you will have DNS resoution problems for all the machines you configured this HOSTS file on.
-As you bring in new workstation computer online, you will have to change the host file for that workstation or suffer the same DNS resolution problems you are currently seeing.
-If the host file can't resolve the query, sometimes it will time out without even querying the Domain's DNS servers and you will not be able to resolve DNS for INTERNAL domain SeRVices (SRV records) like Active Directory, File replications, Distributive file servers, Global catalog servers.
-The administrative overhead of configuring every client and server's host file is rediculous. Think of it this way. You don't go to each machine and configure the users for all users on your workstations, do you? Instead, you have an Active Directory server that centralizes your authentication and authorization. So, why would you go to every client machine and configure each one resolve DNS and locate that same authentication server when you have a centrally managed DNS server? Adding administrative overhead to yourself, especially as your company grows, is like bailing the ocean dry with a teaspoon. I'd like to see you configure hosts files on 15,000 machines and keep them up as those machines are updated.
Distributive File Services use DNS these days, instead of NetBIOS resolution. So, you may see intermittent communications with file shares. In the near future when Group policy goes to DNS, you will see problems with group policy.
-Bottom line is: Host Files should never be configured when you have a DNS server, or in a workgroup/home environment when your router provides internal DNS... So, that pretty much covers every instance, these days.
I would have to agree the work around really is going to cause you problems we just want to make sure you are fixed properly the first time and not cause even more problems.
External DNS servers should never be in your TCP\IP settings within a domain environment. DNS Forwarders should be in place.
We are just looking out for in the long run just trying to explain it might work for you now but trust us you won't be happy soon.
Thank you
Darius
External DNS servers should never be in your TCP\IP settings within a domain environment. DNS Forwarders should be in place.
We are just looking out for in the long run just trying to explain it might work for you now but trust us you won't be happy soon.
Thank you
Darius
Are you getting any errors on clients in Event logs?
Is the software located at HQ? Is HQ DNS servers only pointing to internal DNS servers in their TCP\IP properties