Horizon performance optimization for challenging network conditions

Overview

Users connecting to Omnissa Horizon virtual desktops over challenging networks with high latency, packet loss, jitter, or limited bandwidth can experience degraded responsiveness, choppy video, and slower application performance.

There are various areas to consider in optimizing the user experience, including tuning the Horizon display protocol, configuring network settings, and using Horizon redirection features.

Blast, Horizon's display protocol, is designed to adapt automatically to many of these conditions, but some environments, such as branch offices on satellite links, international WAN circuits, or home offices with limited internet service, can benefit from deliberate, additional configuration.
Horizon has several redirection features, including HTML5 Multimedia Redirection, URL Content Redirection, and Browser Content Redirection, that render the content directly on the client device. These all reduce the amount of traffic that has to go via the virtual desktop.

This guide applies a layered set of adjustments, prioritized by impact and effort, covering the display protocol itself, video-conferencing offload, display resolution, endpoint configuration, the underlying network, and content redirection. Nearly all of the highest-impact changes, reducing resolution, verifying conferencing offload, and adjusting a handful of bandwidth settings, can be implemented quickly and without new hardware or circuit investment. Most recommendations in this guide require no new capital expenditure. They are configuration changes to existing Horizon Agent, Group Policy, and Horizon Client deployments.

It is recommended that you also involve your network team to have them investigate optimization of the physical network transport and routing.

Blast protocol tuning

Blast is designed to adapt automatically to changing bandwidth and latency conditions, and in most LAN and typical WAN scenarios it does not require manual tuning.

Blast's adaptive engine continuously measures round-trip time and available bandwidth and adjusts image quality, frame rate, and build-to-quality behavior in real time.

Manual overrides should only be applied where testing shows the defaults are insufficient, since incorrect tuning can reduce quality without improving usability.

TCP vs. UDP recommendations

UDP is the default and recommended transport for Blast in nearly all conditions. Testing shows UDP and TCP consume essentially the same bandwidth, but UDP tolerates packet loss and variable conditions better because it avoids TCP's retransmission and head-of-line blocking behavior.

Use UDP (default) for all network conditions except the two exceptions below. Switch to TCP only when traffic must traverse a UDP-hostile device, such as a TCP-based SSL VPN that re-encapsulates UDP inside TCP.

Switch to TCP when WAN latency is 250 ms or greater. Testing shows TCP handles very high latency conditions better than UDP in this range.
Blast automatically falls back to TCP if the initial UDP connection attempt fails, so this is a resilient default, not an either/or configuration choice.

Forcing TCP on a network that doesn't need it is one of the most common misconfigurations. It adds retransmission overhead and can make packet loss and jitter worse, not better, below the 250 ms threshold.

For more information, see the Omnissa Blast Optimization Guide.

Bandwidth management

Three key registry / GPO settings govern Blast bandwidth consumption:

Setting	Purpose	Default
MaxBandwidthKbps	Ceiling for all Blast services combined (display, audio, USB, clipboard, file transfer)	1,000,000 Kbps
MinBandwidthKbps	Floor bandwidth guaranteed to the session	256 Kbps
MaxBandwidthKbpsPerMegaPixelSlope	Ceiling specifically for screen/display traffic, independent of other services	6,200 Kbps

These are best-effort settings, not hard caps. Blast will exceed them rather than crash the session if required. For constrained links, it is recommended to adjust MaxBandwidthKbpsPerMegaPixelSlope first, since it limits only display traffic without starving audio or file transfer.

Uncontrolled bandwidth from a handful of graphics-heavy sessions can saturate a branch or home-office circuit, degrading every other user and application on that link. Setting a sensible ceiling protects shared capacity.

Image quality and codec optimization

Blast supports four codecs, each suited to different content types and network conditions:

