Decision: Profile Streaming

Decision: Profile Streaming

Note: The following design decision only applies to those environments that use Citrix Profile Management.

With user profile streaming, files and folders contained in a profile are fetched from the user store (file server) to the local computer when a user accesses them. During the logon process, Citrix Profile

Management immediately reports that the profile load process has completed reducing profile load time to almost zero.

Citrix recommends enabling profile streaming for all scenarios. If it is desired to keep a local cached copy of the user profile, it is recommended to enable the “Always Cache” setting and configure a size of 0. This ensures that the user profile is downloaded in the background and enables the system to use this cached copy going forward.

Note: Profile streaming is not required and does not work with the personal vDisk feature of Citrix XenDesktop. Even if explicitly enabled by means of Group Policy, the profile streaming setting is

automatically disabled.

Decision: Active Write Back

Note: The following design decision only applies to those environments that use Citrix Profile Management.

By enabling the active write back feature, Citrix Profile Manager detects when an application has written and closed a file and copies the file back to the network copy of the profile during idle

periods. In scenarios where a single user leverages multiple virtual desktops or hosted shared desktops simultaneously, this feature can be tremendously beneficial. However, Citrix Profile

Management does not copy any registry changes back to the network, except during an ordered logoff. As such, there is a risk that the registry and files may get out of alignment on provisioned

systems, where locally cached profile information is wiped upon reboot. Therefore, it is recommended to disable active write back functionality for non-persistent Provisioning Services or Machine Creation Services scenarios.

Decision: Configuration Approach

Note: The following design decision only applies to those environments that use Citrix Profile Management.

Citrix Profile Management can be configured by means of an “.ini” file, Microsoft Group Policy and Citrix Policy (Citrix Profile Management 5.0 only). While each option offers the same configuration settings, Group Policy is recommended because it allows administrators to perform Windows and Citrix profile configurations from a single point, minimizing the tools necessary for profile management.

Note: With Citrix Profile Management 5.0, the desktop type is automatically detected and Citrix Profile Management policies set accordingly. For more information, please refer to Citrix eDocs –

How automatic configuration works.

Decision: User Profile Replication Between Datacenters

While having an active/active datacenter on a network level is easily accomplished with GSLB, the replication of user data makes having a fully active/active deployment complex in most situations. To

have an active/active configuration where users are not statically assigned to a specific datacenter, will require users to have no form of personalization requirements. This will limit the user’s ability to

make any configuration changes and will not allow them to create any documents or persistent data. The exception to this is when a high-speed low latency connection such as dark fibre is available between datacenters. This will let resources in both locations can point to the same file server allowing for a true active/active solution. Also, an active/active configuration can be accomplished when applications are used that rely solely on a backend database that is actively replicated between datacenters and do not store any data in the user profile.

For redundancy and failover purposes, user data such as Windows profiles and documents should be synchronized between datacenters. Although it is recommended to replicate user data between datacenters, the replication would be an active/ passive configuration. This means the data can only be actively consumed from a single datacenter. The reason for this limitation is the distributed file locking method inside Windows that only allows a single user to actively write to a file. Therefore, active/ active replication of user data is not supported. Any supported configuration consists of a one-way replication of data that is active in a single datacenter at any point in time.

For example, the figure below describes a scenario where user data is passively replicated from Datacenter A to Datacenter B. In this example, File Server A is the primary location for user data in

Datacenter A and File Server B is the primary location in Datacenter B. One-way replication of the user data occurs for each file server to allow for the user data to be available in the opposite datacenter if a failover occurs. Replication technologies such as Microsoft DFS can be configured to mirror user profiles and documents to a file server in another datacenter. DFS Namespaces can also be used to have a seamless path for the location of the user data.

User Policies

Citrix policies provide the basis to configure and fine tune XenDesktop environments, allowing organizations to control connection, security and bandwidth settings based on various combinations of users, devices or connection types.

