Forum Discussion

KiloFoxtrotMike's avatar
KiloFoxtrotMike
Copper Contributor
Jan 17, 2022

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

A few weeks ago, we recently undertook the following operations (in a single day): Commission two new Win2019 DCs in existing domain containing three Win2012R2 DCs Decommission old Win2012R2 DCs ...
Active Directory
prabks's avatar
prabks
Copper Contributor
Jan 18, 2022
https://www.dell.com/support/kbdoc/en-in/000135060/troubleshooting-group-policy-processing-errors-in-an-active-directory-domain , 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.
KiloFoxtrotMike's avatar
KiloFoxtrotMike
Copper Contributor
Jan 18, 2022

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.

  • KiloFoxtrotMike's avatar
    KiloFoxtrotMike
    Copper Contributor
    Jan 23, 2022

    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 :lol:. 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.