How to Enable DEX (Experience Management) for Omnissa Horizon - Step by Step

In the era of modern distributed work, understanding user experience within virtual desktop infrastructure (VDI) is no longer a luxury - it’s an operational necessity. Omnissa Horizon, coupled with Workspace ONE Experience Management (DEX), gives IT administrators full visibility into VDI performance, from login latencies to application behavior.

If you are looking to tap into these rich analytics, here is your definitive, step-by-step guide to enabling and validating DEX for your Omnissa Horizon environment.

Step 1: Verify Prerequisites & Licensing

Before writing a single line of code or deploying appliances, you must ensure your environment is properly licensed. DEX for Horizon requires a cloud-connected control plane and specific licensing tiers.

• Supported Core License: You must hold an active Horizon Universal Subscription or Horizon Apps Universal Subscription.
• The DEX Add-on: Experience Management features require the Workspace ONE Experience Management for Horizon add-on SKU (or an active Workspace ONE Intelligence Premium Trial activated within your tenant).
• Control Plane: Your on-premises or cloud Horizon pods must be connected to the modern Omnissa Horizon Cloud Service Control Plane.

You can check your license on Horizon Cloud or Omnissa Connect:

Step 2: Deploy & Configure the Horizon Edge Gateway

The Horizon Edge Gateway acts as the crucial bridge between your local Horizon 8 Pods and the cloud-hosted Omnissa Intelligence data lake.

1. Log into your Horizon Universal Console and download the Horizon Edge Gateway OVA template.
2. Deploy the OVA appliance into your vSphere environment (note that it should sit on an internal network segment, not a public DMZ).
3. Pair the Edge Gateway with your Horizon Connection Servers.
4. Critical Step: During or immediately following configuration, ensure that you explicitly enable the Monitoring Option (Horizon Advanced Telemetry). This allows the gateway to capture and forward session metrics.

Step 3: Activate VDI Monitoring in Omnissa Intelligence

With the Edge Gateway operational, you must now instruct the cloud ecosystem to listen for the incoming data stream.

1. Navigate to the Omnissa Intelligence Console.
2. Go to Marketplace > Solutions > Experience Management.
3. Locate the Virtual Desktop & Apps tile and click Set Up.
4. Authorize Horizon Cloud Services as a valid data source and flip the toggle to Enable Monitoring for VDI.

Step 4: Validate Port 31883 & Troubleshoot Agent Monitoring

