XD Design Handbook
Citrix Xen Desktop Design Handbook...
XenDesktop - Design Handbook Your guide to design areas, recommendations and overall architectural best practices for XenDesktop
Contents Overview..................................................................................................... 1 Executive Summary .................................................................................... 1 OS Delivery (Provisioning Services) ........................................................... 1 Device Collections ............................................................................................................................ 1 SQL Database .................................................................................................................................. 2 TFTP ................................................................................................................................................ 2 vDisk Storage Location .................................................................................................................... 3 vDisk Type ....................................................................................................................................... 4 Write Cache Encryption ................................................................................................................... 5 Write Cache Location ....................................................................................................................... 5
Application Delivery (XenApp) .................................................................... 9 Web Interface ................................................................................................................................... 9 Application Integration...................................................................................................................... 9 Application Streaming Cache ......................................................................................................... 11
Desktop Delivery (XenDesktop) ................................................................ 14 Web Interface ................................................................................................................................. 14
Revision History ........................................................................................ 16
Overview The XenDesktop Design Handbook contains a collection of the best practices for designing a XenDesktop solution. The handbook is meant to be used by consultants and architects in the designing of an appropriate XenDesktop solution. This handbook was put together based on the experiences and commitment from the following people: Daniel Feller: Daniel is a Sr. Architect within the Worldwide Consulting Solutions group at Citrix. Daniel has worked with enterprise customers for more than 10 years around application and desktop delivery. Daniel is focused on developing best practices for many solutions like XenDesktop, Provisioning Services for XenApp, XenServer for XenApp, Global Server Load Balancing for XenApp. You can follow Daniel at: o Blog: http://community.citrix.com/blogs/citrite/danielf o Twitter: http://www.twitter.com/djfeller Thomas Berger: Thomas is a Principal Consultant within the Citrix Consulting Central Europe team and is based in Switzerland. He is currently focusing on XenDesktop, Provisioning Services, XenApp and XenServer practices for enterprise customers.
Executive Summary Welcome to the XenDesktop Design Handbook. Virtual desktop delivery is a new enterprise initiative whose goal is to simplify, secure and deliver optimized desktops. Virtual desktops are a major change to the way organizations manage and deliver desktops. The Citrix XenDesktop solution builds a scalable approach for creating, building and delivering virtual desktops through hardware, operating system and application virtualization. These components are merged together to create a personalized desktop environment for each user from standardization. However, in order to create the best XenDesktop environment, requirements, goals and a complete design must be completed. The subsequent sections of the XenDesktop Design Handbook identify the core design considerations and offers options, recommendations and justifications to be used with every XenDesktop design project. With a proper analysis and design, a XenDesktop solution will be manageable, extensible and maintainable. This document focuses on the best practices around desktop delivery and focuses on the following topics:
Operating System Delivery
Virtual Desktop Delivery
The following sections will help identify, define, explain and propose options for each of the core design decisions.
OS Delivery (Provisioning Services) Device Collections The number of defined target devices within a production environment could include thousands of desktops. Trying to remember the purpose, role, configuration of each target device is an impossible task without proper organization. Within the Provisioning Server console, target devices can be grouped into different folders, called device collections. Recommendations To better organize the target devices, it is advantageous to use device collections. Creating a single collection for each vDisk might appear to be the best practice at the outset of a XenDesktop 1
deployment, but it will limit possibilities later on. Initially, a single vDisk will be used for multiple groups of users across many different business units. As time progresses and each business unit has specific requirements, the chances are high that additional target device settings will be required. Also, if a single vDisk image is used for many different business units, that one device collection will contain thousands of target devices. The recommendation is to:
Create a device collection for each business unit.
Create a template target device within each device collection and configure the template target device with the appropriate class, vDisk assignment, personalization settings, etc.
Set the template target device for the device collection. Setting a template for the collection will make all other target devices within the collection take on the same parameters and settings, helping to guarantee consistency within the business unit.
SQL Database With the release of Provisioning Server 5.0 the configuration database has been changed from a JET type database to the more robust Microsoft SQL Server. All editions of Microsoft SQL Server 2005 (even SQL Express, which is included with the Provisioning Server disbursement) are supported, as stated in the Citrix Knowledge Base article CTX114501. Unlike Citrix XenApp implementations, the Provisioning Server configuration database is a highly critical component which needs to be available at all times for serving Target Devices. In case of an outage of the database, existing sessions will continue but new sessions cannot be established. Therefore the SQL database needs to be configured in a fully redundant manner. Further information about how to configure a highly available Microsoft SQL Server environment can be found at the Microsoft TechNet: http://msdn.microsoft.com/en-us/library/ms190202.aspx
TFTP Within Provisioning Server implementations, the Trivial File Transfer Protocol (TFTP) service is used to deliver the Provisioning Server bootstrap. The bootstrap file contains, besides various configuration settings, a list of available Provisioning Services servers within the environment. All information about the location and name of the bootstrap file is delivered by the DHCP Server upon request by the Target Devices through DHCP options 66 (Boot Server Host Name) and 67 (Bootfile Name). Common Options: As the DHCP options required for this task are “single entry” options, which means that only one value per option is allowed, a limited number of high-availability configuration options are possible.
DNS Round Robin: Instead of using an IP address, a fully qualified domain name (FQDN i.e. pvstftp.mycorp.local) can be configured within DHCP option 66. This FQDN can be configured for DNS Round Robin, which means that it contains not a single IP address but a list of multiple IP addresses. In this scenario, all systems corresponding to the IPs configured are used rotationally. The downside is that DNS does not check whether the systems are operational before resolving the FQDN to an IP address. This could result in a situation where one of the two systems is down, which results in 50% of the booting Target Devices failing to receive their bootstrap file. To minimize the impact of an outage, a very short DNS Time-ToLive (TTL) for the FQDN can be configured.
Hardware based Load Balancing (NetScaler): When using hardware based load balancers (i.e. Citrix NetScaler) all load balanced services can be checked for availability and functionality at regular intervals before requests are sent to the service. In the event of an outage of one service, NetScaler will automatically detect and reroute requests to the remaining available services. Instead of configuring DHCP option 66 for a FQDN of a TFTP server, the NetScaler load balanced virtual IP address would be used.
Alternatives to the usage of TFTP and the options 66 & 67 in DHCP are
PXE Service: This service is a default component of all Provisioning Services servers and uses a broadcasting technology similar to DHCP to deliver information about the bootstrap file. In order to serve Target Devices located in different subnets, a DHCP Helper or Proxy DHCP entries (RFC1542, RFC3046) are required.
Boot Device Management Utility: This utility can be leveraged to create an ISO file, which contains the bootstrap and various other configuration settings. The target device can be configured to boot from the ISO that is either burned to a USB drive or a CD-ROM (virtual CDROM if using XenServer).
Notes: Load Balancing Provisioning Server TFTP by means of NetScaler: Load balancing a TFTP service by means of Citrix NetScaler requires certain configuration steps to be completed, as outlined within the knowledge base article CTX11337 - How to Load Balance TFTP Servers. An important aspect of this configuration is defining the default gateway IP address on the TFTP server to the IP address of the NetScaler MIP or SNIP. This will route all communication between the TFTP server and the TFTP clients through the NetScaler. Within a default Provisioning Services environment, the TFTP service is hosted on the Provisioning Services server. This would result in vDisk delivery to be handled by the NetScalers as well. To prevent the additional network hop, to reduce the network load on the NetScaler and to minimize the complexity of a Provisioning Server environment, a standalone TFTP server can be used.
vDisk Storage Location Each Provisioning Server within the farm must access the appropriate vDisk and stream portions of the vDisk to the target devices as needed. The location of the vDisk will have an impact on Provisioning Server functionality and speed. Common Options: There are essentially two different options for the vDisk storage location, but both options will have an impact on items like Provisioning Server high-availability.
Shared Storage o
The shared storage option uses an enterprise storage solution to host the vDisk images. The shared storage solution should have ample storage to host as many vDisk images as needed for the organization. Also, the enterprise storage solution is optimized for file hosting, which will help improve speed of delivery. However, using shared storage requires the Provisioning Server streaming service to cross the network to get to the vDisk. This might take extra time and resources as opposed to the local storage option.
Using the shared storage solution makes the setup and maintenance of Provisioning Server high-availability easy. Each Provisioning Server within the farm will be configured to use the same shared storage device. Because each server can get to the vDisk, all servers can participate in high-availability.
Using shared storage guarantees that each Provisioning Server is using the correct vDisk image, as each server is looking at the same location.
Local Storage: o
Setting up a local storage solution for Provisioning Server is the easiest and least expensive option. Essentially, all vDisks that the Provisioning Server will deliver are stored on the local disks of the Provisioning Server. Provisioning Server's streaming service will access each vDisk and deliver the appropriate portions of the vDisk to the target devices. 3
Although at first glance it may appear that shared storage is required for Provisioning Server high-availability, this is not the case. Each Provisioning Server within the farm must be able to get to the vDisks via the same path. If the vDisks are copied to each Provisioning Server and placed in the same local path, high-availability will be possible.
Recommendations: To help keep costs in check, the best option for vDisk storage location is Local Storage
Each Provisioning Server will have ample storage space that should not be wasted.
Using local storage will provide adequate speed and still allow for the high-availability option.
Processes must be put in place that guarantees the vDisks on each Provisioning Server are in sync with each other.
vDisk Type Provisioning Server allows for the delivery of a vDisk in three different modes: Private, Standard and Differential. Each option has benefits and consequences to the larger XenDesktop solution. Common Options:
Private Image: The first vDisk type is Private Image vDisk, where each target device will have its own vDisk. The vDisk is configured in a read/write fashion, where all changes are stored within the vDisk for future use. o
Support of the vDisk will become increasingly difficult as each vDisk will take on a completely different personality based on user behavior.
Private images are a one-to-one relationship with users, which can require an extensive amount of disk space.
Standard Image: The second vDisk type is a Standard Image vDisk, where multiple devices share the same base vDisk image. The vDisk is a read-only and target device changes are stored in a write cache file. Upon reboot of the target device, the write cache is destroyed, resulting in the target device starting with the same base image time-after-time. o
Complete personalization of the environment because all changes are stored, but at a cost of storage and support.
Server revert back to a consistent, optimized and approved state after each reboot
Storage requirements are reduced as the write cache is reset after each reboot
Any user-installed application is discarded, resulting in potential user frustration if important updates are not part of the base vDisk image or delivered via XenApp.
Any application or system-level automatic updates will start after each reboot, unless this functionality is disabled at the OS and application level.
Differential Image: The third vDisk type is a Differential Image vDisk, where multiple devices share the same base vDisk image. The vDisk is read-only and the target device changes are
stored in a differential cache file. Upon reboot of the target device, the differential cache is kept and reused by the target device after reboot. o
Allows for greater levels of system personalization by not discarding changes upon subsequent reboots.
Once the base vDisk is modified, the differential image is destroyed and the user must rebuild their personality into the target device. This will cause confusion.
XenDesktop 3.0 does not support Differential Images.
Recommendations: For the majority of XenDesktop use cases, a Standard image is the recommended approach. The standard image simplifies maintenance and maintainability of the images as well as uses the least amount of disk space. It is imperative that a proper application analysis is completed to identify all user-required applications. There should also be a process in place to allow users to request new applications into the environment. Even though the Standard Image is the best approach for most XenDesktop implementations, there will be a few use cases where a Private Image is needed. This will most likely result in a small set of users who have such unique and changing requirements that it is easier to create private images with the acknowledgement that maintenance of the image will require additional time. Critical Notes: In XenDesktop 3.0, Differential Image is not supported even though they appear to function properly.
Write Cache Encryption The data stream (along with the write cache) can be encrypted to provide additional security. Common Options:
Recommendations: Unless security guidelines require data to be encrypted, this should not be enabled as it adds extra load to the Provisioning Services processors.
Write Cache Location Using a standard vDisk image (read-only) allows many desktops or servers to utilize the same vDisk image at the same time. Because the vDisk is read-only, the aggregate of these changes are stored in a write cache. The write cache contains anything that has changed during the time between target device reboots. Each target device has its own write cache. Depending on what the target device is doing and how the environment is configured, the write cache could grow quite large. For instance, starting the target device adds to the write cache. If an application is streamed onto the target device, the streamed application profile will also increase the size of the write cache The size of the cache file for each target device depends on several factors, including types of applications used, user workflow, and reboot frequency. A general estimate of the file cache size for a provisioned workstation running only text-based applications such as Microsoft Word and Outlook that gets rebooted daily is about 300-500MB. If workstations are rebooted less often than this, or graphic intensive applications (such as Microsoft PowerPoint, Visual Studio, or CAD/CAM type applications) 5
are used, cache file sizes can grow much larger. This estimate is based on past experience and may not accurately reflect each environment. Citrix recommends each organization perform an analysis to determine the expected cache file size in their environment. Provisioning Server allows for numerous locations to store the write cache, each brining benefits on considerations. The options are:
Target Device – RAM
Target Device – Local Storage
Target Device – Shared Storage
Provisioning Server – Local Storage
Provisioning Server – Shared Storage
Common Options: Target Device – RAM
Definition: The first option for write cache storage location is the target device’s RAM. A portion of the target device’s RAM is set aside and used for the write cache.
Benefits: The main benefit for using the target device’s RAM is it provides the fastest type of write cache.
o A portion of the RAM cannot be used for the target device workload. RAM is often better used for the operating system and applications than for write cache. Plus, using RAM to support the write cache is more expensive than using storage.
o Part of the challenge with using RAM as the write cache storage is determining the amount of RAM required. Provisioning Server can set aside a certain portion of RAM for the write cache, but what happens when the RAM runs out? The write cache is critical to the stable functioning of a provisioned target device. When available write cache is exhausted, the target device can no longer make changes, which results in a target device failure. If the write cache size is not estimated correctly, using a target device’s RAM might pose detrimental to the stability of the environment. Target Device – Local Storage
Definition: The second option for write cache storage location is the target device’s local storage. This storage could be the physical disk drives on the physical server, or it could be the virtual disk on a virtual server
o This solution does not require additional resources, in that most physical target devices being purchased already have local disks installed, which often go unused in Provisioning Server environments. .
o Although target device local storage is not as fast as RAM, it still provides fast response times because the read/write to/from the write cache is local, meaning that the requests do not have to cross the network.
o Trying to estimate the size of the write cache is difficult and if done incorrectly, can result in target device failure. However, local storage typically provides more than enough space for the write cache, without requiring the administrator to estimate space requirements.
o This option provides added resiliency in the event of a failure since only a single target device will be affected if the local disk associated with the system should run out of space.
o If the target device is virtualized, using local storage will prevent live migration processes from succeeding because the storage is not shared across virtual infrastructure servers, like XenServer. Target Device – Shared Storage
Definition: The third option for write cache storage location is on a shared storage device attached to the target device. This solution is usually only valid for environments virtualizing the target device with a solution like Citrix XenServer. This storage is assigned to each virtual machine from a shared storage repository.
o Although target device shared storage is not as fast as RAM or target device local storage, it still provides fast response times. If the shared storage infrastructure is a SAN or NAS, the reads/writes will still perform adequately because the optimized shared storage infrastructure will help overcome the time added for traversing the network.
o Although the configuration of this solution requires the identification of the shared storage size, the costs associated with over-estimating are not nearly as detrimental as overestimating with RAM. Storage costs are significantly cheaper than RAM so a sizeable buffer over the space estimates is of little concern.
o Because the target device’s storage is accessible from multiple virtual machines, virtual machine live migration, like XenMotion, is viable.
o This solution requires the setup and configuration of a shared storage solution. Although if XenServer is already being utilized, the same shared storage solution can be used for the write cache storage. Provisioning Server – Local Storage
Definition: The fourth option for write cache storage location is on the Provisioning Server’s local storage. This storage uses the physical disks installed within the Provisioning Server.
o This solution is extremely easy to setup and requires no additional resources or configuration within the environment.
o Requests to/from the write cache must cross the network and be serviced by the Provisioning Server streaming service. Because the write cache is on the network, servicing write cache requests will be slower than the previously mentioned options.
o The streaming service is responsible for sending the appropriate parts of the vDisk to all target devices. Having the write cache on the Provisioning Server will negatively impact the server’s scalability because the streaming service must also service the write cache requests.
o Provisioning Server includes a high-availability option, but in order for this solution to function, all Provisioning Servers must have access to the vDisk and the target 7
device’s write cache. When the write cache is stored on one Provisioning Server’s local storage, this makes it impossible for other Provisioning Servers to gain access, thus denying the ability to enable Provisioning Server high-availability.
o Although disk space is fairly inexpensive, chances are the Provisioning Server does not have an extensive supply of storage space. With each Provisioning Server supporting a few hundred target devices, it is quite possible the total write cache could exceed hundreds of gigabytes of storage space. This could result in exhausting all local storage on the Provisioning Server causing a server failure. Provisioning Server – Shared Storage
Definition: The fifth option for write cache storage location is on the Provisioning Server’s shared storage. This option utilizes a share storage solution that is connected to the Provisioning Server.
o The shared storage solution allows for Provisioning Server high-availability as each Provisioning Server can access the vDisks and the write cache.
o Size concerns are mitigated because shared storage devices typically contain significant amounts of storage and can be expanded easily.
o This is one of the slowest solutions because requests to/from the write cache must cross the network and be serviced by the Provisioning Server streaming service. The Provisioning Server must then forward the write cache requests onto the shared storage, thus resulting in two network hops for the write cache.
o Provisioning Server scalability is impacted as the streaming service is responsible for handling Provisioning Server write cache requests and forwarding them onto the shared storage. The solution requires the installation and configuration of a shared storage solution into the environment. If one is already present, then this concern is mitigated. Recommendations: Selecting the right place for the target device's write cache should be based on expectations.
Fast: To give users a local desktop feel, the virtual desktop should operate as efficiently as possible. This means the write cache should be fast.
Dynamic: Each user has different needs, which will greatly impact the size of the write cache between virtual desktops. The write cache solution must be able to function with a wide array of possibilities.
Available: Disruptions in the delivery of a virtual desktop will cause user frustration. Organizations will want to select a write cache option that does not impact high availability options that are designed to protect users from impending disruptions.
Based on the aforementioned criteria and the explanation of the different options for the write cache, virtual desktops delivered with Provisioning Server are best suited for Target Device - Shared Storage. The virtual desktops will be on a virtualization infrastructure, like XenServer. In order to provide XenMotion capabilities, defined storage must be shared storage.
Application Delivery (XenApp) Web Interface The Web Interface component of XenApp focuses specifically on the Web Interface site that will be used to deliver resources to the Citrix Receiver embedded within the virtual desktop. This site will be the only method users will have to get to their applications, whether they are hosted or streamed. Recommendations
Authentication: To provide simplicity and speed, the Web Interface site used to deliver applications to the virtual desktop should be configured for Pass-Through authentication. Users will have already entered their credentials before getting into their virtual desktop. Those credentials were passed to the virtual desktop and will be passed again to the XenApp Web Interface site to automatically get the application list. Providing pass-through authentication reduces the number of times a user has to enter credentials, while still customizing the environment based on the user.
Encryption: The Web Interface site should be encrypted with an SSL certificate to protect the transfer of user credentials. The certificate can be from an enterprise certificate server to help save money, but the enterprise root certificate must be installed into the virtual desktop.
Application Integration Separating the application-layer from the operating system-layer allows for a fewer numbers of unique desktops images, as most organizations will have one or two base operating system images. Applications will then be added on top of the operating system based on the current user's identity and rights. This design decision focuses on the ways applications can be integrated and thereby selecting the best approach based on the application in question. Common Options:
Installed: Applications installed into the operating system are part of the base virtual disk image. Every user that uses this particular virtual desktop image will receive the application.
Streamed: Streamed applications are only available to users that have been granted rights. When the application is selected, the bits are sent across the network to the virtual desktop and executed within the isolation environment.
Hosted: Hosted applications are only available to users that have been granted rights to run the application. Users who do not have access will not see the respective application icon. Upon launching the application, all execution occurs on a remote XenApp server.
Recommendations: The approach selected should be based on the type of application.
Base Applications: o
Description: Common applications all users require.
Example: Microsoft Office (Word, Excel, PowerPoint, Outlook) and Instant Messenger
Anomalous Applications: o
Description: Home-grown applications, potentially not following standard application development standards, which might pose issues in a Terminal Services environment.
Resource Intensive Applications: o
Description: Require heavy system resources to perform adequately
Example: CAD/CAM, data processing 9
Technically Challenging Applications: o
Description: Windows applications with significant backend database communication, many moving parts, and strict configuration guidelines.
Example: Electronic Medical Records or Enterprise Resource Planning
This is not a one-size-fits-all model. The following are general recommendations based on the application-type:
Base Applications: Install
Anomalous Applications: Stream
Resource intensive Applications: Stream
Technically Challenging Applications: Host
Base Applications: Installing the base applications within the virtual desktop operating system image recommended. Because application streaming adds another layer to application delivery, utilization will be slightly elevated with the streaming process. Also, base applications are typically dependencies for other applications which require more complex configurations if streamed. Installing the base applications into the vDisk keeps the environment simple. Many base applications have their own automated updated processes that can be invoked each time the vDisk is updated.
Anomalous Applications: Many times, these types of applications are not written as terminal services aware applications, so hosting them on XenApp could prove challenging. Also, as only a few users typically use anomalous applications, having them installed as part of the base image would mean all users receive the application, which is not an optimal solution.
Resource Intensive Applications: These applications are oftentimes recommended to be streamed to the virtual desktop. If these applications are hosted on XenApp, a small number of users would consume the entire XenApp server. However, if the applications are delivered to the virtual desktop, then the XenServer hypervisor would only allow a user to consume their allocated resources, thus limiting the impact to other users.
Technically Challenging Applications: These applications typically have unique configuration and dependencies. Because XenApp is a more tightly-controlled environment than a virtual desktop, an organization will be better able to guarantee the application is setup properly and always functions in a XenApp hosted application delivery model.
Base Applications: By streaming base applications, the applications will be managed and stored in the same place as other streamed applications. When an update is required for these applications, it will follow the same update process. If the base applications are installed as part of the virtual desktop image, then application updates will require an update to the virtual desktop image.
Anomalous Applications: Sometimes the home-grown applications are built in a certain way that results in a failure to stream. In these circumstances, the application should be delivered through the hosting model, if possible.
The following table provides a quick summary for the application integration design consideration. Base Anomalous Resource Technically Applications Applications Intensive Challenging Applications Applications Description Common applications Home-grown Heavy system Large, complex all users require
applications Unique with potentially
applications with many moving parts and
Resource Intensive Applications
limited terminal services support
Microsoft Office (Word, Excel, PowerPoint, Outlook), Adobe Acrobat
Want lowest amount of overhead for most common applications
Simplifies configuration as other streamed applications will require access
Technically Challenging Applications dependencies
CAD/CAM, data processing
Epic, Cerner, SAP
Need granularity in determining who can use the application
Does not require the application to be terminal services aware
Allows hypervisor to limit amount of resources the application can consume
Provides granularity in determining who can use the application
XenApp creates a highly-controlled operating environment for the complexity of the applications
Provides the best scalability for application delivery
Common applications have automated update processes that can be executed when vDisk is updated.
Managed same way as other streamed apps
Updates made using the application update process instead of desktop update process
Application might not stream correctly
Critical Notes: None at this time.
Application Streaming Cache One option for delivering an application to the virtual desktop is through the use of XenApp application streaming. Because the streamed application is not installed on the target device's vDisk, part of the application is sent to the target device over the network as needed. The files are stored within the application cache on the target device. Because the target device will most likely be delivered with Provisioning Server, the application cache will directly impact the Provisioning Server write cache. Each streamed application will incur numerous changes to the vDisk, which will be stored in the write cache. This brings about two potential concerns:
Write cache size
This potential concern can be mitigated by pre-deploying streamed applications into the vDisk. This option brings about its own concerns that must be assessed before the correct option is selected. Common Options: The first option is in the default configuration with no pre-deployment. This type of architecture looks like the following:
Swap & Temp File Write Cache
Provisioned XenApp Server Decompressed App Streaming Cache App CAB files
Figure 1: No Pre-Deployment When a streamed application is launched on a virtual desktop, whose image is delivered from a standard image vDisk, the launch request will start to receive the application profile. Even though the entire application might be 500MB in size, only the portion needed to start the application is sent to the virtual desktop. The first thing that happens is that a portion of the application is delivered over the network. This will delay the start time of the application until enough of the application stream is delivered. As the application is streamed, the write cache will continue to grow because the stream contains new files and settings that cannot be stored in a standard image vDisk. The stream will first contain the .CAB files, which are compressed files from the application profile. This will increase the size of the write cache. Before the files can be used, they must be decompressed, which increases the write cache size even more. As the user continues to access more functionality within the application, more files are delivered to the target device, continuously increasing the size of the write cache. No Pre-Deploy Considerations: By not having the streamed applications part of the vDisk image, updating an application profile does not mean that the vDisk image must also be updated. This helps keep the process simplified, especially as many organizations will have one group manage application profiles and another group manage the vDisk images. To overcome some of these challenges, streamed applications can be Pre-Deployed into the vDisk, as shown in the following figure:
Swap & Temp File Write Cache
Provisioned XenApp Server Decompressed App Streaming Cache
Figure 2: Pre-Deployment During the vDisk build process, streamed applications are pre-deployed within the vDisk image. Even though the streamed application is part of the vDisk, users must still launch the application through the Citrix Receiver, just like with streamed applications that are not pre-deployed. When a user tries to launch a streamed application from the Receiver, the Receiver will validate that the local streamed files are current and launch accordingly. There is less delay in application launch because the files are local and do not have to cross the network, although launch time is still slower than installed applications. Also, as changes are not occurring on the target device, the write cache size is kept to a minimum. Pre-Deploy Considerations: When updates are made to the application profile, the pre-deployed cache also requires updates to keep it in line with the central application profile. If the cache is out-ofdate, the application launch process will update the application profile as needed. Recommendations: Performance is one of the biggest factors in user acceptance. If it takes a noticeable amount of time to launch applications every day, user acceptance for the environment will wane. Because of the performance aspect, pre-deploying applications is the preferred method. However, this recommendation does not mean that all applications should be pre-deployed. The following should be taken into consideration: Pre-deploy
Applications that are used everyday should be pre-deployed because these are the applications users always access and startup delays will cause frustration. Also, because these applications are always used, there will be a constant hit on the network and write cache every day.
Applications that are highly-utilized and undergo semi-frequent, small updates should be predeployed. Just like before, because the application is used often, the performance benefits of pre-deployment is of value to the user. However, just because the application undergoes updates does not necessarily mean that the application cache on vDisk must be updated. If the application update is minor (a hot fix that changes a few files), letting the application streaming update process update the new files will not impact startup time. However, if the update is major, like a service pack for an application, then it would be advantageous to update the application cache on the vDisk.
Do Not Pre-Deploy
Applications that undergo constant large updates should not be included in the predeployment of the application profile. Due to the update frequency and the size of each update, the required updates to the cached application would negate any advantages incurred with pre-deployment.
Applications whose usage is sporadic should not be included in the pre-deployment. Requiring a user to wait a little longer for an application only used from time-to-time will not be as noticeable as everyday applications.
Desktop Delivery (XenDesktop) Web Interface Web Interface is the access point for users to gain access to their desktops or applications. From one web page, users can see links for applications, desktops or both. Users will navigate to Web Interface to launch a virtual desktop or an application. If the user launches a desktop, the Citrix Receiver, installed within the virtual desktop, will automatically connect to the XenApp Services site to pull the same set of applications for use within the virtual desktop. However, will having both applications and desktops within the same console cause issues for users and the environment? Common Options: There are essentially two options, but there are several considerations to take into account before making a decision.
Single Site: The single site option is to use a single Web Interface site for both applications and desktops. This solution provides a completely integrated solution that allows the users to decide if they want a full-blown desktop or just need an application. However, this single site solution might pose confusing if a user selects another virtual desktop and from within their virtual desktop session.
Multiple Sites: The multiple site option uses two different Web Interface sites: one site for desktops and the other site for applications. Users would connect to the desktop site and be presented with their virtual desktop. Upon connection to their virtual desktop, the Citrix Receiver will automatically receive the available applications from the Web Interface site for applications.
Recommendations: The recommendation is based solely on the customer's requirements as both options are valid, but in many situations, a multiple site design will be implemented like the following:
Site 1: The first site will include both applications and desktops. This solution gives the users o
Flexibility: Users can choose if they need a virtual desktop or just an application. This empowers the users to create the environment most optimal for their current work scenario.
Simplicity: With a single site for desktops and applications, every user, regardless if they have access to a virtual desktop or not, will use the same URL. If the site only delivered applications or desktops, then different sets of users would be required to remember different addresses, which will add to confusion.
Site 2: The second site will only include applications. This site will be used by the Citrix Receiver installed within the virtual desktop to automatically enumerate applications on behalf of the user. The second site will help reduce confusion for virtual desktop users because the second site only contains applications. There is no risk of a user starting a virtual desktop from within a virtual desktop.
If a single site design is used, there is a potential issue if workspace control is also enabled. Workspace control will move a user's session to the current target device simply by logging into Web Interface. When a user launches a virtual desktop, the Citrix Receiver will automatically start and authenticate to Web Interface. The Receiver will kick off a workspace control trigger that will move the user's connection to the virtual desktop from their target device to the new target device, which is the virtual desktop. In essence, the user's connection to the virtual desktop will be broken. This potential issue can be overcome by using a multiple site design.
Revision History Revision 1.0
Change Description Initial document created
Updated By Daniel Feller – Sr. Architect Thomas Berger – Principal Consultant
Date March 30, 2009
Citrix Worldwide Worldwide headquarters Citrix Systems, Inc. 851 West Cypress Creek Road Fort Lauderdale, FL 33309 USA T +1 800 393 1888 T +1 954 267 3000 Regional headquarters Americas Citrix Silicon Valley 4988 Great America Parkway Santa Clara, CA 95054 USA T +1 408 790 8000 Europe Citrix Systems International GmbH Rheinweg 9 8200 Schaffhausen Switzerland T +41 52 635 7700 Asia Pacific Citrix Systems Hong Kong Ltd. Suite 3201, 32nd Floor One International Finance Centre 1 Harbour View Street Central Hong Kong T +852 2100 5000 Citrix Online division 6500 Hollister Avenue Goleta, CA 93117 USA T +1 805 690 6400 www.citrix.com
About Citrix Citrix Systems, Inc. (Nasdaq:CTXS) is the global leader and the most trusted name in application delivery infrastructure. More than 215,000 organizations worldwide rely on Citrix to deliver any application to users anywhere with the best performance, highest security and lowest cost. Citrix customers include 100% of the Fortune 100 companies and 99% of the Fortune Global 500, as well as hundreds of thousands of small businesses and prosumers. Citrix has approximately 8,000 channel and alliance partners in more than 100 countries. Annual revenue in 2008 was 1.6 billion. ©2009 Citrix Systems, Inc. All rights reserved. Citrix®, Citrix XenApp™, Citrix XenServer™ are trademarks of Citrix Systems, Inc. and/or one or more of Its subsidiaries, and may be registered in the United States Patent and Trademark Office and In other countries. Microsoft® and Windows® are registered trademarks of Microsoft Corporation in the United States and/or other countries. UNIX® is a registered trademark of The Open Group in the United States and other countries. All other trademarks and registered trademarks are property of their respective owners.