When making policy decisions it is important to consider both Microsoft and Citrix policies to ensure that all user experience, security and optimization settings are considered. For more information on specific Windows related policies, please refer to the Microsoft white paper - Group Policy Settings Reference for Windows and Windows Server, specifically settings related to Windows Server 2008 R2, Windows 7, Windows Server 2012 and Windows 8. For a list of all Citrix-related policies, please refer to the Citrix Policy Reference spreadsheet.

Decision: Preferred Policy Engine

With XenDesktop 7 organizations have the option to configure Citrix policies via Citrix Studio or through Active Directory group policy using Citrix ADMX files, which extend group policy and provide advanced filtering mechanisms.

Using Active Directory group policy allows organizations to manage both Windows policies and Citrix policies in the same location, and minimizes the administrative tools required for policy management. Group policies are automatically replicated across domain controllers, protecting the information and simplifying policy application.

Citrix administrative consoles should be used if Citrix administrators do not have access to Active Directory policies. Architects should select one of the above two methods as appropriate for their

organization’s needs and use that method consistently to avoid confusion with multiple Citrix policy locations.

Decision: Policy Integration

When configuring policies, organizations often require both Active Directory policies and Citrix policies to create a completely configured environment. With the use of both policy sets, the resultant set of policies can become confusing to determine. In some cases, particularly with respect to Windows Remote Desktop Services (RDS) and Citrix policies, similar functionality can be configured in two different locations. For example, it is possible to enable client drive mapping in a Citrix policy and disable client drive mapping in a RDS policy. The ability to use the desired feature may be dependent upon the combination of RDS and Citrix policy. It is important to understand that Citrix policies build upon functionality available in Remote Desktop Services. If the required feature is explicitly disabled in RDS policy, Citrix policy will not be able to affect a configuration as the underlying functionality has been disabled.

In order to avoid this confusion, it is recommended that RDS policies only be configured where required and there is no corresponding policy in the XenDesktop configuration, or the configuration is specifically needed for RDS use within the organization. Configuring policies at the highest common denominator will simplify the process of understanding resultant set of policies and troubleshooting policy configurations.

Decision: Folder Redirection

Decision: Folder Redirection

While redirecting profile folders, such as user documents and favorites, to a network share is a good practice to minimize profile size, architects need to be aware that applications may frequently read and write data to profile folders such as AppData, causing potential issues with file server utilization and responsiveness. It is important to thoroughly test profile redirection before implementation in production to avoid these issues. Therefore, it is important to research profile read / write activities and to perform a pilot before moving to production. Microsoft Outlook is an example of one application that regularly performs profile read activities as the user signature is read from the user profile every time an email is created.

Decision: Folder Exclusion

Excluding folders from being persistently stored as part of a roaming of hybrid profile can help to reduce profile size and logon times. By default Windows excludes the Appdata\Local and Appdata\LocalLow folders, including all subfolders, such as History, Temp and Temporary Internet Files. In addition, the downloads and saved games folders should also be excluded.

Decision: Profile Caching

Local caching of roaming or hybrid user profiles on a server or virtual desktop is default Windows behavior and can reduce login times and file server utilization / network traffic. With profile caching,

the system only has to download changes made to the profile. The downside of profile caching is that it can consume significant amounts of local disk storage on multi-user systems, such as a hosted shared desktop server.

Citrix recommends not deleting locally cached profiles for the following scenarios:

For optimizing logon times:

• Hosted VDI – Dedicated / Existing / Physical

• Hosted VDI – Static with PVD

• Hosted VDI – Remote PC

• Local VM

For optimizing logoff times:

• Non-persistent virtual desktops and Hosted Shared Desktop servers, with reboot on logoff or daily reboot.

Citrix recommends deleting locally cached profiles on logoff for the following scenarios to avoid the proliferation of stale profiles:

• Hosted shared provided by persistent hosted shared desktop servers.

• Hosted VDI pooled without immediate reboot on logoff.

Configuring the “Delay before deleting cached profiles” Citrix policy sets an optional extension to the delay before locally cached profiles are deleted at logoff. Extending the delay is useful if a process keeps files or the user registry hive open during logoff. This can also reduce logoff times for large profiles.