Codec	Best for	GPU offload?	Bandwidth profile
Blast Codec	Office/productivity, SaaS apps, CAD/photo editing (low motion)	No	Lowest of all codecs for non-multimedia workloads
JPG/PNG (Adaptive)	Productivity apps, fine text/detail, still images	No	Moderate; supports build-to-lossless
H.264 (default)	Full-motion video, streaming, gaming	Yes (NVIDIA)	Higher; efficient with GPU offload
HEVC (H.265)	Same as H.264, ~50% better compression at equal quality	Yes (NVIDIA required)	Lower than H.264 at equal quality, but higher CPU cost

Choosing the wrong codec for the workload is a common source of poor performance. Office-style desktops running H.264 by default in a bandwidth-constrained branch will use more bandwidth than necessary. Conversely, forcing JPG/PNG on a video-heavy use case will hurt motion quality.

Test the Blast Codec first for typical office/knowledge-worker desktops in constrained networks. It is the lowest-bandwidth option for non-multimedia workloads. Fall back to JPG/PNG if application compatibility issues appear.
Reserve H.264/HEVC for use cases genuinely dominated by full-motion video or 3D graphics, and pair with NVIDIA GPU offload where available.
Avoid enabling High Color Accuracy (4:4:4) unless users report color washout or font fuzziness. It increases bandwidth by roughly 5% on average and may force CPU-based decoding on weaker endpoints.
Avoid build-to-lossless (PNG) mode outside of use cases that truly require pixel-perfect reproduction (e.g., non-diagnostic medical imaging) as it meaningfully increases bandwidth.

Frame rate considerations

Blast defaults to a 30 FPS cap (EncoderMaxFPS), adjustable up to 60 FPS for gaming/high-motion workloads.

Testing found that reducing frame rate provides little to no bandwidth or CPU savings for typical productivity applications, because such workloads already generate very few frames per second.

Lowering frame rate is not an effective lever for WAN optimization and mainly serves to degrade multimedia playback.

Do not lower EncoderMaxFPS as a bandwidth-saving measure for office workloads as it will not meaningfully help and will harm any video content.
Only raise EncoderMaxFPS toward 60 for GPU-backed, motion-intensive use cases (CAD, gaming, video editing) where the extra bandwidth is available.

Recommended Blast settings by latency tier

For detailed guidance, see the Omnissa Blast Optimization Guide including the following sections on Tuning Blast for Wide Area Networks, Additional Optimizations for High Latency, and Additional Optimizations for Packet Loss.

Moderate latency (50–100 ms)

Keep UDP as transport (default).
Leave codec at default or test the Blast Codec for office workloads.
Set MaxBandwidthKbpsPerMegaPixelSlope to match available circuit capacity per concurrent user; leave MinBandwidthKbps at default (256) unless circuits are shared.
Enable Network QoS marking to protect Blast traffic from competing flows.

High latency (100–200 ms)

Use UDP unless a UDP-hostile device is in the path.
Reduce MaxBandwidthKbpsPerMegaPixelSlope toward the low end of the acceptable range to reduce the number of packets in flight.
Set MinBandwidthKbps to 128 (lowest supported) to avoid the protocol holding onto unnecessary reserved bandwidth.
Turn off non-essential services. Disable client drive redirection (FileTransferState = 0) and restrict clipboard direction if not required.
Use a single monitor at the lowest resolution the use case allows.

Very high latency (200 ms+, incl. satellite)

Switch to TCP once latency reaches or exceeds 250 ms. Testing shows TCP outperforms UDP at this threshold.
Set MinBandwidthKbps to 128 and cap MaxBandwidthKbpsPerMegaPixelSlope aggressively to minimize packets in flight.
Disable audio unless business critical. Rely on offloaded meeting audio (Teams/Zoom optimization) instead.
Disable clipboard and file transfer redirection.
Force single-monitor, reduced-resolution sessions. Avoid full-screen video.
Set expectations with end users. Some interactivity lag is unavoidable at this latency regardless of protocol. This is a physics limitation (speed of light / satellite round-trip), not a misconfiguration.

Network and bandwidth recommendations

Packet loss and jitter considerations

