Posts

Horizon USB Redirection: Working vs. Failing Subnet Evidence Worksheet

Horizon USB redirection subnet troubleshooting flow USB redirection fails only from one subnet Work from known-good path to policy, port, route, and endpoint evidence. Client subnet A USB menu visible? Known-good subnet Same user, same pool Policy decision Smart Policy / GPO Network path 9427 / 32111 / Blast If only one subnet fails Favor ACL, route, NAT, proxy, or location policy. If all subnets fail Favor pool, agent, GPO, or device policy. Verify after change Reconnect, test device, preserve rollback. Original troubleshooting diagram created for this article. Purpose: Use this worksheet to hand a subnet-specific Horizon USB problem to the network and desktop teams with comparable evidence. It complements the USB redirection troubleshooting guide ; it is not a second account of the same incident. This is an unfilled ...

ESXi /bootbank Alarms After Disk Replacement: What This Incident Did and Did Not Prove

Operator-reported incident with documentation-based safety notes. Revised September 12, 2026. The sequence below was supplied by the operator. Exact alarm text, ESXi build, boot-device layout, log extracts, and a measured observation duration were not supplied. The root cause remains unconfirmed. What was actually reported vCenter raised an alarm for another hardware object on one host. A failed physical disk was found and replaced. Afterward, /bootbank warning emails recurred—sometimes within five minutes, sometimes at roughly hourly intervals. The operator and hardware maintenance vendor placed the host in maintenance mode and rebooted it. The emails stopped after some additional time. Continued observation found no further problem, and the host is currently in service according to the operator's account. This is a recovery observation, not proof that the replaced disk held the bootbank, that a RAID fault caused the warning, or that restarting repaired damaged media. We also ...

Horizon USB Across Subnets: Identify the Transport Before Changing Firewall Rules

Documentation-based investigation guide. Revised September 12, 2026. No packet capture or completed incident record is available for this article. The earlier unsupported failure percentage and blanket TCP/UDP rule recommendation have been removed. A USB device that works on one subnet but not another gives you a comparison opportunity—not a proven firewall diagnosis. This guide explains how to choose the traffic path to investigate. The separate subnet worksheet is for recording the results; it does not establish a root cause. First distinguish the feature from the symptom Record whether the device is absent from the client's redirection menu, listed but unable to connect, visible inside Windows but unusable by an application, or disconnected during use. These are different failure stages. Also distinguish generic USB redirection from optimized audio/video, printing, and client drive redirection. A working microphone through an optimized channel does not demonstrate that gener...

Horizon Login Loops After Maintenance: Reconstruct the UAG Access Chain

Documentation-based investigation guide. Revised September 12, 2026. The original narrative did not include an attributable maintenance record or logs. Its topology and recovery story are not presented here as verified firsthand events. A login loop after maintenance needs a timeline, not another full-stack reboot. The question is which part of the access transaction first stops behaving as expected. Restarting a gateway may restore availability while leaving that question unanswered. Build one transaction record For one approved test account, record the timezone, client build, entry FQDN, last successful screen, selected UAG, selected Connection Server, and whether a desktop was allocated. Correlate the test with gateway, authentication, broker, and load-balancer records. Remove account identifiers, tokens, OTP values, and shared secrets before circulating evidence. Do not assume every deployment uses the same order of disclaimer, RADIUS, and AD authentication. Describe the confi...

Horizon Connection Failure on an Older PC: A Controlled Client-Version Test

Documentation-based comparison plan. Revised September 12, 2026. No verified CPU measurements, client builds, or reproduction logs support the old explanation. The claimed 100% CPU mechanism and recommendation to install a client several releases older have been removed. If Horizon fails on an older PC, age is a clue about what to measure, not a diagnosis. A successful connection after a client replacement could reflect a version difference, repaired installation, reset preferences, or changed feature configuration. This article isolates those variables rather than treating a downgrade as proof of weak hardware. Define a reproducible launch test Record the exact error text, client and Agent builds, endpoint OS, graphics driver, configured protocol, monitor arrangement, pool, and last successful connection stage. Preserve client logs before reinstalling. Establish whether the process crashes, the session closes, or the display never opens; these outcomes need different evidence. Us...

Teams Not Optimized on Horizon and Tera2: Check Compatibility Before Replacing Endpoints

A “Not Optimized” status in Teams is not, by itself, proof that the endpoint is defective. Check whether the precise Teams, Horizon Agent, Horizon Client, and endpoint combination supports the intended optimization mode. This guide focuses on that compatibility decision for environments that still use Tera2 PCoIP zero clients. Correction — September 12, 2026: The earlier article described a deployment with 100% of users affected and host CPU exceeding 90%, without an attributable test record. Those numbers and the claim of a universally proven hardware replacement fix have been removed. No measured deployment results are asserted below. Distinguish remote display from media optimization A device being able to display a Horizon desktop does not establish that it can run the endpoint component needed for Teams media optimization. HP documents the Tera2 PCoIP zero-client platform ; use its exact model and firmware when checking support, rather than treating every product called a zer...

Horizon PCoIP Fails on Home Wi-Fi: Compare Paths Before Blaming NAT

A Horizon session working on a hotspot but failing at home isolates a path-dependent symptom, not a proven NAT defect. Keep the endpoint, account, pool, and protocol constant and compare the two paths before blaming the router or excluding the managed infrastructure. Correction, September 12, 2026: The earlier article generalized ISP and hotspot behavior, attributed failures to symmetric NAT without packet evidence, and described Blast as universally using port 443. Those conclusions have been removed. This is a documentation-based investigation guide; no measured ISP comparison is supplied. Make the comparison meaningful Comparison What it helps isolate What it does not prove Same laptop, home Wi-Fi versus approved hotspot A change in the access path or location-dependent policy Which router, carrier, gateway or rule causes the failure. Home wired versus home Wi-Fi Local wireless conditions, where wiring is available That the ISP or gateway is healthy. Same route, another support...

Popular posts from this blog

Horizon vdpConnect_Failure: Connection-Stage Triage Before Reinstalling

Horizon Agent Unreachable: Registration and Desktop-Health Triage

Horizon Protocol Error: Trace the Display-Session Handoff