Monday 25 July 2016

Optimizing Application Delivery

Optimizing Application Delivery


This topic describes how to optimize the user experience so that, for the user, this is as familiar as running applications locally.

For the most seamless user experience, Citrix recommends that you:

• Install the XenApp Plugin for Hosted Apps and configure applications to appear in the Start menu
• Install the XenApp Plugin for Streamed Apps
• Set up pass-through authentication
• Configure a policy to map network drives
• Pre-cache streamed applications at logon

Installing the XenApp Plugins


Install the Citrix XenApp Plugin for Hosted Apps (the new name for the Citrix Presentation Server client) on the virtual desktop image, so that when users connect to their desktop, they automatically get the XenApp Plugin.

Set up Citrix XenApp (the new name for Program Neighborhood Agent) so that applications appear in the user’s Start menu. To the user, these applications appear to behave as if they are installed locally, although the applications are running on the XenApp server. This avoids users having to visit a Web site to start their applications. For more information, see the XenApp Plugin for Hosted Apps for Windows Administrator’s Guide.

For optimal flexibility, also install the XenApp Plugin for Streamed Apps (the plugin needed for client-side application virtualization, formerly known as the Streaming Client) on the virtual desktop image. This allows you to stream applications from XenApp as well as host them. For information about installing and configuring this plugin, see the Citrix Application Streaming Guide.

Setting up Pass-through Authentication

Pass-through authentication allows the XenApp Plugin to access a user’s local Windows user name, password, and domain information and pass it to the XenApp server. This means that users are not prompted to log on to XenApp separately. To enable pass-through authentication, you must configure both the XenApp server and the XenApp Plugin.

To enable pass-through authentication in the XenApp Plugin, during installation, choose Enable Pass-Through Authentication. For more information, see the XenApp Plugin for Hosted Apps for Windows Administrator’s Guide. To enable pass-through authentication on the XenApp server, see “Configuring Pass-through Client Authentication” in the Citrix XenApp Installation Guide.

Mapping Network Drives Using a Policy


To ensure users can see their local drives when running applications hosted on XenApp, you must configure a policy on XenApp to map network drives. When a user connects to a virtual desktop, their local drives are mapped; for example, C:(\\Client) (U:). However, when the user then connects to an application hosted on XenApp, these local drives are not re-mapped, so the user does not see them. This is because XenApp does not map network drives by default.

To ensure your users’ local drives are mapped, configure a policy on the XenApp server.

To map network drives in XenApp

1. On the XenApp server, launch Advanced Configuration (the new name for the Presentation Server Console), then from Policies either create a new policy or amend an existing policy.
2. Select the policy and choose Properties > Client Devices > Resources > Drives > Mappings.
3. Set Mappings to Enabled.
4. Ensure Turn off Remote drives is cleared.
5. Click OK.

To apply the policy, you must create a filter for it so the server can apply it to matching connections. For more information about how to create and apply policies, see the Citrix XenApp Administrator's Guide.

USB Drive Mapping Limitations


Some USB devices may not be accessible to users when running applications hosted on XenApp. Although users can see and access USB devices within their virtual desktops, some devices may not be mapped on the XenApp server.

• Some USB devices will be mapped into applications hosted on XenApp, including printers, PDAs, and scanners. USB drives inserted before the connection to the virtual desktop is established are also mapped into applications hosted on XenApp.
• Other USB devices, as well as devices inserted after the hosted application has been launched from within the virtual desktop, will not be visible to hosted applications.

To address this limitation, stream the application from XenApp, rather than host it, so that users can access any USB drives plugged into their endpoint devices.

Pre-caching Streamed Applications


In XenDesktop environments that use a Provisioning Server private virtual disk (vDisk), consider pre-caching streamed applications at logon. Pre-caching applications at logon means that the application is streamed from the XenApp server to the endpoint device when the user logs on. This provides better performance because the application is streamed across the network before the user launches it. Pre-caching applications at logon is the default streaming behavior.

Smart Card Support


If you require smart card support for data encryption and digital signing within applications delivered by XenApp in your XenDesktop environment, stream applications from the XenApp server.

Once a user has authenticated to their XenDesktop session, the smart card on the endpoint device allows digital signing within streamed applications, such as Microsoft Outlook, and also data encryption.

For more information about using smart cards within your XenDesktop environment, see “Using Smart Cards with XenDesktop” on page 37. For information about configuring application streaming, see the Citrix Application Streaming Guide.

User Profile Manager Considerations


User Profile Manager is the ideal profile solution to manage user personalization settings when using XenApp in a XenDesktop environment. If you are administering XenApp in a XenDesktop environment and you are using Citrix User Profile Manager, you may need to use separate Organizational Units for each published application that creates Citrix user profile data. For more information, see Using Citrix User Profile Manager with XenDesktop.

Saturday 23 July 2016

Desktop Connection Scenarios

Desktop Connection Scenarios


This topic contains a set of typical scenarios designed to help you understand how users interact with virtual desktops in a number of environments. The end-to-end experience of connecting to, using, and logging off from a virtual desktop is described.

In each case, the following prerequisites apply:

• The appropriate client software must be installed on the endpoint (except for scenarios involving XenDesktop Web sites, which can prompt the user to download the software when it is needed)
• Virtual desktop groups must be created correctly, using the instructions in “Creating and Updating Desktop Groups”

Scenario A: Connecting from an Appliance


This scenario is suited to task workers and knowledge workers who require access to a single virtual desktop. The desktop is presented to users in full-screenonly mode. Typical hardware for this scenario includes XenDesktop-ready desktop appliances and non-domain-joined computers.

XenDesktop-ready desktop appliances are devices that, while having limited functionality compared to computers with a full operating system and set of applications, are preinstalled with software designed for accessing virtual desktops created with XenDesktop. XenDesktop-ready desktop appliances run on Windows XP Embedded, Windows CE, and Linux.

For more information about administering these desktop appliances, consult the manufacturer’s documentation. For more general information about XenDesktopready desktop appliances, see http://www.citrix.com/citrixready/.

The user experience in this scenario is as follows. Depending on the appliance manufacturer and any customization that is performed, the screen appearance may vary:

1. The user turns on their local appliance and a connection is established to a desktop appliance connector (or a load-balanced address) on a server running Desktop Delivery Controller.

2. After the startup sequence on the appliance is complete, a Please Wait screen appears while a customized shell loads.

3. The Welcome screen appears.


This figure shows the logon screen for a full-screen-only desktop accessed from a XenDesktop-ready desktop appliance running Windows.

4. The user enters their credentials and logs on. Any errors (for example, if an incorrect password is entered) appear at the bottom of the logon screen.

5. A Please Wait screen appears while the virtual desktop starts and a connection to it is established. The system keeps the user informed of connection progress at each stage.

6. If the desktop is taking a long time to appear, the user can restart it by clicking the Restart button on the Please Wait screen. The desktop restarts automatically. Note that the Restart button is available only if the administrator has enabled user-driven desktop restart when creating the desktop group.

7. When the virtual desktop becomes available, it appears as a local one because it is not displayed in a window but instead it automatically fits to the size of the local monitor. This is the virtual desktop in full-screen-only mode.

The user can create and save work normally on the virtual desktop, use the mouse and keyboard in the usual way, and access network resources and most types of external device. Almost all input is directed to the virtual desktop. The user never interacts directly with the local desktop except for a few reserved key combinations (which may vary between operating systems). For more information about these key combinations in Windows environments, see the Citrix Desktop Receiver Administrator’s Guide. 

If USB support is enabled, when a user plugs in a USB device it is automatically remoted to the virtual desktop. The virtual desktop is responsible for controlling the USB device and displaying it in the user interface. For more details, see “Configuring USB Support” on page 95 and
the Citrix Desktop Receiver Administrator’s Guide.

The user is in full control of the virtual desktop, just as if they were using it locally. The only exceptions that the user may notice are:

• Resizing. The user is prevented from resizing the virtual desktop. This avoids the difficulty of choosing unsuitable screen resolutions, resulting in distorted images and the appearance of scrollbars (neither of which would normally occur on the user’s physical screen). The user can, however, change other desktop properties such as font size.
• Screen locking. For security reasons, on some operating systems the key combinations that lock the local screen (CTRL+ALT+DELETE and Windows logo key+L on Windows) are not sent to the virtual desktop.