Sustained packet loss above 5% should be treated as a network fault to remediate with the circuit/network provider, not a Blast configuration issue. Blast can remain functional above 20% loss, but with a clearly degraded user experience.

UDP handles packet loss better than TCP in most tested conditions. Keep UDP unless latency greater than 250 ms or UDP-hostile-device exceptions apply.
Reducing overall bandwidth (via the settings above) reduces the number of packets exposed to loss and jitter, which is the primary lever available at the protocol level.

Jitter (variation in latency) is often more disruptive to interactivity than average latency itself. Prioritize QoS and buffer management on links with known jitter, and rule out local Wi-Fi contention as the source before engaging the WAN team.

Packet loss above single digits is very rarely something a display protocol can fully mask. Spending time tuning Blast settings without also engaging network/circuit teams on the underlying loss is a common wasted effort.

For more information, see the Additional Optimizations for Packet Loss section of the Omnissa Blast Optimization Guide.

QoS recommendations

Omnissa recommends implementing network Quality of Service (QoS) to prioritize Blast traffic above general-purpose traffic, but below the small number of applications that are even more latency-sensitive (normally Voice over IP).

Mark Blast traffic with Differentiated Services Code Point (DSCP) AF41 when it should sit one priority tier below VoIP.
Mark Blast with DSCP AF31 instead if the network also carries interactive video traffic that should be prioritized above Blast.
Apply QoS marking guidance from the Blast Policy Settings documentation and validate thoroughly in a pilot to confirm QoS changes do not adversely affect other business-critical traffic sharing the same circuit.

Without QoS, operations such as a large file copy, a Windows Update, or an unrelated bulk data transfer sharing the same WAN link can starve Blast of bandwidth at exactly the moment a user needs responsiveness.

QoS is one of the few controls that protects the experience even when the underlying circuit is not upgraded.

Bandwidth planning guidance

Use Case Profile	Planning guidance	Notes
Light office/productivity, single monitor, 1080p	Plan for the low end of MaxBandwidthKbpsPerMegaPixelSlope defaults per concurrent user	Lowest bandwidth footprint Blast Codec and JPG/PNG appropriate
Office + optimized Teams/Zoom conferencing	Add dedicated capacity for endpoint-to-cloud media (offloaded, not through the tunnel) separate from Blast capacity	Offloaded media bypasses the VDI network path but still needs local Internet capacity
Unoptimized conferencing (Real-time audio and video fallback)	Budget significantly more per-user bandwidth. Audio/video now traverses the VDI session twice (in and back out)	Treat as the worst case for bandwidth planning until optimization is confirmed working
Graphics-intensive (CAD, video editing, 4K)	Plan for up to 6x the bandwidth/CPU of an equivalent 1080p office workload Requires NVIDIA GPU offload	Not recommended over very-high-latency links regardless of bandwidth available

WAN optimization considerations

Traditional WAN optimization/acceleration appliances that rely on TCP manipulation, caching, or deduplication generally provide limited benefit to Blast, since its traffic is encrypted and, by default, UDP-based, real-time display traffic rather than bulk file transfer.

Favor direct, well-provisioned circuits with QoS over WAN acceleration hardware as the primary strategy for Blast. Use WAN optimization for other traffic types sharing the circuit instead.
Where feasible, place Unified Access Gateway or connection points to minimize the number of network hops and encryption/decryption boundaries between endpoint and datacenter, particularly for satellite or long-haul international connections.

Display and image quality settings

Recommended display resolutions

Resolution has an outsized effect on both bandwidth and desktop CPU. Testing found that the same workload at 4K (3840×2160) can consume up to six times the resources of 1920×1080, regardless of codec or protocol.

Network condition	Recommended resolution	Notes
LAN / low latency	Up to 4K if business need justifies it	GPU offload recommended above 1080p for video-heavy use
Moderate latency (50–100 ms)	1920×1080 (1080p)	Good balance of usability and bandwidth
High latency (100–200 ms)	1600×900 or 1366×768	Reduce further if multimedia-heavy
Very high latency (200 ms+)	1366×768 or lower, single monitor	Prioritize responsiveness over screen real estate