Decision: Profile Permissions

For security reasons, administrators, by default, cannot access user profiles. While this level of security may be required for organizations that deal with very sensitive data, it is unnecessary for most environments and can complicate operations and maintenance. Therefore, consider enabling the “Add the Administrators security group to roaming user profiles” policy setting. The configuration of this policy should be aligned with the security characteristics of the user groups captured during the

assess phase. For more information on the permissions required for the file share, please refer to Microsoft TechNet - Deploying Roaming Profiles.

Decision: Profile Path

Determining the network path for the user profiles is one of the most significant decisions during a user profile design process. In general it is strongly recommended to leverage a redundant and high performance file server or NAS device.

There are three topics that must be considered for the profile share:

• Performance – File server performance will effect logon times. For large virtual desktop infrastructures, a single file server cluster may not be sufficient to handle periods of peak activity.

In order to distribute the load across multiple file servers, the file server address and share name will need to be adjusted.

• Location – User profiles are transferred over the network by means of the SMB protocol, which does not perform well on high latency network connections. Furthermore, WAN connections are typically bandwidth constrained, which can add additional delay to the profile load process. Therefore, the file server should be located in close proximity to the servers and virtual desktops to

minimize logon times.

• Operating system platforms – User profiles have a tight integration with the underlying operating system and it is not supported to reuse a single user profile on different operating systems or different platforms like 64-Bit (x64) and 32-Bit (x86). For more information, please refer to the Microsoft knowledge base article KB2384951 – Sharing 32 and 64-bit User Profiles. Windows 2008 and Windows Vista introduced a new user profile structure, which can be identified by .V2 profile directory suffix, which makes older user profiles incompatible with newer operating systems such as Windows 2012, 7 and 8. In order to ensure that a separate profile is used per platform, the profile

directory has to be adapted.

There are two methods that can be used to address these challenges that are based on Windows built-in technology:

• User object – For every user object in Active Directory, an individual profile path, which contains file server name and profile directory, can be specified. Since only a single profile path can be specified per user object, it is not possible to ensure that a separate profile is loaded for each operating system platform.

• Computer group policy or system variables – The user profile path can also be configured by means of computer specific group policies or system variables. This enables administrators to ensure that a user profile is dedicated to the platform. Since computer specific configurations affect all users of a system, all user profiles will be written to the same file server. To load balance user profiles across multiple servers dedicated XenDesktop delivery groups have to be created per file server.

Note: Microsoft does not support DFS-N combined with DFS-R for actively used user profiles. For more information, please refer to the Microsoft articles:

• Information about Microsoft support policy for a DFS-R and DFS-N deployment scenario 

• Microsoft’s Support Statement Around Replicated User Profile Data

When using Citrix Profile Management, a third option is available to address these challenges:

User object attributes and variables – Citrix Profile Management enables the administrator to configure the profile path by means of a computer group policy using attributes of the user object in Active Directory to specify the file server dynamically. In order to achieve this, three steps are required:

1. Create a DNS alias (for example, fileserver1) which refers to the actual file server

2. Populate an empty LDAP attribute of the user object (for example, l or UID) with the DNS Alias

3. Configure Citrix Profile Management by means of GPO to use a profile path which refers to the LDAP attribute (for example, If attribute UID is used the profile path becomes \\#UlD#\Profiles\

profiledirectory)

In addition, Citrix Profile Management automatically populates variables to specify the profile path dynamically based on the operating system platform. Valid profile management variables are:

• !CTX_PROFILEVER! – Expands to v1 or v2 depending on the profile version.

• !CTX_OSBITNESS! – Expands to x86 or x64 depending on the bit-level of the operating system.

• !CTX_OSNAME! – Expands to the short name of the operating system, for example Win7

By combining both capabilities of Citrix Profile Management, a fully dynamic user profile path can be created, which can be load balanced across multiple file servers and ensure profiles of different

operating system platforms are not mixed. An example of a fully dynamic user profile path is shown below: \\#UlD#\profiles$\%USERNAME%.%USERDOMAIN%\!CTX_ OSNAME!!CTX_OSBITNESS!

