russco76
asked on
XP client loses contact with DC (2000)
Hi All,
I've already searched EE for hours but can't quite find a solution to my exact problem, so thought I better post my dilemma.
I have a Windows 2000 DC (don't ask) with AD, DNS, DHCP, etc and 120 XP clients. Things have been running happily without issue until recently when a small number of random XP clients would lose their connection with the domain. I think I've narrowed it down to (some) PC's that have been shutdown for a week or more (staff on holidays, or not in use).
Once powered on, the affected PC takes 20+ mins to login, after which the user discovers that they can't access any AD resources (login script, email, etc). Upon further inspection, the affected PC can ping other network devices/servers by IP address, but not by name. BUT, the weird thing is that it can't ping the DC by IP (and vice versa)! Other servers can ping the affected PC's by both name and IP... just not the DC.
The affected clients can still renew their IP via the DHCP. The AD server has been set as the sole DNS server on all client NICs (and the server NIC itself). DHCP leasing is set to 4 days. Nslookup fails (timeout) on the affected PC's. The PC's still have an entry in DNS.
To get around it in the interim, I re-image a spare PC for them (which logs in fine afterwards) but I can't keep that up for much longer. I'm sure its DNS-related (or maybe DHCP's interaction with DNS?), but I'm not sure which steps to take to resolve it.
I'd appreciate any clues/feedback.
Cheers
I've already searched EE for hours but can't quite find a solution to my exact problem, so thought I better post my dilemma.
I have a Windows 2000 DC (don't ask) with AD, DNS, DHCP, etc and 120 XP clients. Things have been running happily without issue until recently when a small number of random XP clients would lose their connection with the domain. I think I've narrowed it down to (some) PC's that have been shutdown for a week or more (staff on holidays, or not in use).
Once powered on, the affected PC takes 20+ mins to login, after which the user discovers that they can't access any AD resources (login script, email, etc). Upon further inspection, the affected PC can ping other network devices/servers by IP address, but not by name. BUT, the weird thing is that it can't ping the DC by IP (and vice versa)! Other servers can ping the affected PC's by both name and IP... just not the DC.
The affected clients can still renew their IP via the DHCP. The AD server has been set as the sole DNS server on all client NICs (and the server NIC itself). DHCP leasing is set to 4 days. Nslookup fails (timeout) on the affected PC's. The PC's still have an entry in DNS.
To get around it in the interim, I re-image a spare PC for them (which logs in fine afterwards) but I can't keep that up for much longer. I'm sure its DNS-related (or maybe DHCP's interaction with DNS?), but I'm not sure which steps to take to resolve it.
I'd appreciate any clues/feedback.
Cheers
ASKER
thanks for your quick response conradjones - just leaving the office but will provide extra info in the morning.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@dnebraski: thanks for your feedback. Assigning a static IP (then rebooting) did allow it to connect back to the domain (and ping server names, etc). Am in the process of updating the NIC driver then will try DHCP again and post the result.
so until then, my next question is: how did this issue occur in the first place (and how can it be avoided)? is it purely driver-related, or hardware-related (ie. dud NIC)? All of my desktops are the same make/model, are only 3 years old, and use the same XP image (ghost) with the same drivers... yet only a small handful encounter this problem.
so until then, my next question is: how did this issue occur in the first place (and how can it be avoided)? is it purely driver-related, or hardware-related (ie. dud NIC)? All of my desktops are the same make/model, are only 3 years old, and use the same XP image (ghost) with the same drivers... yet only a small handful encounter this problem.
ASKER
ok - the affected xp client already had the most up to date nic driver, and patches are all good... but still no luck when switching back to DHCP.
I then applied a static ip to the PC using the same IP address that DHCP usually gave it (192.168.x.52) - the connectivity was lost again. So I set a reservation for that IP (so it would not be re-allocated), then renewed the IP address of the client so its now got 192.168.x.191. Domain connectivity was restored.
I then checked the DNS on the DC, and found that the Reverse Lookup Zone had this new record, BUT the Forward Lookup Zone didn't. The Forward zone still contained the entry for the previous IP address (192.168.x.52). So when you try to ping this PC's hostname from another client, it would look for 192.168.x.52.
I then ran the cmd from the PC ipconfig /flushdns, then /registerdns and the client had the following error in Event Vwr (Source: Dnsapi, EventID: 11163):
===========
The system failed to register host (A) resource records (RRs) for network adapter
with settings:
Adapter Name : {xxxxxxxx-xxxx-xxxx-xxxx-x
Host Name : WKSxxxxxxx
Primary Domain Suffix : xx.local
DNS server list :
192.168.x.10
Sent update to server : 192.1.1.1
IP Address(es) :
192.168.x.191
The reason the system could not register these RRs was because the DNS server failed the update request. The most likely cause of this is that the authoritative DNS server required to process this update request has a lock in place on the zone, probably because a zone transfer is in progress.
You can manually retry DNS registration of the network adapter and its settings by typing "ipconfig /registerdns" at the command prompt. If problems still persist, contact your DNS server or network systems administrator.
==========
I'm not sure where 192.1.1.1 is coming from, as the DNS/DC server is 192.168.x.10???
I then applied a static ip to the PC using the same IP address that DHCP usually gave it (192.168.x.52) - the connectivity was lost again. So I set a reservation for that IP (so it would not be re-allocated), then renewed the IP address of the client so its now got 192.168.x.191. Domain connectivity was restored.
I then checked the DNS on the DC, and found that the Reverse Lookup Zone had this new record, BUT the Forward Lookup Zone didn't. The Forward zone still contained the entry for the previous IP address (192.168.x.52). So when you try to ping this PC's hostname from another client, it would look for 192.168.x.52.
I then ran the cmd from the PC ipconfig /flushdns, then /registerdns and the client had the following error in Event Vwr (Source: Dnsapi, EventID: 11163):
===========
The system failed to register host (A) resource records (RRs) for network adapter
with settings:
Adapter Name : {xxxxxxxx-xxxx-xxxx-xxxx-x
Host Name : WKSxxxxxxx
Primary Domain Suffix : xx.local
DNS server list :
192.168.x.10
Sent update to server : 192.1.1.1
IP Address(es) :
192.168.x.191
The reason the system could not register these RRs was because the DNS server failed the update request. The most likely cause of this is that the authoritative DNS server required to process this update request has a lock in place on the zone, probably because a zone transfer is in progress.
You can manually retry DNS registration of the network adapter and its settings by typing "ipconfig /registerdns" at the command prompt. If problems still persist, contact your DNS server or network systems administrator.
==========
I'm not sure where 192.1.1.1 is coming from, as the DNS/DC server is 192.168.x.10???
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
One more thing I just thought of. I have resolved this issue by removing the suspect computer from the domain, and after a reboot, add it back in. I think it was related to a cloned machine. Give it try.
ASKER
@dnebraski: yep, DHCP was definitely acting strange and your tips got me on the right track. I tried manually removing from domain, rebooting, then re-attaching - but that didn't really work (due to the problem DHCP-assigned IP not finding the DC). In the end, I manually removed all DNS and DHCP entries relating to the affected PC's, deleted them from the domain, then re-imaged them and they connected to the domain and correctly updated the DNS, etc.
Cheers for the help!
Cheers for the help!
can you telnet onto any ports on the server from the affected workstation? telnet server.domain.local 53
can you post here a ipconfig /all
from the server
from the affected workstation
and from the working workstation