White Paper

Citrix Consulting

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
 Application 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-To-
Live (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

2
 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 CD-
ROM 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.
o 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.
o 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
 o 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 Benefits:
 Complete personalization of the environment because all changes are stored,
but at a cost of storage and support.
o Considerations:
 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 Benefits:
 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
o Considerations:
 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

4
 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 Benefits:
 Allows for greater levels of system personalization by not discarding changes
upon subsequent reboots.
o Considerations:
 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:

 Normal

 Encrypted
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.

 Concerns
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

 Benefits:
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.

6
 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.

 Concerns:
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.

 Benefits:
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.

 Concerns:
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.

 Benefits:
o This solution is extremely easy to setup and requires no additional resources or
configuration within the environment.

 Concerns:
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.

 Benefits:
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.

 Concerns:
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.

8
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.
o 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
o 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.
o 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
Justification
 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.
Alternatives
 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 requirements applications with many
Unique with potentially moving parts and

10
 Base Anomalous Resource Technically
Applications Applications Intensive Challenging
Applications Applications
limited terminal dependencies
services support
Examples Microsoft Office (Word, CAD/CAM, data Epic, Cerner, SAP
Excel, PowerPoint, processing
Outlook), Adobe
Acrobat
Primary Install Stream Stream Host
Recommendation  Want lowest  Need granularity  Allows hypervisor  XenApp creates a
amount of in determining to limit amount of highly-controlled
overhead for most who can use the resources the operating
common application application can environment for
applications  Does not require consume the complexity of
 Simplifies the application to  Provides the applications
configuration as be terminal granularity in  Provides the best
other streamed services aware determining who scalability for
applications will can use the application
require access application delivery
 Common
applications have
automated update
processes that
can be executed
when vDisk is
updated.
Secondary Stream Host
Recommendation  Managed same  Application might
way as other not stream
streamed apps correctly
 Updates made
using the
application update
process instead of
desktop update
process

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:
 Network usage
 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:

11
 Swap &
Temp File
Provisioning
Write Cache Server vDisk Storage

Provisioned
XenApp Server

Decompressed App
Streaming Cache

App CAB
files

XenApp Application Hub

Hosts

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:

12
 Swap &
Temp File
Provisioning
Write Cache Server vDisk Storage

Provisioned
XenApp Server

Decompressed App
Streaming Cache

XenApp Application Hub

Hosts

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-of-
date, 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 pre-
deployed. 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

13
  Applications that undergo constant large updates should not be included in the pre-
deployment 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.
o 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.
Critical Notes:

14
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.

15
Revision History
Revision Change Description Updated By Date
1.0 Initial document created Daniel Feller – Sr. Architect March 30, 2009
Thomas Berger – Principal Consultant

16
 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.

PDF-code Date

17