8. If the desktop becomes unresponsive, the user can restart it by pressing CTRL+ALT+DELETE and clicking Restart. The user enters their credentials on the Restart screen and clicks OK to restart the desktop. Any unsaved data is lost during the restart operation. Note that the Restart button is available only if the administrator has enabled user-driven desktop restart when creating the desktop group.

9. When the user completes their work, they log off in the standard way (for example, from the Start menu on Windows). The shell automatically logs the user off from the local computer as well as the virtual desktop. This leaves their monitor displaying the logon screen. In this way, the user experiences the logoff as a local operation.

Scenario B: Connecting from a Domain-Joined or Repurposed Computer


This scenario is suited to task workers and knowledge workers in a Microsoft Windows environment who require access to a single desktop. The desktop is presented to users in full-screen-only mode. Typical setups for this scenario include repurposed Windows XP Professional computers or domain-joined computers running Windows XP Embedded.

Repurposed computers are computers you may have in your existing environment that can be locked down to provide access only to virtual desktops. A prerequisite to this scenario is that you must install the Citrix Desktop Receiver Embedded Edition on the endpoint device.

The user experience in this scenario is as follows:

1. The user turns on their local computer and after the startup sequence on the computer is complete, the Log On to Windows dialog box appears.

2. The user enters their domain credentials and logs on. They should not log on as a local administrator.

3. A customized shell starts and a connection is established to the XenDesktop Services site (or a load-balanced address) on a server running Desktop Delivery Controller.

4. A Please Wait screen appears while the virtual desktop starts and a connection to it is established. The system keeps the user informed of connection progress at each stage.

5. If the desktop is taking a long time to appear, the user can restart the desktop by clicking the Restart button on the Please Wait screen. The desktop restarts automatically. Note that the Restart button is available only if the administrator has enabled user-driven desktop restart when creating the desktop group.

6. When the virtual desktop becomes available, it appears as a local one because it is not displayed in a window but instead it automatically fits to the size of the local monitor. This is the virtual desktop in full-screen-only mode. The user experience is identical to that described in Scenario A.

7. If the desktop becomes unresponsive, the user can restart the desktop. To do so, the user logs off in the standard way. When the Log On to Windows dialog box appears, the user enters their domain credentials and logs back on. When the Please Wait screen appears, the user clicks the Restart button to restart the desktop. Any unsaved data is lost during the restart operation. Note that the Restart button is available only if the administrator has enabled user-driven desktop restart when creating the desktop group.

8. When the user completes their work, they log off in the standard way (for example, using the Start menu on Windows). The shell automatically logs the user off from the local computer as well as the virtual desktop. This leaves their monitor displaying the Log On to Windows dialog box.

Scenario C: Connecting from a Fat Client Device on a LAN


This scenario is suited to knowledge workers in a Microsoft Windows environment who require access to one or more desktops. Desktops are presented to users in separate windows, allowing the user to switch between virtual desktops and the local desktop. Access to more than one desktop mandates the use of this user interface rather than full-screen-only mode, which can be used only when access to a single desktop is required. Typical hardware for this scenario includes fat clients connected to a LAN.

Unlike Scenario B, the Citrix Desktop Receiver Embedded Edition does not need to be installed on the endpoint as a prerequisite. Instead, users can be prompted to download it when they need it.

The user experience in this scenario is as follows:

1. The user is already logged on to Windows from their local computer. They decide to connect to one of their virtual desktops.

2. The user opens a browser window, and browses (for the first time) to a XenDesktop Web site (or a load-balanced address) on a server running Desktop Delivery Controller. For convenience, they bookmarked the site address that you sent them when they were set up as a XenDesktop user.

3. A Please Wait screen appears while a connection to the site is established.

4. The Welcome screen appears.



This figure shows the Web-based logon screen for desktops accessed through a XenDesktop Web site. Depending on your configuration settings, the user may also have to select an authentication method on this screen.

5. Because this is the first time the user is logging on to the site, it automatically detects that the required client is not present on the endpoint and prompts the user to download and install the required software.

6. After the install is complete, the user is presented with a site which contains a Desktops tab showing the set of desktops to which they have access. The user can also access virtual applications from this site if any were published with Citrix XenApp.

If desired, administrators can configure the AutoLaunchDesktop setting in Web Interface to skip this step if the user has been assigned only one desktop (and no published applications). For instructions on configuring that setting, see the Web Interface Administrator’s Guide.



This figure shows the set of desktops available to the user on the XenDesktop Web site.

7. With the software installed, the user accesses a virtual desktop by clicking the appropriate icon on the page.

8. If the desktop is taking a long time to appear, the user can restart it by clicking the Restart button for that desktop, on the Desktops tab. The desktop restarts automatically. Note that the Restart button is available only if the administrator has enabled user-driven desktop restart when creating the desktop group.

9. A new window appears. Progress messages appear inside the window before the desktop is displayed.



This figure shows a desktop displayed in a separate window.

10. The user interacts with the desktop in the usual way and can control its size, position, and other settings, using the controls on the toolbar. For instructions about using the controls, see the Citrix Desktop Receiver Administrator’s Guide.



This figure shows the controls on the toolbar. Users can customize the desktop using the buttons or a drop-down menu located next to the Citrix logo on the left.

11. If USB support is enabled, a list of devices available for remoting to the virtual desktop is displayed by clicking the USB Preferences button on the toolbar. The user can customize how and when devices are remoted to the virtual desktop by clicking the USB Preferences button on the toolbar and changing the settings in the USB Preferences dialog box.

12. If the desktop becomes unresponsive, the user can restart it by clicking the Restart button for that desktop, on the Desktops tab in the browser window.The desktop restarts automatically and appears in a separate window. Any unsaved data is lost during the restart operation. Note that the Restart button is available only if the administrator has enabled userdriven desktop restart when creating the desktop group.

13. When the user completes their work, they can click the Close button on the toolbar, which, after prompting the user to confirm, disconnects the virtual desktop session and returns them to their local desktop. The user can resume the session later when they want to work on the virtual desktop again. Alternatively, if they want to log off, they can do so from the virtual desktop’s Start menu.

Scenario D: Connecting from Remote Computers


This scenario is suited to knowledge workers with any supported Microsoft Windows operating system who are working remotely, outside your LAN, and need secure access to virtual desktops that are inside it. Typically, connections are routed from fat client devices through Citrix Access Gateway and Web Interface. These two components can be configured in a variety of ways. This scenario uses one of the standard configurations in which the Web Interface server is located in the Demilitarized Zone (DMZ). In this scenario, desktops are always presented to users in separate windows.

The user experience in this scenario is as follows:

1. The user browses to the external XenDesktop Web site that was secured using Access Gateway.



This figure shows the Web-based logon screen created for remote access. Depending on your configuration settings, the user may also have to select an authentication method on this screen.

2. The user logs on to the site.

3. The remaining steps are identical to Scenario C. The user selects a desktop from the Desktops tab on the site and the desktop appears in a new window.

4. When the user completes their work, they can click the Close button on the toolbar, which, after prompting the user to confirm, disconnects the virtual desktop session and returns them to their local desktop. The user can resume the session later when they want to work on the virtual desktop again. Alternatively, if they want to log off, they can do so from the virtual desktop’s Start menu.

Friday 22 July 2016

Networking Troubleshooting

Networking Troubleshooting


If you are having problems with configuring networking, first ensure that you have not directly modified any of the control domain ifcfg-* files directly. These files are directly managed by the control domain host agent, and changes will be overwritten.

Diagnosing Network Corruption


Some network card models require firmware upgrades from the vendor to work reliably under load, or when certain optimizations are turned on. If you are seeing corrupted traffic to VMs, then you should first try to obtain the latest recommended firmware from your vendor and apply a BIOS update. If the problem still persists, then you can use the CLI to disable receive / transmit offload optimizations on the physical interface.

First, determine the UUID of the physical interface. You can filter on the device field as follows:

xe pif-list device=eth0

Next, set the following parameter on the PIF to disable TX offload:
xe pif-param-set uuid=<pif_uuid> other-config:ethtool-tx=off
Finally, re-plug the PIF or reboot the host for the change to take effect.

Emergency Network Reset


Incorrect networking settings can cause loss of network connectivity, and a XenServer host may become inaccessible via XenCenter or remote SSH. Emergency Network Reset provides a simple mechanism to recover and reset a host's networking. This feature is available from the Command Line Interface (CLI) using the xe-reset-networking command and within the Network and Management Interface section of xsconsole.