Simplified SmartAccess Decision Logic

Simplified SmartAccess Decision Logic

Decision: Session Policy

User groups with NetScaler Gateway as their authentication point must have corresponding session policies defined. Session policies are used to define the overall user experience.

Organizations create sessions policies based on the type of Citrix Receiver used. For the purpose of session policy assignment, devices are commonly grouped as either non-mobile (such as Windows OS based), or mobile (such as iOS or Android). Therefore a decision on whether to provide support for mobile devices, nonmobile devices, or both should be made based on client device requirements identified during the assess phase.

To identify devices session policies, include expressions such as:

• Mobile devices – The expression is set to REQ.HTTP.HEADER User-Agent CONTAINS Citrix Receiver which is given a higher priority than the non-mobile device policy to ensure mobile devices are matched while non-mobile devices are not.

• Non-mobile devices – The expression is set to ns_true which signifies that it should apply to all traffic that is sent to it.

An alternative use of session policies is to apply endpoint analysis expressions. These session policies are applied post authentication yet mimic the previously mentioned pre-authentication policies. Use

of session policies is an option to provide a fallback scenario to endpoints that do not meet full security requirements such read-only access to specific applications.

Decision: Session Profile

Each session policy must have a corresponding session profile defined. The session profile defines details required for the user group to gain access to the environment. There are two primary forms of session profiles that determine the access method to the virtual desktop environment:

• SSLVPN – Users create a virtual private network and tunnel all traffic configured by IP addresses through the internal network. The user’s client device is able to access permitted intranet resources as if it were on the internal network. This includes XenDesktop sites and any other internal traffic such as file shares or intranet websites. This is considered a potentially less secure access method since network ports and routes to services outside of the virtual desktop infrastructure may be opened leaving the enterprise susceptible to risks that may come with full VPN access. These risks may include denial of service attacks, attempts at hacking internal servers, or any other form of malicious activity that may be launched from malware, trojan horses, or other viruses via an Internet based client against vulnerable enterprise services via routes and ports.

Another decision to consider when SSLVPN is required is whether to enable split tunneling for client network traffic. By enabling split tunneling, client network traffic directed to the intranet by Citrix Receiver may be limited to routes and ports associated with specific services. By disabling split tunneling, all client network traffic is directed to the intranet, therefore both traffic destined for internal services as well as traffic destined for the external services (Internet) traverses the corporate network. The advantage of enabling split tunneling is that exposure of the corporate network is limited and network bandwidth is conserved. The advantage of disabling split tunneling is that client traffic may be monitored or controlled through systems such as web filters or intrusion detection systems.

• HDX proxy – With HDX Proxy, users connect to their virtual desktops and applications through the NetScaler Gateway without exposing internal addresses externally. In this configuration, the NetScaler Gateway acts as a micro VPN and only handles HDX traffic. Other types of traffic on the

client’s endpoint device, such as private mail or personal Internet traffic do not use the NetScaler Gateway.

Based on the endpoint and Citrix Receiver used, a decision must be made as to whether this method is supported for each user group. HDX Proxy is considered a secure access method for remote virtual desktop access since only traffic specific to the desktop session is allowed to pass through to the corporate infrastructure. Most Citrix Receivers support HDX Proxy and it is the preferred method:

Decision: Preferred Datacenter

Enterprises often have multiple active datacenters providing high availability for mission critical applications. Some virtual desktops or applications may fall into that category while others may only be accessed from a specific preferred datacenter. Therefore, the initial NetScaler Gateway that a user authenticates to in a multi-active datacenter environment may not be within the preferred datacenter

corresponding to the user’s virtual desktop resources. StoreFront is able to determine the location of the user’s assigned resources and, direct the HDX session to those resources.

There are static and dynamic methods available to direct HDX sessions to their virtual desktop resources in their primary datacenter. The decision regarding which method to select should be based on the availability of technology to dynamically assign sites links such as Global Server Load Balancing (GSLB) along with the network assessment of intranet and Internet bandwidth as well as Quality of Service (QoS) capabilities.

