processing of Group Policy failed only on 2008 Servers and Name Resolution failure on the current domain controller

Question

Spent last 3 months doing a upgrade from 2003 domain to a 2008R2 domain. our last DC was rebuilt (5 total) and brought up on line. After it was put on line we have some 2008 and 2008R2 servers (10 now) getting these errors in the event logs.

ERRORS Description: The processing of Group Policy failed. Windows could not resolve the user name. This could be caused by one of more of the following: a) Name Resolution failure on the current domain controller. b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).\ Can duplicate this if we drop to command prompt and run GPUPDATE manually

When our users attempt to do a \directory\shared access to shared drive on an affected server get this error.– “THERE ARE CURRETLY NO LOGON SERVER AVAIALBE TO SERICE THE LOGON REQUEST.

This is only affecting the 2008 OS and it is a random set of abotu 10 servers out of some 30 with this OS.

The Services on the machines are running Ok and login. Able to log in with domain/user to the consoles and via RDP. WE can log onto an affected machine, and can get to the \domainname\sysvol and can see the GPO's

Have checked the replication topology of the domain and it states all servers can replicate with no errrors. We went back to the last DC, demoted it, removed DNS and then removed it from the domain and waited 24 hours and issue still persist. Picked one server, removed it from domain, reboooted, and added back to domain with no problems, but still has this behavior.

bottom line is we have some servers that the domain will not let any UDP/client server apps or GPO's process ,but the tcp related items seeme to work fine, http, tcp calls, sql and oracle dbs's connect and process.

Any inputs on some possible reasons for this issue and fixes. It is only affecting the 2008 servers on a 2008R2 domain.

Solution

One funny item that always springs to mind when UDP fails while TCP works: Kerberos MaxPacketSize

http://support.microsoft.com/kb/244474

A similar issue can exist with DNS, which by default uses UDP unless the response is too large for a single UDP packet (e.g. getting a list of SRV records). Normally a client should re-try with DNS over TCP, but if this is blocked, strange errors can occur.

Test DNS via TCP with: "nslookup -vc domain.name [dns server]". If this fails, you may have network ACLs, firewall rules, etc, that are blocking TCP DNS.

One final fault I've seen cause similar issues: routing blackholes, where traffic is silently dropped by routers/firewalls for various reasons.

http://support.microsoft.com/kb/314825

Hope this helps!

Comments

[joeqwerty]

Check and verify that your AD DNS zones have the correct SRV and A RR records and verify that each DC has the correct DNS servers configured in it's TCP/IP properties. - support.microsoft.com/kb/816587

[Ken Wolfrom]

that area was verified. dns is operational and it is serving up other server members of the domain with no issues. Forwarding and zone transfers replicate on schedule and can be done manually with no errors. And to really drive you crazy, a NSLOOKUP on a problem server will resolve the domain name just fine. and any other name on the net. - ken