Incorrect settings which could cause a loss of network connectivity could include renaming network interfaces, creating bonds or VLANs, or mistakes when changing the management interface (for example, entering the wrong IP address). In addition, you may want to run this utility if a rolling pool upgrade, manual upgrade, hotfix installation or driver installation causes a lack of network connectivity, or if a Pool master or host in a resource pool is unable to contact with other hosts.

This utility should only be used in an emergency as it will remove the configuration for all PIFs, Bonds, VLANs and tunnels associated with the host. Guest Networks and VIFs are preserved. As part of this utility, VMs will be shutdown forcefully, where possible before running this command, VMs should be cleanly shutdown. Before applying a reset, users can make changes to the management interface and specify which IP configuration, DHCP or Static, should be used.

If the Pool Master requires a network reset, it must be carried out before a network reset of any other pool members. It should then be followed a network reset on all remaining hosts in the pool to ensure that the pool's networking configuration is homogeneous. This is a particularly important factor for XenMotion.

Verifying the Network Reset

After specifying the configuration mode to be used after the network reset, xsconsole and the CLI will display the settings which will be applied after host reboot. This offers a final chance to make any modifications before applying the emergency network reset command. After reboot, the new network configuration can be verified in XenCenter and xsconsole. In XenCenter, with the host selected, click the Networking tab, this displays the new network configuration. In xsconsole, this information is displayed in the Network and Management Interface section.

Using the CLI for Network Reset

The following table shows the available optional parameters which can be used with the xe-reset-networking command. Resetting the networking configuration of a whole pool must begin on the Pool Master, and should then be followed by network reset on all remaining hosts in the pool.

Pool Master Command Line Examples

Examples of commands that could be applied on a Pool Master:
To reset networking for DHCP configuration:
xe-reset-networking

To reset networking for Static IP configuration:
xe-reset-networking --mode= static --ip=<ip-address> \
--netmask=<netmask> --gateway=<gateway> \
--dns=<dns>

To reset networking for DHCP configuration if another interface became the management interface after initial setup:
xe-reset-networking --device=<device-name>

To reset networking for Static IP configuration if another interface became the management interface after initial setup:
xe-reset-networking --device=<device-name> --mode=static \
--ip=<ip-address> --netmask=<netmask> \
--gateway=<gateway> --dns=<dns>

Pool Member Command Line Examples

All previous examples also apply to pool members. Additionally the Pool Master's IP address can be specified (which will be necessary if it has changed.)

To reset networking for DHCP configuration:
xe-reset-networking

To reset networking for DHCP if the Pool Master's IP address was modified:
xe-reset-networking --master=<master-ip-address>

To reset networking for Static IP configuration, assuming the Pool Master's IP address didn't change:
xe-reset-networking --mode=static --ip=<ip-address> --netmask-<netmask> \
--gateway=<gateway> --dns=<dns>

To reset networking for DHCP configuration if the management interface and the Pool Master's IP address was modified after initial setup:
xe-reset-networking --device=<device-name> --master<master-ip-address>

Thursday 21 July 2016

Storage Multipathing

Storage Multipathing


Dynamic multipathing support is available for Fibre Channel and iSCSI storage backends. By default, XenServer uses round-robin mode load balancing, so both routes have active traffic on them during normal operation. You can enable multipathing in XenCenter or on the xe CLI. For additional information about multipathing, see CTX134881—Configuring Multipathing for XenServer.

Before attempting to enable multipathing, verify that multiple targets are available on your storage server. For example, an iSCSI storage backend queried for sendtargets on a given portal should return multiple targets, as in the following example:

iscsiadm -m discovery --type sendtargets --portal 192.168.0.161
192.168.0.161:3260,1 iqn.strawberry:litchie
192.168.0.204:3260,2 iqn.strawberry:litchie

To enable storage multipathing using the xe CLI

1. Unplug all PBDs on the host:
xe pbd-unplug uuid=<pbd_uuid>

2. Set the host's other-config:multipathing parameter:
xe host-param-set other-config:multipathing=true uuid=host_uuid

3. Set the host's other-config:multipathhandle parameter to dmp:
xe host-param-set other-config:multipathhandle=dmp uuid=host_uuid

4. If there are existing SRs on the host running in single path mode but that have multiple paths:
• Migrate or suspend any running guests with virtual disks in affected the SRs
• Unplug and re-plug the PBD of any affected SRs to reconnect them using multipathing:

xe pbd-plug uuid=<pbd_uuid>

To disable multipathing, first unplug your VBDs, set the host other-config:multipathing parameter to false and then replug your PBDs as described above. Do not modify the otherconfig: multipathhandle parameter as this will be done automatically.

Multipath support in XenServer is based on the device-mapper multipathd components. Activation and deactivation of multipath nodes is handled automatically by the Storage Manager API. Unlike the standard dmmultipath tools in Linux, device mapper nodes are not automatically created for all LUNs on the system, and it is only when LUNs are actively used by the storage management layer that new device mapper nodes are provisioned. Therefore, it is unnecessary to use any of the dm-multipath CLI tools to query or refresh DM table nodes in XenServer. Should it be necessary to query the status of device-mapper tables manually, or list active device mapper multipath nodes on the system, use the mpathutil utility:

• mpathutil status

MPP RDAC Driver Support for LSI Arrays.


XenServer supports the LSI Multi-Path Proxy Driver (MPP) for the Redundant Disk Array Controller (RDAC) used by Dell MD Series. By default this driver is disabled.

To enable the driver:

1. Open a console on the host, and run the following command:
# /opt/xensource/libexec/mpp-rdac --enable

2. Reboot the host.

To disable the driver:

1. Open a console on the host, and run the following command:
# /opt/xensource/libexec/mpp-rdac --disable

2. Reboot the host.

Wednesday 20 July 2016

Configuring Advanced Settings for Desktop Groups

Configuring Advanced Settings for Desktop Groups


You can configure advanced settings such as access control, idle pool settings, logoff behavior, and client options using the Advanced Settings pages of the Create Desktop Group Wizard.

Configuring Access Control


If Access Gateway Advanced Edition is installed as part of your environment, use the Access Control page of the Create Desktop Group Wizard to specify the typesnof connections that can be used to access desktops. By default, all connections made through the Access Gateway Advanced Edition are allowed.

To configure access controlled by Access Gateway

1. To access desktops using connections made through Access Gateway Advanced Edition, select the Allow connections made through Access Gateway Advanced Edition (version 4.0 or later) check box. Go to Step 3.

2. To access desktops using connections other than those made through Access Gateway Advanced Edition, select the Allow all other connections check box.

3. If you selected Allow connections made through Access Gateway Advanced Edition (version 4.0 or later), choose one of the following:

• To restrict allowed connections to those that meet the criteria of specified filters, select Any connection that meets any of the following filters.
• To allow all connections, select Any connection.

Setting Up an Idle Pool


You can use the Idle Pool Settings page of the Create Desktop Group Wizard to configure how many idle desktops you want in your pool at certain times of the day. You can also configure a peak period to cover the time at which most users will be logging on to their desktops. This period starts at the beginning of your business day.

The desktops in this pool are kept in a powered-on state, ready for users to connect. When a user logs on, they are immediately presented with a desktop. You can modify idle pool settings after creating a desktop group, using the Modify desktop group properties task.

If you used the XenDesktop Setup Wizard to create desktops, the idle pool settings are automatically optimized for the number of desktops you created. To modify the settings, use the Modify desktop group properties task.

To set up an idle pool

1. Select your normal business days.

2. Select your time zone from the Time zone list.

3. Enter a start and end time for your normal business hours in the Start time and End time boxes.

4. Enter a time period to cover the peak period for users logging on, in hours, in the Peak period box. This peak period starts at the time you specify in the Start time box.

5. Enter the number of idle desktops you want available during business hours, in the Business hours box.

6. Enter the number of idle desktops you want available during your peak period, in the Peak time box.

7. Enter the number of idle desktops you want available out of business hours, in the Out of hours box.

To keep the same number of desktops in the pool at all times, enter the same time in both the Start time and End time boxes or an identical value for the number of desktops to keep in the idle pool in the Business hours, Peak time, and Out of hours boxes.

Configuring Logoff Behavior


