**Updated 10.3.2023

Since the first release of the Management Pack for Horizon and the shift to an API vs. Agent based architecture, questions have manifested as to what are the best practices for deployment and what factors should a customer consider before enabling the MP in their production Horizon environment?

This post is meant to cover those topics in detail and provide insight into potential configuration challenges and how best to avoid them.

**However, with any point-in-time article new considerations can emerge necessitating the need to test and validate your specific environment and configuration.

Download MP4H 2.6.1: https://marketplace.cloud.vmware.com/services/details/vmware-aria-operations-management-pack-for-vmware-horizon-2-6-1?slug=true

Before deploying…
>>>>>>> Stop <<<<<<<
For this brief service announcement!

While it would be amazing if you could simply install some code, click a few buttons, and everything just magically work, there are usually additional considerations that may impact that mythical moment from becoming a realization. All Horizon environments have a degree of uniqueness that necessitates the need to validate and test for any configuration or environmental conflicts that might prevent a successful deployment.

That is why I like to say, there is no “All” approach to deployments, rather there is a methodology that should be followed to help you achieve a high degree of success. That methodology is based on how vROPs and the MP are designed to collect data against the Horizon APIs, as well as various configuration aspects of the Horizon deployment.

Areas of consideration:

Now let’s move forward with the solution requirements and we can dig into why these topics matter….

MP4H Requirements

**If the old vROPs for Horizon adapter (V4H) is installed, MP4H will not collect data!!!
Recommendation is to uninstall V4H before installing the MP4H adapter; However, if you have already installed the MP4H adapter, simply removing the V4H adapter should resolve the issue.

Horizon Version Support: ** please check the Interop Matrix for the latest supported version information comparing Horizon Version to the version Management Packs for Horizon that are supported.

Horizon to MP4H Interop Matrix: https://interopmatrix.vmware.com/Interoperability?col=569,&row=708,

Horizon 7.13+ is supported with MP4H. This allows customers still on Horizon 7.13 with the older V4H adapter to move to the new MP without having to first upgrade to the Horizon 8/2xxx platform. Once you decide to move to Horizon 2xxx the same adapter will support the new version of Horizon.

While 7.13+ is supported, not all versions will be supported with the latest version of the Management Pack. Please check the Interop Matrix to confirm supported versions.

The planned support model is N & N-1, to include ESB branches moving forward. As long as there are no SDK changes in older versions, then they will also be “supported not tested”.

**Horizon 7.13 End of Support is April 30th, 2023.

vROPs Version Support: ** please check the Interop Matrix for the latest supported version of Aria Operations and the version of the Management Pack for Horizon you plan to deploy.

vROPs to Horizon Interop Matrix: https://interopmatrix.vmware.com/Interoperability?col=116,&row=708,

The current minimum supported version with MP4H 2.6.1 is 8.10, but 8.12.1 is the recommended version. 8.12 will also work, but there are some known UI bugs that are resolved 8.12.1.

vCenter needs to monitor all Horizon Desktops and Management Components:
MP4H still relies on the vCenter adapter to pull VM level and Guest OS metrics from the Management Servers and Desktops within the Horizon Service. If there are objects outside of vROPs monitoring visibility we will not be able to populate VM level performance metrics, or have the ability to calculate the DC% Performance calculation on those objects.

Unified Access Gateways and Connection Servers also need to be monitored by vROPs:
If these objects are not monitored by the vCenter adapter in vROPs we will not collect their VM level performance data. Some data will still be collected, but they will be based purely on the available Horizon API data.

Connection Server Certificates require valid hostnames:
When you configure the Horizon Adapter to communicate with one of the Connection Servers in the Pod, vROPs will attempt to validate the CS certificate and the hostname associated with certificate. If the hostname in the certificate does not match the FQDN of the Connection Server vROPs will reject the certificate, as it cannot validate the authenticity of the Connection Server host providing it. It is recommended to have the Subject Alternative Name of the valid FQDN for the Connection Server in the certificate (or wildcard), so that vROPs can properly validate the certificate and establish a secure connection to the host.

Horizon TLS Certificate Documentation: https://docs.vmware.com/en/VMware-Horizon/2203/horizon-scenarios-ssl-certificates/GUID-47B2EA38-E319-4DC2-9AA4-881AED3DBB58.html

The following diagram highlights the recommended certificate configuration:

External vs. Internal CA’s are not a requirement, but more of a common practice to obscure the internal CS domain names from the outside connections.
The important takeaway is to have a Subject Alternative Name value on the Connection Server certificates that contains either the FQDN of the CS’s or a generic Wildcard (*.yourdomain) that vROPs can properly validate with the Internal CA.
Fun Fact: If SmartCard authentication is set to “required” on the Horizon Connection Server the Horizon API will be inaccessible to the MP. Change this setting to optional to allow the MP to authenticate against the API. ** This will be addressed in an upcoming Horizon release.