Resolution reduction is one of the highest-impact, lowest-effort levers available. Unlike codec or transport changes, it directly cuts the number of pixels that must be encoded, transmitted, and decoded on every frame.

Multi-monitor considerations

Each additional monitor multiplies bandwidth and CPU requirements roughly in proportion to its pixel count. Two 1080p monitors approach the resource cost of a single 4K display.

On constrained networks, standardize on single-monitor sessions unless the use case (e.g., trading floor, engineering) specifically requires more, and treat multi-monitor requests as an explicit bandwidth-planning exception.

Multi-monitor is one of the most common hidden causes of a user's poor experience.

The user reports “Horizon is slow” without realizing they are pushing 2–3x the pixels of a standard build.

Image quality vs. bandwidth trade-offs

Setting	Expected benefit	Trade-off
Lower JPEG quality floor (JpegQualityLow)	Faster initial screen paint on slow links	Visible blur/ blockiness during rapid changes before build-to-quality completes
Build-to-Lossless (EncoderBuildToPNG)	Pixel-perfect final image	Meaningfully higher bandwidth and desktop CPU. Avoid unless required (e.g., medical imaging)
High Color Accuracy (4:4:4)	Eliminates color washout / font fuzziness	~5% higher bandwidth May force CPU-based client decodes on unsupported GPUs
Higher MaxBandwidthKbpsPerMegaPixelSlope	Sharper image, better motion quality	Higher bandwidth consumption, particularly for video/gaming content

Recommendations for users experiencing poor performance

Confirm the session is using UDP (unless the greater than 250 ms exception applies) via Horizon Performance Tracker.
Confirm the correct codec is in use for the workload (Blast Codec or JPG/PNG for office use. H.264 or HEVC only for genuine multimedia use).
Reduce to a single monitor at a lower resolution as a first, fast diagnostic/mitigation step.
Ask the user to run any video content in a window instead of full screen.
Disable unnecessary redirected devices (webcams via USB redirection, unused printers) that may be consuming session bandwidth.
Escalate to the network team if packet loss exceeds 5% or latency exceeds 200 ms consistently. These are network problems, not settings problems.

Horizon Agent and GPO configuration

Most Blast tuning is applied via registry values to machines running the Horizon Agent. On Windows the main keys are in HKEY_LOCAL_MACHINE\SOFTWARE\Omnissa\Horizon\Blast\Config

The easiest way to apply and manage settings is by using the hzn_blast.admx Group Policy template which is available as part of the Omnissa Horizon Extras Bundle.

Import hzn_blast.admx and hzn_blast.adml into your Group Policy Central Store to manage Blast settings at scale.
Prefer Group Policy or a tool such as Omnissa Dynamic Environment Manager over manual per-image registry edits to keep settings consistent and auditable across pools.

Recommended group policy configurations for poor networks

Registry Value	Recommended change	Applies to
UdpEnabled	Leave = 1 (default) unless greater than 250 ms latency or UDP-hostile device	All WAN tiers except very-high-latency
MinBandwidthKbps	128 (minimum supported)	High and very high latency, low bandwidth
MaxBandwidthKbpsPerMegaPixelSlope	Reduce from default 6,200 to match available per-user bandwidth	All constrained-network tiers
H264maxQP	28 (higher starting quality, avoids wasted low-quality initial frames) if H.264 is used	Where H.264 is the active codec
FileTransferState	0 (disable client drive redirection) unless required	High and very-high latency
ClipboardState	0 or restrict to one direction if not required	High and very-high latency
AudioEnabled	0 unless business-critical and media optimization unavailable	Very-high latency
EncoderImageCacheSizeKB / DecoderImageCacheSizeKB	Increase from 256 to 512 (test first)	Bandwidth-constrained links; ~12% bandwidth savings observed in Omnissa testing

For more information see the Optimizing Blast Extreme section of the Omnissa Blast Optimization Guide.

