VMware Horizon USB Redirection Fails Across Subnets: Field Troubleshooting Checklist

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.

Short version: When VMware Horizon USB redirection fails only from one subnet, do not start by reinstalling Horizon Agent or changing the desktop pool. First prove whether the failure follows the client network path, the user/pool policy, or the endpoint device. In this pattern, the most useful test is a side-by-side comparison: same user, same desktop pool, same USB device, different client subnet.

This field note is written for VDI administrators who see a deceptively narrow symptom: USB redirection works in one location but not another. The user can authenticate, the desktop opens, Blast or PCoIP may appear healthy, but the redirected USB device never appears inside the session or disappears after reconnect. That symptom often feels like a Horizon Agent problem, but the better first hypothesis is subnet-specific policy or network path behavior.

Environment

AreaWhat to recordWhy it matters
Client locationWorking subnet, failing subnet, wired/Wi-Fi/VPN path, NAT or proxy pathUSB redirection can fail only where routing, ACLs, or location-based policy differs.
Horizon pathInternal Connection Server path, UAG path, load balancer path, display protocolInternal and external Horizon connections use different flows and port exposure.
Desktop poolPool name, Horizon Agent version, protocol, USB redirection feature installationPrevents chasing network issues when the pool image does not support the feature.
User and deviceSame test user, same endpoint, same USB device, same client versionControls the test so the subnet is the only major variable.
Policy layerHorizon Smart Policies, DEM conditions, GPO, AD group membershipUSB may be enabled for one client location and denied for another.

Symptoms

  • The user can log in to Horizon and launch the desktop, but USB redirection does not work from one subnet.
  • The same USB device redirects correctly from another subnet or from a test VLAN.
  • The Horizon Client menu may show the device, but the device does not appear inside the virtual desktop.
  • Reconnects may briefly show the device and then drop it again.
  • Other features such as basic display, keyboard, and mouse continue to work, which makes the issue easy to misclassify as a device driver problem.

What was ruled out first

Before changing firewall rules or pool settings, rule out the simple differences that create noisy false positives.

  1. Test the same user account from a known-good subnet and the failing subnet.
  2. Use the same Horizon Client version on the endpoint, or at least record the version difference.
  3. Use the same USB device and the same physical endpoint if possible.
  4. Confirm that USB redirection is installed and allowed in the Horizon Agent image.
  5. Check whether the issue appears only through UAG, only internally, or through both paths.
  6. Confirm that the device is not blocked by a USB include/exclude policy.

Evidence to collect

The evidence should answer one question: does the failure follow the subnet or the desktop session?

EvidenceGood signBad signLikely direction
Same user, same pool, known-good subnetUSB redirectsUSB also failsIf it works, suspect subnet path or location policy.
Different user, failing subnetSame failureOnly one user failsSame failure points to network or client location policy.
Policy result / DEM conditionUSB enabled for the locationUSB denied by location/groupFix Smart Policy or GPO before changing ports.
Firewall/ACL logNo denies for Horizon Agent portsDenied TCP 9427, TCP 32111, Blast, or related pathNetwork policy or route issue.
Endpoint client logDevice attach event reaches sessionRepeated attach/drop or no session channelClient path, USB policy, or latency-sensitive feature behavior.

Root cause or best current hypothesis

For a subnet-only USB redirection failure, the strongest starting hypothesis is not “Horizon is broken.” It is one of these four conditions:

  1. Location-based policy mismatch: Horizon Smart Policies, DEM, or GPO allows USB from one location and denies it from another.
  2. Port or side-channel mismatch: the display protocol works, but the redirection channel or side-channel path is not allowed consistently.
  3. Routing or firewall asymmetry: the client can reach the Connection Server or UAG, but the route to the Horizon Agent or return path is different.
  4. WAN quality problem: USB redirection is enabled, but latency, packet loss, or unstable Wi-Fi makes the device appear to connect and disconnect.

Omnissa's Horizon port documentation is useful here because it separates ordinary login/display traffic from redirection features. For internal connections, the table includes TCP 9427 for several redirection features and TCP 32111 for USB redirection and time synchronization, while also noting that Blast can side-channel certain feature traffic depending on configuration. That means a desktop can look connected while one feature path still fails. See Network Ports in Horizon 8.

Fix or workaround

Use the smallest reversible change that matches the evidence.

  • If policy is different by client location, adjust the Horizon Smart Policy or DEM condition and force a reconnect so the policy is reevaluated.
  • If firewall logs show denies, open only the required path for the actual connection type and display protocol. Do not blindly allow every Horizon port.
  • If UAG is involved, compare the failing external path with a known-good internal path before changing the desktop pool.
  • If WAN quality is poor, decide whether the device truly needs USB redirection. Omnissa recommends disabling USB redirection by default unless there is a specific business requirement.
  • If the feature is required for a special peripheral, document the supported subnet, endpoint type, and fallback path instead of treating it as a general desktop feature.

