Editorial correction — September 12, 2026: The earlier version attributed cross-domain account lockouts to a Windows 11 24H2 defect and made claims about Microsoft's support response and patch plans. This article does not have publishable evidence establishing those conclusions. They have been withdrawn. The guide below explains how to investigate the reported symptom without assuming a product defect or recommending password reuse.
Start with the locked account, not the Windows version. When launching an application inside a Horizon desktop appears to trigger a lockout in another domain, identify which account was locked, which computer submitted the requests, and which process was involved. A matching username in two domains and a recent upgrade are investigation clues, not proof of the cause.
Scope and evidence limits
This is a documentation-based investigation guide for administrators of Windows virtual desktops with applications using a separate identity domain. It is not a reproduced Windows regression report. Exact affected builds, application versions, domain trust configuration, authentication traces, and a confirmed vendor root cause are not available here. Do not infer that every Windows 11 24H2 or 25H2 installation is affected.
Read the events correctly
| Signal | What it establishes | What it does not establish |
|---|
| Security event 4740 | An account was locked out; inspect the target account and Caller Computer Name. | Which application or software defect caused the attempts. |
| Security event 4648 | A process attempted a logon with explicitly supplied credentials; examine account domain, process, and target server fields. | A failed password, account lockout, or cross-domain credential leak on its own. |
| Application launch time | A time window to correlate with authentication events. | Causality without a repeatable controlled comparison. |
| Upgrade date | A possible change boundary. | A confirmed Windows defect or the current availability of a patch. |
Microsoft documents event 4740 as an account lockout and event 4648 as an explicit-credential logon attempt. The latter also occurs during normal system activity. Collect relevant events from the domain controllers and the originating desktop as appropriate; do not assume every useful event resides on the domain controller.
Build one correlation record
- Record the full account identity, affected domain, exact Windows build and installed update, Horizon Client and Agent versions, application version, and whether the application runs inside the desktop or on the endpoint.
- Record the lockout time with timezone and verify clock consistency before comparing logs from different machines. Preserve the original event export before changing credentials or clearing caches.
- Use the lockout event's caller information to narrow the source. Where available, correlate explicit-credential events by time, account/domain, process name, and target server. Inspect related authentication failures with the identity team.
- Review that source for stale saved credentials, mapped connections, scheduled tasks, services, and application account configuration. Check the intended domain rather than interpreting a short username as a unique identity.
- With an approved test account and a limited retry plan, compare application closed versus application launched. Change only one variable. Stop before repeated attempts create another production lockout.
Choose a correction only after the source is identified
If one saved connection uses an obsolete password or the wrong account domain, correct that specific connection through the owning application's supported settings. If a scheduled task or service is responsible, have its owner update the credential and assess dependent jobs. Do not delete every saved credential, rename production identities, or reinstall Horizon as an initial experiment.
Do not synchronize passwords across independent domains merely to hide lockouts. That can conceal incorrect authentication attempts and expand the impact of a compromised credential. Likewise, disabling the lockout policy trades an operational symptom for a security exposure. Any identity redesign needs security review and a separate migration plan.
Verification and escalation
Repeat the previously failing application workflow, a fresh VDI login, and the relevant background activity after the scoped correction. Confirm both that the account remains usable and that the originating unwanted attempts have stopped. Define the observation period around the actual retry or scheduled-task cycle; a quiet few minutes is insufficient for an hourly trigger. Restore the prior application configuration if the change causes unrelated access failures.
For vendor escalation, provide sanitized event exports, exact builds, reproduction steps, a known-good comparison, and the precise change that preceded the failure. Redact account names, internal addresses, and tokens before sharing publicly. Describe an upgrade regression as a hypothesis until the evidence supports it; a claim that a vendor has no fix needs a dated, attributable source.
Related troubleshooting guides
Comments
Post a Comment