The MP4H adapter requires an account with Horizon Admin privileges (full or read-only) to access the Horizon APIs:
When configuring the MP4H adapter to authenticate against a Pod Connection Server, you must provide an account with a Horizon Admin role (full or read-only). Both Horizon Administrator roles (full and read-only) are built-in roles for Horizon, and an Active Directory service account should be created and assigned one of these roles. Which role you choose is Horizon version dependent, but the full Administrator role works with every version.

Horizon 7.13 through Horizon 8.2 requires the Administrators role.
Horizon 8.3/2106+ can use the Administrator (Read only) role.

Load Balancing

The MP4H adapter needs to point directly to a Horizon Pod Connection Server and not to a Load Balancer: When configuring the MP4H adapter to point to your Horizon Pod you must provide the FQDN or IP of a Connection Server and not point it to the Load Balancer VIP for the Pod. The Horizon APIs do not support Load Balanced queries, so even though it may initially connect and provide some data, the end result will be missing and inconsistent data coming into the MP4H adapter. Not cool!!!

The following diagram highlights what you can and can’t do to configure the adapter to communicate with Horizon:

To enable Load-Balancing across the Connection Servers in the Pod, simply enable the load-balancing option under the Advanced Settings of the Horizon Adapter. The Adapter will automatically discover every CS in the Pod and will attempt to load-balance API calls across the Connection Servers. This option provides both High-Availability to maintain communication in the case of a loss of CS, as well as scalability in the number of API requests that can be made to the Horizon Pod.

Pausing for another brief service announcement……

Do not Load-Balance your UAG’s across Pod boundaries!!!

While this may seem like a good idea, and technically it will function, doing so has dire consequences:

#1 It’s not supported in Horizon!!!

Link to documentation: https://docs.vmware.com/en/VMware-Horizon/2203/horizon-cloud-pod-architecture/GUID-5BCD8A4B-EEA4-44D2-94BE-535A1A9D815F.html

#2 It removes Fault Domain Isolation between the Pods!!!

#3 MP4H does not support this configuration and it just breaks stuff!!!

While the adapter will still be able to collect data regarding the UAG’s, each POD is reporting its own distinct UAG servers, and the adapter will treat the UAG as a net new item per Pod that it is associated with. It has also been observed that the Horizon Pods intermittently lose their API connection to the UAG’s and they are unable to provide the necessary health and connectivity metrics to the Pod. Not cool!!!

Now let’s discuss Horizon API Scalability and how pulling different metrics impacts scale.

Regardless of the platform or the cloud platform, all API’s have limitations on the ability service a certain number of requests in a given time period. With Horizon, the number of requests that can be serviced in a 5-minute interval is dependent on the type of metric and the number of objects that the metrics has to come from.

Pod level metrics regarding configuration and state of the Pod, Pools, Farms, UAG’s, etc. do not really impact size or scale since the number of objects are relatively low. Session counts on the other hand can impact scale dependent on the number of sessions and the types of metrics being requested. For example, session status and properties are lower impact because the metrics are directly available in the Horizon Pod API and the time to process them is relatively quick. However, other metrics such as Login Times and Protocol metrics must be queried from the desktop by the Connection Server and the time that it takes to get a response per session from each desktop lowers the number of sessions that can be queried in a given time period.

If the “Collection Time” starts to exceed the 5-minute collection window, additional tuning to the adapter or adding additional Connection Servers to the Pod with the load balancing option enabled increases the number of session requests that can be made in the 5-minute time window. You can also create new Pods with an additional MP4h adapter to further increase overall scale.

*Using two different Horizon monitoring solutions that both communicate to the Horizon API can impact scale, as the overall number of requests that the Horizon Pod can support is finite.

**Different APIs are being investigated to see if the current API limits can be improved upon.

The following diagram highlights the Pod scalability:

Let’s wrap this up…

As you can see from the topics covered in this post, there are a number of factors that must be taken into consideration during the deployment of the latest Management Pack for Horizon. While all factors aren’t necessarily exclusive to this MP, the purpose of this article was to help provide a better understanding of how the MP and the Horizon APIs work together to provide rich insight into the health and performance of a Horizon environment.

In the future, we plan to investigate where we can further simplify or minimize some of the considerations outlined in this post. But until that day happens… I hope this article provides you a guidepost to make your deployment successful.

Getting Started with MP4H 2.x: Deployment Considerations