Introduction

A logging migration can bring the new Windows Event Forwarding collector online while servers and workstations still deliver events to the old one. Security teams lose visibility in the new platform, forwarded events keep appearing on the retired collector, or one OU reports correctly while another still uses the previous subscription path because WEF subscriptions, WinRM listeners, and Group Policy settings often persist beyond the cutover.

Treat this as an event-routing problem instead of a generic Windows logging failure. Start by checking which collector URL and subscription manager an affected endpoint actually uses, because migrations often validate the new collector itself while existing sources continue following older policy or cached subscription settings.

Symptoms

  • Windows Event Forwarding still sends events to the old collector after migration
  • The new collector receives fewer events than expected
  • One server group or OU forwards correctly while another still uses the previous collector
  • Event forwarding fails only after the old collector is shut down
  • WinRM appears healthy, but live forwarded events still land in the retired environment
  • The issue started after moving WEF, Windows logging, or SIEM ingestion infrastructure

Common Causes

  • Group Policy still publishes the old subscription manager URL
  • Source-initiated subscriptions still point to the previous collector
  • WinRM listener or certificate config was updated on one collector but not another
  • Endpoint policy refresh is incomplete, leaving some systems on the retired forwarding path
  • Automation or baseline templates keep reapplying the old collector configuration
  • Validation confirmed the new collector could receive events but did not verify what endpoint real sources actually used

Step-by-Step Fix

  1. Capture one affected endpoint and record the subscription manager URL, collector hostname, and forwarding state it actually uses, because the runtime subscription path determines where events really go.
  2. Compare that active forwarding path with the intended post-migration design, because one stale subscription setting can keep a large endpoint group tied to the retired collector.
  3. Review WEF subscription configuration, Group Policy, WinRM listener settings, certificates, and baselines for references to the old collector, because Windows event forwarding depends on both endpoint policy and collector availability.
  4. Check different OUs, server classes, and workstation groups separately if behavior differs, because migrations often fix one GPO scope while another still publishes the previous collector.
  5. Update the authoritative forwarding policy so affected endpoints use the intended subscription manager and collector, because standing up the new server alone does not retarget already enrolled event sources.
  6. Trigger a controlled event on one affected endpoint and confirm it appears on the intended collector, because healthy WinRM connectivity alone does not prove the right backend is receiving forwarded logs.
  7. Verify the old collector no longer receives events from migrated sources, because split log delivery can remain hidden while both collectors stay online.
  8. Review firewall policy, certificate trust, and event channel permissions if forwarding still fails, because the destination can be correct while transport or authorization still blocks delivery.
  9. Document which team owns WEF subscriptions, GPO publication, and migration validation so future collector moves verify the real event-forwarding destination before retiring the previous environment.