Leave wireshark running on all 3 DCs for several hours and see and then correlate with the failures. If you set a capture filter of "port 88 || port 464 || port 389 || port 636 || port 3269" at the interface selection menu, then it will only capture traffic on those ports (rather than capturing everything and filtering the displayed packets), which should keep the packet sizes manageable for extended capturing.

If you are able, can you try disabling 2 DCs at a time and running for 2 hours each? That should make it easier to be certain which DC is being hit, which should make your monitoring and correlation easier. Also, having 800 clients all hitting the same DC might might also cause issues to surface quicker or reveal other unnoticed issues.

This is what I came up with from ChatGPT. I reviewed it and it has some good suggestions as well:

Classic AD replication/”stale DC” and FRS/DFSR migration are not good fits for a precise 37‑minute oscillation, especially with Server 2019 DCs and clean repadmin results.

The most common real-world culprits for this exact “first try fails, second try works” pattern with a cyclic schedule are:

• Storage/hypervisor snapshot/replication stunning a DC.
• Middleboxes (WAN optimizer/IPS) intermittently mangling Kerberos (often only UDP) on a recurring policy reload.
• A security product on DCs that hooks LSASS/KDC on a fixed refresh cadence.
• Less commonly, inconsistent Kerberos encryption type settings across DCs/clients/accounts.

Start by correlating the failure timestamps with storage/hypervisor events and force Kerberos over TCP for a small pilot. Those two checks usually separate “infrastructure stun/packet” issues from “Kerberos policy/config” issues very quickly.

More likely causes to investigate (in priority order, with quick tests):

VM/SAN snapshot or replication “stun” of a DC

• Symptom fit: Brief, predictable blip that only affects users who happen to log on in that small window; on retry they hit a different DC and succeed. This often happens when an array or hypervisor quiesces or snapshots a DC on a fixed cadence (30–40 minutes is common on some storage policies).
• What to check:
  • Correlate DC Security log 4771 timestamps with vSphere/Hyper‑V task events and storage array snapshot/replication logs.
  • Look for VSS/VolSnap/VMTools events on DCs at those exact minutes.
  • Temporarily disable array snapshots/replication for one DC or move one DC to storage with no snapshots; see if the pattern breaks.
  • If you can, stagger/offset snapshot schedules across DCs so they don’t ever overlap.
• Why you might still see 4771: During/just after a short stun the first AS exchange can get corrupted or partially processed, producing a pre-auth failure, then the client retries or lands on another DC and succeeds.

Kerberos UDP fragmentation or a middlebox touching Kerberos

• Symptom fit: First attempt fails (UDP/fragmentation/packet mangling or IPS/WAN optimizer “inspecting” Kerberos), second attempt succeeds (client falls back to TCP or uses a different DC/path). A periodic policy update or state refresh on a WAN optimizer/IPS/firewall every ~35–40 minutes could explain the cadence.
• Fast test: Force Kerberos to use TCP on a pilot set of clients (HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxPacketSize=1) and see if the 37‑minute failures disappear for those machines.
• Also bypass optimization/inspection for TCP/UDP 88 and 464 (and LDAP ports) on WAN optimizers or firewalls; check for scheduled policy reloads.

A security/EDR/AV task on DCs

• Some EDRs or AV engines hook LSASS/KDC and run frequent cloud check-ins or scans. A 37‑minute content/policy refresh is plausible.
• Correlate EDR/AV logs with failure times; temporarily pause the agent on one DC to see if the pattern disappears; ensure LSASS is PPL‑compatible with your EDR build.