You can configure what happens to a desktop when a user logs off, using the Logoff Behavior page of the Create Desktop Group Wizard. For assigned desktops, you can also configure what happens if a session is disconnected.

For pooled desktops, by default, the desktop becomes available to other users as soon as the current user logs off. Any change made to the system by the most recent user is retained, so this option is usually appropriate only for desktops that users cannot customize. Alternatively, you can choose to restart the desktop before making it available to other users.

For assigned desktops, by default, when the user logs off, the desktop is left powered-on and ready for the user to reconnect to. Alternatively, you can suspend the desktop until the next time the user tries to reconnect to it or shut down the desktop and restart it the next time the user tries to reconnect to it. If you specify that an assigned desktop should be suspended or shut down when the user logs off, you can also choose to suspend the desktop if the session is disconnected. By default, the desktop is left powered-on if the session is disconnected. You can modify logoff behavior settings after creating a desktop group, using the Modify desktop group properties task.

To configure logoff behavior for pooled desktops

1. If you want to stop and restart the desktop before making it available to other users, select Restart the virtual desktop.

2. If you want to make the desktop available to other users immediately, select Do nothing.

To configure logoff behavior for assigned desktops

1. If you want to leave the desktop powered on and ready for the user to reconnect, select Leave powered on.

2. If you want to suspend the desktop until the next time the user connects, select Suspend.

3. If you want to shutdown the desktop and restart it the next time the user connects. select Shut down.

4. If you selected Suspend or Shut down as the logoff behavior and you want to suspend the desktop when a session disconnects, select the Suspend virtual desktop when session disconnects check box.

Specifying Client Options


You can use the Clients page of the Create Desktop Group Wizard to specify the level of encryption you want a client to use when connecting to desktops in a group. You can also set the color depth used by desktops in a group.

To specify client options

1. Set the color depth for desktops in the group. Choose from 16 colors, 256 colors, High Color (16-bit), or True Color (24- bit). True color (24-bit) is the default and maximum supported color depth.

2. Set the encryption level for client connections. Choose from the following, but note that the first four options have been deprecated and Citrix recommends that you do not use them:

• Basic. Encrypts the ICA connection using a non-RC5 algorithm. It protects the data stream from being read directly, but is susceptible to decryption.
• 128-Bit Login Only (RC5). Encrypts the logon data with RC5 128-bit encryption and the ICA connection using basic encryption.
• 40-Bit (RC5). Encrypts the ICA connection with RC5 40-bit encryption.
• 56-Bit (RC5). Encrypts the ICA connection with RC5 56-bit encryption.
• 128-Bit (RC5). Encrypts the ICA connection with RC5 128-bit encryption. This is the default.

Tuesday 19 July 2016

XenServer Hosts and Resource Pools

XenServer Hosts and Resource Pools


This describes how resource pools can be created through a series of examples using the xe command line interface (CLI). A simple NFS-based shared storage configuration is presented and a number of simple VM management examples are discussed. Procedures for dealing with physical node failures are also described.

Hosts and Resource Pools Overview


A resource pool comprises multiple XenServer host installations, bound together into a single managed entity which can host Virtual Machines. When combined with shared storage, a resource pool enables VMs to be started on any XenServer host which has sufficient memory and then dynamically moved between XenServer hosts while running with minimal downtime (XenMotion). If an individual XenServer host suffers a hardware failure, then the administrator can restart the failed VMs on another XenServer host in the same resource pool. If high availability (HA) is enabled on the resource pool, VMs will automatically be moved if their host fails. Up to 16 hosts are supported per resource pool, although this restriction is not enforced.

A pool always has at least one physical node, known as the master. Only the master node exposes an
administration interface (used by XenCenter and the XenServer Command Line Interface, known as the xe CLI); the master forwards commands to individual members as necessary.

Requirements for Creating Resource Pools


A resource pool is a homogeneous aggregate of one or more XenServer hosts, up to a maximum of 16. The definition of  homogeneous is:

• the CPUs on the server joining the pool are the same (in terms of vendor, model, and features) as the CPUs on servers already in the pool.
• the server joining the pool is running the same version of XenServer software, at the same patch level, as servers already in the pool

The software will enforce additional constraints when joining a server to a pool – in particular:

• it is not a member of an existing resource pool
• it has no shared storage configured
• there are no running or suspended VMs on the XenServer host which is joining
• there are no active operations on the VMs in progress, such as one shutting down

You must also check that the clock of the host joining the pool is synchronized to the same time as the pool master (for example, by using NTP), that its management interface is not bonded (you can configure this once the host has successfully joined the pool), and that its management IP address is static (either configured on the host itself or by using an appropriate configuration on your DHCP server).

XenServer hosts in resource pools may contain different numbers of physical network interfaces and have local storage repositories of varying size. In practice, it is often difficult to obtain multiple servers with the exact same CPUs, and so minor variations are permitted. If you are sure that it is acceptable in your environment for hosts with varying CPUs to be part of the same resource pool, then the pool joining operation can be forced by passing a --force parameter.

Although not a strict technical requirement for creating a resource pool, the advantages of pools (for example, the ability to dynamically choose on which XenServer host to run a VM and to dynamically move a VM between XenServer hosts) are only available if the pool has one or more shared storage repositories. If possible, postpone creating a pool of XenServer hosts until shared storage is available. Once shared storage has been added, Citrix recommends that you move existing VMs whose disks are in local storage into shared storage. This can be done using the xe vm-copy command or XenCenter.

Creating a Resource Pool


Resource pools can be created using either the XenCenter management console or the CLI. When you join a new host to a resource pool, the joining host synchronizes its local database with the pool-wide one, and inherits some settings from the pool:

• VM, local, and remote storage configuration is added to the pool-wide database. All of these will still be tied to the joining host in the pool unless you explicitly take action to make the resources shared after the join has completed.
• The joining host inherits existing shared storage repositories in the pool and appropriate PBD records are created so that the new host can access existing shared storage automatically.
• Networking information is partially inherited to the joining host: the structural details of NICs, VLANs and bonded interfaces are all inherited, but policy information is not. This policy information, which must be reconfigured, includes:
• the IP addresses of management NICs, which are preserved from the original configuration
• the location of the management interface, which remains the same as the original configuration. For example, if the other pool hosts have their management interfaces on a bonded interface, then the joining host must be explicitly migrated to the bond once it has joined.
• Dedicated storage NICs, which must be re-assigned to the joining host from XenCenter or the CLI, and the PBDs re-plugged to route the traffic accordingly.

To join XenServer hosts host1 and host2 into a resource pool using the CLI

1. Open a console on XenServer host host2.

2. Command XenServer host host2 to join the pool on XenServer host host1 by issuing the command:
xe pool-join master-address=<host1> master-username=<administrators_username> \
master-password=<password>

The master-address must be set to the fully-qualified domain name of XenServer host host1 and the
password must be the administrator password set when XenServer host host1 was installed.

Naming a resource pool

• XenServer hosts belong to an unnamed pool by default. To create your first resource pool, rename the existing nameless pool. Use tab-complete to find the pool_uuid:
xe pool-param-set name-label=<"New Pool"> uuid=<pool_uuid>

Creating Heterogeneous Resource Pools


XenServer 6.2.0 simplifies expanding deployments over time by allowing disparate host hardware to be joined into a resource pool, known as heterogeneous resource pools. Heterogeneous resource pools are made possible by leveraging technologies in recent Intel (FlexMigration) and AMD (Extended Migration) CPUs that provide CPU "masking" or "leveling". These features allow a CPU to be configured to appear as providing a different make, model, or functionality than it actually does. This enables you to create pools of hosts with disparate CPUs but still safely support live migrations.

Using XenServer to mask the CPU features of a new server, so that it will match the features of the existing servers in a pool, requires the following:

• the CPUs of the server joining the pool must be of the same vendor (i.e. AMD, Intel) as the CPUs on servers already in the pool, though the specific type, (family, model and stepping numbers) need not be.
• the CPUs of the server joining the pool must support either Intel FlexMigration or AMD Enhanced Migration.
• the features of the older CPUs must be a sub-set of the features of the CPUs of the server joining the pool.
• the server joining the pool is running the same version of XenServer software, with the same hotfixes installed, as servers already in the pool.

Creating heterogeneous resource pools is most easily done with XenCenter which will automatically suggest using CPU masking when possible. Refer to the Pool Requirements section in the XenCenter help for more details. To display the help in XenCenter press F1.