Note: For more information on configuring the static and dynamic methods of GSLB, please refer to Citrix eDocs – Configuring GSLB for Proximity.

• Static Direct – The user may be given a FQDN mapped to an A record that is dedicated to the primary datacenter NetScaler Gateway(s) allowing them to access their virtual desktop directly wherever they are in the world. This approach eliminates a layer of complexity added with dynamic allocation. However, it also eliminates fault tolerance options such as the ability to access the virtual desktop through an alternative intranet path when a primary datacenter outage is limited to the Internet access infrastructure.

• Dynamic Internet – For most dynamic environments, the initial datacenter selected for authentication is the one closest to the user. Protocols such as GSLB dynamic proximity calculate

the least latency between the user’s local DNS server and the NetScaler Gateway. Thereafter, the HDX session may be redirected through a NetScaler Gateway to the preferred datacenter by assignment in StoreFront accordingly. However, a significant portion of the HDX session would likely be forced to travel over the best effort Internet without QoS guarantees.

For example, a user with a dedicated desktop in the United States, traveling in Europe may be directed to a NetScaler Gateway hosted in a European datacenter. However, when the user launches their desktop, an HDX connection will be established to the virtual desktop via a NetScaler Gateway

hosted in the preferred datacenter in the United States.

Typical StoreFront Architecture

Typical StoreFront Architecture

For more information, please refer to Citrix eDocs:

• Use the SSL Relay (XenApp 6.5 & Below Only)

• Use SSL on XenDesktop & XenApp 7.5 Controllers

• Secure your StoreFront environment

Decision: Routing Receiver with Beacons

Citrix Receiver uses beacon points (websites) to identify whether a user is connected to an internal or external network. Internal users are connected directly to resources while external users are connected via Citrix NetScaler Gateway. It is possible to control what a user sees by restricting applications due to which beacon they have access to.

The internal beacon should not be a site that is resolvable externally. By default, the internal beacon is the StoreFront service URL. The external beacon can be any external site that will produce an http response. Citrix Receiver continuously monitors the status of network connections (for example, link up, link down or change of the default gateway). When a status change is detected, Citrix Receiver will first verify that the internal beacon points can be accessed before moving on to check the accessibility of external beacon points. StoreFront provides Citrix Receiver with the http(s) addresses of the beacon points during the initial connection process and provides updates as necessary.

It is necessary to specify at least two highly available external beacons that can be resolved from public networks.

Decision: Resource Presentation

StoreFront displays resources differently than Web Interface. Instead of having all accessible resources appear on the home screen, first time users are invited to choose (subscribe) to the

resources they want to regularly use after they logon. Before a user can launch an application, they must first choose which resources should be placed on their home screen. This approach, deemed “Self-Service”, allows users to restrict the resources that they see on their home screen to the ones that they use on a regular basis. The resources chosen by every user for each store are recorded by

the subscription store service so that they can be displayed on the Citrix Receiver home screen from any device that the user connects from.

Administrators should determine which applications should always be displayed to users on their home screen or the featured tab. These applications will vary for each deployment and should be

defined during the Assess Phase of a Citrix Assessment. In general, these applications are common applications such as Microsoft Word and any other applications that every user in an environment

may need. StoreFront can filter/present these resources using Keywords.

Using Keywords is a very simple way to prepopulate a user’s home screen. To add applications to the home screen, add KEYWORDS:Auto to the application or desktop description in XenApp or XenDesktop. Another option that can be used to organize resources is using the keyword KEYWORDS:Featured. Unlike the Auto keyword, which places certain resources on the home screen, the Featured keyword only places resources in the Featured category

The resource will also appear in another category if a Client Application folder has been specified.

In addition the string KEYWORDS:prefer=”application” can be used to specify that the locally installed version of an application should be used in preference to the equivalent delivered instance if both are available.

For more information please refer to Citrix eDocs – Optimize the user experience and Configure application delivery.

Decision: Scalability