Performance-focused policy recommendations

Prohibit desktop wallpaper/background images via Group Policy. This incurs unnecessary CPU and bandwidth overhead. Use a solid color background instead.
Run the Omnissa Windows OS Optimization Tool for Omnissa Horizon against golden images before any protocol-level tuning. Many performance escalations can be traced back to unoptimized OS images or undersized virtual desktops, not protocol settings.

Apply Network QoS DSCP marking for Blast traffic as a policy-level, not just endpoint-level, control.

Features that may negatively impact performance under high latency

Client Drive Redirection (file transfer) - Adds sustained background traffic so should be disabled unless required.
Build-to-Lossless mode - Significantly increases bandwidth and should only be enabled for use cases that truly require it.
High Color Accuracy (4:4:4) - Adds ~5% bandwidth and may force CPU decode on unsupported client GPUs.
NVIDIA GPU-encoded H.264/HEVC - Substantially increases session bandwidth due to higher achievable quality. This can complicate already constrained WAN links even though it reduces host CPU load.
Full-screen video playback without HTML5 Multimedia Redirection – Can consume up to 2x the bandwidth of the same content viewed in a window.
Unnecessary audio channels and USB redirection - Consumes bandwidth and, in the case of certain USB redirection, can silently disable Teams/Zoom/Webex native optimization.

Multimedia optimization

Real-time audio and video (RTAV) conferencing is one of the heaviest consumers of bandwidth and CPU in a VDI session and is the area most likely to suffer visibly in constrained networks unless offloaded.

Best Practices for media offloading and redirection

Prioritize enabling native VDI media optimization (Teams, Zoom) over RTAV wherever the platform and client versions support it.
Use HTML5 Multimedia Redirection for browser-based streaming content (YouTube, e-learning video) when no native optimization exists. Testing shows this can reduce desktop/RDSH CPU utilization by up to 60% and per-session bandwidth by up to 80%.
Be aware HTML5 Multimedia Redirection increases client-side CPU utilization (Omnissa observed up to 200% relative increase during redirection in testing) and can cause letterboxing of some content — test key applications before wide deployment.

Disable RTAV entirely for use cases where no conferencing is required, to remove the capability (and its potential misuse) from constrained sessions.
Encourage users to run resource-intensive multimedia content in a window rather than full-screen — Omnissa testing measured 53% less bandwidth and 23% less desktop CPU for a windowed YouTube video versus full-screen playback.

For more information see Configuring HTML5 Multimedia Redirection.

Impact of real-time audio/video on constrained networks

When media optimization is not available or not functioning, Horizon's RTAV feature captures the endpoint's webcam/microphone, sends it into the virtual desktop, and the desktop's Blast session then has to send the resulting video window back out to the client. This doubles the network trip for the same media stream.

Every unoptimized video call adds a sustained, latency-sensitive load on top of already-constrained circuits. On high-latency or low-bandwidth links this is frequently the single largest contributor to poor perceived performance, more so than the display protocol tuning itself.

Microsoft Teams optimization

Media Optimization for Microsoft Teams offloads audio, video, and screen-share processing to the local endpoint instead of routing it through the virtual desktop. The Horizon Client draws over the Teams window, so the experience still feels native, but media travels directly between the endpoint and the Teams service, avoiding RTAV altogether.

