I’ve seen these Event ID’s appear in situations where:
Active Directory was unhealthy (or a single DC, that a workstation was attempting to connect to was unhealthy)
DNS Servers that a workstation points to, are unhealthy
Combination of both (usually they are related)
Where workstations were not receiving GPO updates successfully, and workstations were also displaying unpredictable behavior when accessing network resources.
15, 1053, 1054
However, in today’s occurrence, it wasn’t Active Directory or DNS that was the problem. After some investigating and troubleshooting, a simple IPCONFIG showed that the offending workstation was receiving DHCP addresses from the newly installed SonicWall firewall (or in your situation, some other ‘rogue’ DHCP Server, or router/firewall/WAP providing DHCP Services). Once the ‘DHCP’ server was turned off on the firewall, and the respective workstation received the correct DHCP settings from the DHCP server, operations were running successfully, namely Group Policy Objects were being applies successfully. I.e. the core problem here was the workstation no longer *knew* which correct DNS server to communicate with, as the bogus DHCP Server was providing the ISP’s DNS servers – which are no help at all in an Active Directory setting.
I wanted to post this as this will come up from time to time and the situation isn’t immediately obvious. In an SBS environment, the DHCP Server service on the SBS server would be turned off and logged (by design) which makes this easier to catch. But, in a larger environment that isn’t using SBS, DHCP on a Windows Server does not have this ‘safety mechanism’. So, the quick discovery here is simply to perform an IPCONFIG /ALL and verify the value for the ‘DHCP SERVER’ is what you expect it to be.