Introduction

A Microsoft activation migration can bring the new KMS host online while Windows or Office clients still request activation from the old one. Activation works on one subnet but not another, clients fall out of compliance after the previous host is removed, or new machines activate correctly while older ones still use the retired server because DNS discovery, local activation overrides, and firewall paths often survive the cutover.

Treat this as an activation-target problem instead of a generic licensing failure. Start by checking which KMS host an affected client actually tries to reach for activation, because migrations often validate the new host count and licensing state while real endpoints continue following older SRV records or manual host assignments.

Symptoms

  • Clients still activate against the old KMS host after migration
  • Windows or Office activation fails only after the previous host is disabled
  • One site or subnet uses the new KMS host while another still uses the old one
  • Newly built devices activate correctly, but long-lived clients do not
  • Activation logs continue appearing on the retired host
  • The issue started after moving KMS, activation services, or Microsoft volume licensing infrastructure

Common Causes

  • DNS SRV records still advertise the old KMS host
  • Clients have a manually configured activation host overriding automatic discovery
  • Firewall, routing, or VPN paths still send activation traffic toward the retired environment
  • One DNS zone or site was updated while another still resolves the previous host
  • Golden images or provisioning scripts keep setting the old KMS target
  • Validation confirmed the new KMS host was active but did not verify which host real clients actually queried

Step-by-Step Fix

  1. Capture one affected client and record the KMS host, discovery method, and recent activation attempt it actually uses, because the runtime activation target determines where licensing requests go.
  2. Compare that active activation path with the intended post-migration design, because one stale SRV record or manual host override can keep many devices tied to the retired KMS host.
  3. Review DNS SRV publication, local KMS client settings, imaging scripts, and firewall or routing policy for references to the old host, because activation routing often spans client config and name resolution together.
  4. Check subnets, VPN-connected devices, and newly imaged systems separately if results differ, because migrations often fix one discovery path while another still uses the previous activation source.
  5. Update the authoritative DNS and client activation configuration so affected endpoints discover the intended KMS host, because deploying the replacement server alone does not retarget existing clients.
  6. Trigger a controlled activation attempt and confirm it reaches the intended host and succeeds, because a licensed machine does not prove the current backend is the right one.
  7. Verify the old KMS host no longer receives activation requests from migrated clients, because split activation paths can remain hidden while both servers stay available.
  8. Review time sync, DNS cache, and licensing thresholds if activation still fails, because the destination can be correct while client state or activation prerequisites still block success.
  9. Document which team owns DNS publication, imaging standards, and activation validation so future KMS migrations verify the actual host used by clients before retiring the previous server.