VMware vRealize Operations for Horizon 6.4 Release
vRealize Operations for Horizon 6.4 | 08
Last Document Update: 08 DEC 2016
Check frequently for additions and updates
to these release notes.
These release notes include the following topics:
VMware vRealize™ Operations for Horizon™ extends
the functionality of VMware vRealize™ Operations
Manager™ to monitor and manage VMware Horizon™
vRealize Operations for Horizon collects data about
your resources and presents that data in
preconfigured dashboards for both real-time and
What's New in This Release
vRealize Operations for Horizon 6.4 includes the
following new features.
- Access Point Monitoring - VMware vRealize
Operations for Horizon now includes optional
Access Point monitoring. With this feature, you
can see the status of multiple Access Points,
including blast and PCoIP session counts, usage
percentage (i.e., the percentage of the maximum
number of sessions actually used), IP addresses,
and collection status. You can also use this
feature to get details about the Access Point
(e.g., health and active alerts).
Additionally, you can also configure alert
thresholds for session usage. Access Point
releases 2.6, 2.7, and 2.7.2 are supported in this
- Application Crash Alerts - vRealize
Operations for Horizon now enables you to monitor
events when an application launched inside a
session crashes. The crash alert summary is
shown on the alerts page. Click the link for
the alert to see details of the crash, including
cause and recommended action.
- App Volumes Monitoring - VMware vRealize
Operations for Horizon now includes optional App
Volumes monitoring. With this feature, you can see
which App Stacks are attached to sessions and
users and view their attach times. Additionally,
by viewing objects related to sessions and users,
you can see associated stacks and discern, for
example, which App Volumes Manager controls a
stack, or which AD is associated with it.
Additionally, a new Horizon App Volumes
Environment item on the Environment Overview lets
you view summary information and metrics for App
Volumes servers and App Stacks.
App Volumes releases 2.10 and 2.11 are supported in
- New Root Cause Dashboard - VMware
vRealize Operations for Horizon now includes a
Root Cause Analysis Dashboard. Reachable
from the Horizon Help Desk and Horizon End User
dashboards, it provides metrics for objects
associated with sessions, and uses colors (green,
yellow, and red) to indicate metrics that may
require troubleshooting. Additionally,
clicking on a metric displays it in a chart view
that shows the given metric over time, enabling
- New Widgets - VMware vRealize Operations
for Horizon includes the following new widgets:
- Desktop Applications: Available on the
Horizon VDI Pools Dashboard, this widget
displays a list of all the configured
applications hosted by a VDI desktop.
- Desktop Application Users: Available on
the Horizon VDI Pools Dashboard, this widget
displays a history of user logon information for
a selected application, indicating who uses the
application, and when the application is used.
- Desktop Applications Launched by User:
Available on the Horizon User Session Details
Dashboard, this widget displays when and which
application hosted by a VDI desktop was launched
by the selected user in a selected time period.
Host: Available on the Horizon Help
Desk Dashboard, this widget displays the
ESXi host of the related VM that is hosting
Metrics: Available on the Horizon Help
Desk Dashboard, this widget displays metrics
of a selected host.
to Use the Help Desk Dashboard and How to
Use the Horizon End User Experience widgets.
- New Reports - VMware vRealize Operations
for Horizon includes the following new reports for
- Horizon Application Instance Usage
Report: includes information about CPU and
memory usage of an application instance.
- Horizon Desktop Application Instance Usage
Report: includes information about CPU and
memory usage of a desktop application instance.
- Horizon Desktop Application Usage
Report: includes information about desktop
- Cloud Pod Architecture Support - VMware
vRealize Operations for Horizon 6.4 includes
several changes related to Cloud Pod Architecture
- Two new monitoring objects, View Pod
Federation and View Pod Health, have been added,
enabling you to view pod federations in
hierarchies and to see the health of pods.
- A new column, "Pod Name," has been added to
the Horizons Connected Sessions widget (visible
in the Horizon Help Desk Dashboard).
- A new, pod-related alert has been added.
When any pod in a pod federation goes down, a
“Failed to communicate with target pod” alert
appears for other pods in the federation.
Clicking on this alert (which can be found by
searching for the alert from the Alerts tab)
shows which connection to a target pod is
affected. Note that when connectivity is
reestablished, the alert status changes from
Active to Inactive.
- Support for Windows Server 2016 as
an RDS host for Horizon 7.0.2 - Both
Datacenter and Standard editions of Windows Server 2016 are supported.
vRealize Operations for Horizon has the following
- The RMI registry port 3091 is reused in
vRealize Operations for Horizon 6.4 adapter.
The communications ports are 3099, 3100, and 3101
for the Horizon 6.4 message server. The message
server objects for Horizon 6.x and 7.x
are registered to this port.
- Physical desktops in a pool are not
Physical desktops included in a desktop pool are
not monitored or shown in the user interface.
However, physical RDS hosts are monitored and
shown in the user interface.
- High availability (HA) is not supported
Operations for Horizon 6.x does
not support high
(HA). If a View Adapter
instance is moved to a different
cluster node, the broker and desktop
agents can no longer communicate with the View
Adapter and the vRealize Operations for Horizon
solution stops functioning. For solutions to this
problem, see KB: 2092874: Best practices for
configuring vRealize Operations for Horizon when
HA is enabled.
- You should wait sometime after the adapter
service is restarted. Otherwise the adapter might
not get started.
- Make sure the vRealize Operations Manager does
not have multiple network cards for multiple sub
networks. It might make adapter instance bind to
incorrect IP address.
- The adapter configuration file /usr/lib/vmware-vcops/user/plugins/inbound/V4V_adapter3/conf/msgserver.properties
should be updated at the same time.
- The Broker Agent 6.1 and Desktop Agent 6.1
cannot communicate with Adapter 6.4 even if pairing is
successful because TLS 1.0 is disabled by default.
A hand shake exception is thrown.
- The configuration file of old adapter instance
is not purged during upgrade. Therefore, if other
SSL protocol/ciphers is configured on the adapter
side, the broker and desktop agent might cause a
hand shake failure. Configure some protocol and
ciphers on adapter and agents.
- The adapter can run on the collector node. It
cannot run on the data node or the replica node.
- When the primary controller (broker) fails,
administrators must manually configure and enable
the broker agent at the back-up controller
Top of Page
This section contains notes on the licensing of
vRealize Operations for Horizon
- To run vRealize Operations for Horizon,
customers need to enter two keys.
- A single vRealize Operations Manager license
- A 10-pack or 100-pack vRealize Operations
Manager license key that monitors your desktop
- The VMs must be part of the appropriate
licensing groups in order to ensure accurate
licensing. For detailed licensing
instructions, see Adding a vRealize
Operations for Horizon License Key and
Associate Horizon Objects with Your
vRealize Operations for Horizon License Key
in the vRealize Operations for
Horizon Installation guide.
Customers upgrading from vCenter Operations
Manager to vRealize Operations Manager may
perceive this licensing change as a reduction in
the number of virtual machines they can manage.
This is not the case - following the above steps
and the steps in the vRealize Operations
for Horizon Installation guide will
ensure that all your VMs are monitored and are
- The vRealize Operations Manager component
license that is included is for Horizon-supporting
infrastructure monitoring. A separate vRealize
Operations Manager license is required for
non-Horizon infrastructure monitoring.
This section contains notes on the installation
process for each vRealize Operations for Horizon
component. For complete installation instructions,
see the vRealize Operations for Horizon
This section contains notes of the upgrade
processes. For complete upgrade instructions, see
the vRealize Operations for Horizon
- You can upgrade from vRealize Operations for
Horizon 6.1, 6.2, 6.2.1, or 6.3 to vRealize
Operations for Horizon 6.4. Customers with
vRealize Operations for Horizon 6.0 must first
upgrade to vRealize Operations for Horizon 6.1
before upgrading to vRealize Operations for
- During the upgrade process, the dashboards,
views, and reports from the vRealize Operation for
Horizon 6.1 are retained and new dashboards,
views, and reports are added. Old dashboards,
views and reports are identified by the View
prefix, and the new dashboards, views and reports
are prefixed with Horizon. You can remove old
dashboards, views, and reports.
- After the adapter upgrade, enable the port
numbers 3099, 3100, and 3101 (if not already
enabled). Edit the
file in the vRealize Operations Manager.
Due to an existing limitation, vRealize
Operations Manager cluster must be restarted after
the upgrade for the process to complete. Or,
restart the remote collector (Run service vmware-vcops
Sessions that were active during upgrade may not
report data after the upgrade is complete. Restart
the desktop agent for the active sessions that are
During the Broker Agent upgrade process from
6.1, 6.2, or 6.2.1, or 6.3 to 6.4, vRealize
Operations for Horizon broker agent service is
stopped, configuration is preserved, Broker agent
is uninstalled, and the new version of Broker
Agent is installed. When the Broker Agent
configuration utility launches, on the first
screen of the wizard the vRealize Operations
Manager IP address/FQDN IP and the
pairing credentials have to be re-entered and
paired. The subsequent screen will have the data
populated from the preserved configuration file of
the previous installation. This includes data such
as Horizon Credentials and Events DB
configurations. In case of upgrade, the Broker
Agent service is not started automatically. On the
Configure The Broker Agent Service screen of the
Broker Agent Configuration Utility wizard,
the broker agent service has to be started.
Click Next and on the last page
of the wizard, click Finish.
TLS 1.2 is enforced by default in vRealize
Operations for Horizon Adapter 6.4. The Adapter
cannot communicate with older desktop Agents
running with TLS 1.0, such as vRealize Operations
for Horizon Desktop Agent 6.0/6.1. VDI Pools, RDS
Pools, or Apps running with older desktop Agents
are monitored by default. To monitor pools running
with older desktop Agents, administrators need to
log on to vRealize Operations Manager collector
node and add enforcesslprotocols = false
to the /usr/lib/vmware-vcops/user/plugins/inbound/V4V_adapter3/work/msgserver.properties
file. Horizon Adapter instance has to be
restarted. Broker Agent and Horizon Adapter
instance pairing might be required.
- Add the command: TCPPORTS="$TCPPORTS
3099:3101" after TCPPORTS="$TCPPORTS
3091:3094" in /opt/vmware/etc/vmware-vcops-firewall.conf.
- Restart the firewall: /etc/init.d/vmware-vcops-firewall
- Check the status of the firewall: /etc/init.d/vmware-vcops-firewall
Internationalization (I18N) Support
The vRealize Operations for Horizon user interface
and documentation are both available in English,
Japanese, French, German, Simplified Chinese,
Traditional Chinese, and Korean.
Top of Page
Prior Releases of vRealize Operations Manger for
Features that were introduced in prior releases of
vRealize Operations Manager for Horizon are
described in the release notes for each release,
along with existing known issues
This section contains resolved issues for this
- Functionality - No need to restart the
Broker Agent after restarting a view server.
- Interoperability - An issue with Blast
Metrics having no data with View 7.0.3 has been
- Performance - All string metrics have
been changed to properties to avoid a thread block
issue in the Analytic Module of vRealize
- Performance - Fixed an issue with high
CPU usage with the Desktop Agent, which was caused
by frequently invoking the WMI query API.
- Performance - Fixed a Desktop Agent
memory leak issue.
- Performance - Fixed a broker agent long
topology collection time issue, caused by too many
entitlements in the Horizon Environment.
- Performance - Redundant view API calls
for entitlements have been reduced by half.
- Scalability - A single vRealize
Operations for Horizon 6.4 Broker Agent can now
scale beyond 4K desktops when used in Horizon
6.2.1 or later environment on a single View POD.
- Security - Dual sign is now used for all
binary and installation packages.
- Stability - Enhancements have been made
to RMI connections.
- Upgrade - You no longer need to update a
vRealize Operations Manager firewall rule after
upgrading vRealize Operation Manager to 6.4 or
- Usability - The V4H config file has been
migrated from older versions to 6.4.
This section contains known issues for this
- Cannot navigate to the Horizon Root Cause
Dashboard or other dashboards from End User
Experience Dashboard heat maps if using vRealize
Operations Manager 6.3.
Workaround: Use vRealize Operations
Manager 6.2.4 (or 6.2.1).
- Duplicate App Volumes Managers can be added
with the Horizon Broker Agent Utility
The Horizon Broker Agent Utility allows you to add
an App Volume Manager by FQDN and IP
address. It is possible, but not desirable,
to add the same App Volume Manager twice, once by
FQDN and once by IP, creating duplicate
Workaround: Delete one App Volume
Manager manually via the Broker Agent Utility, and
restart the broker agent service.
- The sessions count may not be accurately
reflected in the Access Point widget.
The total number of sessions shown in the Access
Point widget may not include sessions launched in
Access Point, as some Access Point-launched
sessions may still be alive but not counted in the
session total of the widget. (The total
number of sessions will be appropriate in other
places apart from the Access Point widget.)
This only applies to sessions launched in Access
Workaround: None for vRealize
Operations for Horizon. (Try troubleshooting
- Blast protocol metric is not available in the
RDSH Pool dashboard.
Workaround: Create a supermetric to
calculate Blast data with the Pool object.
- The Desktop Agent may not run
normally after you restart a VM or log in as
This is caused by an installation mistake. It's
not permitted to install the Desktop Agent on a
desktop machine with an account that has an App
Stack assignment in App Volumes. In such a case,
the Desktop Agent might be installed successfully,
but it would be installed on the mounted App
Stack, not on the local storage, and the Desktop
Agent will not run normally after you restart the
VM or log in as another user.
Workaround: Install the Desktop Agent
on an account that is not assigned an App Stack,
or install the Desktop Agent on the base template
of the desktop machine.
- Too many application crash alerts may be
displayed on the Alerts page.
When an application crash happens on the desktop,
the Desktop Agent sends this information to the
adapter; the adapter then throws a notification
alert that is displayed on the Alerts page. Over
time, unless old alert notifications are cleared,
the Alerts page will be overpopulated with alerts.
Workaround: Use cleanallstopobjects.jar
to remove unwanted alerts:
Usage: java -jar cleanallstopobjects.jar
VROPS_IP Admin_User password record_per_page
example: java -jar cleanallstopobjects.jar
vrops.vmware.com admin password 100 7
("7" means all notifications that are created 7
days ago will be canceled when the program is
Set a daily cron job to run cleanallstopobjects.jar.
- The Access Point widget displays deleted
Access Point objects.
If you remove an Access Point with the Horizon
Broker Agent, the Access Point widget may still
display the deleted Access Point object.
- Stop the adapter instance.
- Delete the unused Access Point object from the
- Restart the adapter instance.
- Pod names do not appear in the Connected
Sessions widget within the expected time of 15
Names of connecting pods may not appear in the Pod
Name column of the Connected Sessions widget of
the Horizon Help Desk Dashboard within the
expected time of 15 minutes after session launch.
Data appears within 15 minutes in all other
columns related to the launched session in this
Workaround: None. Pod names should appear
within a maximum delay of 40-60 minutes after
- In the Broker Agent Utility for Horizon,
the test for Desktop Pool ID in the optional
Specify Desktop Pools, fails if this ID is
different from the Desktop Pool name.
Workaround: Enter the correct
Desktop Pool ID, ignore the error message and
click Next for the configuration.
- When vRealize
Operations for Horizon solution is upgraded to
6.1, duplicate session objects would appear
When vRealize Operations for Horizon solution is
upgraded to 6.1, duplicate session objects would
appear. Newer object will have a
and the older object is without a
Only the session objects containing a
will fetch the metrics. Session Objects without
are stale and will not fetch any metrics (because
of vRealize Operations Manager limitation of not
deleting stale objects immediately). This is
applicable to VDI session objects only.
- Horizon pods that are no longer being
monitored still appear in the Horizon dashboards
If you stop monitoring a Horizon pod, the Horizon
pod resource continues to appear in the Horizon
Workaround: Manually delete the
Horizon pod resource and all Horizon Connection
Server, security server, and pool resources
related to this Horizon pod from the vRealize
Operations Manager user interface.
linked-clone desktops must be recomposed
If you created desktop pool images that utilize
linked clones prior to installing vRealize
Operations for Horizon, you must to recompose the
linked clones to include the vRealize Operations
for Horizon desktop agent in the image.
names that include multibyte characters might
not appear correctly in the vRealize Operations
Manager user interface
alerts are not generated for user sessions that
were established before the View adapter was set
The following alerts are not generated for user
sessions that were initiated before the
configuration of a View adapter instance:
PCoIP|Round Trip Latency (ms) and PCoIP|Packet
Loss Percent. See KB 1030695: PCoIP performance is
slower than expected for troubleshooting
high latency and packet loss issues.
Changing the adapter name causes the View
Adapter Status dashboard to display incorrect
If the name of the View adapter instance is
changed, the health of the View Adapter in the
Select View Adapter widget and the health of the
objects in the View Adapter Status widget are
unknown on the View Adapter Status dashboard.
These problems occur because the View Adapter
Collector resource does not automatically update
to reflect the name change of the vCenter
Operations for Horizon View adapter instance.
Workaround: Do not change the
adapter name. If the adapter name has already been
changed, update the adapter name in the vRealize
Operations for Horizon user interface.
Certain View reports return inconsistent
or incorrect results
The View Desktop Pool Usage and View Application
Pool Usage reports return inconsistent or
incorrect results in the Connected and
Disconnected Desktop Sessions sections.
If a View adapter receives data from more
than 1,000 desktop agents, the ARP cache on the
vRealize Operations Manager collector node is
not large enough to handle all of the necessary
entries in the cache.
Workaround: For a solution to
this problem, see KB 2096607: Adjusting the ARP
cache on a vRealize Operations Manager remote
Scoreboard widgets on the View Overview,
View Remote Session Details, View RDS & and
View Adapter Self Health dashboards do not
Most scoreboard widgets are configured to refresh
every two minutes, but this problem prevents
auto-refreshing. This problem is most apparent if
the affected dashboards are always kept open.
Workaround: Click the Perform
Multi-Select Interaction button on
master widget's toolbar to reinitiate interactions
and refresh the corresponding scoreboard widgets.
For example, on the View Overview dashboard, click
the Perform Multi-Select Interaction
button on the View Pods widget toolbar to refresh
the Pod Indicator Metrics scoreboard widget.
- In Horizon Desktop Agent 6.1 or earlier
versions, the Logon time, Logon duration,
Session duration, Average Logon, Average
Recollect, and Maximum Logon Time information
cannot not be collected.
These metrics cannot be seen in the widgets such
as Top RDS Desktop Session Logon Time in Horizon
RDS Pools dashboard, Top Application Session Logon
Time in RDS Pools dashboard, Top VDI Session Logon
Time Horizon in VDI Pools dashboard, Horizon
Remote Session in Horizon User Session Details
dashboard, Pool Desktop Sessions in Horizon
Desktop Usage dashboard, Top RDS Desktop Session
Logon Time in Horizon user sessions dashboard, Top
Application Session Logon Time in Horizon User
Session dashboard, Top VDI Session Logon Time
Horizon in Horizon User Session dashboard, All
desktop Pools in Horizon Desktop Usage dashboard,
Horizon pods in Horizon Overview dashboard.
Workaround: Upgrade the Desktop
Agent version to 6.2 or later.
- Tab traversal does not work in the
correct order while configuring the Broker Agent
- The name of the virtual machine does not
appear in the Applications Instances widget in
the Horizon Application dashboard if you are
using a Desktop Agent 6.1 or earlier versions.
Workaround: Upgrade the Desktop
Agent version to 6.2 or later.
- Applications launched by user widget in
Horizon Remote Sessions Details dashboard does
not populate any data if you have installed
Desktop Agent 6.1 or earlier versions on RDS
Server or VDI machine.
Workaround: Upgrade the Desktop
Agent version to 6.2 or later.
- If you restart a connection server
machine, the Broker Agent cannot initialize the
event db type. The following message appears:
WARNING: Exception creating connection for
EventDBListener: Unsupported Event DB.
Workaround: Restart the Broker
- Blank view sessions are listed in the
vRealize Operations Administrator UI after the
Adapter receives the desktop Agent data.
Workaround: Perform the following
- Click the pencil icon on the top right corner
of the widget.
- In the pop-up window, go to Select which
tags to filter, expand Collection
States and ensure the Collecting
option is selected.
- Click Save.
When you upgrade vRealize Operations for
Horizon adapter from 6.x to 6.4, the
collection state of the adapter instance shows
Workaround: Either restart the
collector service ( Run service
vmware-vcops --full-restart) or restart
the vRealize Operations Manager appliance.
Log on time, average logon time, and
maximum log on time values are not retained for
the existing sessions after upgrading adapter
from 6.x to 6.4.
Workaround: Log off and login
Even after the deletion of the View Pod
environment, the stale entries are retained on
Workaround: Restart the service (
Run service vmware-vcops
--full-restart). Login to vRealize
Operations Manager, go to Administrator
> Inventory Explorer, and
select the objects and delete them manually.
For reconnected sessions, Horizon
connected widget in help desk dashboard shows
Workaround: Edit the Horizon
connected widget and select All Active
Sessions and click Save.
If the View server is configured with
IP, then the Broker Agent first tries to connect
as a local host and displays a redundant error
'Could not connect to the connection server with
the provided credentials.' in the utility. The
second time it automatically connects to IP or
host name. There is no impact on the