Unable to process group policy objects—gpsvc log shows many "deferring search" entries

[KiloFoxtrotMike]

A few weeks ago, we recently undertook the following operations (in a single day):

1. Commission two new Win2019 DCs in existing domain containing three Win2012R2 DCs
2. Decommission old Win2012R2 DCs
3. Raise domain and forest functional levels to Windows Server 2016

Since then, no member servers or workstations have been able to apply GPOs properly. The last process time for all GPO components (GP Environment, GP Local Users and Groups, GP Registry, etc) except for GP Infrastructure, show the last process time to be the date that we performed the above steps. The GP Infrastructure component has a proper last process time of whenever we run gpresult or RSOP.

We've enabled group policy debugging and analysed the log but there is nothing immediately obvious apart from the fact that there are a whole bunch of GPOs for which gpsvc is "Deferring search for <LDAP://cn={UID},cn=policies,cn=system,DC=example,DC=COM>". This seems to appear whenever GPO processing fails.

I can confirm there is no connectivity issues, DNS issues, FRS issues or replication issues.

What we have found is that if we remove a computer from the domain and rejoin it, everything works! It's not feasible however, to repeat this process across the organisation as there are several hundred domain-joined computers.

I cannot find any information on what "deferring search" means but I have a hunch that it may lead us to the root cause.

[#2]

did you find anything from the event logs on the member servers and workstations?

[#3]

No, most of the messages were informational in nature and didn't mention any errors.

[#4]

https://www.dell.com/support/kbdoc/en-in/000135060/troubleshooting-group-policy-processing-errors-in... , This could help you. Also I would suggest you to upgrade your SYSVOL replication from FRS to DFSR … I think 2016/2019 DCs no longer support FRS replication.

[#5]

Thanks for your quick response!

I confirmed they're using DFSR during the AD works, so it's definitely not that.

As for the Dell article, the bit on secure channel looks somewhat promising as this point—In some cases, it may be necessary to remove the affected machine from the domain, reset its AD computer account, and rejoin it to the domain in order to reset its secure channel—was done to resolve it on a test domain member.

[#6]

So we did fix this problem in the end. For interested readers, it turned out to be DNS, however even though the fix was trivial, determining that it was DNS, wasn't.

As it turns out, we found that the "Deferring search for..." is largely a red herring (for us anyway) and some computers were logging an additional "ldap_bind_s failed with 82". This is simply an error message saying that a synchronous call to bind failed. The gpsvc logs do indicate which DC the computer is reaching out to, to process the group policy but it doesn't appear to be the same for all GPOs, which means it's not trivial to determine which DC the bind is failing for.

We ran a packet capture on the DCs, filtered by a computer that was having problems and discovered that the computer was reaching out for an SRV record (in the base example.com domain). When we searched DNS, there were multiples of this SRV record, however one was pointing to a DC that we had just decommissioned. When we deleted this old SRV record then all computers that were failing GP processing, started working.

Lesson: it's (still) ALWAYS DNS . And after a DC removal, clean up all stale DNS (ldap and SRV) entries in not only the _msdcs.example.com zone but also the example.com zone.