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.
Best Answer
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!