Media Optimization has been enabled by default since Horizon Agent 2212. Verify that it is active rather than assuming a legacy image still has it configured.
A newer, re-architected Teams VDI optimization (built on Teams' native media engine, replacing the legacy WebRTC-based approach) entered public preview for Omnissa Horizon in 2026. Confirm current support status and supported client/agent versions in the KB compatibility matrix before planning migration.

Without media offload, every Teams call's audio, video, and Blast screen updates all compete for the same constrained link. Offloading removes the largest and most latency-sensitive traffic class from the VDI network path entirely.

For more information, see Microsoft Teams Optimization with Horizon.

Zoom optimization

Zoom provides its own VDI client and plugin architecture (rather than relying on Horizon RTAV) that renders the Zoom meeting window locally and sends media directly from the endpoint to Zoom's cloud, bypassing the virtual desktop for the audio/video stream.

Install both the Zoom VDI meeting client (on the virtual desktop) and the matching Zoom VDI plugin (on the endpoint/thin client). Version mismatches are a common cause of calls silently falling back to unoptimized RTAV.
Do not redirect webcams via generic USB redirection when using the Zoom VDI plugin. This is a frequently reported misconfiguration that breaks the optimization for Zoom, Teams, and Webex alike and forces media back through the datacenter.

If USB redirection intercepts the camera, all optimized VDI plugins for Teams, Zoom, and Webex lose the ability to offload media and silently degrade to the least efficient path. This is exactly the failure mode you are trying to avoid on a constrained network.

Content redirection

HTML5 Multimedia Redirection and Teams/Zoom media optimization address video and conferencing content specifically. Two additional Horizon redirection features address general web/SaaS content and are worth evaluating on bandwidth or latency-constrained pools where users spend significant time in browser-based applications.

URL Content Redirection

URL Content Redirection hands off a specific URL entirely, not just a rendered view of it, between the client and the remote session, based on the protocol (HTTP, HTTPS, mailto, callto, and others) and administrator-defined rules.

Agent-to-client redirection - Horizon Agent sends the URL to Horizon Client, which opens it in the default local application on the endpoint instead of inside the remote session.
Client-to-agent redirection - Horizon Client opens the URL inside a specified remote desktop or application instead of locally.

Requires the Horizon URL Content Redirection Helper browser extension (available for Chrome, Edge, and Firefox) installed on the endpoint, plus matching agent-side configuration.
Best candidates for agent-to-client redirection: line-of-business web portals, mail links, and SaaS URLs that don't strictly need to run inside the managed desktop image.
Because this is a full handoff rather than a rendering optimization, redirected content generates zero Blast display traffic for that URL. This is the largest possible bandwidth saving of any redirection feature covered in this guide.

Unlike HTML5 Multimedia Redirection or Browser Content Redirection, which still render content and stream it as Blast traffic (just more efficiently), URL Content Redirection removes the content from the remote session's network path altogether.

On very constrained links, this is the single most effective redirection technique available. It also means the content now runs outside the managed/monitored desktop environment so URL allow-lists should be reviewed with security stakeholders before broad deployment.

For more information, see the following documentation:

Browser Content Redirection

Browser Content Redirection renders approved web pages on the client endpoint device instead of the agent, then overlays that client-rendered content onto the corresponding browser window inside the remote session. This is similar in concept to HTML5 Multimedia Redirection but applied to whole pages on an administrator-defined allow-list rather than just embedded video/audio elements.

Avoids server-side fetch and hairpinning. The client fetches and renders the page directly rather than the virtual desktop fetching it, sending it out to the internet, and then re-encoding the rendered result back to the client device over Blast.
Best candidates are heavy, frequently used SaaS applications (CRM, ITSM, HR portals, O365 web apps) where users spend extended periods, as opposed to occasional one-off links better suited to full URL Content Redirection handoff.
Unlike URL Content Redirection, the page still appears to run inside the virtual desktop session from the user's perspective. This is useful where policy requires content to remain visually and contextually part of the corporate desktop.

Browser Content Redirection targets a gap that HTML5 Multimedia Redirection and URL Content Redirection do not fully cover bandwidth-heavy general web content that is not a discrete video element (HTML5 Multimedia Redirection target) and does not warrant a full handoff out of the session (URL Content Redirection's approach).

For SaaS-heavy desktops on constrained links, piloting Browser Content Redirection on the highest-traffic internal sites is often the best return on effort after HTLM5 Multimedia Redirection and conferencing optimization are already in place

This is supported in Chrome and Edge via a Horizon browser extension, paired with agent-side and Group Policy configuration identifying which URLs qualify for redirection.

For more information, see the following documentation:

USB Redirection

Disable USB redirection by default unless there’s a specific business need (security-token dongles, specialized peripherals). USB redirection has real-time bandwidth and latency sensitivity that suffers badly on a 200ms+ WAN link and is a common source of “USB device disconnects/reconnects” complaints on high-latency connections.

Client Drive Redirection and clipboard

Disable Client Drive Redirection unless it is required by the use case. If used, consider limiting it to download-only or upload-only depending on the workflow.

Keep the clipboard functional as required for each use case. Consider limiting directionality (client to agent, agent to client, or both).

Printing

Use a redirected/virtual printing solution designed for VDI (rather than full local printer driver installs in the virtual desktop) to avoid it becoming a bandwidth or stability issue.

Recommended approach by latency tier

Latency tier	Recommendation
Moderate (50–100 ms)	Evaluate Browser Content Redirection for the top 3–5 highest-traffic internal SaaS sites URL Content Redirection is optional for convenience/security segmentation rather than bandwidth necessity
High (100–200 ms)	Prioritize Browser Content Redirection for heavy SaaS use Use URL Content Redirection for any URL that does not strictly need to run inside the managed session
Very high (200 ms+)	Prefer URL Content Redirection wherever policy allows. It removes redirected content from the Blast path entirely, which matters most at this tier Use Browser Content Redirection only for content that must remain inside the session

Configuration notes and common pitfalls

Both URL Content Redirection and Browser Content Redirection require the matching browser extension to be installed and enabled on the endpoint. If the extension is missing or disabled, the content silently renders through the normal (unoptimized) remote session path with no error to the user.
Allow-lists/URL rules must be maintained deliberately. An overly broad URL Content Redirection rule set can inadvertently move business content outside the managed desktop's security controls (DLP, browser isolation, logging).
Test both features with the specific Horizon Agent and Horizon Client versions in use. Supported browsers and minimum version requirements have changed across Horizon releases and should be confirmed against current Omnissa documentation before rollout.

Client device considerations

Offload protocol decoding to endpoint GPU

Favor endpoint devices manufactured from 2013 or later as these typically offer near-universal H.264 GPU decode support, and from 2015 or later for H.265/HEVC decode support. This offloads the decoding of the Blast traffic to the GPU in the endpoint device and avoids using the endpoint CPU for decoding Blast.

Requirements:

Local GPU: A graphics card (Intel, NVIDIA, or AMD) with hardware decode capabilities for the target codec.
Horizon Client: A modern version supporting H.264, HEVC, or AV1 hardware offload.
Horizon Agent settings: Horizon Agent on the host must permit the matching hardware encode format

By default, the Horizon Client should have the options already selected to use hardware decoding (if the appropriate hardware is available in the client device). You can check and change the configuration.

Open the Horizon Client on your local device before or during an active session.
Go to Settings, Preferences, or the Gear symbol (depending on the OS)
Select the option for Horizon Blast.
Check the boxes to enable the desired hardware decoders. The options available will depend on the device OS version.
1. Allow H.264 decoding (enabled by default on most supported hardware)
2. Allow High Efficiency Video Decoding (HEVC)
3. Allow AV1 decoding (if supported by both client and agent GPUs)
Uncheck or adjust options like High-definition color if the specific local GPU struggles with high-color-bitrate hardware decoding or if bandwidth is constrained.
Restart the remote session to force codec negotiation and switch decoding from the CPU to the local GPU.

Redirect content

Use redirection features, such as Multimedia optimization, URL Content Redirection, or Browser Content Redirection. Ensure that the endpoint CPUs have adequate headroom for local processing of the redirected content.

Horizon Client best practices

Keep the Horizon Client updated to a version aligned with the Horizon Agent version in use. Codec and optimization features (Blast Codec, HDR, Teams/Zoom optimization) frequently require matched minimum client and agent versions.

Select Blast explicitly in the client connection properties if the pool allows a protocol choice. Only configure the codec options appropriate to the workload.

For work-from-home/home-to-cloud use, treat the connection as a medium-to-high-speed WAN, not a LAN. Most residential circuits do not provide gigabit-class, symmetric, low-jitter connectivity. For more information see Guidance for Work-from-Home and Home-Office-to-Cloud Use Cases.

Local network recommendations

Eliminate Wi-Fi congestion at the access-point level (channel overlap, excessive client counts) before assuming a Blast or WAN problem is at fault. Local network issues are among the most common root causes misdiagnosed as “Horizon is slow.”

Verify local router/firewall QoS is not deprioritizing UDP traffic, and no local device is performing deep packet inspection that adds latency to Blast traffic flows.

Wi-Fi vs. wired connectivity

Factor	Wired ethernet	Wi-Fi
Latency consistency	Very stable	Variable and can be affected by interference, distance, contention
Packet loss risk	Low under normal conditions	Higher, especially on congested/overlapping channels
Recommendation	Preferred for latency-sensitive or multimedia-heavy roles	Acceptable for typical productivity if 5 GHz/Wi-Fi 6 with good signal Avoid for demanding graphics or conferencing-heavy roles

Jitter introduced by Wi-Fi contention is frequently indistinguishable, from the end user's point of view, from WAN-induced jitter but it is fixed very differently (access-point tuning vs. circuit/QoS changes).

Diagnosing which one is at fault first saves significant troubleshooting time.

Endpoint troubleshooting guidance

Use the Horizon Performance Tracker (installable with Horizon Agent) to confirm transport (TCP/UDP), codec in use, frame rate, and estimated bandwidth/latency for the live session.
If Performance Tracker is unavailable, review Blast-Worker-SessionId<#>.log under %ProgramData%\Omnissa\Horizon\logs on the agent for transport and codec confirmation.
Rule out local Wi-Fi/LAN issues before escalating to the WAN/network team.
Confirm no conflicting USB redirection is intercepting webcams/microphones intended for optimized conferencing.
Capture a simple ping/traceroute (or equivalent) from endpoint to the Unified Access Gateway/Connection Server to independently corroborate latency and loss reported by Performance Tracker.

Summary and additional resources

References and documentation

What Is Horizon 8? - https://techzone.omnissa.com/resource/what-horizon-8
What is Horizon Cloud - https://techzone.omnissa.com/resource/what-horizon-cloud
Omnissa Blast Optimization Guide - https://techzone.omnissa.com/resource/omnissa-blast-extreme-optimization-guide
Omnissa Horizon Blast Display Protocol - https://techzone.omnissa.com/resource/omnissa-horizon-blast-extreme-display-protocol
Omnissa Blast Policy Settings - https://docs.omnissa.com/bundle/Horizon-Remote-Desktop-FeaturesV2603/page/BlastPolicySettings.html
Configuring HTML5 Multimedia Redirection - https://docs.omnissa.com/bundle/Horizon-Remote-Desktop-FeaturesV2603/page/ConfiguringHTML5MultimediaRedirection.html
Configuring URL Content Redirection - https://docs.omnissa.com/bundle/Horizon-Remote-Desktop-FeaturesV2603/page/ConfiguringURLContentRedirection.html
Install and Configure Browser Content Redirection - https://docs.omnissa.com/bundle/Horizon-Remote-Desktop-FeaturesV2603/page/InstallandConfigureBrowserContentRedirection.html
Using Horizon Performance Tracker - https://docs.omnissa.com/bundle/Horizon-AdministrationV2603/page/UsingHorizonPerformanceTracker.html
Microsoft Teams Optimization with Horizon - https://techzone.omnissa.com/resource/microsoft-teams-optimization-horizon

Changelog

The following updates were made to this guide:

Date	Description of changes
2026/08/12	Initial version published.

About the author and contributors

Graeme Gordon, Sr. Staff Architect, Omnissa.

Feedback

Your feedback is valuable.

To comment on this paper, contact us at tech_content_feedback@omnissa.com.