In our last blog article we looked at some of the headline new features in Horizon 6.2. In this blog we continue to explore some of the key functionality added in this new release.
Access Point is a virtual appliance designed to allow secure remote access to virtual desktops and applications served by Horizon 6. Access Point is very similar to the View Security Server, but offers some additional benefits. Access Point is a hardened Linux appliance that can be deployed into the DMZ. Access Point does not need to be paired with a View Connection Server and can avoid the need to provision additional Connection Servers for authentication mechanism support.
Mark Benson’s blog on Access Point takes you through the details of the Access Point appliance and how it can be used as an alternative to the Horizon View Security Server. Additionally, you will find the Documentation on how to deploy the appliance here.
Alex Birch, EUC Architect, within the EUC Technical Marketing team has put together this video showing you how to install and configure Access Point.
In our last blog we also talked about some of the improvements to the RDSH management capabilities in Horizon 6.2. Specifically, one of the headline features is the ability to now pro-actively load balance RDSH sessions across RDS hosts.
Previously in Horizon 6, RDSH sessions were load balanced based upon the host with the most available sessions “slots”. Now in Horizon 6.2 sessions can be balanced based on CPU, Memory or another performance metric. In addition to this, affinity and anti-affinity rules allow administrators to avoid mixing specific applications to ensure they are not run together. We can also limit the number of times a specific application can be run on a single RDSH. Combining affinity rules with performance metric based load balancing provides a powerful way for administrators to ensure optimal user experience and application performance.
Performance metrics are setup via scripts running on the Remote Desktop Services Host. The VMware Horizon View Script Host service must be running and only one load balancing script should be running at anyone time. Of course, all RDS Hosts in your RDS farm should be running the same script.
VMware provides two scripts out of the box in MemoryOptimisation.vbs and CPUOptimisation.vbs.
Scripts can be customized and can use any performance counter metric. Scripts must return a valid integer code between 0 and 3 – no other return code is supported. A return code of 0 means block any new sessions. Values 1-3 indicate the level of load, with 1 being the highest load and 3 being the lightest. Every few minutes the “status” (script return code) is returned to the View Connection Server to indicate the RDSH current load status. All Scripts are located in C:\ProgramFiles\Vmware\VMWare View\Agent\Scripts.
In order to ensure a user’s session is not unnecessarily split across multiple RDS hosts, applications are always launched in the user’s existing RDS session – this essentially overrides the load balancing logic. Only new sessions are load balanced across RDS hosts.
In the next blog post we will look at some of the new user experience features including NVIDIA GRID vGPU support in RDSH and biometric single sign on to Horizon View Desktops.
