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 Controller. After you install the initial Controller, you can add more Controllers when you create a Site, or later. 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 database activity. Additional Controllers provide the ability to handle more users and more applications and desktop requests, and can improve overall responsiveness.
Each Controller communicates directly with the Site database. In a Site with more than one zone, the Controllers in every zone communicate with the Site database in the primary zone.
Important: Do not change the computer name or the domain membership of a Controller after the Site is configured.
Before a VDA can be used, it must register (establish communication) with a Delivery Controller in the Site. For information about VDA registration, see VDA registration with Controllers.
(In the documentation for earlier XenApp and XenDesktop 7.x releases, information about VDA registration was included in this article. That information has been enhanced and now resides in the article linked above.)
To add, remove, or move a Controller, you must have the server role and database role permissions listed in the Databases article.
Note: Installing a Controller on a node in an SQL clustering or SQL mirroring installation is not supported.
If your deployment uses database mirroring:
- Before adding, removing, or moving a Controller, ensure that the principal and mirrored databases are both running. In addition, if you are using scripts with SQL Server Management Studio, enable SQLCMD mode before executing the scripts.
- To verify mirroring after adding, removing, or moving a Controller, run the PowerShell get-configdbconnection cmdlet to ensure that the Failover Partner has been set in the connection string to the mirror.
After you add, remove, or move a Controller:
- If auto-update is enabled, the VDAs will receive an updated list of Controllers within 90 minutes.
- If auto-update is not enabled, ensure that the Controller policy setting or ListOfDDCs registry key are updated for all VDAs. After moving a Controller to another Site, update the policy setting or registry key on both Sites.
You can add Controllers when you create a Site and later. You cannot add Controllers installed with an earlier version of this software to a Site that was created with this version.
- Run the installer on a server containing a supported operating system. Install the Delivery Controller component and any other core components you want. Complete the installation wizard.
- If you have not yet created a Site, launch Studio; you are prompted to create a Site. On the Databases page in the Site creation wizard, click the Select button and then add the address of the server where you installed the additional Controller. Important: If you plan to generate scripts that will initialize the databases, add the Controllers before you generate the scripts.
- If you have already created a Site, point Studio to the server where you installed the additional Controller. Click Scale your deployment and enter the Site address.
Removing a Controller from a Site does not uninstall the Citrix software or any other component; it removes the Controller from the database so that it can no longer be used to broker connections and perform other tasks. If you remove a Controller, you can later add it back to the same Site or to another Site. A Site requires at least one Controller, so you cannot remove the last one listed in Studio.
When you remove a Controller from a Site, the Controller logon to the database server is not removed. This avoids potentially removing a logon that is used by other products' services on the same machine. The logon must be removed manually if it is no longer required; the securityadmin server role permission is needed to remove the logon.
Important: Do not remove the Controller from Active Directory until after you remove it from the Site.
- Make sure the Controller is powered on so that Studio loads in less than one hour. Once Studio loads the Controller you want to remove, power off the Controller when prompted to do so.
- Select Configuration > Controllers in the Studio navigation pane and then select the Controller you want to remove.
- Select Remove Controller in the Actions pane. If you do not have the correct database roles and permissions, you are offered the option of generating a script that allows your database administrator to remove the Controller for you.
- You might need to remove the Controller’s machine account from the database server. Before doing this, check that another service is not using the account.
After using Studio to remove a Controller, traffic to that Controller might linger for a short amount of time to ensure proper completion of current tasks. If you want to force the removal of a Controller in a very short time, Citrix recommends you shut down the server where it was installed, or remove that server from Active Directory. Then, restart the other Controllers on the Site to ensure no further communication with the removed Controller.
If your Site contains more than one zone, you can move a Controller to a different zone. See the Zones article for information about how this can affect VDA registration and other operations.
- Select Configuration > Controllers in the Studio navigation pane and then select the Controller you want to move.
- Select Move in the Actions pane.
- Specify the zone where you want to move the Controller.
You cannot move a Controller to a Site that was created with an earlier version of this software.
- On the Site where the Controller is currently located (the old Site), select Configuration > Controllers in the Studio navigation pane and then select the Controller you want to move.
- Select Remove Controller in the Actions pane. If you do not have the correct database roles and permissions, you are offered the option of generating a script that allows someone with those permissions (such as a database administrator) to remove the Controller for you. A Site requires at least one Controller, so you cannot remove the last one listed in Studio.
- On the Controller you are moving, open Studio, reset the services when prompted, select Join existing site, and enter the address of the new Site.
If a VDA was provisioned using Provisioning Services or is an existing image, you can move a VDA to another Site (from Site 1 to Site 2) when upgrading, or when moving a VDA image that was created in a test Site to a production Site. VDAs provisioned using Machine Creation Services (MCS) cannot be moved from one Site to another because MCS does not support changing the ListOfDDCs a VDA checks to register with a Controller; VDAs provisioned using MCS always check the ListOfDDCs associated with the Site in which they were created.
There are two ways to move a VDA to another Site: using the installer or Citrix policies.
Installer: Run the installer and add a Controller, specifying the FQDN (DNS entry) of a Controller in Site 2. Important: Specify Controllers in the installer only when the Controllers policy setting is not used.
Group Policy Editor: The following example moves multiple VDAs between Sites.
- Create a policy in Site 1 that contains the following settings, then filter the policy to the Delivery Group level to initiate a staged VDA migration between the Sites.
Controllers - containing FQDNs (DNS entries) of one or more Controllers in Site 2.
Enable auto update of Controllers - set to disabled.
- Each VDA in the Delivery Group is alerted within 90 minutes of the new policy. The VDA ignores the list of Controllers it receives (because auto-update is disabled); it selects one of the Controllers specified in the policy, which lists the Controllers in Site 2.
- When the VDA successfully registers with a Controller in Site 2, it receives the Site 2 ListOfDDCs and policy information, which has auto-update enabled by default. Since the Controller with which the VDA was registered in Site 1 is not on the list sent by the Controller in Site 2, the VDA re-registers, choosing among the Controllers in the Site 2 list. From then on, the VDA is automatically updated with information from Site 2.