Omnissa Horizon (on-prem)

The on-prem version of Omnissa Horizon runs in an organization’s own data center or private cloud. This allows enterprises to centralize control of virtual desktops while leveraging their existing infrastructure investments. It is commonly used by organizations that want full control over their VDI environment, data, and compliance, while maintaining flexibility in how virtual desktops are provisioned and managed.

1

Set up the connector

Configure Nexthink to connect to Omnissa Horizon APIs for session metadata ingestion. This step ensures that contextual data is available to enrich insights within the VDI Experience module.

To set up the connector, perform the procedure described in .

2

Install Collector on VMs

Manual or automated deployment

  • Shared VDI: Install Collector on Horizon multi-session hosts. Ensure that session hosts are domain-joined and provisioned with appropriate sizing.

  • Personal VDI (persistent): Install Collector as a standard agent during provisioning or onboarding of the persistent desktop.

For both scenarios, perform the procedures described in the following documentations:

Golden image-based deployment

Pooled VDIs (non-persistent) use a golden image for deployment.

Perform the procedures described in the following documentations:

3

Test the connector and Collector

Connector

Confirm that device and session data is being enriched with information from the connector integration by verifying fields such as:

  • Disk Image

  • Desktop Pool

  • Virtualization Host Name

  • Virtualization Type

To test enrichment, ensure that Collector is installed on the VMs and is operational, and run the following query:

devices
| where virtualization.desktop_broker == horizon_on_prem
| list name, hardware.type, virtualization.disk_image, virtualization.desktop_pool, virtualization.environment_name, virtualization.hypervisor_name,  virtualization.hostname, virtualization.type, virtualization.last_update
| sort virtualization.last_update desc

For more information about running queries, see the Investigations documentation.

Collector on VMs

If needed, contact Nexthink support or your Nexthink representative.

Shared VDI

Ensure data such as the following are visible in Nexthink:

  • Device ID

  • User Name

  • Session Hostname

To check this, run the following query:

vdi_sessions
| where device.virtualization.desktop_broker == horizon_on_prem and vdi_session.virtualization_type == shared
| list vdi_session.name, user.name, device.name, vdi_session.hostname, desktop_pool, first_seen
| sort first_seen desc

Pooled VDI (non-persistent)

Confirm that instances report the following after deployment:

  • Unique Device IDs

  • Accurate Pool Names

  • Fresh Boot Times

To check this, run the following query:

devices
| where virtualization.desktop_broker == horizon_on_prem and virtualization.type == pooled
| list name, virtualization.desktop_pool, boot.last_full_boot_time
| sort boot.last_full_boot_time desc

Personal VDI (persistent)

Verify the consistent reporting of the following:

  • Device ID and Assigned User

  • System uptime across Reboots and Logons

To check this, run the following query:

devices
| where virtualization.desktop_broker == horizon_on_prem and virtualization.type == personal
| with session.vdi_events during past 168h
| compute number_of_sessions = vdi_session.count(), time_since_session_last_seen = end_time.last().time_elapsed(), last_user = user.name.last()
| include device_performance.boots during past 168h
| compute number_of_restarts = number_of_boots.sum()
| include session.logins during past 168h
| compute time_since_last_login = time.last().time_elapsed(), number_of_logons = number_of_logins.sum()
| list name, last_user, number_of_sessions, time_since_session_last_seen, number_of_logons, time_since_last_login, number_of_restarts, boot.last_full_boot_time.time_elapsed(), last_seen.time_elapsed()
| sort time_since_session_last_seen desc

Last updated

Was this helpful?