You create farms using the Farms page.

About this task


The RDS-enabled assignable image is also referred to as an RDS host or an RDSH (Remote Desktop Services Host) image.

For an example of how rolling maintenance works for a farm, see Example of Farm Rolling Maintenance.


Verify that you have at least one assignable image listed on the Images page, that image has an RDS-enabled Windows server operating system, and that image is located in the node in which you want to create the farm. You cannot create a farm in a node without an assignable image available in that node.

Decide whether this farm will serve session-based desktops or remote applications.


  1. In the Administration Console, navigate to Inventory > Farms.

    Farms page in the Administration Console

  2. Click New.

    The New Farm wizard opens.

  3. In the wizard's Definition step, complete the fields and make your selections as appropriate and then click Next.

    You might have to use the scroll bar to see all of the required fields.




    Enter a name for this farm.


    Enter an optional description.

    Farm Type

    Specify the type of asset this farm will provide to end users:

    • Select Desktops to use this farm to provide session-based desktops.

    • Select Applications to use this farm to provide access to remote applications. After an applications farm is created, you can use the New Application workflow's Auto-scan from Farm option to import applications from the farm's servers into your application inventory.


    Select the location associated with the node that has the RDSH image. This selection filters the choices in the Node field to only the nodes in the selected location.


    Select the node.

    Server Model

    Select the server model to use for the farm's server instances. The server model defines the set of underlying resources that will be used when the farm's server instances are created, in terms of capacity (compute, storage, and so on). The available choices map to standard VM sizes that are available in Microsoft Azure.


    Select the assignable RDSH image.

    Preferred Protocol

    Select a default display protocol you want the end user sessions to use.

    Circumstances might occur that cause another protocol to be used instead of the default protocol. For example, the client device does not support the default protocol or the end user overrides the default protocol selection.

    Preferred Client Type

    Select the preferred client type used when end users launch their session-based desktops from the Workspace™ ONE™ platform's portal, either a Horizon Client or a browser for HTML Access.


    Select the Active Directory domain registered with your environment.

    Join Domain

    Select Yes so that the farm's server instances are automatically joined the domain when they are created.

    Min Servers

    Max Servers

    Specify the minimum number and maximum number of servers you want in this farm. When the farm is first created, the system deploys the number of servers specified in the Max Servers field, and then powers off the servers except the number specified for Min Servers.

    Only the minimum number of server instances is initially powered on. As end user demand increases, the system powers on additional servers, up to the Max Servers number. Then as end user demand shrinks, the system powers off the servers, until it reaches the Min Servers number of servers. A server must be completely empty of user sessions before the system will power it off.

    When you specify zero (0) for Min Servers, it indicates that you want the system to power off all of the farm's servers when there is no end user demand for sessions to the farm. When you enter zero (0) fo Min Servers, the First Server Empty Duration field appears. Use the First Server Empty Duration field to specify the amount of time you want the system to wait after determining the remaining powered-on server has no user sessions before the system powers off that server.

    Sessions per Server

    Specify the number of concurrent end user sessions per server that this farm will allow.


    In this release, you cannot update this number after the farm is created. As a result, you must choose judiciously the value you select here.

    For a node in Microsoft Azure, based on performance testing of user densities, VMware recommends the following maximums. For details about these recommendations and the analysis behind them, see the VMware Horizon Cloud Service™ on Microsoft Azure RDS Desktop and Application Scalability white paper located here in

    • Small (D2V2): 26 concurrent sessions for task workers; 20 concurrent sessions for knowledge workers.

    • Medium (D3V2): 50 concurrent sessions for task workers; 30 concurrent sessions for knowledge workers.

    • Large (D4V2): 85 concurrent sessions for task workers; 60 concurrent sessions for knowledge workers.

    • GPU (NV6): 20 sessions maximum.


    In this release, a farm using NV6 VM size servers is currently limited to 20 sessions maximum per server. If you have selected NV6 servers, do not specify more than 20 here.

    Optionally configure the advanced properties.



    VM Names

    Name for all of the server VMs created for this farm, which will have a number appended to it, for example, win2016-1, win2016-2, etc. The name must start with a letter and can contain only letters, dashes, and numbers.

    Computer OU

    Active Directory Organizational Unit where the server VMs are to be located. For example, OU=RootOrgName,DC=DomainComponent,DC=eng, and so on. The entries must be comma-separated with no spaces in between.

    If you need to use nested Organization Units, see Considerations For Using Nested Active Directory Domain Organizational Units

    Run Once Script

    (Optional) Location of scripts that you want run after system preparation completes.

    Session Timeout Interval

    This is the amount of time the end users' sessions can be idle before the system forces a log off from the session-based desktops or applications that are served by this farm. This timeout applies to the logged-in session to the underlying Windows operating system. This timeout interval is separate from the timeout settings that govern the end users' Horizon Client or HTML Access logged-in session.


    When the system forces the log off in the underlying Windows operating system session, any unsaved data is lost. To prevent an unintended loss of data, set this interval high enough to accommodate the business needs of your end users.

    The default interval is one day (1440 minutes).


    If no user activity occurs before the timeout interval is reached, a message indicates that the user will be logged off if they do not click OK in the next 30 seconds. If the logoff occurs, any unsaved user data, such as documents or files, is lost.

  4. In the wizard's Management step, complete the fields and make your selections as appropriate and then click Next.



    Rolling Maintenance

    Select the maintenance type, either according to a time cadence (Scheduled) or based on user sessions to this farm's servers (Session).

    When Scheduled is selected, configure the maintenance cadence, either daily or weekly. If you choose a daily recurrence, specify the hour at which the maintenance will start. If you choose a weekly recurrence, specify both the day of the week and the hour.

    When Session is selected, specify the number of sessions at which the farm should begin rolling maintenance.


    Sessions which are logged off within 15 minutes are not counted for the purposes of the rolling maintenance calculations, to prevent restarting or rebuilding the servers based on a count of short running sessions.

    In the Concurrent Quiescing Servers field, specify the number of servers that can be in the quiescing state at the same time. When a server is in quiescing state, the server continues to work for the user sessions already connected to that server, but it does not accept any new user connections.

    For a simple example, see Example of Farm Rolling Maintenance.

    Server Action

    Select the action that the system should perform on the servers undergoing maintenance.

    • With Restart, the server VMs are restarted.

    • With Rebuild, the server VMs are first deleted and then reprovisioned from their RDS desktop image.

    If you choose to have the unused servers powered off, they will still consume some storage use in your cloud environment.

    Power Management

    These power management settings are related to the thresholds at which the system automatically grows and shrinks the number of powered-on server instances in the farm according to the session usage on the servers. When the usage grows above an upper bound, the system automatically powers up a new server instance. When the usage shrinks below a lower bound, the system drains the server until it is not being used. Then the system shuts down the server VM and deallocates it.

    The power management selections balance capacity cost with faster availability:

    • Select Optimized Performance when you want the system to power on the next server instance sooner rather than later. Even though you are spending more by having the next server ready to go before the user demand requires it, this setting increases the chance that when users log in, the server is already powered up to meet that demand.

    • Select Optimized Power, when you want the system to wait as long as possible before powering on the next server instance. The occupancy of the servers are higher before the system powers up the next server. Even though this selection minimizes capacity costs by having more utilization of the existing servers, this setting increases the chance that there might be a delay when new users try to log in because they might have to wait during the time system has to power on the server.

    • Select Balanced to strike a balance between capacity costs and time-to-availability for users.

    The low and high thresholds for each selection are:

    • Optimized Performance

      • Low threshold: 27%

      • High threshold: 50%

    • Optimized Power

      • Low threshold: 55%

      • High threshold: 80%

    • Balanced

      • Low threshold: 37%

      • High threshold: 66%

    For an in-depth description about the power management features of Horizon Cloud and descriptions of how they work in various scenarios, see the VMware Horizon Cloud Service™ on Microsoft Azure RDS Desktop and Application Scalability white paper located here in

    Timeout Handling

    Configure how you want the system to handle certain types of user sessions.


    The user sessions governed by these settings are the user logins to the Windows operating system session of the RDS session desktop or application. These sessions are not the user logins in Horizon Client, Horizon HTML Access, or Workspace ONE.

    The user's session begins when the user authenticates to the Windows operating system that underlies the session-based desktop or the remote application that is served from this farm's servers.

    • Empty Session Timeout - For applications farms, select how the system should handle idle user sessions, whether to never timeout idle sessions or to timeout after a specified number of minutes. Idle timeouts are based on the activity on the endpoint device, not on the session-based desktop or application. If you specify to timeout an idle session, select what happens when the timeout period is up: whether to disconnect the session or log the user off. When a session is disconnected, the session is disconnected from the network and preserved in memory. When a session is logged off, the session is not preserved in memory, and any unsaved documents are lost.

    • Log Off Disconnected Sessions - Select when the system logs the user off of a disconnected session.

    • Max Session Lifetime - Specify the maximum number of minutes the system should allow for a single user session.

  5. In the wizard's Summary step, review the settings and then click Submit to begin creating the farm.


The system starts creating the farm. You can monitor the progress using the Activity page. When the farm's status shows a green dot on the Farms page:

  • If you created a desktops farm, you can use it to create a session-based desktop assignment.

  • If you created an applications farm, you can use it to load applications from the servers' underlying RDS-enabled operating system into your Horizon Cloud applications catalog.

Farms in ready state on the Farms page

What to do next

If you created a desktops farm, you would next create a session-based desktop assignment for your end users by following the steps in Create an RDSH Session Desktop Assignment.

If you created an applications farm, you would next scan that farm to load applications into Horizon Cloud and then create an applications assignment so your end users can use the remote applications from that farm.

For more information, see Applications in Your Horizon Cloud Inventory, Importing New Applications from an RDSH Farm Using Auto-Scan from Farm, and Create a Remote Application Assignment.