The internal telemetry architecture relies on local desktop services communicating directly back to your Edge Gateway and Workspace ONE Intelligence Endpoints (The endpoints will be aligned with the region in which your tenant is hosted.

• The Network Requirements:
1. Ensure your VDI desktops/RDSH hosts can communicate with the Horizon Edge Gateway over Port 31883.
2. Ensure your VDI desktops/RDSH hosts can communicate with the Workspace ONE Intelligence endpoints and necessary CRLs.
   

        For example:

            edge-gateway.domain.local:31883

            https://eventproxy.eu1.data.workspaceone.com

            https://auth.eu1.data.workspaceone.com

            http://crl.r2m02.amazontrust.com/r2m02.crl

• Troubleshooting Connection Failures: If data isn’t flowing:

1. log directly into the affected virtual desktop and open the Horizon Agent Monitor Service log located at: C:\ProgramData\Omnissa\Horizon\logs\horizon-hzAgentMonService-<replace_with_timestamp>.log
   What to look for: Search the text log for the string "ssl:" or handshake errors to determine if a certificate mismatch or something else is causing an obstacle.
2. On the same desktop you are testing, you can also use the connectivity validation script available at the following link:  https://cameronfore.com/Powershell/Horizon%20DEX%20Validation.ps1

Step 5: Check the Horizon Operations View Dashboard

Before proceeding to endpoint agent installations, confirm that the infrastructure components are talking to each other.

1. In the Omnissa Intelligence Console, navigate to your Dashboards.
2. Open the Horizon Operations View Dashboard.
3. Verify that fundamental infrastructure data- such as Connection Server health, active session counts, and basic pod statistics is successfully populating. If this dashboard is blank, re-verify Steps 2 through 4.

Step 6: Install the DEX Telemetry Agent on Desktops/RDSH

To pull deep "inside-the-guest" operating system and application performance metrics, you must deploy the DEX Telemetry Agent (Workspace ONE Experience Management Agent) directly to your virtual machines.

• Persistent Desktops: Deploy the agent directly to the target endpoints via Workspace ONE UEM or your software deployment tool of choice.
• Non-Persistent Desktops / RDSH: Install the agent directly onto your Gold Image / Master Image before sealing and recomposing/publishing the pool.

When installing, you must use the specific CLI installation syntax tailored for a Horizon environment so the agent knows how to route telemetry payload properly:

Omnissa-Telemetry-Agent-x86_64-<Replace>.exe /v INTEGRATION=HorizonAgent MANAGEMENT_MODE=Horizon

To confirm that the agent was installed correctly, review the following registry key:

"Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WorkspaceONE\Endpoint Telemetry\DEEM"

Step 7: Verify dynamic_config.json Creation

Once the installer completes its routing logic, the agent needs a brief moment to download its cloud-assigned policy configuration.

1. Wait roughly 30 to 60 seconds after installation.
2. On the virtual machine, navigate to the following hidden path: C:\ProgramData\WorkspaceONE\ws1etlm\config\lastKnownConfig\HorizonForwarder
3. Verify that a file named dynamic_config.json has been successfully generated inside this directory.

Step 8: Confirm the DEEM JSON Payload

Simply having the file isn't enough; we need to guarantee that the Digital Employee Experience Management (DEEM) module is actively flagged to "true."

1. Open the dynamic_config.json file using a text editor (like Notepad).
2. Scan the JSON structure or run a quick search to ensure it contains exactly this configuration line:

{"deem_enabled":{"enabled":true}}

Step 9: Use Data Explorer for Real-Time Telemetry Validation

Now it's time to run an end-to-end sanity check to guarantee telemetry data from the endpoint has safely arrived in your tenant workspace.

1. Go to Omnissa Intelligence > Analytics > Data Explorer.
2. Create a new query or filter by selecting your data source.
3. Drill down to Employee Experience > App Performance (Horizon) (or a similar session metric category).
4. Click Run. If your configuration is correct, you will immediately see recent line-item records populating the preview grid from your tested VDI machines.

Step 10: Wait for Experience Score Population

You’ve completed the heavy lifting! However, calculating overall experience scores requires a data aggregation baseline.

Patience is a virtue: Expect a buffer window of about 4 hours before the high-level Digital Employee Experience Scores and historical trend baselines begin fully compiling on your main Intelligence dashboards.

Conclusion

By bridging your Horizon Edge infrastructure with the intelligence capabilities of Workspace ONE Experience Management, you transition from reactive troubleshooting to proactive optimization. You now have the metrics required to address micro-stutters, application crashes, and network bottle-necks before your users ever open a support ticket.

Advanced Troubleshooting Considerations

While the onboarding process is usually straightforward, there are several common issues that can prevent Horizon Edge Gateway and DEX Experience Management from functioning correctly.

1. Use a Specific Connection Server FQDN Instead of a VIP
   
   When configuring the Connection Server details under the Horizon Cloud Console Edge configuration, avoid using a load balancer VIP address. Instead, specify the fully qualified domain name (FQDN) of a single Horizon Connection Server.
   
   
   
   
   This recommendation aligns with the Horizon Edge Gateway design. During the pairing process, the Edge Gateway establishes communication with a primary Connection Server and automatically discovers the remaining Connection Servers in the pod. As documented by Omnissa:
   
   "If you leverage multiple Horizon Connection Servers in your Horizon pod, you only need to provide details for the primary Horizon Connection Server. The Horizon Edge Gateway Appliance
   will find the other Horizon Connection Servers automatically."
   
   For reference - https://techzone.omnissa.com/resource/deploying-horizon-edge-gateway#connect-to-the-horizon-connection-server
   
   
   
2. Proxy and SSL Inspection Considerations
   
   The Horizon Edge Gateway supports outbound proxy configurations; however, SSL inspection (SSL deep packet inspection) is not supported for the required Horizon Cloud and Edge Gateway communication endpoints. Omnissa specifically recommends bypassing SSL inspection for the required Edge Gateway destinations.
   
   Reference: https://kb.omnissa.com/s/article/6000749
   
   If your organization uses an outbound proxy, verify that:
   
   
• The Horizon Edge Gateway can reach all required Horizon Cloud and Workspace ONE Intelligence endpoints.
  
  
• SSL inspection is bypassed for the required Horizon Cloud URLs.
  Any required regional DEX/Workspace ONE Intelligence URLs are reachable without SSL interception.
  
  
• For the Horizon virtual desktops themselves, an outbound proxy with SSL inspection is generally supported. However, the desktops must still be able to:
  
  
• Communicate with the Horizon Edge Gateway on TCP port 31883.
  Reach the Workspace ONE Intelligence endpoints associated with the region hosting your tenant.
  
  When troubleshooting proxy-related problems, reviewing the Edge Gateway diagnostics can quickly reveal blocked URLs or SSL inspection issues.
  
  Reference: https://kb.omnissa.com/s/article/6000749
  
  
  
3. Verify JMS Connectivity Between Edge Gateway and Connection Server
   
   A frequently overlooked requirement is JMS communication between the Horizon Edge Gateway and the Horizon Connection Server. Ensure that the Edge Gateway can communicate with the Connection Server over TCP port 4002. Network firewalls, security appliances, or routing restrictions that block this traffic can prevent successful integration and data flow.
   
   If connectivity appears healthy but issues persist, collect an Edge Gateway log bundle for further analysis. Omnissa provides a built-in log collection utility and troubleshooting workflow for this purpose.
   Reference: https://kb.omnissa.com/s/article/92056
   After extracting the log bundle, review the file:
   

   "agent-module-deployment-<replace>.txt

   This file often contains valuable information related to agent deployment status, connectivity validation, and communication failures between components.
   
   For additional troubleshooting guidance and log bundle collection procedures, refer to the Omnissa knowledge base article on Horizon Edge connectivity troubleshooting mentioned previously.
   

I hope you found this guide helpful! If you have any questions or want to share your experience with the rollout, please feel free to connect or reach out to me on LinkedIn.