VDI Experience FAQ

Are there separate hardware requirements for Collector with the VDI extension enabled?

Since there is only one Collector, which is the same for VDI and non-VDI scenarios, the same hardware requirements and resource usage apply. The VDI capability of Collector comes from enabling the following parameter: DEPLOY_VDI_CLIENT_PLUGIN=1

Can I install the VDI Client Extension on a device that already has Collector installed?

There is no need to install Collector and the extension on the same device. If you can install Collector on it, do so with the VDI parameter enabled: DEPLOY_VDI_CLIENT_PLUGIN=1

However, if you want to use the Nexthink VDI Client Extension, a lightweight agent, instead of the full range of capabilities Collector offers, you have to uninstall Collector first and then install the extension.

If Collector is already deployed at a customer site, do I have to redeploy it for VDI completely?

Yes, you must redeploy Collector with the extra parameter DEPLOY_VDI_CLIENT_PLUGIN=1. Currently, you cannot apply this parameter retroactively to already deployed Collectors.

What new NQL data model fields does VDI Experience provide compared to the combined metrics from session.events and device_performance.events ?

VDI Experience provides the following unique metrics:

• client_app_version

• client_device_name

• client_os_platform

• client_vdi_plugin_version

• cpu_context_switches

• framerate

• ica_input_bandwidth_available

• ica_input_bandwidth_used

• ica_input_session_bandwidth

• ica_input_session_linespeed

• ica_output_bandwidth_available

• ica_output_bandwidth_used

• ica_output_session_bandwidth

• ica_output_session_linespeed

• idle_duration

• initial_program

• last_interaction_time

• logon_server

• memory_available

• memory_pages_out

• memory_usage

• network_incoming_errors

• network_incoming_packets

• network_incoming_throughput

• network_outgoing_errors

• network_outgoing_packets

• network_outgoing_throughput

• network_wan_latency

• network_wired_link_speed

• rdp_frame_quality

• rdp_frames_skipped_client

• rdp_frames_skipped_network

• rdp_frames_skipped_server

• rdp_send_rate

• rdp_tcp_bandwidth

• rdp_tcp_receive_rate

• rdp_tcp_send_rate

• rdp_udp_bandwidth

• rdp_udp_receive_rate

• resolution

• session_state

• system_drive_name

• system_drive_read_throughput

• system_drive_write_throughput

• system_volume_usage

• transport_protocol

• user_input_delay

• vm_agent_version

Where does the value of CPU -> Normalized queue length come from?

It shows the total queue length divided by the number of CPU cores. A CPU queue length higher than 2 per CPU core indicates a problem.

Is it possible to set the Collector VDI parameter DEPLOY_VDI_CLIENT_PLUGIN=1 using the silent installer?

At the moment, the parameter can only be set using the MSI, which has a silent option for mass deployments. See the #installingcollectoronwindows-prerequisites-7documentation to learn how to use the silent installer.

What is the recommended way to deploy Collector in a large-scale, hybrid environment with thousands of endpoints when some endpoints are not connecting to VDI? Is it safe to deploy Collector with the VDI parameter enabled on these endpoints as well?

The best practice is to enable the parameter only on devices that will use it. However, the VDI extension does not consume any resources unless a VDI remote client application connects to a compatible VDI environment and loads it.

Currently, Omnissa Horizon is not supported. A prerequisite for using VDI Experience is to obtain enriching context data through connectors. Is there a way to manually populate these fields, for example, through an API or other means, to use VDI Experience?

Supporting Omnissa Horizon has two main components:

• Data enrichment through an API adds details about the VDI environment’s topology, such as virtualization hosts and desktop pools.

• The VDI Experience Dashboard requires Collector support for Horizon to provide high-granularity performance metrics.

Although these features are not yet available, both are necessary for VDI Experience and will be supported in a future release.

If I have Citrix and Omnissa and I enable VDI Experience, will Collector automatically start improved session data collection for every VDI desktop (hardware type = virtual)? In the case of Omnissa, there is no connector and no protocol information yet.

Collector does not "know" about the environment. It checks if the VM it is running on has a Citrix or AVD/CPC agent. If yes, it knows the list of metrics it can query with high granularity. Collector does not know the Omnissa metrics, therefore it will not try looking for an Omnissa agent. You will see the new events being populated for their Citrix VMs and only the legacy events for Omnissa.

If I use Citrix DaaS to manage virtual desktops running on AVD, should I also configure the AVD connector?

No, all the information VDI Experience needs is available through the Citrix DaaS connector.

Can I still monitor the contractor endpoint if I have Collector from another environment?

Example scenario

There is a contractor with company A using a persistent desktop from company B. The contractor is complaining about slowness while their laptops are connected to company A.

This scenario is fully supported and will respect the privacy of the user and the involved customers.

• Collector will keep sending all data to company A.

• Company B will only see the name of the device, but it will not be present in company B's device inventory, and the system does not send or display details in Device View or other dashboards.

• The Extension recognizes to which VDI environment the remote client application is connected.

  • When connected to company A's VDI (assuming the company also uses VDI Experience), the client will complement the VDI performance metrics with additional context.

  • When connected to company B's VDI environment, the Extension will similarly expand the VDI performance metrics otherwise reported by Collectors running on company B's VMs.

  • This additional context in both cases is limited to

    • The time period while the client is connected to the specific VDI environment

    • Only includes overall device-level CPU, memory, and network usage data. No process or user-level insights will be available, and no sensitive information, only performance metrics.