Best Practices for Published Applications and Desktops in VMware Horizon and VMware Horizon Apps


NOTE: This asset was originally written with guidance based on Horizon 7.12. Refer to the Product Lifecycle Policies page for details on the most current supported versions of Horizon.

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 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, 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.


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 Setting up Published Applications and Desktops in Horizon.

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 VMware vSphere® and VMware vSAN™ 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 Technical Papers download page. 

System and Hardware Requirements

Before deploying a system, perform the following tasks:

  1. Verify that all hardware is compatible with the version of the VMware products that you plan to use. See the VMware Compatibility Guide.
  2. If you are using vSAN, ensure that all hardware, including disk controllers, are compatible. See the VMware Compatibility Guide – vSAN Components.
  3. 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 vSphere Documentation.
  4. 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.
  5. 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.


Description automatically generated

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.

A screenshot of a cell phone

Description automatically generated

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 Technical Papers 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.

Active Directory

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. 

You can find more details in the License your RDS deployment with client access licenses (CALs)

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

Graphical user interface, text, application

Description automatically generated

Figure 3: RDSH Licensing options

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

LicenseServers (REG_MULTI_SZ)

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod

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:

  1. Establish a baseline of user requirements.
  2. Calculate CPU requirements based on users’ workloads.
  3. Calculate memory requirements based on users’ workloads.
  4. Perform a load test.
  5. Use a pilot to validate ESXi host requirements.
  6. 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

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 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:

  1. Create the golden RDS host or Hosted Applications VM, install Windows, and go to audit mode.
  2. Install common Microsoft runtimes and features and applications wanted in the golden image.
  3. Install Microsoft updates.
  4. Optimize Windows with the OS Optimization Tool.
  5. Generalize Windows with the OS Optimization Tool.
  6. Finalize Windows with the OS Optimization Tool.
  7. Export the image.

See Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop.

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

For more information, see Deploying Applications that Run on Desktop Pools with VM Hosted Applications.

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:

  1. 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.

    A screenshot of a cell phone

Description automatically generated
    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.

A screenshot of a cell phone

Description automatically generated
Figure 5: Add VM hosted apps desktop pool

  1. Entitlement is done in the same way and the published apps look the same to the user as RDSH hosted applications do.

    A screenshot of a cell phone

Description automatically generated
    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, consider using the more advanced methods that work as outlined in the product documentation.

In addition to the best practices found below, you can find more information on managing RDS Hosts 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.

A screenshot of a cell phone

Description automatically generated

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.

A screenshot of a cell phone

Description automatically generated

Figure 8: Load Balancing Settings tab

Table 1: RDS load balancing options



Use custom script

Select this setting to use a custom script for load balancing. If this setting is enabled, Horizon does not consider other load balancing settings. You cannot use the settings in the Horizon Administrator if you choose to use a script. See Setting RDS Host Load Balancing with a Script.

Include session count 

Select this setting to include the session count on the RDS host for load balancing. If none of the settings are selected for load balancing and if the custom script setting is not selected, Horizon uses the session count by default. Turn off this setting if you do not need to consider the session count for load balancing.

CPU usage threshold 

Threshold value for the CPU usage in percentage. Horizon uses the configured CPU threshold to calculate the CPU load index factor. You can set a value from 0 to 100. The recommended value is 90. By default, this setting is not considered for load balancing. The default value is 0.

Memory usage threshold 

Threshold value for the memory in percentage. Horizon uses the configured memory threshold to calculate the Memory Load Index factor. You can set a value from 0 to 100. The recommended value is 90. By default, this setting is not considered for load balancing. The default value is 0.

Disk queue length threshold 

Threshold of the average number of both read and write requests that were queued for the selected disk during the sample interval. Horizon uses the configured threshold to calculate the Disk Load Index factor. You can set the value to any positive integer. By default, this setting is not considered for load balancing.

Disk read latency threshold 

Threshold of the average time of read of data from the disk in milliseconds. Horizon uses the configured threshold to calculate the Disk Load Index factor. You can set the value to any positive integer. By default, this setting is not considered for load balancing. The default value is 0.

Disk write latency threshold 

Threshold of the average time of write of data to the disk in milliseconds. Horizon uses the configured threshold to calculate the Disk Load Index factor. You can set the value to any positive integer. By default, this setting is not considered for load balancing. The default value is 0.

Setting RDS Host Load Balancing with a Script

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

A screenshot of a cell phone

Description automatically generated

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.

  1. Browse to the following key in the Registry Editor: HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\ScriptEvents
  2. Select the RDSHLoad key
  3. Right-click in the topic area for the RdshLoad key, select New > String Value, and create a new string value.
  4. As a best practice, use a name that represents the load balancing script to be run.
  5. 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"
  6. 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.

For more information, see Configuring Load Balancing for RDS Hosts in Horizon Console.

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 VMware Dynamic Environment Manager Administration Guide.

Horizon Smart Policies are available for configuring USB redirection, client-drive redirection, bandwidth profiles, and more.

Folder Redirection

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 VMware Dynamic Environment Manager Administration Guide.

User Profiles

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.

Printer Configuration

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 product documentation.

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.

Internet Explorer

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.

Microsoft Office

To turn off hardware graphics acceleration for Microsoft Office, navigate to File > Options > Advanced and select Disable hardware graphics acceleration.

Adobe Reader

To turn off hardware graphics acceleration and other CPU-intensive display options for Adobe Reader:

  1. Navigate to Preferences > Page Display > Rendering and deselect the following options:
  • Smooth imaging
  • Smooth line art
  • Use page cache
  • Enhance thin lines
  1. Navigate to Preferences > Page Display > Page Content and Information and select Disable smooth zooming.

For more information, see the Adobe documentation about General Application Settings in the Windows Registry.

Google Chrome

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.

Before installing applications on an AppStack, switch the RDSH server to the RD-Install mode. For more information, see the Quick Start Tutorial on 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.

  • 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
    • %systemroot%\SoftwareDistribution\DataStore
    • %allusersprofile%\NTUser.pol
    • *.pst, *.pstx, and *.ost files – %systemroot%\System32\Spool\Printers
    • %ProgramData%\VMware\VDM\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

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.

A screenshot of a cell phone

Description automatically generated

Figure 13: Schedule recurring maintenance

You can choose whether to log out users or wait for them to log out before performing maintenance.

A screenshot of a cell phone

Description automatically generated

Figure 14: Configuring logout behavior for maintenance operations

Drain Mode

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:

HKLM\System\CurrentControlSet\Control\Terminal Server\TSServerDrainMode

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.

Additional Resources



Description of Changes


  • Updated and added links to new content.
  • Updated vSphere performance guidance section to point to directly to vSphere performance best practices content.


  • 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.



  • Added information about the VM Hosted Apps feature, introduced in Horizon 7.9, which includes Windows 10 desktop application publishing.
  • Updated for Horizon 7.12.
  • Updated for vSphere 6.7 and 7.0.
  • Renamed User Environment Manager to Dynamic Environment Manager.

About the Authors and Contributors

Hilko Lantinga 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.


  • Richard Terlep, Staff Technical Marketing Architect, End-User Computing, VMware.


Your feedback is valuable.

To comment on this paper, contact VMware End-User-Computing Technical Marketing at

Filter Tags

Horizon Horizon Horizon Apps Document Deployment Considerations Intermediate Design Deploy Optimize Modern Management Windows Delivery