The number of Citrix Receiver users supported by a single StoreFront server depends on the resources assigned and level of user activity:

For an optimal user experience, Citrix recommends that no more than ten XenDesktop, XenApp, App Controller and VDI-in-a-Box deployments are aggregated into a single store.

Synchronization Database – If users connect to multiple StoreFront servers within an environment, their personalized settings (application subscriptions) are immediately stored on the StoreFront server and replicated to other StoreFront servers. The Synchronization Database on each StoreFront server needs to be large enough to accommodate user and application subscriptions, about 3 KB per user per app.

Decision: Multi-site App Synchronization

Moving between multiple locations would benefit from synchronization of their application subscriptions between multiple deployments. For example, a user based in Location 1 can log on to the StoreFront deployment in Location 1, access the store, and subscribe to some applications. If same user would travel to Location 2 and accessed a similar store provided by the Location 2 StoreFront deployment, the user would have to re-subscribe to all of their applications once again.

Each StoreFront deployment maintains details of users’ application subscriptions separately by default. By configuring subscription synchronization between the stores, it is possible to ensure that users only need to subscribe to applications in one location. The interval for the subscription synchronization will vary from site to site due to the distance between sites. The recommended interval should be less than the time needed for a user to travel from one site to another. For more information on how to use PowerShell with StoreFront 2.5, please refer to the Citrix eDocs article – To configure subscription synchronization.

User Layer

User Layer

The top layer of the design methodology is the user layer, which is defined for each unique user group.

The user layer appropriately sets the overall direction for each user group’s virtualized environment. This layer incorporates the assessment criteria for business priorities and user group requirements in order to define effective strategies for endpoints and Citrix Receiver. These design decisions impact the flexibility and functionality for each user group.

Endpoint Selection

There are a variety of endpoints devices available, all with differing capabilities, including:

• Tablet based on Android or iOS

• Laptop

• Desktop PC

• Thin client

• Smartphone

The user’s primary endpoint device must align with the overall business drivers as well as each user’s role and associated requirements. In many circumstances, multiple endpoints may be suitable, each offering differing capabilities.

Decision: Endpoint Ownership

and managed. However, more and more organizations are now introducing bring your own device (BYOD) programs to improve employee satisfaction, reduce costs and to simplify device management. Even if BYOD is a business priority, it does not mean that every user should be allowed to use a personal device in the corporate environment.

Certain user requirements, which were identified during the user segmentation, can greatly impact the suitability of personal devices:

• Security – Users requiring a high-level of security might not be able to bring a personal device into the secured environment for risk of data theft.

• Mobility – Users operating in a disconnected mode might not be able to use a personal device, as the local VM FlexCast model associated with this type of requirement can have specific hardware requirements, or special maintenance requirements. Additionally, the local operating system may be destroyed when the local VM FlexCast option is utilized.

• Criticality – Users with a high criticality rating might require redundant endpoints in the event of failure. This would require the user to have an alternative means for connecting in the event their personal device fails, likely making these users poor candidates for a BYOD program.

• FlexCast model – A personal device should not be recommended for user groups utilizing a client-hosted FlexCast model like streamed VHD, local VM or Remote PC. These FlexCast models typically require a specific hardware configuration or installation that will restrict device selection.

The diagram shown below provides guidance on when user owned devices could be used.

Decision: Endpoint Lifecycle

Organizations may choose to repurpose devices in order to extend refresh cycles or to provide overflow capacity for contract workers. Endpoints now offer more capabilities allowing them to have longer useful lifespans. In many cases, these hardware capabilities vastly outstrip the needs of a typical user. When coupled with the ability to virtualize application and desktop workloads, this provides new options to administrators such as repurposing existing workstations. These options go well beyond the simple threeyear PC refresh cycle. However, the benefits of repurposing or reallocating a workstation should be balanced against the following considerations.

• Minimum standards – While cost factors of repurposing existing workstations may be compelling, certain minimum standards should be met to guarantee a good user experience. At a minimum, it is recommended that repurposed workstations have a 1GHz processor, 1GB of RAM, 16GB of free disk space and a GPU that is capable of supporting HDX features.

