You create farms using the Farms page.
For an example of how rolling maintenance works for a farm, see Example of Farm Rolling Maintenance.
- Verify that you have at least one image listed on the Images page, that image has an RDS-enabled Windows server operating system, the Images page shows that image is in Published state, and that image is located in the pod in which you want to create the farm. You cannot create a farm in a pod without such an image available in that pod.
- Verify whether you are eligible to use the Azure Hybrid Benefit (also known as Azure Hybrid Use Benefit or HUB) with the image's Microsoft Windows Server operating system. When you are eligible to use the Azure Hybrid Benefit with your VMs in Microsoft Azure, you can choose to apply your Azure Hybrid Benefit to this farm's server instances.
- Decide whether this farm will serve session-based desktops or remote applications. In this release, the same farm cannot serve both.
- Decide whether you want the farm's servers to have encrypted disks. You must specify disk encryption when creating the farm. You cannot later add disk encryption after the farm is created. For a description of the disk capability, see Using Microsoft Azure Disk Encryption with Your Farms and VDI Desktops.
Important: If you are creating this farm in a pod that was upgraded from manifest version 740 or earlier, and you plan to use an image that existed in the pod before the pod upgrade, do not encrypt the farm. The encryption process fails if the image was created when the pod was at manifest version 740 or earlier. Such images do not have a working Microsoft Azure Agent, which is required for encrypting VMs. To re-use such an image for an encrypted farm, you must:
- Duplicate the image. This action creates a new master VM based on the existing image. This new master VM has the required Microsoft Azure Agent.
- Convert the duplicate to an image. This action creates a sealed image from the duplicate.
- Use that new sealed image when creating the encrypted farm.
- Decide whether you want the ability to use NSX Cloud features with the farm's server VMs. You must enable NSX Cloud management when creating the farm. You cannot later enable the farm for NSX Cloud management after the farm is created. The published image you choose for this farm must have the NSX agent installed in it. You must have installed the NSX agent prior to publishing the image. See VMware NSX Cloud and Horizon Cloud Pods in Microsoft Azure and its subtopics.
- In the Administration Console, navigate to
- Click New.
The New Farm wizard opens.
- In the wizard's Definition step, complete the fields and make your selections as appropriate and then click Next.
Note: You might have to use the scroll bar to see all the required fields.
Option Description Name Enter a name for this farm. Description Enter an optional description. VM Names Base name for all of the server VMs created for this farm. The VM names will have numbers appended to this base name, for example, win2016-1, win2016-2, etc. The name must start with a letter and can contain only letters, dashes, and numbers. Farm Type Specify the type of asset this farm provides 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.
Location Select the location associated with the pod that has the RDSH image. This selection filters the choices in the Pod field to only the pods in the selected location. Pod Select the pod. Filter Models Set one or more filters to control the models available in the Models drop-down menu. You can filter models by type, series, number of CPUs, memory, and tags. For more information about selecting models, see Managing VM Types and Sizes for Farms and Assignments, which describes the options on the VM Types & Sizes page ( ).
To set a filter, you first select the criterion in the drop-down menu and then enter the desired value(s). By default, there is a single filter with the criterion 'Tag' the value 'VMware Recommended'. You can edit this first filter and add more filters connected by And and Or operators.The following are the criteria you can use for filters and descriptions of the values you can enter for each.
You can set additional filters by performing the following steps for each filter:
When you select this option, there is only value available in the second drop-down menu:
- GPU and High Performance - Models with GPU.
Note: If you choose a GPU model (for example, Standard_NV6), then the list of images shown will contain only images that were created with the Include GPU flag selected, so you need at least one such image in order to create a farm or pool using a GPU model. If you choose a non-GPU model, then the list of images shown will contain only images that were created without the Include GPU flag.
- GPU and High Performance - Models with GPU.
When you select this option, you can then select a series of models from a second drop-down menu. You can also filter this list by entering text in the Filter text box at the top of the list.
When you select this option, you can then enter a CPU range.Important: For production environments, to avoid unexpected end-user connection issues, use VM models that have a minimum of two (2) CPUs.
When you select this option, you can then enter a range of memory in GBs.
When you select this option, you can then select a tag from a second drop-down menu. You can also filter this list by entering text in the Filter text box at the top of the list. Tags available in the drop-down menu are both hard-coded system tags and custom tags that you created on the VM Types & Sizes page ( ).
Note: If the model you selected to create the farm becomes unavailable in the future, you will not be able to expand the farm. The farm remains fully functional except for this limitation. To see if a VM type is available, navigate to the VM Types & Sizes page ( ).
- Click the Add link.
- Select either And or Or as the operator between the previous filter and the new one you are creating.
- Set the new filter by selecting a criterion and entering value(s).
Model Select the VM model to use for the farm's server instances. This selection 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.Important: For production environments, select a VM model that has a minimum of two (2) CPUs. VMware scale testing has shown that using 2 CPUs or more avoids unexpected end-user connection issues. Even though the system does not prevent you from choosing a VM model with a single CPU, you should use such models for tests or proof-of-concepts only. Image Select the assignable RDSH image.Important: If you set the NSX Cloud Managed toggle to Yes, ensure that the image you select here has the NSX agent installed on it. For the NSX Cloud management features to work with the farm's server instances, the image that you select for this farm must have the NSX agent already installed on it. The system does not verify if the selected image has the NSX agent when it creates the farm. 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 start their session-based desktops from the Workspace™ ONE™ platform's portal, either a Horizon Client or a browser for HTML Access. Domain 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. Encrypt Disks Select Yes so that the farm's server instances have encrypted disks.Important: If you want disk encryption, you must make this selection when creating the farm. You cannot later add disk encryption after the farm is created. NSX Cloud Managed Select Yes so that you can use features of NSX Cloud with the farm's server instances. For a description of using NSX Cloud features with your farms in Microsoft Azure, see VMware NSX Cloud and Horizon Cloud Pods in Microsoft Azure and its subtopics.Important:
- If you want to use NSX Cloud with the farm's server instances, you must make this selection when creating the farm. You cannot later enable NSX Cloud management after the farm is created.
- For the NSX Cloud management features to work with the server instances, the image that you select for this farm must have the NSX agent already installed on it. When you set this toggle to Yes, ensure that the image you select in Image has the NSX agent installed on it. The system does not verify if the selected image has the NSX agent when it creates the farm.
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 powers it off.
When you specify zero (0) for Min Servers, it indicates that you want the system to power off all the farm's servers when there is no end-user demand for sessions to the farm. When you enter zero (0) for Min Servers, use the Power Of Protect Time 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.
Power Off Protect Time Specify the number of minutes that you want the system to wait before automatically powering off a powered-on server instance. You can enter a value from 1 to 60. The default is 30 minutes.
This protect time is used primarily for the situations where the system would normally power off a server VM. You can use this Power Off Protect Time setting to tell the system to wait the specified time before starting to power off the VM. The default wait time is 30 minutes.
Sessions per Server Specify the number of concurrent end-user sessions per server that this farm will allow.
For a pod in Microsoft Azure, based on performance testing of user densities, VMware has some recommended 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 vmware.com.Note:
Optionally configure the advanced properties.
- Due to an NVIDIA driver limitation, if your GPU-enabled master image has Microsoft Windows Server 2012 R2 for its operating system, a farm using that image for its servers is limited to 20 sessions maximum per server. If you have that particular combination (image with GPU, Microsoft Windows Server 2012 R2, NVIDIA drivers, and an NV-series server model), do not specify more than 20 here.
Option Description Computer OU Active Directory Organizational Unit where the server VMs are to be located. Enter the Active Directory Organizational Unit using the distinguished name, for example,
OU=RootOrgName,DC=DomainComponent,DC=eng, and so on. The OU and each path in a nested OU can contain any combination of letters, numbers, special characters, and spaces, and can have a maximum of 64 characters.
If you need to use nested Organization Units, see Considerations For Using Nested Active Directory Domain Organizational Units.Note: If the Computer OU is set to
CN=Computers, the system uses the default Active Directory
Computerscontainer for VMs. Your Active Directory might have this default container redirected to an organizational unit class container.
Run Once Script (Optional) Location of a script that you want run in the farm's server VMs after the VM creation process.Note: The script should end with a reboot step to reboot the VM. A sample reboot line as a Windows command is:
shutdown /r /t 0
The script is run after the Microsoft Windows System Preparation (Sysprep) process. When the system creates a server VM for the farm, the VM starts up and completes the Sysprep process in the Windows operating system. When the Sysprep process completes, the agent in the VM reaches out to do the domain join. At the same time, the agent gets the script path you specify here. The agent sets the
Windows RunOncepath (
System run once) and then restarts the server VM. On the next restart, the system logs in to the Windows operating system using the local administrator account and runs the script.
Azure Resource Tags
(Optional) Create custom tags to be applied to Azure resource groups. Azure resource tags are only applied to the resource groups, and are not inherited by the resources in the groups.
To create the first tag, enter information in the Name and Value fields. To create an additional tag, click Add and then enter information in the Name and Value fields that appear below the existing ones.
Note: You can only add tags when creating the farm. After a farm has been created, you cannot add, edit, or delete Azure resource tags for that farm.
- You can create a maximum of 10 tags.
- The tag name is limited to 512 characters, and the tag value is limited to 256 characters.
- Tag names cannot contain the following characters:
< > % & \ ? /
Windows License question
This toggle and its associated check box indicate:
- Whether you are eligible to use the Azure Hybrid Benefit (also known as Azure Hybrid Use Benefit or HUB) with the image's Microsoft Windows Server operating system.
- Whether you want to use the Azure Hybrid Benefit with this farm's server instances.
The farm's server instances will be created with the HUB setting that is indicated here. By default, this toggle is set to match the HUB property set in the base image you specify in Image. For example, if the base image was created with the HUB setting as Yes, this toggle is automatically set to Yes. If the base image was created with the HUB setting as No, this toggle is automatically set to No.
If the toggle is set to No and you are eligible to use the Azure Hybrid Benefit, you can set this toggle to Yes to have the farm's server instances use the Hybrid Benefit. If you change this toggle to Yes, you must also check the check box that is displayed.
When this toggle is set to Yes, it means both:
- That you are eligible to use the HUB with the server instances' Microsoft Windows Server operating system
- That you want to have the farm's server instances use the HUB setting
As described in the Microsoft Azure documentation, the Azure Hybrid Benefit is designed by Microsoft to save you money when you already have valid Microsoft Windows licenses. The Azure Hybrid Benefit FAQ is located in the Microsoft Azure documentation at https://azure.microsoft.com/en-us/pricing/hybrid-benefit/faq/. According to the Microsoft Azure documentation, when you have a Windows Server license with Software Assurance or a Windows Server subscription for the selected server operating system, you can use the Azure Hybrid Benefit for your virtual server instances that have those Windows Server operating systems.
- In the wizard's Management step, complete the fields and make your selections as appropriate and then click Next.
Option Description 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.Note: 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.
These power management settings are related to the thresholds at which the system automatically increases and shrinks the number of powered-on server instances in the farm according to the session usage on the servers. When the usage increases 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 the maximum amount of time possible before powering on the next server instance. The occupancy of the servers is higher before the system powers up the next server. Even though this selection minimizes capacity costs by getting higher use 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: 23%
- High threshold: 50%
- Optimized Power
- Low threshold: 38%
- High threshold: 80%
- Low threshold: 31%
- 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 vmware.com.
Timeout Handling Configure how you want the system to handle certain types of user sessions.Note: 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 time out idle sessions or to time out 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 time out 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.
Session Timeout Interval This time interval 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. The time you specify here is different from the time out settings that govern the end users' Horizon Client or HTML Access logged-in session.Caution: 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).Note: 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 logout occurs, any unsaved user data, such as documents or files, is lost.
Schedule Power Management
To help optimize savings and performance of the farm's server VMs in Microsoft Azure, you can optionally configure schedules to adjust the minimum number of powered-on servers in this farm on a recurring weekly basis. For example:
- For weekends or night hours when you know that your end users will not be using their desktops or remote applications, you can have a schedule for zero or a low number of powered-on servers.
- For specific days or specific hourly stretches that you can predict will have increased end-user demand, you can have a schedule that increases the minimum number of powered-on servers to be available to meet that demand.
You can specify up to 10 schedules for the farm. If any schedules have overlapping time periods but specify different minimum server numbers, the system uses the largest value of minimum servers for the overlapping time period.
- Click the + icon to add the first row in the Schedule Power Management section.
- Type an identifying name for the first schedule.
- Select the days for the first schedule.
Note: One day is automatically selected by default when the row is added. If you do not want to include the selected day in this schedule, click the drop-down and deselect that selected day.
- Specify the applicable hours in the specified days. Either:
- Select the All Day check box to have this schedule in effect for all hours of the specified days.
- Specify start and end times for the time period in each day.
Note: Encrypted VMs take longer to power on than non-encrypted VMs. If you have set Encrypt Disks to Yes, and you want 100% of the encrypted VMs to be ready for end-user connections at a particular time of day, you might have to set an earlier start time here. See When Scheduling Power Management for Farms and VDI Desktop Assignments That Have Large Numbers of Encrypted VMs.
- Select the time zone. The time zone closest to your end users' location is recommended. As appropriate for the selected time zone, Daylight Savings Time is automatically applied.
Note: If two schedules have the same time zone setting and have overlapping times, a warning is displayed. However, if two schedules have different time zone settings and overlap, the warning is not displayed. As an example, if you have two all-day Saturday schedules and one has Europe/London time zone selected and the other has America/Toronto selected, the overlap warning does not display.
- In the Min Servers field, type the minimum number of servers you want powered on during the specified time period. During the specified time period, that number of servers at a minimum will be powered on to be available to take end-user requests during that time. The number can range from zero (0) up to the number specified for Max Servers for the farm. When this number is zero (0) and there are no active end-user sessions at the schedule's starting time point, the farm's servers are powered off. In that scenario, if an end user then attempts to connect to a desktop or application served by this farm during the scheduled time period, there will be a delay before the desktop or application is in a usable state because the underlying server VM has to power on.
- 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.
Also, when an image VM has a data disk, additional time is needed for creating an encrypted farm server VM based on that image VM. The longest times occur for data disks of larger, terabyte sizes.
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.
If the image for this farm has applications that require opening special ports, you might need to modify this farm's associated Network Security Group (NSG) in Microsoft Azure. For details about the NSG, see About Network Security Groups and Your Farms.
If you specified NSX Cloud management for this farm, you can use your NSX Cloud environment's Service Manager (CSM) to see that the farm's server VMs are managed in NSX Cloud. Log in to your environment's CSM and navigate to Managed for the server instances, you can start implementing NSX policies on them.. When that Instances page shows a status of