- Cumulative Update 6 (CU 6)
- Cumulative Update 5 (CU5)
- Cumulative Update 4 (CU4)
- Cumulative Update 3 (CU3)
- Cumulative Update 2 (CU2)
- Cumulative Update 1 (CU1)
- Long Term Service Release (LTSR)
- Features not in this release
- Known issues
- System requirements
- Technical overview
- Install and upgrade analytics
- Prepare to install
- Prepare the virtualization environment - VMware
- Prepare the virtualization environment - Microsoft System Center Virtual Machine Manager
- Prepare for using Microsoft System Center Configuration Manager
- Install using the graphical interface
- Install using the command line
- Create a Site
- Install or remove Virtual Delivery Agents using scripts
- Install VDAs using the standalone package
- Machine catalogs
- Delivery groups
- XenApp published apps and desktops
- VM hosted apps
- VDI desktops
- Remote PC Access
- Local App Access and URL redirection
- Server VDI
- Remove components
Upgrades and migration
- Install and upgrade analytics
- Upgrade a deployment
- Migrate XenApp 6.x
- Install and upgrade analytics
- Migrate XenDesktop 4
- Work with policies
- Policy templates
- Create policies
- Compare, prioritize, model, and troubleshoot policies
- Default policy settings
Policy settings reference
- ICA policy settings
- Load management policy settings
- Profile management policy settings
- Receiver policy settings
- Virtual Delivery Agent policy settings
- Virtual IP policy settings
- Configure COM Port and LPT Port Redirection settings using the registry
- Connector for Configuration Manager 2012 policy settings
- Connections and resources
- Connection leasing
- Virtual IP and virtual loopback
- Secondary database locations
- Delivery Controller environment
- Session management
- Using Search in Studio
- IPv4/IPv6 support
- Client folder redirection
- Personal vDisk 7.x (Excluded from LTSR)
- User profiles
- Get started with Session Recording
- Grant access rights to users
- Create and activate recording policies
- Disable or enable recording
- Configure the connection to the Session Recording Server
- Create notification messages
- Enable custom event recording
- Enable or disable live session playback and playback
- Enable or disable playback protection
- Enable and disable digital signing
- Specify where recordings are stored
- Specify file size for recordings
- View recordings
- Troubleshoot Session Recording
- Reference - Manage your database records
- Third Party Notices
- Personal vDisk
- Configuration Logging
- Monitor Service OData API
- XenApp and XenDesktop SDK
- Citrix VDI Best Practices for XenApp and XenDesktop 7.6 LTSR
- Third party notices
Delivery Controller environment
May 28, 2016
In a deployment, the Delivery Controller is the server-side component that is responsible for managing user access, plus brokering and optimizing connections. Controllers also provide the Machine Creation Services that create desktop and server images.
A Site must have at least one Delivery Controller. After you install the initial Controller and create a Site, you can add additional Controllers. There are two primary benefits from having more than one Controller in a Site.
- Redundancy — As best practice, a production Site should always have at least two Controllers on different physical servers. If one Controller fails, the others can manage connections and administer the Site.
- Scalability — As Site activity grows, so does CPU utilization on the Controller and SQL Server database activity. Additional Controllers provide the ability to handle more users and more applications and desktop requests, and can improve overall responsiveness.
Before a VDA can be used, it must register (establish communication) with a Controller on the Site. The VDA finds a Controller by checking a list of Controllers called the ListofDDCs. The ListOfDDCs comprises one or more DNS entries or IP addresses that point the VDA to Controllers on the Site. For load balancing, the VDA automatically distributes connections across all Controllers in the list.
In addition to the ListOfDDCs, the ListOfSIDs indicates which machine Security IDs (SIDs) the VDA allows to contact it as a Controller. The ListOfSIDs can be used to decrease the load on Active Directory or to avoid possible security threats from a compromised DNS server.
It is important to ensure that the ListOfDDCs and ListOfSIDs on all VDAs contain current information as Controllers are added and removed in the Site. If the lists are not updated, a VDA might reject session launches that were brokered by an unlisted Controller. Invalid entries can delay the startup of the virtual desktop system software. To keep the lists current, you can:
- Use the auto-update feature, which automatically updates the ListOfDDCs and ListOfSIDs as Controllers are added or removed. By default, auto-update is enabled.
- Self-manage – that is, manually update policy or registry settings that identify Controllers.
Information in the ListOfDDCs and ListOfSIDs can come from several places in a deployment. The VDA checks the following locations, in order, stopping at the first place it finds the lists:
A persistent storage location maintained for the auto-update feature. This location contains Controller information when auto-update is enabled and after the VDA successfully registers for the first time after installation. (This storage also holds machine policy information, which ensures that policy settings are retained across restarts.)
For its initial registration after installation, or when auto-update is disabled, the VDA checks the following locations.
Policy settings (Controllers, Controller SIDs).
The Controller information under the Virtual Desktop Agent key in the registry. The VDA installer initially populates these values, based on Controller information you specify when installing the VDA.
OU-based Controller discovery. This is a legacy method maintained for backward compatibility.
The Personality.ini file created by Machine Creation Services.
If a ListOfDDCs specifies more than one Controller, the VDA attempts to connect to them in random order. The ListOfDDCs can also contain Controller groups, which are designated by brackets surrounding two or more Controller entries. The VDA attempts to connect to each Controller in a group before moving to other entries in the ListOfDDCs.
For XenDesktop users who have upgraded from versions earlier than 7.0, the auto-update feature replaces the CNAME function from the earlier version. You can manually re-enable the CNAME function, if desired; however, for DNS aliasing to work consistently, you cannot use both the auto-update feature and the CNAME function. See CTX137960 for information about re-enabling the CNAME functionality.
The policy setting that enables/disables auto-update is enabled by default.
The following types of deployments cannot use auto-update, and must self-manage.
- Deployments that use Controller groups.
- Deployments that use ListOfSIDs for security reasons. (Deployments that use ListOfSIDs to decrease the Active Directory load can use auto-update.)
- Deployments that use Provisioning Services without a write-back disk.
- Deployments that use the Controllers or Controller SIDs policy setting.
The auto-update policy setting is located in the Virtual Delivery Agent category.
- To enable auto-update, enable the Enable auto update of Controllers policy setting. This setting is enabled by default.
- To disable auto-update, disable the Enable auto update of Controllers policy setting.
When auto-update is enabled and you install a VDA, the VDA attempts to register with one of the Controller values you specified when you installed the VDA. The installer writes the Controller information you specify during VDA installation to the ListOfDDCs registry value.
After the VDA registers, the Controller with which it registered sends a list of the current Controller Fully Qualified Domain Names (FQDNs) and Security IDs (SIDs) to the VDA. The VDA writes this list to the auto-update persistent storage. Each Controller also checks the Site Configuration Database every 90 minutes for Controller information – if a Controller has been added or removed since the last check, or if a policy change has occurred, the Controller sends updated lists to its registered VDAs. The VDA will accept connections from all the Controllers in the most recent list it received.
If a VDA receives a list that does not include the Controller it is registered with (in other words, that Controller was removed from the Site), the VDA re-registers, choosing among the Controllers in the list. After a VDA registers or re-registers, it receives an updated list.
- A deployment has three Controllers: A, B, and C. A VDA is installed and registers with Controller B (which was specified during VDA installation).
- Two Controllers (D and E) are added to the Site. Within 90 minutes, VDAs receive updated lists and will accept connections from Controllers A, B, C, D, and E. (The load will not be spread equally to all Controllers until the VDAs are restarted.)
- Controller B is removed from the Site. Within 90 minutes, VDAs receive updated lists because there has been a Controller change since the last check. The VDA installed in step 1 is registered with Controller B, which is no longer on the list, so that VDA re-registers, choosing among the Controllers in the current list (A, C, D, and E).
If you do not use auto-update, you must update the Citrix policy setting or registry values for each Virtual Delivery Agent (VDA) in the site (or the VDA image) after you add, move, or remove Delivery Controllers in the Site. Registry changes can also be updated using Group Policy Object.
To self-manage using Citrix policy settings:
- Update the FQDN values specified in the Controllers policy setting. This policy setting is located in the Virtual Delivery Agent category.
- If you also use ListOfSIDs in your deployment, update the SID values specified in the Controller SIDs policy setting.
To self-manage using the registry:
Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
Update the ListOfDDCs registry key, which lists the FQDNs of all the Controllers in the Site. (This key is the equivalent of the Active Directory Site OU.) Separate multiple values with spaces. Surround Controller groups with brackets.
pre codeblock HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
If the HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent registry location contains both the ListOfDDCs and FarmGUID keys, ListOfDDCs is used for Controller discovery; FarmGUID is present if a site OU was specified during VDA installation.
Optionally, update the ListOfSIDs registry key:
pre codeblock HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)