5

We installed a few new computers to the network, and all of them appear to be having the same issue in Application Event Log:

Windows cannot obtain the domain controller name for your computer network. (The network path was not found. ). Group Policy processing aborted.

These workstations can still log into the domain, but deployed software installs and such to network computers are not taking place for these machines.

Is there a likely cause to this? Again, these were brand new machines, same OS (Win XP Pro) as all others.

CandyCo
  • 143
  • 3
  • 6
  • Are these computers joined to the domain? – Wesley Feb 18 '10 at 16:54
  • 1
    @Wesley: If they're getting that kind of event log message then they have to be. – Evan Anderson Feb 18 '10 at 16:56
  • Quite right. My tunnel vision strikes again. – Wesley Feb 18 '10 at 17:09
  • I have the same problem. I don't have DHCP. DNS was written manually. And it works properly (nslookup receive an IP by domen name). Moreover another PC's in this subnet work good - there isn't any errors. BUT 1! On problem PC I have a Comodo firewall. I put it inactive mode. May be when it starts it blocks ICMP (Helvick answer) and only after login put firewall in inactive mode. BUT 2! I had made several experiments with local group policy on problem PC before. – user35115 Feb 19 '10 at 05:22
  • user35115, did disabling the firewall resolve the issue? – CandyCo Feb 19 '10 at 13:38

5 Answers5

4

Obviously, be sure that the "problem" computers have the same DNS server specified as the "working" computers. (Ideally they're having that set by DHCP.)

It seems unlikely that your Ethernet switch's spanning tree implementation would be blocking access, but to be sure that it's not switch port-related you might try one of the "problem" computers on one of the ports used by a known-working computer.

Some NICs have a problem with "media sense" and can cause problems with Group Policy processing. If you see event log entries from the NIC driver about the network connection coming up after the entries complaining about being unable to find the domain controller name then you've probably got a media sense problem. Have a look here for more background:

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • Interestingly enough there was an updated driver for a gigabit nic card that specifically stated it addressed an issue with AD. However, even after updating and rebooting several times, the issue persists. Same with the registry edit. Great info either way, as I'm sure it was needed. Still searching for teh solution though. And yes, all DNS servers are consistent across 'working' and 'problem' computers. – CandyCo Feb 18 '10 at 20:22
  • Selecting this as my solution, because for all intents and purposes, it was at least part of the resolution. – CandyCo Feb 19 '10 at 19:45
2

Make the client PCs use the Domain Controllers as DNS servers. Check that the proper SRV records are in the DC's DNS records. Run DCDIAG /TEST:DNS on the Domain Controllers to check for any errors in the DNS records.

Wesley
  • 32,320
  • 9
  • 80
  • 116
0

Does your switch have STP enabled? If so, try disabling it on the ports for the affected computers (enable portfast). There's also a GPO and\or registry setting you can try:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "WaitForNetwork"=dword:00000001

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
0

Check if you're assigning an FQDN as part of your DHCP setup and correct it if it's not the same as your DNS domain name.

Maximus Minimus
  • 8,937
  • 1
  • 22
  • 36
0

XP uses ICMP to check connectivity to domain controllers in order to decide whether to be selective about applying Group Policies. If ICMP is blocked or restricted by your network then you will see the error you report for XP systems. Vista and Windows 7 use NLA which isn't affected by this. Obviously since most of your XP systems don't have this issue it's not a core network problem but possibly these new systems all connect via a common switch\router that is doing something undesirable. It may not be the root cause but if it is this Microsoft KB article discusses some mitigation approaches if you can't fix this on the network hardware.

Helvick
  • 19,579
  • 4
  • 37
  • 55
  • These problematic machines connect through the same switch that healthy machines are connected to. Thank you for the suggestion, however. – CandyCo Feb 19 '10 at 18:32