• Business drivers – Priorities underpin the success of any major project. Those organizations that have prioritized reducing capital expenditure by means of prolonging the hardware refresh cycle can benefit from repurposing hardware. Conversely, if an organization’s business drivers include reducing power consumption as part of an overall green initiative, purchasing newer endpoints may be beneficial in order to take advantage of the latest generation of power management capabilities available in the most modern devices.

• Workload – The type of work and FlexCast model for an end user can determine whether they are a good candidate for a repurposed endpoint, or may be better served with a new device. If the work performed by the individual involves locally installed applications, the individual may be best served by a new endpoint that offers the most powerful and recently updated processor and graphics architecture. However, if a user is largely performing tasks associated with virtualized applications that do not involve the latest multimedia capabilities such as webcams, VoIP and media redirection, then a repurposed workstation should be a viable alternative.

Decision: Endpoint Form Factor

The capabilities of endpoints have grown along with efficiencies offered in thin client form factors. Even mid-range thin clients now have graphics capabilities that allow utilization of HDX features such as multi-monitor support while offering management and power efficiency benefits. This expansion of capabilities has given IT administrators more options and flexibility than ever before.

Most organizations will likely deploy a mixture of fully featured clients as well as thin clients. It is important to focus on multiple user group attributed in order to best determine the type of endpoint that should be deployed:

Decision: Thin Client Selection

Thin client vendors now offer a range of operating system choices, including Windows Thin PC (based on Windows 7), embedded versions of Windows (XP, Windows 7 and Windows 8), Linux

variants, as well as limited functionality clients that boot directly into a virtual desktop and offer a zero operating system footprint. The following factors should be considered during the selection of  a thin-client device:

• User workload – Windows Thin PC or limited functionality solutions such as Dell Wyse Zero clients should be tailored to true task workers or knowledge workers with limited needs. More

capable thin devices such as Windows Embedded solutions can be provided to users that require

• In-house expertise – Many organizations have management toolsets already in place to handle thin client infrastructure such as retailers that may have kiosks. In-house expertise with a thin client management infrastructure can determine the selection of thin client platform. It is recommended that existing in-house expertise is leveraged, so long as the platform is capable of supporting a virtual desktop infrastructure implementation, as outlined on the Citrix Ready site.

• Licensing cost – There are licensing considerations for most platforms. Windows thin PC and embedded versions incur immediate license costs related to Microsoft licensing, whereas a custom Linux solution may not. However, these costs must be closely balanced against additional add-on licensing that may be required for Linux devices, which are built into Windows. For example, various media codecs may require additional license expenditure in a Linux thin client context. For more information, please refer to the Microsoft Partner Site.

Experience from the Field

Large systems integrator – A large systems integrator recommended that a customer deploy a single type of low-end, limited capability endpoint for all users. Upon deployment to production, users immediately complained that they received a poor user experience when viewing multimedia content over the WAN. At great cost, the systems integrator and customer re-assessed the environment and chose to deploy endpoints that supported HDX MediaStream. The mistake caused a schism between systems integrator and the customer, resulting in lost time, capital and the end of a business relationship that was fostered over many years. It is critical that the endpoints assigned to each user group can support their requirements.

Managing Your Desktop Delivery Controller Deployment

Managing Your Desktop Delivery Controller Deployment

Overview

This section describes how to carry out the following tasks:

• Putting desktops into maintenance mode.

• Managing sessions. You can view, disconnect, and log off sessions. You can also send messages to users.

• Manually controlling VMs.

• Migrating controllers to other farms.

• Migrating desktops to other farms.

• Updating license server settings.

The details of all these tasks are described in the following topics. Other general management tasks, such as configuring connections and securing farms, are described in detail in the Citrix Presentation Server Administrator’s Guide.

Putting Desktops into Maintenance Mode

If you want to temporarily stop connections to a desktop so that maintenance tasks can be carried out, you can put the desktop into maintenance mode. If the desktop is in a group that uses the idle pool settings, note that it will be entirely under manual control until you take it out of maintenance mode again.

