The Application server farms feature (ASF) allows to deploy new machines (App Servers) on an existing AppServer template and assign new users and groups on SDI mode. It also allows assigning those published applications per template. It's the entity that keeps the relationship between the relevant Citrix components involved in the deployment of the machines (mainly catalogs and delivery groups).

The Application server farm "Detail" screen shows the related template data in the General area:

If the "Automatically Apply Changes To Applications From The Template" control is checked (default option), each change in the template will be automatically applied to the linked ASF. Otherwise, any change should be manually propagated in each linked ASF. Several ASF can be based on the same template. However, just one ASF per template is allowed to have that setting activated. 

To deselect this option, please use the "Stop applying changes on the application from the template" button, which is located in the top right side of the "Detail" screen, between the "Open template" and the navigation buttons(<>). Once this option is deactivated and saved, rollback isn't possible.

The "A.D. Organizational Unit" area shows the OU data:

The next area is comprised of six tabs. The "Delivery groups" list is displayed by default and shows the current ASF assignments:

The selected "Delivery group detail" screen provides with the related ASF basic data as well as a VM counter, to increase/decrease the number of app servers in the farm:

This template can be assigned/unassigned to users or groups in the "USERS/GROUPS" area on the bottom side of this screen:

Also, for ASFs with delivery type "Desktops & apps" and "Apps only", restart schedules for the application servers can be configured in the "Restart schedules" tab:

Notes: 

• The "Restart schedules" tab if visible for a delivery group only once the ASF has been saved.
• Multiple schedules can be created for the same delivery group, and they can overlap. To learn more about restart schedules, please read https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/install-configure/delivery-groups-manage.html#shut-down-and-restart-machines-in-a-delivery-group
• Citrix Virtual Apps & Desktops supports multiple restart schedules per delivery group since version 7.12, but if you use the Citrix Studio management console, be aware that multiple schedules can only be displayed and managed from version 1912. If, for example, you create multiple schedules in a Citrix Virtual Apps & Desktops in a 7.15 version by using Flexxible|SUITE, they will be functional, but only the first one will be visible from Citrix Studio, although you can query them by using the PowerShell API.

Enabled: When this box is unchecked, you can define and save the schedule to Citrix Virtual Apps & desktops, but it will be disabled. You can use this checkbox to temporarily disable a particular restart schedule.

Restrict to VMs with tag: optionally, a tag defined in the Citrix Virtual Apps & Desktops site can be associated to this restart schedule, so it only applies to VMs that have been assigned this tag. For example, a restart schedule could be associated to the tag "Marketing Dpt app servers". If this field is left empty, the schedule applies to every VM in the delivery group.

Frequency: It can be daily or weekly. When the frequency is weekly, the day of the week must be selected. You can create multiple weekly restart schedules, each one for a different day of the week.

Day: For weekly frequency, it is the day of the week that the schedule will be executed.

Start time: the time of day (in 24 hour format) at which the restart schedule begins execution. The exact time that a particular VM will be restarted depends on the schedule configuration and the number of VMs in the delivery group that must be restarted.

Maximum overtime start minutes: If some condition -like a temporary database access problem- prevents the execution of the scheduled restart, this value indicates the maximum number of minutes past the scheduled start time after which the restart will not be executed. If the zero value is specified, the restart will take place no matter how much time elapsed from the scheduled start time. Note that this behaviour could be confusing for users and administrators if a restart schedule is executed at an unexpected time, just after the blocking problem is solved.

Reboot duration: The time frame in minutes within which the restart of VMs takes place. If the zero value is specified, all the VMs will be restarted simultaneously.

Drain: if the box is checked, the VMs will be restarted when they happen to have no open sessions.

Ignore maintenance mode: if the box is checked, VMs affected by the restart schedule will be restarted regardless of they being set in maintenance mode.

Warning duration: For how many minutes the user of a desktop open session or published application in the VM will be warned that an automatic restart will be performed. The zero value means that no warning will be displayed to the user.

Warning repeat interval: Every how many minutes the restart warning is repeated within the warning duration minutes.

Warning title: The title of the warning message to display to the user.

Warning message: The text of the warning message to display to the user. You can use the placeholder '%m%' value to automatically indicate the number of remaining minutes until the VM is automatically restarted, for example: "Please save your documents to prevent losing your work. The VM will be restarted in %m% minutes for maintenance tasks."

The changes made to restart schedules are applied to Citrix Virtual Apps & Desktops as an equeued job when the "Process pending changes" button is pressed in the ASF.

A new delivery group may be created from the "Delivery groups" tab by first clicking on the "New" button:

and second, by populating the "New delivery group" form:

Please, refer to the catalog management article for more information about catalogs.

The "Jobs" tab shows both the manual and the automatic jobs run for the selected ASF:

Changes applied to the selected template were logged and are displayed in the "Logs" tab:

The "VMs" tab shows all the app servers that belong to this ASF:

By clicking on the “Deployment overrides” tab we will be able to configure some resources for the new catalogs of this ASF:

The "Published applications" tab allows seeing those published apps from the selected ASF. If the auto-propagate changes option (checkbox) is activated in the General area, neither the "Import" nor the "New" options are available here:

If the auto-propagate changes option (checkbox) is activated in the General area, both the "Import" and the "New" options are available here:

It's mandatory to click on the "Save" button before exiting from an ASF, in order to perform and process any change to it:

Any published application properties can be checked out by selecting any application on the list. Users or groups can be assigned to the selected application at its detail screen:

To set up the Azure subnets, storage account type and hybrid benefit support you must configure the following parameters:

• VMStorageAccountType: Specifies the Azure storage account SKU type to use for new VM catalogs. Possible values: Standard_LRS (default), Premium_LRS.
• EnableAzureHybridBenefit: [true/false (default)] Indicates if Azure Hybrid Benefit licensing will be used for new VMs.

The changes in these settings will be applied in the new catalogs, the existing catalogs will maintain the previous configuration.