To disconnect or log off a session
1. From the Virtual Desktops In Use view, select the session.
2. From the task pane, select Disconnect or Logoff respectively.
If you log off a session, it closes and the desktop becomes available to other users, unless it is assigned to a specific user.
If you disconnect a session, the user’s applications continue to run and the desktop remains assigned to that user. If the user reconnects, the same desktop is assigned. You can configure a time-out to ensure that disconnected sessions are logged off automatically after a certain number of minutes; for further
information about this, see “Configuring Connection Timers” on page 99.
To send a message to users
1. From the task pane, select Send message.
2. In the dialog box that appears, type your message, then click OK to send the message to all selected users.
Manually Controlling Virtual Machines
For VM-based desktop groups, you can manually control VMs through the Access Management Console.
If you want to manually control the power state of a VM in a group that uses the idle pool settings, put it into maintenance mode as described in “To put a desktop into maintenance mode” on page 104.
To start virtual machines
1. Select the relevant desktop group in the console tree.
2. From the Virtual Desktops view, select the relevant desktops.
3. To start powered-off or suspended VMs, from the Tasks list, select Start.
The VMs are powered-on or resumed and the list of desktops is refreshed to show the new state.
Note: If the hosting infrastructure does not support the power-on function, the Start task is not available.
To shut down and restart virtual machines
1. Select the relevant desktop group in the console tree.
2. From the Virtual Desktops view, select the relevant desktops.
3. From the Tasks list, select Shutdown/suspend.
The Shutdown/Suspend Virtual Machine dialog box appears.
4. Select from the following options. Depending on the state of the machine, some of these options may not be available:
• Shutdown. Requests the VM’s operating system to shut down.
Note: If the machine does not shut down within 10 minutes, it is powered off. If Windows attempts to install updates during shutdown, there is a risk that the machine will be powered off before the updates are complete.
• Power off. Forcibly powers off the VM and refreshes the list of desktops.
• Shutdown and Restart. Requests the VM’s operating system to shut down and then start the VM again. If the operating system is unable to do this, the VM remains in its current state.
• Power off and Restart. Forcibly restarts the VM.
• Suspend. Pauses the VM without shutting it down and refreshes the list of desktops.
Migrating Controllers to Other Farms
If, for example, you want to move a controller from a test or pilot farm into production, you may need to migrate it to another farm. To do this, you need Active Directory permissions over the OU structure of both the controller’s existing farm and the controller’s new farm.
If you remove all the controllers from a farm, Citrix recommends that you delete the farm OU.
Citrix recommends that you do not move controllers to a farm created using an earlier version of XenDesktop, Desktop Delivery Controller or Desktop Server; if you do this your farm may become unusable.
9 Managing Your Desktop Delivery Controller Deployment 107
To migrate a controller to another farm
1. Remove the controller from the old farm OU. To do this, use the ADSetup tool with the REMOVECONTROLLER parameter, as described in
“Configuring Active Directory Using ADSetup” on page 122.
2. Use the chfarm utility to either create a new farm (if this is the first controller in the farm) or move the controller to the new farm (if this is the second or subsequent controller in the farm). For further information on chfarm, see the Citrix Presentation Server Administrator’s Guide.
When using chfarm to move a controller to a new farm, make sure you configure the zone name, zone preference, and license server details correctly, because you cannot easily change these later.
3. Add the controller to the new farm OU. To do this, use the ADSetup tool with the ADDCONTROLLER parameter, as described in “Configuring Active Directory Using ADSetup” on page 122.
4. Restart the controller to make the new farm settings take effect.
Migrating Desktops to Other Farms
1. Remove the desktops from the desktop group in the old farm. For details of how to do this, see “To update a desktop group” on page 90.
2. Note the farm GUID of the new farm. This is one of the read-only farm properties in the Access Management Console.
3. In the new farm, add the desktops to an existing or new desktop group.
There are various ways in which you can do this; for details, see “Creating and Updating Desktop Groups” on page 75.
4. Apply the new farm’s GUID to the desktops. To do this, use Group Policy.
The Desktop Delivery Controller Farm GUID policy enables you to use a generic desktop image with multiple XenDesktop deployments. The administrative template (ADM) file is supplied on the Desktop Delivery Controller installation media:
platform\lang\support\configuration\FarmGUID.adm
For information about how to use ADM files, consult your Active Directory documentation.
5. Check the registry to ensure that the group policy has propagated to the desktop computer, then restart the computer. This registers the desktop with a controller in the new farm. Until you do this, the desktop is not available to users.
Updating License Server Settings
During installation you specify the name of the license server your farm accesses to check out licenses and the port number the license server uses to communicate.
You may want to change these settings in the following instances:
• You rename your license server
• The default port number (27000) is already in use
• You have a firewall between the license server and the computers running your Citrix products, and you must specify an alternative Citrix vendor daemon port number
Use the License Server page of the farm’s properties to change the name of the license server or port number that the license server uses to communicate. You can apply the changes to either an individual server or an entire farm. You must also take the following actions:
• If you decide to change the license server name, first ensure that a license server with the new name already exists on your network. Because license files are tied to the license server’s host name, if you change the license server name, you must download a license file that is generated for the new license server. This may involve returning and reallocating the licenses. To return and reallocate your licenses, go to www.mycitrix.com. For
additional information, see Licensing: Migrating, Upgrading, and Renaming, which you can download from
http://support.citrix.com/pages/licensing/.
• If you change a port number, you must specify the new number in all license files on the server. For additional information, see Licensing:
Firewalls and Security Considerations, which you can download from http://support.citrix.com/pages/licensing/.
To specify a license server for the farm
1. In the left pane of the Access Management Console, select the farm.
2. From the Action menu, select Modify farm properties > Modify all properties.
3. From the Properties list, select License Server.
4. Enter the name or IP address of the license server in the Name box.
5. Enter the license server port number in the Port number (default 27000) box.
6. Click Apply to implement your changes.
9 Managing Your Desktop Delivery Controller Deployment 109
To specify a license server for an individual controller
1. In the left pane of the Access Management Console, select the controller.
2. From the Action menu, select Modify controller properties > Modify license server properties.
3. Clear the Use farm settings check box.
4. Enter the name or IP address of the license server in the Name box.
5. Enter the license server port number in the Port number (default 27000) box.
10
Using XenApp for Virtual Desktops
This section explains how to use Citrix XenApp for Virtual Desktops in a XenDesktop deployment to deliver applications to end users. It outlines the benefits of using XenApp and factors to consider when deciding between application streaming and hosting. It also explains how to configure your deployment to provide the optimum end-user experience.
This section covers the use of XenApp for Virtual Desktops in a XenDesktop environment. For information about using Citrix XenDesktop alongside an existing Citrix XenApp deployment, in which XenApp is licensed separately, refer to the Citrix Knowledge Center at http://support.citrix.com/.
Why Use XenApp with XenDesktop?
Using XenApp with XenDesktop allows you to separate applications from the desktop, thus reducing the overall number of virtual desktop images that must be managed. With XenApp you can place a single copy of an application on a centralized XenApp server, rather than having multiple copies of the application running on desktops.
In addition to increasing application and network performance, hosting an application on a XenApp server greatly simplifies Windows application delivery.
Consider, for example, how much easier it is to patch just one copy of an application running on a XenApp server, rather than patch multiple copies of an application running on desktops.
Application Streaming Versus Hosting
Using XenApp, you can deliver an application to users either by streaming it to the user’s virtual desktop or by hosting it on the XenApp server.
Application streaming simplifies delivery by allowing you to install and configure an application on one file server for delivery to desktops. To upgrade or patch the application, you make the updates only in the location where you stored the application.
Application hosting makes applications available to users from the XenApp server, instead of from their desktop. When a user runs an application that is published on XenApp, the application is virtualized on the desktop and so appears to the user to run locally. However, the application is running on the XenApp server in a separate protected ICA session, which keeps application processing on the endpoint device to a minimum. You can also publish content, such as documents, media clips, and graphics on a XenApp server.
The following diagram shows the three main options for application deployment in a XenDesktop environment. In the first desktop, the application is installed on the virtual desktop image; in the second desktop, the application is streamed from XenApp to the virtual desktop’s local hard-drive; in the third desktop, the application is available as a published (hosted) application from XenApp.
Diagram showing the three main application deployment options in a XenDesktop environment.
When deciding whether to stream or host applications using XenApp in a XenDesktop environment, there are particular considerations to be aware of.
Network connectivity may factor in your decision whether to stream or host applications. If the servers running XenDesktop are near to the XenApp server or file share from where applications are streamed, the resulting good connectivity makes application streaming an ideal option because of the amount of data that must be streamed to the virtual desktop. Streamed applications also tend to behave in a familiar way, similar to applications that run locally.