To add a heterogeneous XenServer host to a resource pool using the xe CLI

1. Find the CPU features of the Pool Master by running the xe host-get-cpu-features command.

2. On the new server, run the xe host-set-cpu-features command and copy and paste the Pool Master's
features into the features parameter. For example:
xe host-set-cpu-features features=<pool_master's_cpu_ features>

3. Restart the new server.

4. Run the xe pool-join command on the new server to join the pool.

To return a server with masked CPU features back to its normal capabilities, run the xe host-reset-cpu-features command.

Adding Shared Storage


For a complete list of supported shared storage types, see the Storage chapter. This section demonstrates how shared storage (represented as a storage repository) can be created on an existing NFS server.

Adding NFS shared storage to a resource pool using the CLI

1. Open a console on any XenServer host in the pool.

2. Create the storage repository on <server:/path> by issuing the command
xe sr-create content-type=user type=nfs name-label=<"Example SR"> shared=true \
device-config:server=<server> \
device-config:serverpath=<path>

The device-config:server refers to the hostname of the NFS server and deviceconfig: serverpath refers to the path on the NFS server. Since shared is set to true, the shared storage will be automatically connected to every XenServer host in the pool and any XenServer hosts that subsequently join will also be connected to the storage. The Universally Unique Identifier (UUID) of the created storage repository will be printed on the screen.

3. Find the UUID of the pool by the command
xe pool-list

4. Set the shared storage as the pool-wide default with the command
xe pool-param-set uuid=<pool_uuid> default-SR=<sr_uuid>

Since the shared storage has been set as the pool-wide default, all future VMs will have their disks created on shared storage by default. See Chapter 5, Storage for information about creating other types of shared storage.

Monday 18 July 2016

Customizing Your Desktop Delivery Controller Environment

Customizing Your Desktop Delivery Controller Environment


Overview


After completing the initial setup tasks, you can customize and optimize your Desktop Delivery Controller deployment:

1. Create additional administrators for the farm, if necessary. 

2. Set up any general Citrix policies that you require, using the Presentation Server Console. See the Citrix Presentation Server Administrator’s Guide for details of configuring policies. Note the following points in relation XenDesktop:

• You can set up policies that filter on desktop group name. If you rename the desktop group, you must update the policy with the new name.
• You cannot filter polices on server name.

3. Configure USB support. See “Configuring USB Support” on page 95.

4. Optimize the user experience by ensuring that settings for desktops and users are appropriate. See “Optimizing the User Experience” on page 98.

5. Set up printers, using the Presentation Server Console. See the Citrix Presentation Server Administrator’s Guide for details of setting up and managing printers. In XenDesktop, the following XenApp printer management features are not available:

• Driver replication, compatibility, and mapping
• Support for legacy Windows CE and DOS clients that cannot correctly report which printers are attached to the endpoint device
• Control of the total bandwidth limit of all printing connections to a particular controller

Creating Administrators


To manage your Desktop Delivery Controller environment efficiently, you may need to create additional administrators. You may also need to delegate Active Directory permissions to these administrators.

Delegating Active Directory Access Control

Active Directory is used to store information about the controllers in a farm. To add or remove controllers, administrators need certain Active Directory rights. For further information about this, 

Delegating Desktop Delivery Controller Administration Tasks

When you install Desktop Delivery Controller, the account you use to log on is automatically granted full administration rights, with authority to manage and administer all areas of Desktop Delivery Controller farm management. Using this account, you can then start the Access Management Console and create further full or delegated administrators.

Delegated administrators can view all information in the Desktop Delivery Controller extension of the console and they can also:

• Send messages to users
• Disconnect users
• Log off users
• Put desktops into maintenance mode and remove them from maintenance mode
• Start, stop, suspend, and resume virtual machines

Delegated administrators cannot:
• Create, modify, or delete desktop groups
• Add, modify, or delete administrators

Administrators who will run the Access Management Console remotely must have DCOM remote launch permissions.

To create a new Desktop Delivery Controller administrator

1. In the left pane of the Access Management Console, under the farm, select the Administrators node.

2. From the Action menu, select Add administrator.

3. On the Select Users page, click Add.

4. Click OK to add the user as an administrator.
Use the Active Directory object picker to select your user or group. Note that:
• You can only browse account authorities and select users and groups that are accessible from the computer running the Access Management Console.
• You should not select users and groups outside the trust intersection of the farm. If you do this, errors will occur.

5. Continue selecting the administrators you want to add, then click OK.


7. On the Privileges page, choose one of the following options:
• Select Delegated Administration to delegate specific, limited tasks to the selected administrators.
• Select Full Administration to give the selected administrators full access to all areas of farm management.

8. Click Finish.

Configuring USB Support


You can enable users to interact with a wide range of USB devices during a XenDesktop session. USB support is available on endpoints running the Desktop Receiver 11.1 or later, or the Client for Linux 11.0 or later.

By default, certain types of USB device are not supported for remoting through XenDesktop. For example, a user may have a network interface card attached to the system board by internal USB. Remoting this would not be appropriate. The following types of USB device are not supported by default for use in a XenDesktop session:

• Keyboards
• Mice
• Bluetooth dongles
• Integrated network interface cards
• Smart cards
• USB hubs

For more detailed information about the devices included in each class or type of device and whether or not USB support is provided for them, see the relevant client documentation.

To configure USB support

1. Enable the USB policy rule, which is located in the USB subfolder of the Client Devices Resources folder in the Presentation Server Console. 

2. Enable USB support when you install the client on endpoint devices. For information about how to do this, see the Citrix Desktop Receiver Administrator’s Guide or the Client for Linux Administrator’s Guide.

3. If necessary, update the range of USB devices supported. To do this:

• Edit the Desktop Receiver registry (or the .ini files in the case of the Client for Linux). For information about how to do this, see the Citrix Desktop Receiver Administrator’s Guide or the Client for Linux Administrator’s Guide.

• Edit the administrator override rules in the Virtual Desktop Agent registry on the machine(s) hosting the desktops. The range specified in the Virtual Desktop Agent must correspond exactly to the range specified on the client; if it does not, then only the devices disallowed in both ranges are disallowed.

The product default rules are stored in
HKLM\SOFTWARE\Citrix\PortICA\GenericUSB Type=String Name=“DeviceRules”

Do not edit the product default rules.
The administrator override rules are stored in
HKLM\SOFTWARE\Policies\Citrix\PortICA\GenericUSB Type=String Name=“DeviceRules”

ADM files are included on the installation media to allow you to make changes to the Desktop Receiver and the Virtual Desktop Agent through

Active Directory Group Policy. The file for the Desktop Receiver is:
dvd root\os\lang\Support\Configuration\icaclient_usb.adm

and the file for the Virtual Desktop Agent is:
dvd root\os\lang\Support\Configuration\vda_usb.adm

For further information on setting up policies, see the Presentation Server Administrator’s Guide.

Support for USB Mass Storage Devices

For mass storage devices only, remote access is also available through client drive mapping, which you configure by enabling the Citrix Mappings rule. When this rule is applied, the drives on the endpoint device are automatically mapped to drive letters on the virtual desktop when users log on. The drives are displayed as shared folders with mapped drive letters. The Mappings rule is in the Drives subfolder of the Client Devices Resources folder in the Presentation Server Console.

The main differences between the two types of remoting policy are:

Feature :

Rule enabled by default
Read-only access configurable
Safe to remove device during a session

Mappings rule :

Yes
Yes
No

USB rule :

No
No 
Yes, provided users follow operating system recommendations for safe removal.

If both rules are enabled, then if a mass storage device is inserted before a session starts, it will be redirected using client drive mapping first, before being considered for redirection through USB support. If it is inserted after a session has started, it will be considered for redirection using USB support before client drive mapping. Automatic support of devices upon insertion, however, depends on the type of client being used and the individual user preferences; for further information, see the relevant client documentation.

Optimizing the User Experience


This topic describes how to:

• Configure time zone settings to allow users to see their local time when using desktops.
• Configure connection timers to provide appropriate durations for uninterrupted connections, idle sessions, and disconnected sessions.
• Disable RDP, because the use of RDP can interfere with the operation of ICA.
• Remove the Shut Down command to prevent users from powering off their desktops, which would then require a manual restart by an administrator. This is not necessary for VM-based desktop groups.

