Best Practices for Published Applications and Desktops in VMware Horizon and VMware Horizon Apps
® provides a virtual desktop solution as well as an enterprise-class, application publishing solution. For users who do not require personalized virtual desktops and who handle a standard set of tasks, VMware Horizon Apps is the ideal solution. Horizon Apps offers published applications and session-based desktops, without VDI.
Horizon Apps leverages Microsoft RDSH servers to deliver published applications or desktops and VM Hosted Apps on Horizon 7.9 or later to deliver published applications. Data, applications, and desktops are centrally managed and secured. Users access their published applications and desktops from a single digital workspace, through single sign-on from any authenticated device or OS.
Critical Horizon features and components, such as the Blast Extreme display protocol, instant-clone provisioning, ™ application delivery, and ™, are integrated with published applications and desktops to provide a seamless user experience and an easy-to-manage, scalable solution.
Published applications and desktops provide the opportunity to reduce hardware, software, operating costs, and simplify installation, upgrades, and troubleshooting.
This guide provides best practices for anyone deploying a published application or published desktop solution based on Horizon.
This guide is for anyone installing or administering Horizon. Readers should be familiar with basic installation and administration procedures, such as those described in .
Organization of This Document
As you set up and configure your Horizon Apps deployment, you need to consider
- General vSphere best practices
- vSphere storage and networking best practices
- Core services infrastructure best practices
- VMware ESXi™ host sizing best practices
- Remote Desktop Session Host configuration best practices
- Horizon best practices
- Dynamic Environment Manager policy configuration best practices
- App Volumes best practices
- Antivirus configuration best practices
- Maintenance operations best practices
General vSphere Best Practices
Like any VMware deployment, Horizon relies on hardware that is compatible with the appropriate versions of ® and ™ and configured according to VMware best practices. Review details in the Performance Best Practices for VMware vSphere for the appropriate version and update from the download page.
System and Hardware Requirements
Before deploying a system, perform the following tasks:
- Verify that all hardware is compatible with the version of the VMware products that you plan to use. See the VMware Compatibility Guide.
- If you are using vSAN, ensure that all hardware, including disk controllers, are compatible. See the VMware Compatibility Guide – vSAN Components.
- Make sure that your hardware meets the minimum system requirements for the VMware products that you plan to use. See the Horizon Documentation and the .
- Consider using the latest version of Horizon and the latest versions of ESXi and VMware vCenter Server® that are supported. For example, when using Windows 10 1809 or Windows Server 2019, vSphere 6.5 U3 or later, vSphere 6.7 U3 or later, or vSphere 7.0 or later are recommended.
- Test your system memory for 72 hours, checking for hardware errors. For instructions, see the hardware manufacturer’s documentation.
ESXi Host Power-Management BIOS Settings
ESXi includes Host Power-Management capabilities that can save power when a host is not fully utilized. Configure the BIOS settings to allow ESXi the most flexibility for the power-management features offered by your hardware and then make your power-management choices within ESXi. For example, turn off all hardware-controlled power management features, but enable all power-management features that the operating system can control.
For the management cluster, the recommended power option is Balanced, which is the default.
Figure 1: Recommended power option for ESXi Management Cluster
For the resource cluster, the recommended power option is High performance because it allows the highest user density and provides consistent performance. Since vSphere 7, this must be configured in the ESXi Embedded Host Client.
Figure 2: Recommended power option for an ESXi Resource Cluster
vSphere Storage and Networking Best Practices
To create a vSphere infrastructure that supports Horizon, you must follow particular storage and network guidelines. Review details in the Performance Best Practices for VMware vSphere for the appropriate version and update from the download page, and if applicable, relevant storage vendor product documentation.
Core Services Infrastructure Best Practices
All core infrastructure components, such as Active Directory (AD), Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Network Time Protocol (NTP), Key Management Service (KMS), and Remote Desktop Licensing (RD Licensing), need to be highly available per site. When servers for these components are running as VMs, affinity rules need to be in place so that when a host or rack goes down, these services remain operational. For more information, see vSphere HA and DRS Affinity Rules in the vSphere Availability Guide.
To apply group policies to the RDS hosts that deliver remote desktop or application sessions, without affecting other Windows computers in the same AD domain, create an organizational unit (OU) specifically for your RDS hosts. This OU cannot have inheritance or linked GPOs applied to nonvirtual machines.
Domain Name Services
Make DNS servers highly available on every site. When running virtual affinity rules, set up the servers so that the instances are not running on the same host or rack.
Dynamic Host Configuration Protocol
Make sure that the subnet and DHCP pool are large enough—or prepare for multiple VLANs—to accommodate growth. When using instant clones, the lease time is not important because an instant clone releases the IP address before deleting the VM.
Network Time Protocol
For management and RDSH or Hosted Applications VMs and ESXi hosts, use AD as the NTP source.
Key Management Service
It is recommended to advertise KMS by DNS ( _vlmcs._tcp SRV records) and to clear and turn off the KMS cache when creating the client image. This action ensures that KMS requests are load-balanced by DNS, even when a KMS host is down during initial deployment.
Remote Desktop Licensing
Licensing is an important component of any Remote Desktop deployment. Users must have a valid RDS CAL issued by a license server before they can log on to an RD Session Host server. It is best practice to make sure that your remote access license servers are highly available. Consider setting up redundant servers (at least two) to provide the appropriate redundancy for this service.
Use GPO policy or Windows registry to specify all RDSH license servers and the licensing mode.
For the GPO policy, go to:
Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing
Figure 3: RDSH Licensing options
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
LicensingMode (2 = per device, 4 = per user)
It is recommended that you delete the key containing timebomb in the following hive of the registry of the RDSH image so that the grace period starts after deployment and not on creation of the image:
ESXi Host Sizing Best Practices
To determine the number of ESXi hosts you need, as well as the number of CPUs and the amount of memory on each host, consider how many end users you must serve, how many and what type of applications they use, and how intensive their workloads are.
The steps to follow are:
- Establish a baseline of user requirements.
- Calculate CPU requirements based on users’ workloads.
- Calculate memory requirements based on users’ workloads.
- Perform a load test.
- Use a pilot to validate ESXi host requirements.
- Calculate the number of ESXi hosts required.
Establish a Baseline of User Requirements
Gather the baseline information on the user groups that have been identified as good candidates for an RDSH environment. The purpose of this step is to understand the performance characteristics of the target users’ workload. For example:
Which applications do users need?
Are the applications CPU- or memory-intensive?
Does their work generate a large number of storage operations?
What type of network load is being generated by user activities?
Note: This information is applicable whether you are implementing a new RDSH environment or migrating an existing RDSH or virtual desktop infrastructure (VDI) environment to a Horizon published applications environment.
A performance-monitoring tool, such as VMware vRealize® Operations Manager™, Liquidware Labs Stratusphere FIT, or Lakeside Software SysTrack, can help you gather the baseline information. In addition, Windows includes Performance Monitor (Perfmon), which allows you to capture and graph performance statistics from local and remote computers. See the VMware knowledge base article Collecting the Windows Perfmon log data to diagnose virtual machine performance issues (2010970).
Calculate CPU Requirements Based on Users’ Workloads
There are two recommended virtual CPU configurations when deploying Horizon RDSH.
- Four virtual CPUs with a 1:1 virtual-to-physical CPU ratio
- Eight virtual CPUs with a 2:1 virtual-to-physical CPU ratio
Make sure that the ratios do not span CPUs because every RDSH needs to follow NUMA.
Which configuration works best depends on the thread use of the application workload. Always test your configuration with a pilot.
For example, if the hosts used for an RDSH cluster have two Intel Xeon Processor E5-2699 v4 (22 cores), the hosts should run a maximum of:
2 (physical CPUs) * 1 (1:1 ratio) * 20 (physical cores) / 4 (virtual CPUs) = 10 RDSH VMs
This amount is equal for both ratios. The extra cores and hyper-threaded cores are not lost, unless Microarchitectural Data Sampling or L1 Terminal fault vulnerabilities are fully mitigated with the v1 schedular, then the hyper-threaded cores are no longer used, else they are used for virtual networking, storage, and other host tasks.
From the baseline that you previously established, you can estimate the CPU resources required per type of user. With this example, we can determine the number of hosts required for a company:
Based on Perfmon, the average CPU usage of one type of user found is 550 MHz.
The Intel Xeon Processor E5-2699 v4 has an all-core turbo. If Turbo Boost is turned off or high temperatures are expected, use the base frequency, which is 2200 MHz.
With a speed of 2800 MHz and with four physical cores available per RDSH, this processor allows for 11200 MHz to be shared among users.
When leaving a 40 percent margin for CPU spikes, such as during boot storms, you can have 15 users per RDSH, or 150 per ESXi host:
11200 / (550*1.4) = 14.55
Calculate Memory Requirements Based on Users’ Workloads
The amount of memory required for an ESXi host depends on the private memory references for an application workload combined with
- Memory for the host operating system
- Shared application memory
- Memory required for a user session
Start with 4 GB of memory for the operating system, plus 1331 MB (1024 MB + 30 percent margin) per user, unless the performance monitoring shows high memory usage. In our example, the amount is 24 GB:
4 + (15 users * 1.3) = 23.5 GB
Perform a Load Test
Use a Pilot to Validate ESXi Host Requirements
Now that we have calculated our starting point—10 RDS hosts with 30 users per ESXi host—you want to pilot these numbers on a few ESXi hosts. Have users perform their normal day-to-day operations while monitoring the environment extensively. Adjust the configurations based on the outcome.
Besides validating your calculations, you can determine whether to use a 1:1 or 2:1 virtual-to-physical CPU ratio, based on performance or mitigations.
Calculate the Number of ESXi Hosts Required
After the numbers are adjusted based on the pilot, calculate the number of hosts required: total number of users divided by the number of users per server, plus the number of servers required for redundancy or other minimums.
For example, if you have 900 users who need to continue working when an ESXi host is down, you need seven hosts:
(900 / 150) + 1
You need 384 GB of host memory, which is the closest supported configuration to the required amount of 288 GB to allow enough (20%) headroom for vSAN and other services:
1.2 * (10 * 24) = 288 GB
When using Instant Clones with Horizon, a parent VM per host per pool would also be created:
1.2 * ((10+1) * 24) = 317 GB
Remote Desktop Session Host Configuration Best Practices
After you set up the vSphere infrastructure, you can create an optimized golden VM for cloning RDS hosts.
The steps are as follows:
- Create the golden RDS host or Hosted Applications VM, install Windows, and go to audit mode.
- Install common Microsoft runtimes and features and applications wanted in the golden image.
- Install Microsoft updates.
- Optimize Windows with the OS Optimization Tool.
- Generalize Windows with the OS Optimization Tool.
- Finalize Windows with the OS Optimization Tool.
- Export the image.
VM Hosted Applications
As of Horizon 7.9, there is a new feature in Horizon called VM Hosted Applications. This allows floating Instant Clone Desktop Pools to be used as a source for Application Pools.
The advantages are:
- Publish application that do not run on a server OS
- Want to run applications on Windows 10
- Same deployment and configuration process as a normal desktop
- Publish UWP apps as well as any Win32 application
- Better security that one to many RDS servers
- One to One user to machine assignment - the prevents a user from impacting performance for another user as can happen in RDSH
- No need for RDS CALs
Requirements for VM Hosted Applications:
- Horizon 7.9 server or later
- Horizon 7.9 agent or later
- Horizon Client 5.1 or later
- Instant Clone Floating Pool
- Windows 10 1803 or later
To create a floating Instant Clone pool:
- Choose the session type of Application or Desktop & Application to enable this feature. Desktop & Application allows the pool to be accessed via users for both Desktops and Applications. Note that users can only use one type (Desktop or Application) at a time.
Figure 4: Choosing application session type
After the pool is created go through the standard Application Pool creation process but choose Desktop Pool and select the name of the Pool you just created. You can then either select applications to publish manually or automatically.
Figure 5: Add VM hosted apps desktop pool
- Entitlement is done in the same way and the published apps look the same to the user as RDSH hosted applications do.
Figure 6: VM hosted apps in the Horizon Client
Horizon Best Practices
We recommend using Instant Clone Technology when creating RDSH server farms. Load balancing for server farms should be used. The default method for load balancing bases load-balancing decisions on the current session count. If this method is not adequate for your needs, that work as outlined in the product documentation.
Provisioning RDS Hosts Using Instant Clones
Instant clones deploy RDS hosts more rapidly, scale more easily, and perform maintenance up to 85 percent more quickly than was previously possible.
Publishing occurs only when you create a new farm or update an existing farm to incorporate changes. Publishing the golden image takes between 7 and 40 minutes, depending on the type of storage and number of hosts that you are using.
After the publishing process is complete, provisioning the servers takes 1 or 2 seconds per server. Provisioning does not require power operations, and the clones are forked from a running parent VM to further expedite the process.
You can delay the provisioning process by not enabling it in the Add Farm wizard. When you scale up the pool, all that needs to be done is provisioning.
RDS Host Load Balancing
By default, the Connection Server use the following formula to determine placement of published application and desktops on RDS hosts.
(connected sessions + pending sessions + disconnected sessions)/(maximum session count)
You can override this behavior and control the placement of new application sessions by either configuration Load balancing in the Horizon Administrator or by using a Load balancing script. Horizon calculates the Server Load Index based on the load balancing settings you configure. The Server Load Index can range from 0 to 100, where 0 represents no load and 100 represents full load. A Server Load Index of -1 indicates that load balancing is turned off. The current load of an RDS host can be viewed in the dashboard of the Horizon Administrator under System Health.
Figure 7: Load index in Horizon Administrator dashboard
Setting RDS Host Load Balancing in Horizon Administrator
Configure load balancing settings in a Farm on the Load Balancing Settings tab. The options available are in the Table 1.
Figure 8: Load Balancing Settings tab
Table 1: RDS load balancing options
Load balancing on multiple metrics like CPU, memory, disk, and network is recommended. You can write your own load-balancing script or use one of the samples provided with Horizon Agent.
A load-balancing script returns a load index value. The load value can be based on any host metric, such as CPU utilization or memory utilization. The Connection Server uses the load index value to determine where to place new application sessions.
Important: Include margins for peak loads in the script, just as we did in the CPU and memory calculations. Use the script in conjunction with a reasonable maximum number of connections per host, which is set on the host or farm. Session load balancing addresses load balancing only at connection time and cannot move users after they have been assigned.
The load balancing script must write the load index value to the CustomLoadValue registry key in the following location: HKLM\Software\VMware Inc.\VMware VDM\Performance Stats\CustomLoadValue.
This value must be between 0-100. Copy your load balancing script to the Horizon Agent scripts directory C:\Program Files\VMware\VMware View\Agent\scripts on each RDS host in the farm. You must copy the same script to every RDS host in the farm.
Note: After a Connection Server and Horizon Agent upgrade to version 7.8 and later, earlier versions of custom scripts must write the custom load index to the CustomLoadValue registry key in the following location: HKLM\Sofware\VMware Inc.\VMware VDM\Performance Stats\CustomLoadValue. This value must be between 0-100. Custom scripts written to work with Connection Server and Horizon Agent versions earlier than 7.8 returned a number between 0-3. If you upgraded Horizon Agent to 7.8 and later but did not upgrade Connection Server to 7.8 and later, you cannot use custom scripts for load balancing. In this case, Horizon load-balances the desktop and application sessions in the farm using the default option when no load balance settings are configured in the Horizon Administrator.
Sample scripts are provided when the Horizon Agent is installed on an RDS host at C:\Program Files\VMware\VMware View\Agent\scripts
Figure 9: Sample RDS load balancing script
You must enable the VMware Horizon View Script Host service on an RDS host before you configure a load-balancing script. The service is turned off by default. Set it to automatic using services.msc.
Note: You must configure the same load-balancing script on every RDS host in the farm. Configuring a load-balancing script involves setting a registry key on the RDS host.
- Browse to the following key in the Registry Editor: HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\ScriptEvents
- Select the RDSHLoad key
- Right-click in the topic area for the RdshLoad key, select New > String Value, and create a new string value.
- As a best practice, use a name that represents the load balancing script to be run.
- In the Value data text box, enter the full path to your load balancing script. For example: cscript.exe "C:\Program Files\VMware\VMware View Agent\scripts\cpuutilisation.vbs"
- Restart the Horizon Agent service on the RDS host to make your changes take effect.
Note: If you are using an automated farm, you perform this procedure on the golden VM for the automated farm.
Dynamic Environment Manager Policy Configuration Best Practices
After you have created farms of RDS hosts, you can use VMware Dynamic Environment Manager for fine-grained policy management.
Horizon Smart Policies
By default, Horizon allows pasting from a client system to an RDS host, but not the reverse. If users need to be able to copy text from the session, you can use a Smart Policy, as described in Configure Horizon Smart Policies for User Environment Settings in the .
To allow user data to persist between sessions, use folder redirection for the Documents folder, at a minimum. We recommend using Dynamic Environment Manager to configure folder redirection.
Figure 10: Dynamic Environment Manager redirection configuration dialog box
For more information, see Configure Folder Redirection in the.
Because users can get a different RDS host each time they log in, we do not recommend keeping profile information on the RDS host. Doing so consumes an excessive amount of disk space. Instead, remove the cached user profile at logout. See Delete cached copies of roaming profiles.
When using locally attached personal printers or specialized printers, such as bar code printers and label printers, users can use local printer redirection (also called the virtual printing feature), which is included with Horizon. This feature does not require installing printer drivers in the RDS host because the printer driver is installed on client endpoints.
Keep the following in mind when using local printer redirection with VMware Horizon.
Printer redirection supports many common printer features, such as two-sided printing, but it might not support some unique features of a specific printer.
Client systems that do not have local printer drivers, such as PCoIP zero clients and mobile clients, are not supported.
However, local printer redirection is not the right solution for corporate network printers. Network printing is redirected over virtual channels, which can impact overall performance. When using network print servers, we recommend using Dynamic Environment Manager to set up printer mappings and to deliver a follow-me printing solution. Printers can be mapped during the user login process. The printer is ready immediately after the login process completes.
For example, you map a particular printer, such as a barcode printer, when a user launches a specific application. The mapping is deleted when the user closes the application. This setup streamlines the login process because the printer is mapped only when the user needs it.
Figure 11: Printer Mapping settings tab showing the path to the printer
Figure 12: Printer Mapping conditions based on IP range and endpoint name
For more information, see the VMware blog post Choosing Printing Options for VMware Horizon or review the .
Turning Off Hardware Graphics Acceleration in Commonly Used Applications
If the RDSH VMs are not using a physical GPU in the ESXi hosts, you can reduce CPU usage by not emulating hardware graphics in applications. We recommend using Dynamic Environment Manager configuration files to control these application settings.
To turn off hardware graphics acceleration for Internet Explorer, navigate to Internet Options > Advanced > Accelerated graphics and select Use software rendering instead of GPU rendering.
To turn off hardware graphics acceleration for Microsoft Office, navigate to File > Options > Advanced and select Disable hardware graphics acceleration.
To turn off hardware graphics acceleration and other CPU-intensive display options for Adobe Reader:
- Navigate to Preferences > Page Display > Rendering and deselect the following options:
- Smooth imaging
- Smooth line art
- Use page cache
- Enhance thin lines
- Navigate to Preferences > Page Display > Page Content and Information and select Disable smooth zooming.
To turn off hardware graphics acceleration for Chrome, navigate to chrome://settings > System and deselect Use hardware acceleration when available.
App Volumes Best Practices
App Volumes stores applications in shared read-only virtual disks (VMDK files) called AppStacks (Packages in App Volumes 4.0). AppStacks are assigned to RDS hosts rather than to users, as is done with VDI. Because RDS hosts can be deleted and recreated regularly, assign the AppStack to the AD group object that contains the computer objects for the RDS hosts. That way, the AppStack assignment does not depend on specific computer names.
Note: Create dedicated AppStacks for RDS hosts. Do not reuse an AppStack that was originally created for a desktop OS.
Install the applications on the same operating system that is on the deployment RDS host.
Antivirus Configuration Best Practices
To increase performance, you can adjust the all-inclusive antivirus scanning. The following recommendations apply to both desktops and applications provided by RDSH.
- Always run a virus scan on golden images before putting them into production.
- Stagger scheduled scans on RDS hosts to not scan all hosts at the same time, which would overload the vSphere environment.
- Turn off scanning on read operations for RDS hosts that are rebuilt frequently, such as for recurring maintenance.
Important: This recommendation assumes that the golden image has already been scanned and is known to be virus free. Do not turn off real-time scanning, and make sure that scanning for write operations is enabled.
- Remove unnecessary antivirus actions or processes from the desktop’s startup or login routines. Important: Seek guidance from your security team or antivirus vendor if you are unsure what is unnecessary.
- Turn off heuristic scanning on RDS hosts that are rebuilt frequently.
- Turn off auto-updates of antivirus software on RDS hosts that are rebuilt frequently.
Important: This recommendation applies to all installed software, not just antivirus software, because updates made when using a nonpersistent VM are lost on refresh. Ensure that you keep golden images regularly updated with new antivirus software versions and signature files.
- Exclude low-risk files and folders from real-time scans on RDS hosts. Some locations include:
- Page files
- Windows event logs
- C:\Program Files\VMware
- *.pst, *.pstx, and *.ost files – %systemroot%\System32\Spool\Printers
- App Volumes: C:\SnapVolumesTemp
- App Volumes: C:\SVROOT
Important: Continue to scan low-risk files and folders excluded from real-time scans on a regular schedule.
For more information, see https://techzone.vmware.com/resource/antivirus-considerations-vmware-horizon-environment.
Maintenance Operations Best Practices
With Instant Clones, a recurring maintenance schedule ensures that the RDS hosts are periodically regenerated. Potential contamination is removed so that the farm runs optimally. Because the maintenance operation does only provisioning, the operation needs little time to complete, which is one of the many reasons why using instant clones is highly recommended.
We recommend scheduling weekly or daily maintenance outside of business hours to minimize the impact on users. If you have multiple shifts per day of users, weekly maintenance is recommended. Otherwise, daily maintenance is recommended.
Figure 13: Schedule recurring maintenance
You can choose whether to log out users or wait for them to log out before performing maintenance.
Figure 14: Configuring logout behavior for maintenance operations
You can set the RDS hosts in drain mode which prevents new users from logging into the system while allowing existing users to remain connected. Using this with the "Wait for users to log off" maintenance setting will provide the least disruption for your users. In this scenario, it would be recommended to turn on drain mode. This will allow users to "drain" out of the RDS server and when the last user logs off, it will run the maintenance operations. When the RDS machine comes back online, the drain mode will be turned off.
This change can be made via a registry setting or via the change logon command. The registry keys are located here:
To set the RDS host in the drain mode state, use the change logon /drain command or set the registry keys WinStationsDisabled = 0 and TSServerDrainMode = 2.
Connection Server has the following behavior for the RDS host in the drain mode state:
- Does not send new connection requests to the RDS host.
- Routes new connections to other available RDS hosts in the farm.
- Allows reconnections to the RDS host.
- Horizon Administrator displays the Drain mode enabled status of the RDS host.
Summary and Additional Resources
Setting up a Horizon RDSH environment is similar to deploying a VDI desktop environment. The main differences involve calculating VM density on vSphere hosts and installing software and features on the RDS host VMs. Adhering to the best practices described in this guide ensures that you get the best performance for your RDSH applications and desktops.
- Collecting the Windows Perfmon log data to diagnose virtual machine performance issues (VMware knowledge base article)
- App Volumes Documentation
- Horizon Documentation
- Just-in-Time Apps with VMware Horizon 7 (VMware blog post)
- Storage vMotion to thin disk does not reclaim null blocks (VMware knowledge base article)
- Virtualizing Performance Critical Database Applications in VMware vSphere 6.0
- VMware OS Optimization Tool
Description of Changes
About the Authors and Contributors
is an End-User-Computing Architect in VMware Technical Marketing with a focus on application and desktop virtualization. Previously, he was a senior consultant in VMware Professional Services, leading large-scale EUC deployments in EMEA, and he has 18 years of experience in end-user computing.
Your feedback is valuable.