Best Practices for Published Applications and Desktops in VMware Horizon and VMware Horizon AppsVMware Horizon 7 version 7.12 VMware Horizon Apps version 7.12
VMware Horizon® 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. With Horizon 7.9 or later, published applications can also be delivered through applications hosted on Windows 10 VMs. This feature, called VM Hosted Applications, supports Universal Windows Platform (UWP) applications that run on Windows 10 virtual desktop (WVD) hosts or a Windows 10 desktop pool. 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, VMware App Volumes™ application delivery, and VMware Dynamic Environment Manager™, 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.
JMP – Next-Generation Application and Delivery Platform
JMP (pronounced jump), which stands for Just-in-Time Management Platform, represents capabilities in VMware Horizon Enterprise Edition and Horizon Apps Advanced Edition that deliver Just-in-Time Desktops and Apps in a flexible, fast, and personalized manner. JMP is composed of the following VMware technologies:
- Nonpersistent desktops and RDSH sessions
- App Volumes for real-time application delivery
- Dynamic Environment Manager for contextual policy management
JMP allows components of a desktop or RDSH server to be decoupled and managed independently in a centralized manner yet reconstituted on demand to deliver a personalized user workspace when needed. JMP is supported with both on-premises and cloud-based Horizon deployments, providing a unified and consistent management platform regardless of your deployment topology.
The JMP approach provides several key benefits, including simplified desktop and RDSH image management, faster delivery and maintenance of applications, and elimination of the need to manage “full persistent” desktops.
This guide provides best practices for anyone deploying a published application or published desktop solution based on VMware Horizon on a VMware vSphere® infrastructure. Readers should be familiar with basic installation and administration procedures, such as those described in Setting Up Published Applications and Desktops in Horizon 7.
General vSphere Best Practices
Like any VMware deployment, VMware Horizon relies on hardware that is compatible with the appropriate versions of vSphere and VMware vSAN™ and configured according to VMware best practices.
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 7 Documentation and the vSphere Documentation.
- Consider using the latest version of VMware Horizon and the latest versions of VMware 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, we recommend using vSphere 6.7 U3 or later or vSphere 7.0 or later.
- Test your system memory for 72 hours, checking for hardware errors. For instructions, see the hardware manufacturer’s documentation.
Network Adapter Recommendations
When using load balancing across multiple physical network adapters connected to one vSwitch, make sure that all the NICs have the same line speed.
Figure 1 shows an example of the proper configuration. The two adapters vmnic0 and vmnic1 are connected to vSwitch0 and both have a line speed of 1000 Mb. The adapters vmnic2 and vmnic3 are connected to DSwitch10GBe. Both have a line speed of 10000 Mb.
Figure 1: Multiple Network Adapters Connected to the Same vSwitch
ESXi Host General BIOS Settings
The following recommendations are for ESXi host BIOS settings:
- Run the latest BIOS version available for your system, as listed in the VMware Compatibility Guide.
Note: After making updates to the BIOS, review the BIOS settings in case new options have become available or the settings for existing options have changed.
- Enable all populated processor sockets and all cores in each socket.
- Enable Turbo Boost, and pass P-state and C-state control to the operating system.
- Enable hyper-threading for processors that support it.
- Disable node interleaving (that is, leave NUMA enabled).
- Enable hardware-assisted virtualization features (VT-x, AMD-V, EPT, RVI, and so on).
Note: If you make changes, some systems might need to be powered off for changes to take effect.
- Disable the devices you do not plan to use, such as unneeded serial, USB, or network ports.
ESXi Host Power-Management BIOS Settings
ESXi includes 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, disable 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 2: Recommended Power Option for an 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. For vSphere 7 or later, this setting needs to be configured in the ESXi Embedded Host Client.
Figure 3: Recommended Power Option for an ESXi Resource Cluster
vSphere Storage and Networking Best Practices
To create a vSphere infrastructure that supports VMware Horizon, you must follow particular storage and network guidelines.
General Storage Guidelines
Storage guidelines include recommendations for iSCSI performance and ESXi.
Using jumbo frames with iSCSI can reduce packet-processing overhead, thus improving the CPU efficiency of storage I/O. For the best iSCSI performance, enable jumbo frames when possible. See the VMware knowledge base article iSCSI and Jumbo Frames configuration on VMware ESXi/ESX (1007654).
ESXi also supports jumbo frames for hardware iSCSI.
- To use jumbo frames with an independent hardware iSCSI adapter, enable jumbo frame support in the iSCSI storage array and any hardware network switches through which the traffic will pass.
- To use jumbo frames with a dependent hardware iSCSI adapter or with software iSCSI, enable jumbo frame support in the storage array, any hardware network switches through which the traffic will pass, and both the vmknic and the vSwitch in ESXi.
ESXi Storage Recommendations
The number of LUNs in a storage array and the way virtual machines (VMs) are distributed across those LUNs can affect performance.
Provisioning more LUNs with fewer VMs on each LUN can enable the ESXi hosts to simultaneously present more I/O requests to the array. This setup has the potential to improve performance by ensuring full utilization of all array resources and giving the array more opportunities to optimize the I/O.
However, provisioning too many LUNs, especially when many ESXi hosts are connected to a single array, can allow the ESXi hosts to simultaneously send so many I/O requests that they fill the array queue, and the array returns QFULL/BUSY errors. This situation can reduce performance due to the need to retry the rejected I/O requests.
Check with your storage vendor for the recommended settings.
To ensure optimal network performance, we recommend using the vSphere Network I/O Control feature to control bandwidth. We also recommend using the VMXNET3 network adapter whenever possible.
Network I/O Control Feature
Network I/O Control (NetIOC) allows you to allocate different amounts of network bandwidth to specific network resource pools. You can create user-defined resource pools or select from among nine predefined resource pools:
- Management traffic
- Fault-tolerance traffic
- iSCSI traffic
- NFS traffic
- VMware vSAN traffic
- VMware vSphere vMotion® traffic
- VMware vSphere Replication™ traffic
- VMware vSphere Data Protection™ backup traffic
- VM traffic
Each resource pool is associated with a port group. When network resource pools are not split across physical network adapters, we recommend using NetIOC. For more information, see vSphere Network I/O Control in the vSphere Networking Guide.
VMXNET Network Adapters
The VMXNET family of paravirtualized network adapters provides better performance in most cases than emulated adapters, which include E1000e. VMXNET network adapters implement an idealized network interface that passes network traffic between the VM and the physical network interface card with minimal overhead.
The VMXNET network adapters—especially VMXNET3—also offer performance features not found in other virtual network adapters. For optimal performance, use VMXNET3. For more information, see Network Adapter Types in the vSphere Virtual Machine Administration Guide.
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 RDSH servers 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 RDSH servers. 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 servers, Windows 10 VMs used in VM Hosted Applications pools, and ESXi hosts, use Active Directory as the NTP source.
Key Management Service
It is recommended to advertise KMS by DNS (
_vlmcs._tcp SRV records) and to clear and disable 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
Use group policy or the Windows Registry to specify all (at least two) RDSH license servers and the licensing mode. Make RDSH license servers highly available on every site.
For the group policy, in the Group Policy Management Editor, go to:
Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing
Figure 4: RDSH Licensing Options
If you are using Windows Registry:
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 VMware 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 VMware 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 server 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 scheduler. For more information about this tool, see the VMware knowledgebase article HTAware Mitigation Tool Overview and Usage (56931). In that case, the hyper-threaded cores are no longer used. If you do not use the v1 scheduler, the extra cores can be 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 disabled 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 server, 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 server, 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
After calculating the CPU and memory requirements, perform a load test with a tool like VMware View Planner before doing a day-to-day operations pilot.
Use a Pilot to Validate ESXi Host Requirements
Now that we have calculated our starting point—10 RDSH servers 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 percent) headroom for vSAN and other services:
1.2 * (10 * 24) = 288 GB
When using instant clones with VMware Horizon, a parent VM per host per pool is also created:
1.2 * ((10+1) * 24) = 317 GB
Master Image Configuration Best Practices
After you set up the vSphere infrastructure, you can create an optimized master VM for cloning RDSH servers and Windows 10 desktops used for VM Hosted Applications.
- Create the master RDSH server or Windows 10 VM to be used for VM Hosted Applications, install Windows, and go to audit mode.
- Install common Microsoft runtimes and features and applications that you want in the master image.
- Install Microsoft updates.
- Optimize Windows with the VMware OS Optimization Tool.
- Generalize Windows with the OS Optimization Tool.
- Finalize Windows with the OS Optimization Tool.
- Export the image.
For step-by-step instructions, see Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop.
VM Hosted Applications Best Practices
Horizon 7.9 introduced a feature called VM Hosted Applications, which allows a desktop pool to be used as a source for an application pool.
The advantages are:
- Published applications do not run on a server OS.
- Users can run applications on Windows 10.
- This strategy uses the same deployment and configuration process as a normal desktop.
- Administrators can publish UWP apps as well as any Win32 applications.
- This setup offers better security than the one-to-many-session relationship used with RDSH servers.
- One-to-one user-to-machine assignment also prevents one user from impacting performance for another user, which can happen in the one-to-many relationship with RDSH servers.
- RDS CALs are not needed.
Requirements for the VM Hosted Applications feature:
- Horizon 7.9 server or later
- Horizon 7.9 agent or later
- Horizon Client 5.1 or later
- Instant-clone floating pool
- Instant-clone dedicated pool
- Instant-clone dedicated pool with longer-lived instant clones
- Full-clone pool
- Windows 10 1803 or later
For helpful hints and guidance about when to use this feature, see the Tech Zone video VMware Horizon 7.9: Desktop Application Publishing - Feature Walk-through.
To enable this feature, you create a pool as you normally would, and choose a session type of either Application or Desktop & Application. Desktop & Application allows the pool to be accessed by users for both desktop and application sessions. Note that users can only use one type of session (desktop or application) at a time.
Figure 5: 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 select applications to publish either manually or automatically.
Figure 6: Add VM Hosted Apps Desktop Pool
Entitlement is done in the same manner as for RDSH-published apps, and the desktop-published apps look the same to the user as RDSH-published applications do.
Figure 7: VM Hosted Applications in the Horizon Client
Horizon Best Practices
We recommend using Instant Clone Technology when creating RDSH server farms. Depending on your environment, we might also recommend changing the default load-balancing behavior, which bases load-balancing decisions on the current session count. These topics are discussed in the sections that follow.
Provisioning RDSH Servers Using Instant Clones
Instant clones deploy RDSH servers 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 master 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.
RDSH Server Load Balancing
By default, Horizon Connection Server uses the following formula to determine placement of published applications and desktops on RDSH servers.
(connected sessions + pending sessions + disconnected sessions)/(maximum session count)
You can override this behavior and control the placement of new application sessions either by configuring load balancing in the Horizon Console 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 a full load. A server load index of -1 indicates that load balancing is disabled. The current load on an RDSH server can be viewed in the Horizon Console dashboard under System Health.
Figure 8: Load Index in Horizon Console Dashboard
Setting RDSH Server Load Balancing in Horizon Console
Configure load balancing settings for a farm on the Load Balancing Settings tab.
Figure 9: Load Balancing Settings Tab
You have many options for configuring load balancing if the default settings do not work for your environment. You can use a custom script or specify settings in the Horizon Console, taking into consideration things like session count, percentage of CPU usage, percentage of memory usage, network latency, and disk queue length. For detailed descriptions of the available settings see Load Balancing Settings in the product documentation.
Configuring RDSH Server Load Balancing Using a Script
Load balancing on multiple metrics like CPU, memory, disk, and network latency 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 and 100. Copy the same load-balancing script to the Horizon Agent
scripts directory for every RDSH server in the farm. The directory is located in:
C:\Program Files\VMware\VMware View\Agent\scripts
Sample scripts are provided when the Horizon Agent is installed on an RDSH server, in the following location:
C:\Program Files\VMware\VMware View\Agent\scripts
Figure 10: Sample RDSH Server Load-Balancing Script
You must enable the VMware Horizon View Script Host service on the RDSH servers before you configure a load-balancing script to be run. The service is disabled by default. Set it to automatic using
You must configure the same load-balancing script to be run on every RDSH server in the farm. Configuring a load-balancing script involves setting a registry key on the RDSH server.
- Browse to the following key in the Windows Registry Editor:
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\ScriptEvents
- Select the
- Right-click in the topic area for the
RdshLoadkey, 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, type 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 RDSH server to make your changes take effect.
Note: If you are using an automated farm, you perform this procedure on the master VM for the automated farm.
For more information, see Configure Load Balancing for RDS Hosts.
Dynamic Environment Manager Policy Configuration Best Practices
After you have created farms of RDSH servers or pools of Windows 10 VMs for VM Hosted Applications, you can use Dynamic Environment Manager for fine-grained policy management.
Horizon Smart Policies
By default, Horizon allows pasting from a client system to a VM, 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 VMware Dynamic Environment Manager Administration Guide.
Horizon Smart Policies are available for configuring USB redirection, client-drive redirection, network bandwidth profiles, and more.
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 11: Dynamic Environment Manager Folder Redirection Configuration Dialog Box
Because users can get a different RDSH server or Windows 10 desktop each time they log in, we do not recommend keeping profile information on the VM. 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 barcode printers and label printers, users can use local printer redirection (also called the virtual printing feature), which is included with VMware Horizon. This feature does not require installing printer drivers in the RDSH server or Windows 10 desktop 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 12: Printer Mapping Settings Tab Showing the Path to the Printer
Figure 13: Printer Mapping Conditions Based on IP Range and Endpoint Name
Turning Off Hardware Graphics Acceleration in Some Apps
If the RDSH servers or Windows 10 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, in 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, in the Office app, navigate to File > Options > Advanced and select Disable hardware graphics acceleration.
To turn off hardware graphics acceleration and disable 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 the URL
chrome://settings, expand the Advanced section, and in the System section, turn off Use hardware acceleration when available.
App Volumes Best Practices
App Volumes stores applications in shared read-only virtual disks (VMDK files), called AppStacks in App Volumes 2.x, and called packages in App Volumes 4. AppStacks, or packages, are assigned to RDSH servers rather than to users, as is done with VDI. Because RDSH servers can be deleted and recreated regularly, assign the AppStack or package to the AD group object that contains the computer objects for the RDSH servers. That way, the AppStack or package assignment does not depend on specific computer names.
Note: Create dedicated AppStacks or packages for RDSH servers. Do not reuse an AppStack or package that was originally created for a desktop OS.
Install the applications on the same operating system that is used on the deployment RDSH server.
Before installing applications on an AppStack, switch the RDSH server to the
RD-Install mode. For more information, see the Quick Start Tutorial for VMware App Volumes.
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 servers:
- Always run a virus scan on master images before putting them into production.
- Stagger scheduled scans on RDSH servers to not scan all hosts at the same time, which would overload the vSphere environment.
- Disable scanning on read operations for RDSH servers that are rebuilt frequently, such as for recurring maintenance.
Important: This recommendation assumes that the master image has already been scanned and is known to be virus free. Do not disable 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 whether a process is unnecessary.
- Disable heuristic scanning on RDSH servers that are rebuilt frequently.
- Disable auto-updates of antivirus software on RDSH servers 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 master images regularly updated with new antivirus software versions and signature files.
- Exclude low-risk files and folders from real-time scans on RDSH servers. Some locations include:
- Page files
- Windows event logs
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 Antivirus Considerations in a VMware Horizon 7 Environment.
Maintenance Operations Best Practices
With instant-clone RDSH servers, a recurring maintenance schedule ensures that the RDSH servers 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.
Note: Scheduling maintenance operations is required for RDSH server farms but not for Windows 10 desktop pools used for VM Hosted Applications. For Windows 10 desktop pools, VMs are destroyed and recreated fairly frequently, every time the user logs out.
Figure 14: Schedule Recurring Maintenance
You can choose whether to log users off or wait for them to log off before performing maintenance.
Figure 14: Configuring Logoff Behavior for Maintenance Operations
You can place the RDSH servers in drain mode, which prevents new users from logging in to the system while allowing existing users to remain connected. Drain mode allows users to "drain" out of the RDSH server. When the last user logs off, the server is allowed to run its maintenance operations. Using drain mode with the Wait for users to log off maintenance setting ensures the least disruption for your users. When the RDSH machine comes back online, drain mode is turned off.
This change can be made using a Windows Registry setting or by using the
change logon command. The registry keys are located here:
To place the RDSH server in drain mode, use the
change logon /drain command or set the registry keys
WinStationsDisabled = 0 and
TSServerDrainMode = 2.
Connection Server has the following behavior with regards to the RDSH server when it is in drain mode:
- Does not send new connection requests to the RDSH server
- Routes new connections to other available RDSH servers in the farm
- Allows reconnections to the RDSH server
- Horizon Console displays the Drain mode enabled status for the RDSH server
Conclusion and Additional Resources
Setting up an environment for published applications and desktops 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 RDSH server VMs for the Windows 10 VMs used for VM Hosted Applications. Adhering to the best practices described in this guide ensures that you get the best performance for your published applications and desktops.
Choosing Printing Options for VMware Horizon 7 (VMware blog post)
Collecting the Windows Perfmon log data to diagnose virtual machine performance issues (VMware knowledge base article)
The following updates were made to this guide.
|Date||Description of Changes|
|2020‑06‑02||Added instant-clone dedicated pool, instant-clone dedicated pool with longer-lived instant clones, and full-clone pool to the list of requirements for the VM Hosted Applications feature.|
About the Author
Hilko Lantinga is a Staff End-User-Computing (EUC) Architect in End-User-Computing Technical Marketing, VMware, 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 more than 20 years of experience in end-user computing.
To comment on this paper, contact VMware End-User-Computing Technical Marketing at firstname.lastname@example.org.