For the best user experience, consider preinstalling frequently used software, such as a Flash player or other browser plug-ins in your desktops. Also consider enabling Microsoft ClearType or other font-smoothing technologies by default in users’ profiles.

Configuring Time Zone Settings

By default, when non-privileged users connect to Windows XP desktops, they see the time zone of the system running the desktop instead of the time zone of their own endpoint device. To allow them to see their local time when using these desktops you need to give them rights to:

• Change the time on the system on which the desktop is running. To do this, set up a Group Policy with rights given to non-privileged users to change system time settings.
• Change the time zone registry area.

After you do this, users who connect to Windows XP desktops see their local time zone reflected in the desktop. When they log off or disconnect, the time zone of the desktop is reset to what it was before they logged on.

You can configure time zone settings through Citrix policies. If you want endpoint devices to use the time zone of the virtual desktop to which they are connected, enable the rule Do not use Clients’ local time, which is in the Time Zones subfolder of the User Workspace folder in the Presentation Server Console.

Configuring Connection Timers

You can configure three connection timers:
• A maximum connection timer. This setting determines the maximum duration of an uninterrupted connection between an endpoint device and a desktop. By default, this setting is disabled.
• A connection idle timer. This setting determines how long an uninterrupted endpoint device connection to a desktop will be maintained if there is no input from the user. By default, this is set to 1440 minutes (24 hours).
• A disconnect timer. This setting determines how long a disconnected, locked desktop can remain locked before the session is logged off. By default, this setting is disabled for pre-assigned or assigned-on-first-use desktop groups and enabled for pooled desktop groups. The default setting is 1440 minutes (24 hours).

If you need to update any of these settings, ensure that settings are consistent across your deployment.

After you update any of these settings, you must restart the computer hosting the desktop for the new setting to take effect.