To put a desktop into maintenance mode

1. Select the relevant desktop group.

2. Select the Virtual Desktops view so that all the desktops for that group are listed.

3. Select the relevant desktop.

4. From the task pane, select Enable maintenance mode.

No user can now log on to that desktop. If a user is logged on when you select maintenance mode, maintenance mode takes effect as soon as that user logs off. If a user tries to connect to an assigned desktop while it is in maintenance mode, a message appears telling them that the desktop is currently unavailable and to try reconnecting.

When a desktop is in maintenance mode, the Disable maintenance mode task becomes available. To take a desktop out of maintenance mode, select the desktop, then select Disable maintenance mode.

Managing Sessions

To view sessions for a desktop group

1. Select the relevant desktop group in the console tree.

2. Select the Virtual Desktops In Use view.

To view all sessions for a particular user

1. From the Search options in the tasks pane, select Advanced search.

The Advanced Search dialog box appears.

2. From the Find list, select Session by user.

3. Type the user name.

4. Select the relevant node of the console tree (for example, Desktop Groups).

5. Click Search.

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”

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.

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.

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.

• 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 thelist 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.

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”

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

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” 

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” 

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.

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.

Command-Line Tools

Command-Line Tools
Tools are provided to enable you to install and remove controllers and the Virtual Desktop Agent using the command line. You can also use a command-line tool to configure Active Directory.

Installing and Removing Controllers Using Setup.exe
The Setup.exe file supports several command-line options for controlling the installation and removal of Desktop Delivery Controller.

If you control the installation through the command line, you must also configure Active Directory from the command line. For further information, see “Configuring Active Directory Using ADSetup” on page 122. You have to configure Active Directory not only when you create a new farm, but also when you add a controller to a farm.

Examples
The -passive option is an efficient way to install a large number of controllers compared with using the Installation wizard on individual controllers.

Example 1: Installing a Single Component
setup.exe -passive -components CONSOLES where CONSOLES (the management consoles) is the component you are installing.

Example 2: Installing all the Desktop Delivery Controller
Components on a Single Server setup.exe -passive -createfarm MyFarm
-components DDC,LIC_SERVER,CONSOLES
-edition STD
where:
MyFarm is the farm you are creating, DDC, LIC_SERVER, and CONSOLES are the components you are installing on the server, and you are licensed to use XenDesktop Standard Edition.

Example 3: Creating a New Controller and Adding it to a Farm
The following example shows how to create a new controller, installing only the core Desktop Deliver Controller component, and then add that controller to an existing farm that is using an external database on a separate server:
setup.exe -passive -joinfarm ele1985 -components DDC
-dsnfilepath c:\MF20.dsn -dbusername alexco -dbpassword libby02
where:
ele1985 is an existing controller in the farm, DDC is the component you want to install, c:\MF20.dsn is the path to the dsn file, alexco is the user name for accessing the database, and libby02 is the password for accessing the database.
In this example the MF20.dsn file was copied to the server before the installation process started.

Installing and Removing the Virtual Desktop Agent Using XdsAgent.msi
The Virtual Desktop Agent installer (XdsAgent.msi) supports the standard msiexec command-line options. For details of these options, go to:
http://msdn2.microsoft.com/en-us/library/aa367988.aspx

You can set the following properties as msiexec property arguments:
You must ensure that Microsoft .NET Framework 3.5 has already been installed before you install the Virtual Desktop Agent.

Configuring Active Directory Using ADSetup
configuration. You can use it to start the wizard described in “Configuring Active Directory” on page 50. You can also run it using any of the other parameters described in the table below.

Note: If you need to relocate or rename the farm OU, Citrix recommends that you use standard Active Directory management tools to do this.
Several of the options described in the table below refer to OU distinguished names. For more information about character-handling in these names, refer to:
http://msdn2.microsoft.com/en-us/library/aa366101(VS.85).aspx
and
http://www.ietf.org/rfc/rfc2253.txt

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.

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.