Verification

  1. Disconnect and reconnect the Horizon session after the policy or network change.
  2. Test the same USB device from the previously failing subnet.
  3. Confirm the device appears in the Horizon Client menu and inside the remote desktop.
  4. Repeat the test from the known-good subnet to ensure the fix did not break the working path.
  5. Record the final route, policy, client version, pool, and protocol so the next subnet issue can be compared quickly.

Rollback and safety notes

  • Back up DEM and GPO settings before changing USB redirection policy.
  • Prefer a test AD group, test pool, or pilot subnet before enabling USB broadly.
  • Do not allow USB redirection globally just to resolve one device complaint. USB redirection can increase security and data movement risk.
  • If firewall changes are required, apply explicit source/destination scoping and keep a rollback record.
  • For external users, consider whether client drive redirection or a supported application workflow is safer than raw USB redirection.

When to escalate

Escalate to the network, security, or Horizon platform owner when the evidence shows any of the following:

  • The failing subnet has different routing, NAT, SSL inspection, proxy, or firewall behavior that the VDI team cannot change.
  • The required business device needs USB redirection across a high-latency WAN path and disconnects remain reproducible.
  • Smart Policy conditions conflict with security rules for external, contractor, or unmanaged endpoints.
  • The issue appears only after a Horizon Client, Agent, UAG, or DEM upgrade and cannot be reproduced on the previous version.

Sources and vendor documentation

Comments

Post a Comment

Popular posts from this blog

Troubleshooting VMware Horizon Client vdpConnect_Failure Issue

  Introduction VMware Horizon Client is a widely used solution for virtual desktop infrastructure (VDI). However, users may encounter various connection issues, one of which is the vdpConnect_Failure error. This error often results in a black screen followed by a disconnection, preventing users from accessing their virtual desktop. In this article, we will explore the possible causes of this issue and provide step-by-step solutions to resolve it. Common Causes of vdpConnect_Failure 1. RPC Server Unavailable One of the most common reasons for vdpConnect_Failure is the unavailability of the Remote Procedure Call (RPC) server . This can occur due to: The RPC service being stopped or disabled Network issues preventing communication with the server Firewall blocking required ports 2. Display Protocol Issues (Blast/PCoIP/RDP) Horizon Client uses different display protocols such as Blast, PCoIP, or RDP . If there are misconfigurations or compatibility issues with the selected protocol, ...
Read more

VMware / Omnissa Horizon Agent Unreachable – Causes and Fixes (Complete Troubleshooting Guide)

  Keywords: VMware Horizon Agent Unreachable, Omnissa Horizon Agent unreachable, Horizon View troubleshooting, Blast service issue, Horizon Agent not responding, VDI connectivity problem In VMware Horizon (now branded as Omnissa Horizon ), administrators frequently encounter the “Agent Unreachable” state in the Horizon Console. While a simple reboot often resolves the issue, persistent cases indicate deeper infrastructure, service, or network-layer problems. This guide provides a structured root-cause analysis and remediation checklist suitable for production VDI environments. What Does “Agent Unreachable” Mean? When a desktop shows Agent Unreachable , the Horizon Agent inside the VM cannot communicate with the Connection Server . The failure typically occurs in one of these control paths: Horizon Agent → Horizon Connection Server Blast Secure Gateway (BSG) → Agent Windows OS services → Horizon Agent service Firewall or network layer blocking agent heartbeat ...
Read more

VMware Horizon Agent Protocol Error and Windows Firewall: A Safe Fix Checklist

Direct answer: A Horizon Agent protocol error is often caused by a blocked secondary protocol path or a Windows Firewall profile mismatch. Fix it by proving which protocol is selected, which component initiates the connection, and whether the desktop firewall allows the required path. Symptoms and affected environment The user can authenticate but the desktop disconnects during launch. Only specific pools, images, or network segments fail. Changing display protocol changes the symptom, which suggests protocol path or firewall behavior. Evidence checklist Check Evidence Failure clue Safe action Selected protocol Pool and client setting Blast fails but RDP test succeeds Focus on Blast path Agent firewall Windows Firewall profile and rules Domain profile not active or rule missing Correct scoped rule only Gateway path UAG and Connection Server logs Secondary protocol timeout Validate route before changing image Image drift Golden image policy and agent version Only one image family fails...
Read more