To enable the maximum connection timer, create the following registry key (DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\ ConnectionTimer\enabled
and set the key to 1. To disable the timer, set the key to 0.

To update the maximum connection timer, create the following registry key (DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\
ConnectionTimer\MaxConnectionTime and set the maximum connection time in minutes.

To enable the connection idle timer, create the following registry key (DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\IdleTimer\ \enabled and set the key to 1. To disable the timer, set the key to 0.

To update the connection idle timer, create the following registry key (DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\IdleTimer\ \MaxIdleTime and set the maximum idle time in minutes.

To enable the disconnect timer, create the following registry key (DWORD):
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session\ DisconnectTimer\enabled and set the key to 1. To disable the timer, set the key to 0.

To update the disconnect timer, create the following registry key (DWORD): 
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\Session DisconnectTimer\MaxDisconnectTime and set the maximum time in minutes to wait before logging off a disconnected session.

Disabling RDP

If a user makes an RDP connection to a desktop, an ICA connection is not possible until either a user logs on interactively on the console of the computer hosting the desktop or the computer is restarted. Disconnecting the RDP session or logging off from RDP is not sufficient. 

Removing the Shut Down Command

Citrix recommends that you apply this Microsoft policy to all XenDesktop users. This prevents users from selecting Shut Down within a XenDesktop session and powering off the desktop, which would require manual intervention from the system administrator.

Locate this policy under User Configuration\Administrative Templates\Start Menu & Taskbar\Remove and prevent access to the Shut Down command and set it to Enabled.

Saturday 16 July 2016

Using Smart Cards with XenDesktop

Using Smart Cards with XenDesktop


Overview


XenDesktop users can use smart cards for:
• Authenticating to XenDesktop sessions
• Digitally signing or encrypting documents
• Authenticating to locally installed or virtualized applications

Virtual desktops must be running Microsoft Windows XP 32-bit with Service Pack 2 or later.

Smart Card Types and Readers Supported


The following are supported:
• Smart cards, including Common Access Card (CAC)
• USB smart card tokens

All the above must be Microsoft-compatible.

Only one reader per endpoint is supported, and, for roaming, all readers across endpoints must be identical.

You must obtain a device driver for the smart card reader and install it on the endpoint device. Many smart card readers comply with the Chip/Smart Card Interface Devices (CCID) standard and can use the CCID device driver supplied by Microsoft.

You must also obtain a device driver (a Cryptographic Service Provider in the case of Windows) for the smart card and install it on both the endpoint device and the virtual desktop. Citrix recommends that you:

• Install drivers and CSPs on the virtual desktop before installing any Citrix software on it
• Install and test the drivers on a physical computer before installing Citrix software

After the Virtual Desktop Agent has been installed on a computer, you can no longer use locally connected smart cards for any purpose, including logon.

Smart card support also involves components available from Citrix partners. These will be updated independently by the partners, and are not described in this document. Refer to the Citrix Ready program at http://www.citrix.com/ready/ for more information.

Endpoint Device Requirements


The following types of endpoint support smart card authentication:

• Domain-joined and non-domain joined desktop appliances. Desktop appliances are devices that can connect only to virtual desktops; all other services are obtained through the virtual desktop. They can support only one connection at a time.

• Domain-joined fat client computers. These are computers that can connect directly to virtual desktops, applications, and other services. They can run local applications and support simultaneous connections.

Endpoints must have the following installed:

• Microsoft Windows XP or XPe (depending on device type) 32-bit with Service Pack 2 or 3.
• Citrix Desktop Receiver 11.1. For further details about installing the Desktop Receiver, see the Citrix Desktop Receiver Administrator’s Guide.
• Microsoft Internet Explorer 7, if users need to access desktops from a browser.
• Appropriate device drivers for the smart cards and readers.

XenDesktop-ready desktop appliances may also support smart card authentication: consult your supplier for further details about this.

Secure Use of Smart Cards


Your organization may have specific security policies concerning the use of smart cards. These policies may, for example, state how smart cards are issued and how users should safeguard them. Some aspects of these policies may need to be reassessed in a XenDesktop environment:

• Tasks performed by smart card administrators (for example smart card issuance) may be inappropriate for carrying out through XenDesktop. Usually these functions are performed at a dedicated smart card station, and may require two smart card readers.

• Infrequent and sensitive tasks, such as unblocking a smart card or resetting a PIN, may also be inappropriate for carrying out through XenDesktop. Security policies often forbid users to perform these functions; they are carried out by the smart card administrator.

• Highly sensitive applications that require strict separation of duties or tamper-resistant audit trails may entail additional special-purpose security control measures. These measures are outside the scope of XenDesktop.

Configuring Smart Card Authentication


To allow users to authenticate with smart cards, you must use the Web Interface to reconfigure the relevant default Web site provided with XenDesktop, or create new Web sites, as follows:

• You can reconfigure the following default Web sites to incorporate a smart card authentication method:
a. The XenDesktop Services site, which is for full-screen-only use with domain-joined Windows XP and XPe computers.
b. The XenDesktop Web site, which is for users of fat client devices, who need to be able to access desktops from a browser.

• The desktop appliance connector Web site installed as part of XenDesktop does not support smart cards. To enable smart card authentication for desktop appliances you must use XenApp Web sites. For further details, see http://support.citrix.com/article/CTX119227/.

If you need to support more than one authentication method, Citrix recommends that you maintain a separate Web site for each method to ensure the best user authentication experience. Pass-through authentication with smart cards is supported for domain-joined computers. For further details, see http://support.citrix.com/article/CTX119227/.

For details of where on the installation media to find the Web Interface and the Web Interface Access Management Console extension, and the locations of the default Web sites, see “Using the Web Interface with Desktop Delivery Controller” on page 18. For information on how to create and configure Web sites, see the Web Interface Administrator’s Guide.

Managing Smart Card Use


Keep the following points in mind when managing the use of smart cards in your organization:

• Every time a user logs on with a smart card to a non-domain-joined Windows XP desktop appliance, the certificate contained on the smart card is copied from the smart card into the desktop appliance’s personal certificate store. All these certificates are displayed when the user attempts to logon. You should either ensure that the user knows which certificate to select, or manually delete the certificates from the certificate store.

• To use smart cards for digitally signing and encrypting streamed applications in a XenDesktop session, you must create an Ignore rule in the relevant profile and add the following named objects to the rule:
\??\Pipe\CtxSmartCardSvc\*
\\.\Pipe\CtxSmartCardSvc\*

You need to create this Ignore rule only for profiles created using Streaming Profiler 1.2.
For details of creating and updating streaming application profiles, see the Citrix Application Streaming Guide.

Removing Smart Cards


When the user removes their smart card, the XenDesktop behavior depends on the smart card removal policy setting on the virtual desktop:

Windows Server 2003 policy setting:

No action
Lock workstation
Force logoff
Disconnect if a remote Terminal Services session

XenDesktop behavior:

No action.
The XenDesktop session is disconnected and the virtual desktop is locked.
The user is forced to log off. If the network connection is lost and this setting is enabled, the session may be logged off and the user may lose data.
The XenDesktop session is disconnected and the virtual desktop is locked.

There may also be an endpoint smart card removal behavior policy if the endpoint is domain-joined. In this case the endpoint has the default Windows behavior.

Friday 15 July 2016

Planning Your Deployment

Planning Your Deployment


Before you install the various components of XenDesktop you need to plan your deployment to ensure that it meets all your organization’s needs. This section provides information about:

• New features in this release and where to find information about how to configure them
• Planning your farm
• Using Active Directory with Desktop Delivery Controller
• Using the Web Interface with Desktop Delivery Controller
• Security planning
• Upgrading from previous versions of XenDesktop

New Features in this Release


The Citrix XenDesktop Overview contains a complete list of new features at this release. The following are new features that require configuration and that are described in this guide:

Feature:

Smart card authentication
User-driven desktop restart
USB support

Described in......

“Using Smart Cards with XenDesktop” on page 37
“To configure user-driven desktop restart” on page 92
“Configuring USB Support” on page 95

Planning Your Farm


XenDesktop allows you to grow your deployment at the rate that best suits your organization. You can start with a simple default configuration that provides you with a working deployment on a minimum number of computers. You can then add further controllers and components to the farm as necessary.

The essential elements you need to have in place for a working XenDesktop farm are:

1. A server to host:

• The main delivery controller component.
• Citrix Licensing. By default, this is installed when you install Desktop Delivery Controller, but you can choose to use a separate server for licensing. For further information on licensing, see “Licensing” on page 46.
• A farm data store. This is where persistent information about the farm, such as configuration information and administrator account information, is stored. By default, a database for this is created locally when you create your server farm, but you can choose to use a database on a separate server. For further information on farm data stores, see “Creating the Farm Data Store” on page 47.
• Management consoles to enable you to create desktop groups and manage your deployment. These are installed by default on servers on which you install Desktop Delivery Controller, and you can also install them on separate computers if you want to manage your deployment remotely. You carry out most management tasks using the Access Management Console; the Presentation Server Console is used only for configuring printing and policies.

2. A domain controller running Active Directory. Active Directory is required for XenDesktop, but you cannot install XenDesktop on a domain controller. For more information on using Active Directory, see “Using Active Directory with Desktop Delivery Controller” on page 15.

3. VMs or physical computers hosting the desktops you want to deliver to your users. You install the Virtual Desktop Agent on these machines to manage communications and broker connections.

4. Endpoint devices running the Citrix Desktop Receiver to enable your users to access desktops.

An initial deployment might consist of the following:

This figure shows a single controller configuration of XenDesktop.

You can distribute the components of your deployment among a greater number of servers, or to provide greater scalability and failover by increasing the number of controllers in your farm. You can install the management consoles on separate computers to enable you to manage your deployment remotely. A distributed deployment is also necessary for an infrastructure based on remote access through Access Gateway.

A more distributed deployment might consist of the following:

This figure shows a distributed components configuration of XenDesktop.

You can also use XenServer, which is provided with all editions of XenDesktop, for scalable and cost-effective hosting of desktops, as described in “Preparing and Provisioning Desktops” on page 67.

The Advanced, Enterprise, and Platinum editions of XenDesktop provide further components to enhance your deployment:

1. Provisioning Server enables you to stream a single desktop image to create multiple virtual desktops on one or more servers in a data center, and then to manage images on an ongoing basis. This greatly reduces the amount of storage required compared to other methods of creating virtual desktops. For information on using Provisioning Server, see “Preparing and Provisioning Desktops” on page 67.

2. You can use XenApp for Virtual Desktops to deliver applications to your sers either by streaming them to virtual desktops or hosting them on a XenApp server. For information on using XenApp for Virtual Desktops, see “Using XenApp for Virtual Desktops” on page 111.

3. Ensure that your users get a consistent experience every time they log on by managing user personalization settings with Citrix User Profile Manager. For information on using Citrix User Profile Manager with XenDesktop, see Using Citrix User Profile Manager with XenDesktop.

4. Information on using Citrix Access Gateway, Edgesight for Endpoints, WANScaler, GoToAssist, and EasyCall is provided in their own productspecific documentation.

Using Active Directory with Desktop Delivery Controller


Desktop Delivery Controller uses the services provided by Active Directory. It requires that all computers in a farm are members of the same domain, or of mutually trusting domains in a single Active Directory forest. It is important to understand how Desktop Delivery Controller uses Active Directory to appreciate the implications for your Active Directory environment.

Desktop Delivery Controller uses Active Directory for two main purposes:

1. Active Directory’s inbuilt security infrastructure is used by desktops to check that incoming communications from controllers come from authorized controllers in the appropriate farm. Active Directory’s security infrastructure also ensures that the data exchanged by desktops and controllers is confidential. Desktop Delivery Controller uses Active Directory's inbuilt Kerberos infrastructure to guarantee the authenticity and confidentiality of communication. For more information about Kerberos, refer to Microsoft’s product documentation.

2. Active Directory is used by desktops to discover the controllers that constitute a farm. This means you can add a new controller to a farm without having to reconfigure all desktops in the farm. Instead, desktops determine which controllers are available by referring to information that controllers publish in Active Directory.

When you create a farm, a corresponding Organizational Unit (OU) must be created in Active Directory. The OU can be created in any domain in the forest that contains your computers. As best practice the OU should also contain the delivery controllers in the farm, but this is not enforced or required. A domain administrator with appropriate privileges can create the OU as an empty container. This administrator can then delegate administrative authority over the OU to the Desktop Delivery Controller administrator. If, however, the installing administrator has CreateChild permissions on a parent OU, this administrator can create the farm OU through the Active Directory Configuration wizard during installation. You can use the standard Active Directory Users and Computers MMC snap-in to configure these permissions. For further information about how to create the OU, see “Configuring Active Directory” on page 50.

During the Desktop Delivery Controller installation process, a small number of objects that are essential for the operation of the farm are created in the OU.

The set of objects created includes:

1. A Controllers security group. The computer account of all controllers in the farm must be a member of this security group. By default, this is done as part of installing Desktop Delivery Controller on a server. Desktops in a farm accept data from controllers only if they are members of this security group.

Ensure that all controllers have the ‘Access this computer from the network’ privilege on all virtual desktops running the Virtual Desktop Agent. You can do this by giving the Controllers security group this privilege. If controllers do not have this privilege, virtual desktops will fail to register.

2. A Service Connection Point (SCP) object that contains meta-information about the farm, such as the farm’s name.

3. A container called RegistrationServices, which is created within the farm’s OU. This contains one SCP object for each controller in the farm. The SCP is created when Desktop Delivery Controller is installed on a server. Each time the controller starts, it validates the contents of its SCP and updates them if necessary.

If multiple administrators are likely to add and remove controllers after the initial installation is complete, they need permissions to create and delete children on the RegistrationServices container and Write properties on the Controllers security group. (These permissions are granted automatically to the administrator who installs the farm.) Either the domain administrator or the original installing administrator can grant these permissions, and Citrix recommends setting up a security group to do this.

The following points are important to bear in mind when you are using Desktop Delivery Controller:

1. Information is written to Active Directory only when installing or uninstalling Desktop Delivery Controller, or when a controller starts and needs to update the information in its SCP (for example, because the controller was renamed or because the communication port was changed). By default, the installation routine sets up permissions on the objects in the farm’s OU appropriately, giving controllers Write access to their SCP. The contents of the objects in the farm OU are used to establish trust between desktops and controllers. You should ensure that:
• Only authorized Desktop Delivery Controller administrators can add or remove computers from the Controllers security group, using the security group’s access control list (ACL)
• Only authorized administrators and the respective controller can change the information in the controller’s SCP

2. Depending on your Active Directory infrastructure, you should be aware of replication and its impact on a Desktop Delivery Controller implementation. Refer to Microsoft’s documentation to understand the concepts of replication and associated delays. This is particularly important if you create the farm’s OU in a domain that has domain controllers located in multiple Active Directory sites. Depending on the location of desktops, delivery controllers, and domain controllers, changes that are made to Active Directory when you are initially creating the OU for the farm, installing or uninstalling controllers, or changing controller names or communication ports may not be visible to desktops until that information is replicated to the appropriate domain controller. The symptoms of such replication delay include desktops that cannot establish contact with controllers and are, therefore, not available for user connections.

Monday 11 July 2016

Preparing and Provisioning Desktops

Preparing and Provisioning Desktops


Overview


This section is intended for administrators who are delivering desktops through virtual machines (VMs). It describes how to use XenServer and Provisioning Server to build a base desktop VM, a vDisk, and a template, which can then be used by the XenDesktop Setup Wizard to create and populate pooled desktop groups.

This section assumes that you are using XenServer as your hosting infrastructure. XenServer is provided on the XenDesktop installation media. XenDesktop also supports Microsoft SCVMM 2008 and VMware Infrastructure 3. You can download documents describing how to use third-party hosting infrastructures with XenDesktop from When you use a third-party hosting infrastructure, Provisioning Server, Desktop Delivery Controller, and the virtual desktops you create all work in the same way as they would on XenServer. Certain features, such as XenMotion (dynamic swapping of VMs between servers), are not available without XenServer.

To use Provisioning Server, you must have licenses for the Advanced, Enterprise, or Platinum editions of XenDesktop.

This section is not intended to replace the core documentation provided with XenServer and Provisioning Server. You should have this documentation available while you are carrying out the tasks described in this section. 

To enable you to use the XenDesktop Setup Wizard to create desktop groups and populate them with desktops, as described in “To create a VM-based pooled desktop group using the XenDesktop Setup Wizard” on page 76, carry out the following tasks in the order shown below. Details of the tasks are provided in the subsequent topics.

1. Create the base desktop image, using XenCenter. To simplify and reduce the number of unique desktops, the base image should contain only a minimal set of options.
2. Set up the infrastructure to provision the base desktop image, by creating a vDisk on Provisioning Server.
3. Add the VM containing the base desktop image to the Provisioning Server database.
4. Install a Provisioning Server target device on the base desktop VM.
5. Image the base desktop VM to the vDisk.
6. Set the vDisk access mode to Standard. When you create desktop groups using the XenDesktop Setup Wizard, only Standard vDisks are listed in the wizard, so you must ensure that this access mode is selected.
7. Create a template using XenCenter. This template is a diskless VM template that you associate with a Provisioning Server vDisk when creating multiple desktops. It provides a guide to how the VMs should be allocated; for example RAM, CPU, and optimization settings.

If you encounter any issues when using Provisioning Server, refer to the following logs that are on the machine running Provisioning Server:

• %ALLUSERSPROFILE%\Citrix\Provisioning Server\mcli.log
• %ALLUSERSPROFILE%\Citrix\Provisioning Server\soapserver.log

To create a base desktop VM


1. In XenCenter, use the New VM wizard to create a VM in the relevant resource pool, ensuring that Start VM automatically is selected on the final page of the wizard.
2. When the VM starts, use your operating system installation media to install either Windows XP or Vista.
3. When prompted, configure a dynamic IP address so that the base desktop VM receives its IP address from the DHCP server running on the domain controller.
4. Install XenServer Tools into the image to provide optimal performance and functionality. To install XenServer Tools, select VM > Install XenServer Tools.
5. Restart the VM.
6. Apply any recommended operating system updates to the VM.
7. Log on to the VM and add it to the Active Directory domain. For more information about this procedure, see the relevant Microsoft documentation.
8. Add the DNS suffix to the VM:
A. On the VM, open the Windows Internet Protocol (TCP/IP) Properties dialog box, click Advanced, and select the DNS tab in the Advanced TCP/IP Settings dialog box.
B. Type the DNS suffix for the domain and click OK.
C. Restart the VM and ensure that it is running.
9. Install the Virtual Desktop Agent on the VM as described in “To install the Virtual Desktop Agent” on page 59.
10. Restart the VM.
11. Customize the VM to meet your users’ requirements. For example, if you have the Enterprise or Platinum editions of XenDesktop, you can install the XenApp plugins to the base desktop VM to allow users to log on to XenApp for Virtual Desktops automatically and access virtual applications. For more information, see “Installing the XenApp Plugins” on page 115. You can also pre-cache streamed applications at logon from XenApp to optimize performance; see “Pre-caching Streamed Applications” on page 116 for more information.

To create a vDisk


1. In the Provisioning Server Console, right-click the Stores folder and select Create store.
2. Select the General tab and specify a name and, optionally, a description for the new store.
3. Select the Paths tab and specify the path for the new store. This can be a local drive on the machine running Provisioning Server or a network share.
4. Click the Servers tab and select a site from the list. Select the relevant server under Servers that provide this store and click OK.
5. In the left pane of the console, right-click the new store you just created and select Create vDisk.
6. In the Create vDisk dialog box, specify the requested values and click Create vDisk.
If you intend to use the XenDesktop Setup Wizard, your vDisk name and description must contain only standard, printable ANSI characters.
The Vdisk size should match the VM disk size.
7. Enable Active Directory machine account password management by editing the properties of the vDisk you have just created.
8. Enable automatic password management on the server.
9. In the details pane of the console, right-click the new disk you created and select Mount vDisk.
A. On the Provisioning Server machine, open the My Computer folder (the Computer folder on Windows Vista).
B. Under Devices with Removable Storage, right-click the entry for removable disk and select Format.
C. Format the vDisk as an NTFS disk.
10. In the details pane of the Provisioning Server Console, right-click your new vDisk and select Unmount vDisk.

To add the base desktop VM to the Provisioning Server database


1. In XenCenter, right-click the base desktop VM and select Edit.
2. Select the Startup Options tab, move Network to the top of the Boot Order list, and click OK.
3. Select the Network tab and make a note of the MAC address for the base desktop VM.
4. In Provisioning Server, navigate to the Device Collections folder for the site, right-click the collection, and select Create Device.
5. Specify the device name and a description.
6. Type the MAC address of the base desktop VM and click Add device.
7. In the left pane of the console, right-click the new device and select Properties.
8. Select Hard Disk from the Boot from list.
9. Select the vDisk tab, click Add, and select the vDisk you created. Click OK and then click OK again.

To install a target device for the x86 Platform on the base desktop VM


1. In XenCenter, restart the base desktop VM.
2. Insert the Provisioning Server installation media into the optical drive. If the installation window does not appear, run PVSSRV_Device.exe.
3. On the product installation window, click Install Target Device for 32 bit Platform, and follow the instructions provided in the wizard. When you have completed the wizard, the vDisk is mapped to the base desktop VM and a vDisk icon appears in the Windows notification area
4. Double-click the vDisk icon and confirm that the vDisk status is Active.
5. In My Computer, check the label assigned to the new drive (typically, this is E) and make a note of it.

To image the base desktop VM to the Provisioning Server vDisk


1. On the base desktop VM, click Start > All Programs > Citrix > Provisioning Server > Provisioning Server Image Builder.
2. In the Device Image Builder dialog box, click Optimize.
3. In the Provisioning Server Device Optimization Tool dialog box, ensure that all the options are selected and click OK.
4. In the Device Image Builder dialog box, ensure that the destination drive is set to the letter denoting the new drive (typically E:) and click OK. The destination drive maps to the vDisk you created.
5. Ensure that the Delete all files and folders in destination path before building image check box is selected and click Build.
6. On the Confirm Build details page, click Yes.
7. When the client image build is complete, click OK.
8. Click Close.
9. Shut down the base desktop VM.

To set the vDisk access mode


1. In the Provisioning Server Console, navigate to the vDisk, select Properties, and click Edit device properties.
2. In the vDisk File Properties dialog box, select the Mode tab and, under Access Mode, select Standard Image. Click OK and then click OK again.

To create a Provisioning Server VM template


1. In XenCenter, select New VM.
2. In the New VM wizard, specify appropriate values for your deployment. On the Virtual Disks page, do not assign a vDisk to this VM.
3. On the Finish page, clear the Start VM automatically check box and click Finish.
4. In XenCenter, right-click PvS VM Template, select Convert to Template, and click OK.